Outline

1. Outline • Concepts: Services, SOA, WebServices • Services as reusable components • Service engineering • Software development with services • Simple case: a client consumes a service • WS APIs • Common case: several services are composed with support of the service platform • Workflows • BPEL • Service Oriented Software Engineering particularities

2. Review: Service-oriented software engineering • Existing approaches to software engineering have to evolve to reflect the service-oriented approach to software development • Service engineering. The development of dependable, reusable services • Software development for reuse • Software development with services. The development of dependable software where services are the fundamental components • Software development with reuse

3. Software development with services • Simplest case: • a client uses (“consumes”) a service • Common case: • several services are composed

4. In order to use a service, a Client program needs only its WSDL (contains abstract interface description and URI of service endpoint) How Clients Use Services Types Messages Operations Port Type WHAT Bindings Port Service HOW WHERE

5. Interoperability WSDL description Client1 Service1 J2EE <Vendor A> <Vendor C> WSDL description Client2 Service2 .NET <Vendor B> <Vendor D>

6. How can a client bind to a service ? • Static binding • Service at fixed URL • Dynamic binding by reference • Service URL given at runtime • Dynamic binding by lookup • Look up service URL in registry (need lookup API) • Dynamic operation selection • Service type/operation name given at runtime • => API’s for Web Services: Java, .NET

7. Java APIs for Web Services • SOAP messages as Java objects • SAAJ ( SOAP with Attachments API for Java) • Programming Model • JAX-RPC (Java API for XML-based RPC) => JAX-WS (Java API for XML Web Services) • Accessing WSDL descriptions • JWSDL • Accessing Web Services Registries • JAXR (Java API for XML Registries)

8. JAX-WS (JAX-RPC) • WSDL/XML to Java Mapping (wsimport) • Java to WSDL/XML Mapping (wsgen) • Client API • Classes generated from WSDL • Dynamic Proxy • DII call Interface

9. Web Service Example A Web service AddFunction with operation addInt is known through its WSDL: <wsdl:message name="addIntResponse"> <wsdl:part name="addIntReturn" type="xsd:int"/> </wsdl:message> <wsdl:message name="addIntRequest"> <wsdl:part name="a" type="xsd:int"/> <wsdl:part name="b" type="xsd:int"/> </wsdl:message> <wsdl:portType name="AddFunction"> <wsdl:operation name="addInt" parameterOrder="a b"> <wsdl:input message="impl:addIntRequest" name="addIntRequest"/> <wsdl:output message="impl:addIntResponse" name="addIntResponse"/> </wsdl:operation> </wsdl:portType> // possible implementation of WS: // AddFunction.jws public class AddFunction { int addInt(int a, int b){ return(a+b); } }

10. Writing the Client Program • There are many ways to write a Client program that uses the AddFunction Service (invoking its addInt operation) • Using Dynamic Invocation Interface ( DII) • Using generated Stubs from Service WSDL description • Using Dynamic Proxy

11. Client – using DII • Using Dynamic Invocation Interface ( DII): • Service type (WSDL) can be discovered at runtime (WSDL description is actually not even needed !) • Service URL is given at runtime (could be extracted from a WSDL) • Operation name can also be given at runtime • Invocation is done by constructing and sending a call message • Most flexible way; but client code looks “ugly”

12. Client - using DII - Example import javax.xml.rpc.Call; import javax.xml.rpc.Service; import javax.xml.namespace.QName; String endpoint = "http://localhost:8080/axis/AddFunction.jws"; Service service = new Service(); Call call = (Call) service.createCall(); call.setOperationName(new QName(endpoint, "addInt")); call.setTargetEndpointAddress( new java.net.URL(endpoint) ); Integer ret = (Integer)call.invoke(new Object[]{ new Integer(5), new Integer(6)}); System.out.println("addInt(5, 6) = " + ret);

13. Client – using generated stubs • Using generated Stubs from Service WSDL description • Service to be used is known from the beginning and the WSDL is available at client development time • Service Endpoint Interface (SEI): the (Java) programming language representation of a WSDL port type. Can be generated automatically by tools from a WSDL • Stubs (proxies) are classes that implement the SEI. They are generated from the WSDL description (similar with RMI or CORBA middleware for distributed object computing)

14. Client – using Generated Stubs Generate the stubs: java org.apache.axis.wsdl.WSDL2Java \ http://localhost:8080/axis/AddFunction.jws?wsdl import localhost.*; AddFunctionService afs = new AddFunctionServiceLocator(); AddFunction af = afs.getAddFunction(); System.out.println("addInt(5, 3) = " + af.addInt(5, 3));

15. Client – using Dynamic Proxy • Using Dynamic Proxy • you need to know the abstract WSDL (port type) at development-time • you need to run your WSDL mapping tool against the WSDL document before runtime in order to get the Service Endpoint Interface • The proxy (a class implementing the SEI) is obtained at runtime (here is the difference with generated stubs: these are obtained at development time)

