Reuse and Composition in Service Computing Main Bibliography: Chap. 31, Sommerville Additional Reading: Thomas Erl: SOA: Concepts, Technology and Design

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

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

Software development with services Simplest case: a client uses (“consumes”) a service

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

Interoperability.NET J2EE WSDL description Client1 Client2 Service1 Service2 WSDL description

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

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)

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

Web Service Example // possible implementation of WS: // AddFunction.jws public class AddFunction { int addInt(int a, int b){ return(a+b); } A Web service AddFunction with operation addInt is known through its WSDL:

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

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”

Client - using DII - Example import javax.xml.rpc.Call; import javax.xml.rpc.Service; import javax.xml.namespace.QName; String endpoint = " 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);

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) Client – using generated stubs

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

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) Client – using Dynamic Proxy

import javax.xml.namespace.QName; import javax.xml.rpc.*; String wsdlUrl = " String nameSpaceUri = " 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));

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 –

Web Services search engine

Search Services – seekda! feature

Test Services – seekda! feature

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 Workflows BPEL BPEL – Service Oriented Software Engineering particularities

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

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

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 activity1 activity2 activity3 input data1 input data2 input data3 activity4 output data

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

Workflow Management Systems History: – Workflow management systems date back to the late 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

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)

Workflow patterns 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

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

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)

Types of WFMS Centralized (Orchestration) Decentralized (Choreography)

Orchestration vs Choreography 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

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)

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

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)

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

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

WS-BPEL Language Structure Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities ReceiveReply Invoke

WS-BPEL Process 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 Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities ReceiveReply Invoke

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 Web Service Loan Approval Process receive reply WSDL Loan Approval PortType

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

WS-BPEL PartnerLinks 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 Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities ReceiveReply Invoke

Composition of Web Services Partner Link Type Service PService AService B A’s WSDLP’s WSDLB’s WSDLF invoke receive invoke

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

BPEL- WSDL- XML Schema

WS-BPEL primitive activities 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) Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities ReceiveReply Invoke

WS-BPEL structured activities 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 Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities ReceiveReply Invoke

WS-BPEL correlation sets 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. Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities ReceiveReply Invoke

Example: Hotel booking workflow

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

Interacting workflows

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

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

Advantages of WS-BPEL Portable, interoperable process model for long running business processes Flexible integration of Web services – WSDL abstract interfaces alone used to define composition Enables two levels of adaptive behavior – Abstract partners can be bound to actual services at runtime – The process can choose a protocol for communicating with the service at runtime – Services whose data definitions do not match can be composed Data transformations can be inlined in process definition

Disadvantages of WS-BPEL Static process composition. Process participants (partner‘s web services) must be defined and bound to the process flow at design time. BPEL standard is not about Semantic Web services: – Partner discovery and bounding at run time not possible. – Message mediation not possible.

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

Construction by composition

Service testing Testing is intended to find defects and demonstrate that a system meets its functional and non-functional requirements Service testing is difficult as (external) services are ‘black-boxes’. Testing techniques that rely on the program source code cannot be used

Service testing problems External services may be modified by the service provider thus invalidating tests which have been completed Dynamic binding means that the service used in an application may vary - the application tests are not, therefore, reliable The non-functional behaviour of the service is unpredictable because it depends on load If services have to be paid for as used, testing a service may be expensive It may be difficult to invoke compensating actions in external services as these may rely on the failure of other services which cannot be simulated

Key points Service-oriented software engineering is based on the notion that programs can be constructed by composing independent services which encapsulate reusable functionality. Service interfaces are defined in WSDL. A WSDL specification includes a definition of the interface types and operations, the binding protocol used by the service and the service location. Services may be classified as utility services, business services or coordination services. The service engineering process involves identifying candidate services for implementation, defining the service interface and implementing, testing and deploying the service.

Key points Service interfaces may be defined for legacy software systems which may then be reused in other applications. Software development using services involves creating programs by composing and configuring services to create new composite services. Business process models define the activities and information exchange in business processes. Activities in the business process may be implemented by services so the business process model represents a service composition. Techniques of software testing based on source-code analysis cannot be used in service-oriented systems that rely on externally provided services.