Web Services Composition

1. Web Services Composition By Angela Maduko

2. Web Services Composition Putting several web services together to achieve new and more useful solutions • A Trip planner composite web service (web process) might incorporate: • A distance measuring web service • A flight-booking/car-rental web service • A hotel-booking web service

3. Why Compose Web Services A single web service is often not able to satisfy users’ goals on its own For example, without the Trip planner web process, a use would have to: Locate the individual web services Understand and then establish interactions among these services often using typical procedural programming constructs

4. Types of Composition • Static Composition • The control flow and data flow amongst the component web services are given by the user ie the services are chosen at design-time • Dynamic Composition • Component web services are decided at run-time, the control flow and data flow amongst the component web services are generated automatically

5. Composing Web Services • This involves • Discovering the web services to be composed • Centralized (UDDI) with availability and scalability problems • Distributed (P2P systems) • Integrating the discovered web services

6. Executing web services • Centralized Execution • Here a single entity is responsible for the coordination of the web services to be composed • Distributed Execution • Peer-to-peer models are utilized here in which several peers may be responsible for the coordination of the web services to be composed

7. Web Services Architecture • The W3C Web Services Workshop, led by IBM and Microsoft, has agreed that the architecture stack consists of three components: • Wire • Description and • Discovery

8. Wire Stack • Service Provider and Service Requestor exchange information on the wire using the standards included in the Transport Layer of the Wire Stack. • SOAP is currently the standard to be used in Wire Stack. • The wire stack tells us that Web Service applications will communicate with each other using SOAP protocol , that will work as an envelope for XML messages

9. Description Stack • Description is the interface of the web service provided by the Service Provider. • Description stack also contains • XML schema definition of types • Choreography or Business Process Orchestration • Workflow that will explain the ordering of messages between 2 or more parties • Service characsteritics that will provide static information about a service, such as reliability, availability and privacy policies.

10. Discovery Stack • The Discovery stack contains information about discovering a service registered by the Service Provider. • It has two layers • Inspection • This is about retrieval of information about a Service or Organization from that Service or Organization • Registry • UDDI is the most commonly used protocol in the Registry layer

11. Description Stack • The Description Stack, the most important component, consists of five layers. • Our interest lies in the Business Process Orchestration Layer

12. The need for business process standards • We require standards for business process models that are built on Web Service architectures that would enable processes to be modeled, deployed, executed, and managed by software from various vendors

13. Some Business Process Features • A business process standard that provides comprehensive support for both public and private processes should consider the following features • Collaboration-Based Process Models: • Workflow • Transaction Management • Exception Handling • Services Interfaces • Message Security and Reliability • Audit Trail • Agreements • Executions

14. Collaborations BasedProcess Models • Processes are described as a set of collaborations between various participants, including organizations, applications, employees, and other business processes. • The ability to recursively decompose process models is generally required.

15. Workflow • The workflow defines how the participants in a process work together to execute a process from start to finish, and is also called choreography or orchestration. • Workflow descriptions can be generated from collaboration models, or specified independently

16. Transaction Management • A comprehensive business process standard must provide a means for specifying how transactions are managed. • Long-running transactions that may take hours or weeks to complete must be supported. • Compensating actions may be needed. For example if a hotel reservation is cancelled after a payment has been authorized, a compensating action may be required to cancel the payment. • Time constraints for receiving responses or acknowledgements may also be required

17. Exception Handling • If an exception is raised during the course of a business process, then it is important that the model allow appropriate recovery actions to be taken.

18. Service Interfaces • Web Services provide a basis for passing messages between participants in collaboration-based processes.

19. Message Security and Reliability • For mission-critical processes, reliable and secure message delivery is required. • Additionally, B2B messages may need to be digitally signed and authenticated.

20. Audit Trail • It is generally very important for legal purposes in B2B processes that an audit trail of certain business transactions is kept. • This ensures non-repudiation of the transaction by the partner. • Digitally signed receipt acknowledgements of messages may be demanded.

