Table Of ContentA Planner for Composing Services Described in DAML-S
Mithun Sheshagiri⁄, Marie desJardins, Timothy Finin
Computer Science and Electrical Engineering
University of Maryland Baltimore County
Baltimore MD 21250 USA
Abstract Ourexperiencewithbuildingthisplannerrevealedcer-
taindesirablepropertiesofservicedescriptionsthatwill
A web service is a web-accessible piece of soft-
make composition for a planner easier. We also stress
ware or hardware. In recent years, industry has
the importance of developing ontologies that can cap-
been showing increasing interest in web services
ture relationships between services, which are crucial
as a technology for building distributed web ap-
plications. However, web services as a technol- for composition.
ogy lacks in several departments. Representa-
tionsfordescribingwebserviceshavebeenwidely Related Work
investigated by industry and academia. Service
SWORD (Ponnekanti & Fox 2002) is a model for web
composition-that is, automated methods for con-
service composition. However, it uses its own simple
structing a sequence of web services to achieve
descriptionlanguageanddoesnotsupportanyexisting
a desired result- has been relatively neglected.
We present in this paper, a planner that com- standardslikeWSDLorDAML-S.Servicesaremodeled
posesatomic/basicservicesdescribedinDAML-S using inputs and outputs, which are specifled using an
(Ankolenkar et al. 2002) into a composite ser- Entity Relationship model. Inputs are classifled into
vice. We discuss issues involved with the design conditional inputs and data inputs. Outputs are clas-
ofplannersforcomposition. Wealsoproposeaset sifled similarly. Conditional inputs/outputs are asser-
ofguidelinesfordescribingservicesthatfacilitates tions about entities on which the service operates and
composition.
therelationshipsbetweenentities. Datainputs/outputs
constitute the actual data (attributes of entities) that
Introduction the service uses.
The focus of (Thakkar et al. 2002) is primarily on
Web services are a relatively new paradigm for build-
information discovery, extraction and integration and
ingdistributedwebapplications. Inspiteofkeeninter-
does not deal speciflcally with web services or auto-
estshownbyindustryinwebservices,severalobstacles
maticcomposition. Thissystemhasbeenbeendesigned
have prevented companies from efiectively harnessing
to work with a speciflc set of services; our system is
web service technology to build web applications. One
designed to be a generic service composer. This sys-
obstacleisthelackofasetoftoolsthatwouldallowde-
tem describes a forward-chaining composer, specialized
velopers(orintelligentagents)todescribe,discoverand
to information integration queries; our system uses a
composewebservices. WSDL (Christensenetal. 2001)
backward-chainingplannerandweplantobuildamore
is a popular XML-based language for describing web
general partial-order planner. Like (Ponnekanti & Fox
services,butitdoesnotcapturesemantics. DAML-Sis
2002), they have their own model for describing web
an application of DAML+OIL (dam 2001) that can be
services; we speciflcally deal with services described in
usedforsemanticdescriptionofwebservices. DAML-S
DAML-S.
consistsofasetofontologiesthatprovideavocabulary
A similar framework is being developed at IBM Re-
to describe services. The use of semantics enables in-
searchLaboratoriesaspartoftheWebServicesToolkit
ference about the requirements and efiects of services,
(WSTK) (wst 2000). A composition engine (Sri-
which in turn facilitates automatic discovery and rea-
vastava 2002) has been built for services described in
soning. WehavebuiltaplannerthatusesSTRIPS-style
WSDL. Although (Srivastava 2002) describes the use
services to compose a plan, given the goal and a set of
of a planner for composition, constructing operators
basic services. We have used the Java Expert Shell
from the service description is not fully automated.
System(JESS) (Friedman-Hill2002)toimplementthe
This is primarily because of the absence of a mech-
plannerandasetofJESSrulesthattranslateDAML-S
anism to capture domain knowledge in WSDL. Our
descriptions of atomic services into planning operators.
planner makes use of services described in DAML-S.
⁄Mithun Sheshagiri is a graduate student at UMBC DAML+OIL helps us to describe explicit ontologies
for capturing domain language. This added knowledge defqueries in JESS) that transform services encoded as
gives our planner greater versatility and helps compose VSOtriplesintoasetoffactsthatformtheplanningop-
complex services. erator. The planning operators are similar to STRIPS
Golog has been used for service composition (McIl- planning operators and consist of a service name, in-
raith & Son 2002) by constructing general templates puts, preconditions, outputs and efiects.
thatarethenmodifledbasedonuserpreferences,yield-
We characterize inputs and preconditions (IPs) into
ing a composite plan. The templates are not automat-
two types: external IPs and internal IPs. External
ically built and constitute part of the plan. Our ap-
IPs are IPs that are provided directly by the agent or
proach is able to build plans dynamically from scratch
satisfled externally and are not generated as efiects or
and does not rely on templates for composition.
outputs of other operators. Internal IPs, on the other
hand, can be provided or satisfled only by other oper-
Service Description Using DAML-S
ators/services. For example, the user provides his/her
DAML-S uses DAML+OIL to describe a set of ontolo- contactinformationthroughsomeinterface. Therefore,
gies for characterizing web services. DAML-S (dam this information is an external IP. Suppose that there
2002) describes the following ontologies: is an operator that produces the efiect ProfllePresent
1. A Service ontology that forms the topmost part of a when user fllls in his/her proflle information. In this
case, ProfllePresent is an internally generated efiect;
hierarchy of services.
therefore it is an internal IP if used as a precondition
2. A Service \presents" a ServiceProflle. The Service-
by another operator.
Proflle is typically used for advertising and discover-
Outputs and efiects as deflned by DAML-S specifl-
ing the service.
cations can be conditional: that is, depending on the
3. AService \isDescribedBy"a ServiceModel. TheSer-
current state of the world, the efiect or output of a
viceModel contains information required for com-
service can be difierent. It is not necessary for a com-
position: inputs, outputs, preconditions and efiects
poser to represent the control structure for conditional
(IOPEs). A ProcessModel is a type of ServiceModel.
efiectsandoutputs;merelyenumeratingthemasmulti-
4. A Service \supports" a ServiceGrounding. Service- ple efiects or outputs is su–cient for composition. The
Grounding provideslow-leveldetailslikecommunica- DAML-S website includes a sample book-buying do-
tionprotocols(e.g.,RPC,SOAP),portsanddescrip- main called congo.com, which includes service descrip-
tionsofdatastructuresexchanged. Thisinformation tionsandontologiesassociatedwiththedomain. Figure
is used by a web service execution engine to actually 1 shows an example of a service from this domain that
invoke services. creates an account:
The manner in which DAML-S is used is slightly un-
usual. Typically when using DAML+OIL, a schema or
ontology is designed and concepts (classes and proper-
ties) deflned in this schema are instantiated as a next
step. DAML-Susesanintermediatestepwhereservices
aredescribedasnewschemasandnotinstantiated. The
actual instantiation of services is done only during run
time. This is analogous to writing procedures which
form the service descriptions and a call to these pro-
cedures creates an instance of this procedure (Martin
2001). An atomic service is a directly invocable ser-
vice that executes in a single step. An atomic service
consists of inputs, preconditions, efiects and outputs.
These are deflned as properties in DAML-S speciflca-
tions.
Planner
The Service model describes the service and consists of
inputs, preconditions, outputs and efiects of services.
The flrst step in planning a service composition con-
sists of converting DAML-S ServiceModel descriptions
of services into Verb-Subject-Object(VSO) triples. All
VSO triples corresponding to the services are asserted
into the JESS KB as facts.
The next step involves building planning operators
that correspond to each of the atomic services. We Figure 1: CreateAcct Service described in
have written a set of rules and queries (defrules and DAML-S
The equivalent planning operator of the service (sname Login)
described in Figure 1 is the following set of facts: (input Login UserName)
(output Login UserType)
(sname http://www.csee.umbc.edu/mits1/daml/modCongoProcess.daml#CreateAcct)
(precon http://www.csee.umbc.edu/mits1/daml/modCongoProcess.daml#CreateAcct
(sname GetInfo)
nil)
(input GetInfo UserType)
(input http://www.csee.umbc.edu/mits1/daml/modCongoProcess.daml#CreateAcct
(effect GetInfo ProfileExists)
http://www.csee.umbc.edu/mits1/daml/modCongoProcess.daml#createAcctInfo)
(effect GetInfo ProfileDoesNotExist)
(effect http://www.csee.umbc.edu/mits1/daml/modCongoProcess.daml#CreateAcct
nil)
(sname QueryUser)
(output http://www.csee.umbc.edu/mits1/daml/modCongoProcess.daml#CreateAcct
(precon QueryUser ProfileDoesNotExist)
http://www.csee.umbc.edu/mits1/daml/modCongoProcess.daml#createAcctOutput)
(output QueryUser AskUser)
Since the output is unconditional in the above case,
we just have a single output. Now consider an example (sname BookLookUp)
of a service which produces an efiect BookPresent if (input BookLookUp BookName)
BookInStock is true or BookAbsent if BookInStock is (output BookLookUp ISBN)
false. The equivalent planning operator will have the (output BookLookUp BookInStock)
following efiects as follows. (output BookLookUp BookOutOfStock)
(sname foo) (sname PutInCart)
(input foo BookName) (input PutInCart ISBN)
--- (precon PutInCart ProfileExists)
(effect foo BookPresent) (precon PutInCart BookInStock)
(effect foo BookAbsent) (effect PutInCart InCart)
AlthoughtheservicedescriptionexposestheBookIn- (sname CreditCard)
Stock condition, its \value" is decided by the input (input CreditCard CardType)
BookName and therefore not known in advance. Such (input CreditCard CardNum)
services are therefore non-deterministic. The planning (input CreditCard CardExpiryDate)
operators for these services show both efiects. The (effect CreditCard Approved)
actual efiect cannot be ascertained till execution (effect CreditCard NotApproved)
time. We assume the that the efiect produced during
execution is the one desired by us. We plan a thorough (sname ShipItem)
treatment of this issue in our next version. In cases (precon ShipItem InCart)
where the value of the condition is known in advance, (precon ShipItem Approved)
the planning operators are built using a technique (effect ShipItem BookShipped)
similartothe\when"clausedescribedin (Weld1994). (output ShipItem InformUser)
The approach for conditional ouputs is similar.
The goal we specify to start composition is Book-
(sname S1) Shipped. Figure 2 shows the plan generated by the
-- planner. The light gray rectangles represent external
(condeffect S1 CE1) IPs-that is, information that must be provided by the
(CE1 FLAGA E1) user or some external source such as database. The
(CE1 FLAGB E2) //FLAGA = (:FLAGB) dark rectangles request internal IPs-that is, precondi-
tions that are satisfled by efiects of services. The el-
The planner applies the following two steps repeat- lipses represent atomic services to be executed. The
edly until none of the services satisfy any of the goals. structure of the plan imposes a partial ordering on the
execution of the services. For example, Login must be
1. Findservicesthatsatisfyexistinggoalandstorethem
executed before GetInfo, but either of these steps can
(add them to the plan).
be executed in parallel with BookLookUp.
2. Converttheinputsandpreconditionsofalltheoper-
ators stored in step 1 into new set of goals. Describing Services for Composition
Composition is successful if all outstanding goals are Currentspeciflcationspermitthedescriptionofservices
external IPs. We have developed a set of atomic without efiects or outputs. We claim that it is di–cult
services that are similar to the set of services described to compose services without efiects or outputs. A web
for congo.com. The equivalent planning operators are service either provides information (has outputs) or al-
shown below. For the sake of readability complete ters the world (has efiects) or both. In either case, the
URI’s have not been used. efiectoroutputrepresentsthechangeinthestateofthe
world that the execution brings about. A planner uses
Figure 2: Plan generated by composer
thisinformationtoformlinkswithotherservices. Ifone combination of a general description of the service and
describes a service without any efiects or outputs, then some additional logic description is required. DAML
the change of state is not made explicit, and therefore lets you express these two parts in a single language
a composer would have to maintain additional data to and therefore is a better choice for describing services.
representthechangeofstate. Theefiectsoroutputsde- WSDL currently provides a vocabulary that lets you
scribewhattheservicedoesandarethereforeessential, describe just the services; therefore it is di–cult for a
forcomposition. OurrecommendationisthatDAML-S system using WSDL alone to compose a service from
speciflcations should be modifled to make speciflcation atomic services.
of outputs or efiects mandatory. The design of our planner is in accordance with the
above principle: the actual planning engine is domain-
Service Description and Additional independent. The planner can be conflgured to handle
Constraints speciflc domains by plugging in domain speciflc ontolo-
giesthatcapturetheadditionalconstraints. Theservice
The ServiceModel only lets one describe core proper-
itself provides a minimal core set of IOPEs that form
ties of services. Non-trivial composition of services
the planning operator; additional knowledge can then
fromatomicservicesinvolvesfactorslikebusinesslogic,
beaddedthatusesdomain-centricontologiestomodify
changing market scenarios, temporal dependencies be-
the existing IOPEs.
tween services. These, though required, are not (and
typically should not be (Bussler, Maedche, & Fensel
Future Work
2002)) part of the service.
Consider the example of a book look-up service that In the near term, we plan to design an ontology that
takes a book’s name as input and gives the ISBN num- would let one specify relations among services as a pol-
ber as an output. Companies A and B sell books and icy, as described in the previous section. We also plan
use the book look-up service to obtain the ISBN. Com- to demonstrate our framework in a pervasive comput-
pany A has a policy that lets any user pose an ISBN ing environment. In this domain, the composer might
request. Company B only lets users registered with come up with difierent plans for the same goal. The
them to use the ISBN look-up. Company B therefore agent’s location, speed and physical limitations deter-
needsasimilarISBNlook-upservicewithanadditional mine the best plan; these parameters will be captured
precondition. Instead of designing a new service for B, as additional knowledge.
we could provide a generic description of the service Theplannerwehavecurrentlyimplementedisaproof
and let B use it as it wants to. Company B could de- ofconcept,demonstratingthatservicecompositioncan
flne their policy using DAML+OIL which specifles ad- beperformedautomaticallyfromDAML-Sdescriptions
ditional constraints on the operator. It is also in the of atomic services. In future work, we plan to develop
interest of the service provider to advertise a generic a more sophisticated planner that can apply planning
version of the service to enable varied entities to use it. methods to do service composition in real-world en-
Wethereforeclaimthatfornon-trivialcomposition,a vironments. We have identifled three key challenges
in developing such a planner: (1) Selecting among al- plan. If a service for some reason cannot be executed,
ternative atomic and composed services; (2) reasoning then the execution engine requests an alternative ser-
about interactions between atomic services within the vice from the planner. More generally, the failure to
plan; and (3) interleaving planning and execution dur- execute a service could lead to a cascading efiect, re-
ing service composition. In the following subsections, quiring the planner to supply an alternative sub-plan.
we brie(cid:176)y discuss the key issues in each of these areas It is not possible at any stage of the planning process
and our proposed approach to addressing them. to predict the success of the plan. Therefore, not all
services can be checked by executing them; checking
Choosing Among Alternatives can be performed only for idempotent services that do
Our flrst version of the planner is a simple backward- not alter world state. The advantage of this framework
chaining algorithm that assumes that there is always a is its capability to produce plans that are more likely
singleservicethatsatisflesagivengoal. Therecaneas- to be executed successfully compared to the ones pro-
ily be scenarios where a goal can be satisfled by more duced by a framework with disconnected composition
than one service. In these cases, choosing an appropri- and execution. Ideally, the planner would not only be
ate operator is an obvious requirement. Composition able to dynamically replan in case a service fails, but
might succeed or fail based on the choice of service, generate contingency plans to anticipate such failures.
sincedifierentoperators might have difierentsetsof in-
putsandpreconditions,whichformthenewsetofgoals Conclusion
that need to be satisfled in the next planning cycle.
Theoverwhelminginterestshownbyindustryindicates
One possible approach would be to generate all possi-
that web service as a technology is here to stay. How-
bleplans,thenchoosethebestalternativebasedonuser
ever, a rich set of tools are required to demonstrate
specifledcriteriasuchascost. Thistechnique,however,
its use in building distributed web applications. We
is not scalable. An alternative would be to use a best-
present a planner for composing services that handles
flrst backtracking approach by applying heuristics such
servicesdescribedinDAML-S.Wealsoarguethataddi-
as selecting the operator (service) with the least num-
tional logic is required for composing non-trivial tasks.
ber of preconditions or inputs, or selecting operators
This can be done by the use of explicit domain-speciflc
that have pre-conditions that are known to be easily
ontologies.
satisflable.
References
Reasoning About Interactions
Ankolenkar, A.; Burstein, M.; Hobbs, J. R.; Lassila,
Ourcurrentplannerdoesnotreasonaboutinteractions
O.; Martin, D. L.; McDermott, D.; McIlraith, S. A.;
between actions within the plan. However, it may be
Narayanan,S.;Paolucci,M.;Payne,T.R.;andSycara,K.
the case that one action interferes with another (e.g., 2002.DAML-S:SemanticMarkupforWebServices.InThe
clearing out the user’s cookies in between two service First International Semantic Web Conference (ISWC),
invocations on the same website may delete the nec- Sardinia (Italy).
essary authorizations, requiring more inputs from the Bussler,C.;Maedche,A.;andFensel,D. 2002. AConcep-
user),orthattheefiectsofaservicecanbeusedtosat- tualArchitectureforSemanticWebEnabledWebServices.
isfy preconditions of more than one action in the plan Christensen, E.; Curbera, F.; Meredith, G.; and Weer-
(e.g., looking up the title of a book gives not only the awarana, S. 2001. Web Service Description Language,
ISBNnumbertousefororderingthebook,butalsothe http://www.w3.org/TR/wsdl.
full publication information to enter in a bibliography 2001. DARPA Agent Markup Language,
being produced elsewhere in the plan). The partial- http://www.daml.org.
order planning and hierarchical task network planning
2002. DAML-S Ontologies,
paradigms both provide models for reasoning about in- http://www.daml.org/services/0.7.
teractions within the plan, and resolving con(cid:176)icts (or
Friedman-Hill, E. J. 2002. Jess, The Expert System Shell
taking advantage of opportunities).
for the Java Platform.
Interleaving Planning and Execution Martin, D. 2001. Web Services Mailing
List, http://lists.w3.org/Archives/Public/www-
Therearetwowaystocomposeandexecuteacomposite ws/2001Nov/0009.html.
service. In the flrst approach, planning and execution
McIlraith,S.,andSon,T. 2002. AdaptingGologforCom-
areseparate. Thesecond,moreadvanced,approachin-
position of Semantic Web Services. In Proceedings of the
terleaves planning and execution. The initial planner Eighth International Conference on Knowledge Represen-
we have implemented is an instance of the former ap- tation and Reasoning (KR2002), Toulouse, France.
proach: the planner produces a plan assuming that all Ponnekanti, S. R., and Fox, A. 2002. SWORD: A De-
involvedserviceswillbeavailableandexecutenormally. veloper Toolkit for Web Service Composition. In Proc. of
The design of the planner will be difierent for a frame- the Eleventh International World Wide Web Conference,
workthatsupportsparallelcompositionandexecution. Honolulu, HI.
In this case, services are checked for availability and Srivastava,B. 2002. AutomaticWebServicesComposition
successful execution before being included in the flnal Using Planning. In Proc. of KBCS 2002, Mumbai, India.
Thakkar,S.;Knoblock,C.A.;Ambite,J.L.;andShahabi,
C. 2002. Dynamically Composing Web Services from On-
line Sources. In Workshop on Intelligent Service Integra-
tion, The Eigth National Conference on Artiflcial Intelli-
gence (AAAI), Edmonton, Alberta, Cananda.
Weld, D. S. 1994. An introduction to least commitment
planning. AI Magazine 15(4):27{61.
2000. Web Services Toolkit,
http://www.alphaworks.ibm.com/tech/webservicestoolkit.