16. Client – using Dynamic Proxy import javax.xml.namespace.QName; import javax.xml.rpc.*; String wsdlUrl = "http://localhost:8080/axis/AddFunction.jws?wsdl"; String nameSpaceUri = "http://localhost:8080/axis/AddFunction.jws"; String serviceName = "AddFunctionService"; String portName = "AddFunction"; ServiceFactory serviceFactory = ServiceFactory.newInstance(); Service afs = serviceFactory.createService(new java.net.URL(wsdlUrl), new QName(nameSpaceUri, serviceName)); AddFunctionServiceIntf afsIntf = (AddFunctionServiceIntf)afs.getPort( new QName(nameSpaceUri, portName), AddFunctionServiceIntf.class); System.out.println("addInt(5, 3) = " + afsIntf.addInt(5, 3));

17. Where and How to find Services ? • Service registies: • UDDI • Standard for representing and organizing registry informations • Standard API’s for: • publishing services on UDDI registry • Lookup services from registry • Private UDDI registries: inside one enterprise • Public UDDI registries: • Existed maintained by major companies • Not anymore (since 2008) • Problems of UDDI: (why public UDDI registries died): • Complex standard and API • No semantic information • No certification, no trust • Info published in UDDI registry accessible only via UDDI lookup API’s, not accessible via usual search engines • Using usual search engines • Using Web service search engines • http://webservices.seekda.com/

18. Outline • Concepts: Services, SOA, WebServices • Services as reusable components • Service engineering • Software development with services • Simple case: a client consumes a service • WS APIs • Common case: several services are composed with support of the service platform • Workflows • BPEL • Service Oriented Software Engineering particularities

19. Software development with services • Common case: a client uses multiple services • Existing services are composed and configured to create new composite services and applications • Solution 1: implement root of composite service in usual programming language. • The internal application implements the composition logic, by invoking services as needed • The service platform is not involved in the composition • Solution 2: use specific facilities of the service platform to support composition • A composition model describes the business logic • The service platform provides runtime support for the execution of the composition model by invoking other services • Fundamental concepts: • Workflows • Orchestration • Choreography

20. implement root of composite service in usual programming language use specific facilities of the service platform to support composition

21. Workflow • Workflows represent a set of activities to be executed, their interdependencies relations, inputs and outputs. • Activities can be executed in parallel or in sequence input data1 activity1 activity3 output data input data2 activity2 input data3 activity4

22. What are workflows? The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. workflow management consortium Participants perform the work represented by a workflow activity instance and can be human or machine resources

23. Workflow Management Systems • History: • Workflow management systemsdate back to the late 1980. They are used to coordinate the work of multiple people in a project that has a fixed process. • What a WMS supports: • defining process in terms of finer-grained tasks or activities • scheduling these activities and • dispatching (invoking) the activities • passing of information between activities

24. Two-level Programming Model • Programming in the large • Non-programmers implementing flows • Flow logic deals with combining functions in order to solve a more complex problem (such as processing an order) • Programming in the small • Programmers implementing functions • Function logic deals with a discrete fine-grained task (such as retrieving an order document or updating a customer record)

25. Basic Control Flow Sequence Parallel Split Synchronization Exclusive Choice Advanced Branching and Synchronization Multi-Choice Structured Synchronizing Merge Multi-Merge Structured Discriminator Blocking Discriminator Multiple Instance Patterns Multiple Instances without Synchronization Multiple Instances with a Priori Design-Time Knowledge Multiple Instances with a Priori Run-Time Knowledge State-Based Patterns Deferred Choice Interleaved Parallel Routing Milestone Cancellation and Force Completion Patterns Cancel Task Cancel Case Interation Patterns Arbitrary Cycles Structured Loop Recursion Termination Patterns Implicit Termination Explicit Termination Trigger Patterns Transient Trigger Persistent Trigger Workflow patterns www.workflowpatterns.com

26. Some Challenges for WfMS • Process Representation (control flow & data flow) • Process Specification • Process Definition Interoperability • Process Enactment (automated sequencing) • Process Monitoring & Control/Config. • Process Participant Modelling, Monitoring & Control

27. Workflows and services • Workflow technology is the predecessor of service composition • Disadvantages of workflows: • high license costs • complex software • heterogeneity • But service composition is different (or, the business and IT environment is different): • standardization (components and composers) • maturity • reduced costs (small layer on top of other middleware)

28. Types of WFMS • Centralized (Orchestration) • Decentralized (Choreography)

29. Orchestration: A centralized mechanism that describes how diverse services can interact. This interaction includes message exchange, business logic and order of execution. interacting components are not be aware of each other Choreography: Choreography focuses on enabling the description of how to interact with services at a larger scale than the individual message exchange pattern Interacting components are aware of each other. “A choreography defines re-usable common rules that govern the ordering of exchanged messages, and the provisioning patterns of collaborative behavior, as agreed upon between two or more interacting participants “ [W3C] Orchestration vs Choreography

30. Orchestration vs Choreography

31. Business Process Modelling • Formal model based on Petri-Nets • Formal mathematical model = directed graph • Basic concepts: • Places • Transitions • Arcs • Markers • Languages for modelling busines processes • Petri net based • UML activity diagrams • YAWL (Yet Another Workflow Language) • BPMN (Business Process Modelling Notation)

