SWORD: A Developer Toolkit for Web Service CompositionShankar R. Ponnekanti and Armando FoxComputer Science DeptStanford UniversityStanford, CA 94305{pshankar, fox}@cs.stanford.eduAbstract:The formidable problem of automatic or semi-automatic composition of existing Web services is the subject of much currentattention. We address a particular subset of this problem with SWORD, a set of tools for the composition of a class of webservices including ``information-providing'' services. In SWORD, a service is represented by a rule that expresses that givencertain inputs, the service is capable of producing particular outputs. A rule-based expert system is then used to automaticallydetermine whether a desired composite service can be realized using existing services. If so, this derivation is used to construct aplan that when executed instantiates the composite service. As our working prototype and examples demonstrate, SWORD doesnot require (but could benefit from) wider deployment of emerging service-description standards such as WSDL, SOAP, RDF andDAML. We also distinguish SWORD from some other plausible existing approaches, especially information integration. Weshow that although SWORD's expressive capabilities are weaker, the abstractions it exposes capture more appropriately thelimited kinds of queries supported by typical Web services and thus result in simplicity and efficiency. [Word Count: 7950words]Keywords: Information integration, service composition, service integration, rule-based system.1. Introduction Service composition: the problem of composing autonomous services to achieve new functionality, is generatingconsiderable interest in recent years in several computer science communities. Service composition has the potential to reducedevelopment time and effort for new applications. The web is a particularly interesting domain for service composition forseveral reasons. Firstly, increasing numbers of interesting services are moving online and the web is fast transforming from acollection of static pages to a provider of numerous useful services. Another reason is that web services conform to the standardHTTP protocol which makes it (relatively) easier to integrate them into a common framework. Third, because the web has severalindependent service providers providing related services, there is an inherent need for composing complementary servicesprovided by independent providers to achieve the end-user's needs.The service composition problem is particularly challenging because web services fall into many categories and composingsuch a diverse set of services may require several different tools, techniques, and technologies. In this paper, we propose onesuch toolset: SWORD. SWORD is a toolset that allows service developers to quickly compose base web services to realize newcomposite web services. SWORD can compose information providing services (such as the web services providing informationabout people, movies, theaters, restaurants, etc) and a class of other services (such as email and image conversion services). Thekey idea behind SWORD is as follows:Individual services are defined in terms of their inputs and outputs in an (entity relationship based) ``world model''. Given the inputs andoutputs of the service, a rule (as in rule-based expert systems [24]) is then defined which indicates which outputs can be obtained by theservice given which inputs.1.When a developer wishes to create and deploy a new composite service, she specifies the inputs and outputs of the composite service inthe world model and submits it to SWORD.2.SWORD determines using a rule engine if the composite service can be realized using the existing services. If so, SWORD generates acomposition plan for the composite service.3.The developer can then view the generated plan and if appropriate, request that a persistent representation of the plan be generated.This representation contains the sequence of services that need be invoked to obtain the composite service outputs from its inputs.Roughly speaking, each step used during the derivation (i.e., each rule that fired) in the rule engine corresponds to a service invocation.4.When an actual request for the composite service is received, the service(s) specified in the plan are executed, starting with the knowninputs, in order to compute the desired outputs. In practice, some services can yield multiple responses to a query for which a singleanswer is logically desired; and some services can legitimately yield multiple matches. (As an example of the first, a name-to-addresslookup service may return multiple matches if there are multiple individuals with the same name. As an example of the second, a servicethat returns restaurants within a certain radius will likely return multiple restaurants). If the user's goal was (eg) to obtain drivingdirections, the user would have to select a particular restaurant with which to continue execution. Our execution environment providesa way of resolving these cases, either by prompting the user or by supplying filter code. We focus on making the overall system, includingthis filtering mechanism, very easy to use so that the cost to the user of trying multiple options is low.5.The contributions of SWORD are three-fold:A composition model well-suited to typical informational web services as well as certain other web services.An execution model for the composite services with a customizable filter mechanism that makes the composite services easy to use. Thecost to the user of trying multiple options when services (expectedly or otherwise) produce multiple results is low.An implemented prototype, which demonstrates that SWORD can work with today's web services unlike some other upcomingresearch/industry projects which rely on the deployment of standards such as SOAP [28], WSDL [29], UDDI [8], RDF [27] and/orDAML [14]. Further, given the simplicity of our model, it can easily be extended to work with such standards if they are widelydeployed in the future.Note that in general, SWORD cannot currently handle web services with various side-effects, such as services involvingaccount credits/debits, or various other business-business services. This is an area of future work and we plan to explore how theSWORD model can be (incrementally) expanded to include other types of web services.In this