21. Agreements • An agreement represents a contract between two or more partners to carry out specific functions (identified by roles) in a public business process.

22. Execution • To fully automate the execution of the business proces, the complete information flow within that organization as well as across its firewalls must be specified. • This requires the process models to fully describe the private as well as the public activities of the organization. • A powerful approach supported by some standards is Web Service aggregation, whereby one Web Service is used in the implementation of another.

23. The Candidates • Now let's examine those specifications that address the orchestration layer of the Web Services stack, the core layer that describes business process semantics. • Some of these are XLANG, WSFL, and BPML. Each supports some subset of the aforementioned features, depending largely on the domain they are addressing.

24. XLANG • Microsoft’s proposal for a business process language • XLANG uses WSDL to describe the service interfaces of each participating web service • There is no means for specifying data flow between operations • Long-running transactions encompassing multiple operations are supported and can be nested. • Compensating operations for transactions can be specified.

25. XLANG • Exceptions can be caught and recovery operations specified. • XLANG does not define quality-of-service characteristics of Web Services • Acknowledgements and timeouts can be flexibly incorporated. • Some support for agreements is provided in XLANG by contracts, which defines how to stitch together Web Services of collaborating partners.

26. WSFL • IBM’s proposal for a business process language • It covers both public and private processes • Like XLANG uses WSDL to describe the service interfaces • A flow model describes the workflow for a process • Both control flow and data flow can be defined using a state-transition model

27. WSFL • Transactions and exception handling are not explicitly supported, but some of the semantics can be implemented using conditional transitions • Activities in a workflow can be exported as Web Service operations, and activities can also be implemented by delegation to a Web Service

28. WSFL • A global model defines how the various Web Services are linked together in the process • Quality-of-service characteristics are delegated to a separate specification called WSEL (Web Services Endpoint Language)

29. BPML • BPML describes comprehensive control flow and data flow constructs • It supports both short- and long-running transactions with compensating activities • It also supports exception handling and timeouts. • It does not provide a means to specify characteristics that are important to B2B processes

30. BPEL4WS • By Microsoft, IBM and BEA • Merge of WSFL and XLANG • Best of both worlds, graph-oriented processes from WSFL and structural constructs for processes from XLANG • Supports the implementation of any type of business process in a very natural manner

31. BPEL4WS • Designed to enable a would-be service composer to aggregate one or more web services into a possibly non-deterministic execution of one or more web services • Supports two usage scenarios • Implementing executable business processes • Describing non-executable abstract processes • Abstract processes may cloak internal behaviour eg decision processes, as non-deterministic junctions while executable processes define a new web service by composing a set of existing web services

32. BPEL4WS • Aggregated services are modeled as directed graphs where the nodes are services and the edges represent a dependency link from one service to another A simple BPEL4WS process for handling purchase order Source: http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/

33. BPEL4WS • Just like any other web service, the interface of the composite service is defined by a set of WSDL port types • Supports only the input only and input-output ( request-response) operations of WSDL

34. BPEL4WS • A BPEL4WS document uses descriptions of portTypes in WSDL documents to define "roles" within a composition that are filled by "partners". • A service that meets the restrictions set by a partner definition may fill that role in a composition. • The port-specific information about a partner may be set at run time, allowing partner roles to be filled dynamically.

35. BPEL4WS • BPEL4WS processes mainly consist of making invocations to other services and/or receiving invocations from clients • The prior is done using the <invoke> activity and the latter using the <receive> and <reply> activities. • BPEL4WS calls other services that interact with a process a “partner”. • Thus, a partner is either a service the process invokes (invoked partners) as an integral part of its algorithm, or those that invoke the process (client partners).

36. BPEL4WS • Partners are one of the following: • services that the process invokes only. • services that invoke the process only. • or services that the process invokes and invoke the process (where either may occur first).