32. BPMN • Developed by Sun, BEA and Intalio • Modeling of activities that are performed at certain points in time • Basic elements: • Flow elements • Connection Objects • Swimlanes • Artefacts • translation of business process model to executable model required: direct mapping from BPMN to BPEL

33. BPEL • Business Process Execution Language • Language for Business Process Description & Composition of Web Services • Facilitates automated process integration • Presented in 2002 as BPEL4WS by Microsoft, IBM and BEA • Standardised by OASIS as WS-BPEL – 2.0 latest version (2007) • Based on XML and Web Services • Syntax defined by XML schema • No standardised graphical notation • Successor of 2 earlier work flow languages: • WSFL: Web Services Flow Language (by IBM) • XLANG: Web Services for Business Process Design (by Microsoft)

34. WS-BPEL in the WS-* Stack WS-BPEL Business Processes WSDL, Policy, UDDI, Inspection Description Security Reliable Messaging Transactions Quality Of Service Coordination Other protocols Transport and Encoding SOAP (Logical Messaging) Other services XML, Encoding

35. BPEL supported types of business processes • Executable Process • Orchestration of specific activities and particular services which must be executed • Executable via an execution engine • => Definition of an Orchestration • Abstract Process • Specification of the message exchanges between multiple participants • No definition of internal process details • Interfaces defined through set of all receive and reply • => Definition of a Choreography • Still BPEL is not used for choreography • WS-CDL (Choreography Description Language) • A choreography is not an executable process -> usually it is translated into a concrete orchestration description and executed

36. WS-BPEL Language Structure Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities Receive Reply Invoke

37. WS-BPEL Process: Made up of “Activities” – the individual steps of a process Activities are implemented by Web Services Specifies order in which participating Web Services should be invoked WS-BPEL process is itself represented as Web Services WS-BPEL Process Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities Receive Reply Invoke

38. BPEL and WSDL • BPEL processes are exposed as WSDL services • Message exchanges map to WSDL operations • WSDL can be derived from partner definitions and the role played by the process in interactions with partners WSDL Loan Approval PortType Web Service Loan Approval Process receive reply

39. Recursive Composition • BPEL processes interact with WSDL services exposed by business partners Interfaces exposed by the BPEL process Interfaces consumed by the BPEL process WSDL Loan Approval PortType Web Service Web Service Loan Approval Process receive Financial Institution‘s Web Service (Loan Approver) invoke reply

40. partnerLinks: Defined in WSDL files Represent the interaction between a BPEL process and the participants (the different web services) Possess roles with portTypes e.g. invocation role: computePrice and callback role: provideInvoice WS-BPEL PartnerLinks Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities Receive Reply Invoke

41. Composition of Web Services Service A Service P Service B receive invoke receive invoke invoke A’s WSDL P’s WSDL F B’s WSDL Partner Link Type Partner Link Type

42. Variables Save data which is exchanged within processes Activities access data stored in variables WS-BPEL variables Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities Receive Reply Invoke

43. BPEL- WSDL- XML Schema

44. Primitive Activities – for common tasks • Invoke: Calling other Web Service Activities (port types) • Receive: Waiting in blocked state for arrival of messages • Reply: Generation of reply to received message • Wait: Wait for a certain amount of time • Assign: Copying of data from one place to another • Throw: Error handling, creation of error message • Terminate: End complete process instance • Empty: Inserting of NOOP (no operations) WS-BPEL primitive activities Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities Receive Reply Invoke

45. Structured Activities – to combine primitive activities Sequence - set of activities that will be invoked in ordered sequence Flow - set of activities that will be invoked in parallel Switch - Case-switch construct for implementing branches While - for defining loops Pick - select one of several alternative paths WS-BPEL structured activities Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities Receive Reply Invoke

46. Correlation Sets Declarative description of a group of properties which together describe a conversation BPEL execution systems support multiple concurrent conversations Necessary to match messages to correct process instance (conversation) E.g. invoice correlated with correct instance of buyer process via apurchase order number received in earlier purchase order message. WS-BPEL correlation sets Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities Receive Reply Invoke

47. Example: Hotel booking workflow

48. Workflow design and implementation • WS-BPEL is an XML-standard for workflow specification. However, WS-BPEL descriptions are long and unreadable • Graphical workflow notations, such as BPMN, are more readable and WS-BPEL can be generated from them • In inter-organisational systems, separate workflows are created for each organisation and linked through message exchange

49. BPEL design tools • EclipseBPEL Designer • JBossIDE • NetBeansIDE • IBM WebSphere Integration Developer • Microsoft BizTalk Orchestration Designer • Oracle BPEL Designer (for JDeveloper and Eclipse) • Active Endpoints Active BPEL Designer

50. BPEL execution engines • BPEL-Engine: Runtime environment for the interpretation of the BPEL documents und execution of the Processes • Apache ODE • IBM WebSphere Process Choreographer • Microsoft BizTalk Server • Oracle BPEL Process Manager (Intalio n3 Server • ActiveBPEL Engine • JBoss Application Server with jBPM