Web Services Composition By Angela Maduko

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

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

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 Types of Composition

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

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

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

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

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.

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

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

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

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

Collaborations Based Process 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.

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

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

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.

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

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.

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.

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

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.

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.

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.

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.

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

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

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)

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

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

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

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: bpel/

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

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.

BPEL4WS BPEL4WS processes mainly consist of making invocations to other services and/or receiving invocations from clients The prior is done using the activity and the latter using the and 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).

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).

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

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.

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 and constructs. The fault concept on BPEL4WS is directly related to and builds on the fault concept in WSDL

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

DAML-S The DAML-S Ontology comprises –Service Profile –Service Model –Service Grounding

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

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

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

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.

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.

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.

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.

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.

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

WSCI It proposes a language standard that can be used in conjunction with existing Web-service protocols to provide a description of the observable behavior of Web services. The Web Service Choreography Interface (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. WSCI describes the dynamic interface of the Web Service participating in a given message exchange by means of reusing the operations defined for a static interface.

WSCI WSCI works in conjunction with the Web Service Description Language (WSDL) It can also work with another service definition language that exhibits the same characteristics as WSDL. WSCI describes the observable behavior of a Web Service expressed in terms of temporal and logical dependencies among the exchanged messages, featuring sequencing rules, correlation, exception handling, and transactions. WSCI also describes the collective message exchange among interacting Web Services, thus providing a global, message-oriented view of the interactions."

WSCI Problem and rationale for the WSCI solution Fundamentally, the challenge will be to describe Web Services –From an external point of view (without knowing how internally they operate) –Independently of any particular integration model (workflow, MOM etc) –Precisely enough to allow other components to have a clear understanding of how to properly interact with them –In the context of each specific message exchange in which they participate