CIS*6650.01 Service-Oriented Computing

1. CIS*6650.01Service-Oriented Computing Qusay H. Mahmoud, Ph.D. qmahmoud@uoguelph.ca CIS*6650.01

2. Topics • Service Composition • BPEL (Business Process Execution Language) • Orchestration and Choreography CIS*6650.01

3. Service Composition • Problem: more than one service might be needed to achieve a given objective • All such services need to interact seamlessly to achieve the objective • Composite Web Services • Individual components implemented by different services and located at different locations • Execute in different contexts and containers • Need to interact to achieve an objective • Benefits • Services can be reused • Access to high-level complex services CIS*6650.01

4. Service Composition • Approaches • Static composition • By hand • BPEL4WS • Dynamic composition • Model-driven • Semantic approach (OWL-S, DAML-S): Will discuss later • Example: • Use WSDL for the interface • Interaction of messages between WS using BPEL or WSCL • Composition process involves: • Specifying the role of each participating WS • Specifying logical flow of messages between them CIS*6650.01

5. Service Composition • Services execute in different containers separated by firewalls and trust barriers • Some of the key requirements that a composition approach must satisfy (e.g. scalability, dependability, correctness) • Requirements (from paper in references) that composition approach should guarantee • Connectivity • Non-functional QoS properties • Correctness • Scalability • Why need such requirements? • Consider a service composed of two trusted services from different providers, is the composed service trusted? CIS*6650.01

6. Service Composition Requirements • Connectivity • Must be reliable to determine which services are composed and reason about input/output messages • Non-functional QoS properties • Based on message passing, thus needs to address • Performance, security, dependability • Correctness • Verification of the composed service’s properties • Scalability • Multiple services will be involved, composition framework must scale with the number of composed services CIS*6650.01

7. Composition Approaches • First generation • IBM’s Web Service Flow Language (WSFL) • BEA Systems’ Web Services Choreography Interface (WSCI) • They are incompatible • Second generation • Business Process Execution Language for Web Services (BPEL4WS or BPEL): combines WSFL and WSCI with Microsoft’s XLANG CIS*6650.01

8. BPEL • An XML-based language for process-oriented service composition • Developed by IBM, BEA, Microsoft, SAP, and Siebel. Being standardized by OASIS • Approach: • Interact with a Web services’ subset to achieve a given task • Composition result is called a “process”, participating services are “partners”, message exchange or intermediate result transformation are “activities” • A process interacts with external partner services through a WSDL interface CIS*6650.01

9. BPEL • To define a process, use: • A BPEL source file (.bpel) that describes activities • A process interface (.wsdl) that describes ports of a composed service • An optional deployment descriptor (.xml) that contains the partner services’ physical locations • Several element groups, the basic ones are: • Process initiation: <process> • Participating services: <partnerLink> • Synchronous and Asynchronous calls: <invoke> and <invoke>…<receive> • Intermediate variables: <variable>, <assign>, <copy> • Error handling: <scope>, <faultHandlers> • Sequential and parallel execution: <sequence>, <flow> • Logic control: <switch> CIS*6650.01

10. BPEL • Process flow (basic and structured activities) Source: C. Peltz;Web Services Orchestration and Choreography, IEEE Computer, Oct 2003, pp. 46-52 CIS*6650.01

11. BPEL • Example: Model the composition of 3 services: A is called asynchronously and starts a process. B and C are called in parallel using A’s output as their input. The process waits for their completion and then makes a decision based on the results • Not all code is shown • Assumption: All services offer only one operation at one port CIS*6650.01

12. BPEL • Code (source: Milanovic, N.; Malek, M.; Current Solutions for Web Service Composition, IEEE Internet Computing, Nov/Dec 2004, pp. 51-59) <process name=“test”> <partnerLinks> <partnerLink name=“client”/> <partnerLink name=“serviceA”/> <partnerLink name=“serviceB”/> <partnerLink name=“serviceC”/> </partnerLinks> <variables> <variable name=“processInput”/> <variable name=“AInput”/> <variable name=“AOutput”/> <variable name=“BCInput”/> <variable name=“BOutput”/> <variable name=“COutput”/> <variable name=“processOutput”/> <variable name=“AError”/> </variables> CIS*6650.01

13. BPEL • …Code CIS*6650.01

14. BPEL • …code… CIS*6650.01

15. BPEL • BPELJ: Allows developers to include Java code inside BPEL code • BPEL can be used with two other specifications: • Web Services-Coordination: Coordinates Web services’ actions when an agreement must be reached • Web Services-Transactions: Defines Web services’ transactional behavior • Several BPEL orchestration server implementations for Java EE and .NET are available including: • IBM WebSphere • Oracle BPEL Process Manager (formerly Collaxa BPEL) • Microsoft BizTalk • OpenStorm ChoreServer • Active BPEL CIS*6650.01

16. Orchestration and Choreography • Describe two aspects of creating business processes from composite Web services • Orchestration: represents control from one party’s perspective • Choreography: tracks the message sequence among multiple parties Source: C. Peltz; Web Services Orchestration and Choreography, IEEE Computer, Oct 2003, pp. 46-52 CIS*6650.01

17. WSCI • Web Services Choreography Interface • Developed by Sun, SAP, BEA, and Intalio • Defines a collaboration extension to WSDL • Defines the overall choreography or message exchange between Web services • Describes only the observable behavior and doesn’t address the definition of executable business processes as BPEL does • A WSCI choreography would include a set of WSCI interfaces, one for each partner in the interaction • No single process manages the interaction CIS*6650.01

18. WSCI • Each WSCI action represents a unit of work that maps to a specific WSDL operation • Extends WSDL to describe how to choreography the available WSDL operations • WSDL describes the entry points for each available service, and WSCI describes the interactions among WSDL operations • Supports basic and structured activities • An “action” tag defines a basic request/response msg • Each activity specifies the WSDL operation involved and the specific participant that performs it • A choreography invokes external services through a “call” tag CIS*6650.01

19. WSCI • Example: Create a purchasing process that contains two sequential activities, Receive Order and Confirm. Each activity maps to a WSDL portType, and WSCI establishes a correlation between them Source: C. Peltz; Web Services Orchestration and Choreography, IEEE Computer, Oct 2003, pp. 46-52 CIS*6650.01