37. BPEL4WS • A service link type defines a collection of roles, where each role indicates a list of portTypes. The idea is that when two services interact with each other, the service link type is a declaration of how they interact -- essentially what each party offers • BPEL4WS uses service link types to define partners. Basically, a partner is defined by giving it a name and then indicating the name of a service link type and identifying the role that the process will play from that service link type and the role that the partner will play

38. BPEL4WS • Service references • How does a partner work at runtime? In order for it to work at runtime, the partner must resolve to an actual Web service. • Thus, a partner is really eventually just a typed service reference, where the typing comes from the service link type and the roles.

39. BPEL4WS • Dealing with problems • Developers need ways to handle and recover from errors in business processes. • BPEL4WS has exceptions (faults) built into the language via the <throw> and <catch> constructs. • The fault concept on BPEL4WS is directly related to and builds on the fault concept in WSDL

40. DAML-S • DAML-S is a DAML+OIL ontology for describing web services. It represents part of the semantic web initiative to provide semantics to the web • It aims to make web services computer-interpretable ie described with sufficient information to enable automated web service discovery, invocation, composition and execution monitoring

41. DAML-S • The DAML-S Ontology comprises • Service Profile • Service Model • Service Grounding

42. Service Profile • Can be likened to the yellow pages entry for a service • Relates and builds upon the type of contents in UDDI, describing properties of a service necessary for automatic discovery such as what the service offers, its inputs, outputs, preconditions and effects etc

43. Service Model • Describes the services process model ( the control flow and data flow involved in using the service) • Designed to enable automated composition and execution of service

44. Service Grounding • Connects the process model description to communication-level protocols and message descriptions in WSDL

45. BPEL4WS and DAML-S • DAML-S and BPEL4WS have broad and somewhat complementary objectives. • DAML-S's Service Profile complements and extends ideas in UDDI. • It is the Service Model (aka Process Model) in DAML-S that relates most closely to the business process model in BPEL4WS.

46. Comparison of BPEL4WS and DAML-S • Expressiveness: • DAML-S is augmented with preconditions and effects, this enables encoding of side effects of services. This enables higher level reasoning about how services may be composed to achieve a particular goal while exacting particular changes on the world. • BPEL4WS uses WSDL port type information for service descriptions. WSDL does not describe side effects, pre or post-conditions of services, and the expressiveness of service behavior and inputs/outputs is constrained by XML and XML schema.

47. Comparison of BPEL4WS and DAML-S • Semantics: • DAML-S process model is based on formal semantics • Although BPEL4WS represents the merging of XLANG and WSFL there is currently no evidence that BPEL4WS is based on a formal semantics.

48. Comparison of BPEL4WS and DAML-S • Automated discovery, composition, and execution: • The DAML-S ServiceProfile and ServiceModel provide sufficient information to enable automated discovery, composition, and execution based on well-defined descriptions of a service's inputs, outputs, preconditions, effects, and process model. • BPEL4WS does not provide a well-defined semantics. Partners are restricted by structured XML content contained in WSDL port type definitions.

49. Comparison of BPEL4WS and DAML-S • Fault handling, execution monitoring, and transactions: • BPEL4WS defines a mechanism for catching and handling faults similar to common programming languages like Java. One may also define a compensation handler to enable compensatory activities in the event of actions that cannot be explicitly undone. • DAML-S does not define recovery protocols but Petri Net translations of DAML-S descriptions may be extended to support them. • Neither BPEL4WS or DAML-S directly support query mechanisms to expose the state of executing processes. BPEL4WS lists this item as a Future Direction. Petri Net translations of DAML-S descriptions may be extended to support execution monitoring.

50. WSCI • On June 13, 2002 a web services choreography specification was released jointly by BEA Systems, Inc., Intalio, Inc., SAP AG, and Sun Microsystems, Inc. • WSCI is an XML-based interface description language that describes the flow of messages exchanged by a Web Service participating in choreographed interactions with other services • It leverages BPML, BPEL4WS, WfMC's XPDL, and ebXML's BPSS, and is thus the most comprehensive specification yet