Outline Concepts Services SOA Web Services Services as

Outline • Concepts: Services, SOA, Web. Services • 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

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

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

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) WHAT Types Messages Operations Port Type HOW WHERE Bindings Port Service

Interoperability Client 1 WSDL description J 2 EE <Vendor A> Client 2. NET <Vendor B> Service 1 <Vendor C> WSDL description Service 2 <Vendor D>

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 A Web service Add. Function with operation add. Int is known through its WSDL: <wsdl: message name="add. Int. Response"> <wsdl: part name="add. Int. Return" type="xsd: int" /> </wsdl: message> <wsdl: message name="add. Int. Request"> <wsdl: part name="a" type="xsd: int" /> <wsdl: part name="b" type="xsd: int" /> </wsdl: message> <wsdl: port. Type name="Add. Function"> <wsdl: operation name="add. Int" parameter. Order="a b"> <wsdl: input message="impl: add. Int. Request" name="add. Int. Request" /> <wsdl: output message="impl: add. Int. Response" name="add. Int. Response" /> </wsdl: operation> </wsdl: port. Type> // possible implementation of WS: // Add. Function. jws public class Add. Function { int add. Int(int a, int b){ return(a+b); } }

Writing the Client Program • There are many ways to write a Client program that uses the Add. Function Service (invoking its add. Int 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 = "http: //localhost: 8080/axis/Add. Function. jws"; Service service = new Service(); Call call = (Call) service. create. Call(); call. set. Operation. Name(new QName(endpoint, "add. Int")); call. set. Target. Endpoint. Address( new java. net. URL(endpoint) ); Integer ret = (Integer)call. invoke(new Object[]{ new Integer(5), new Integer(6)}); System. out. println("add. Int(5, 6) = " + ret);

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)

Client – using Generated Stubs Generate the stubs: java org. apache. axis. wsdl. WSDL 2 Java http: //localhost: 8080/axis/Add. Function. jws? wsdl import localhost. *; Add. Function. Service afs = new Add. Function. Service. Locator(); Add. Function af = afs. get. Add. Function(); System. out. println("add. Int(5, 3) = " + af. add. Int(5, 3));

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)

Client – using Dynamic Proxy import javax. xml. namespace. QName; import javax. xml. rpc. *; String wsdl. Url = "http: //localhost: 8080/axis/Add. Function. jws? wsdl"; String name. Space. Uri = "http: //localhost: 8080/axis/Add. Function. jws"; String service. Name = "Add. Function. Service"; String port. Name = "Add. Function"; Service. Factory service. Factory = Service. Factory. new. Instance(); Service afs = service. Factory. create. Service(new java. net. URL(wsdl. Url), new QName(name. Space. Uri, service. Name)); Add. Function. Service. Intf afs. Intf = (Add. Function. Service. Intf)afs. get. Port( new QName(name. Space. Uri, port. Name), Add. Function. Service. Intf. class); System. out. println("add. Int(5, 3) = " + afs. Intf. add. Int(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 Web service search engines – http: //webservices. seekda. com/

Outline • Concepts: Services, SOA, Web. Services • 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

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 activity 1 activity 3 input data 1 activity 2 input data 2 output data activity 4 input data 3

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

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 Instances without Synchronization – Multiple Instances with a Priori Design-Time Knowledge – Multiple Instances with a Priori Run-Time Knowledge – Deferred Choice – Interleaved Parallel Routing – Milestone Arbitrary Cycles Structured Loop Recursion Termination Patterns – – • Cancel Task Cancel Case Interation Patterns – – – Multiple Instance Patterns State-Based Patterns Cancellation and Force Completion Patterns Implicit Termination Explicit Termination Trigger Patterns – – www. workflowpatterns. com Transient Trigger Persistent Trigger

Some Challenges for Wf. MS • 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 “ [W 3 C]

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 BPEL 4 WS 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 Business Processes WSDL, Policy, UDDI, Inspection Description Security Reliable Messaging Transactions Coordination SOAP (Logical Messaging) Other protocols XML, Encoding Other services Quality Of Service Transport and Encoding

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 Receive Invoke Reply

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

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 Port. Type Loan Approval Process receive reply Web Service

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

WS-BPEL Partner. Links Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities Receive Invoke Reply • partner. Links: • Defined in WSDL files • Represent the interaction between a BPEL process and the participants (the different web services) • Possess roles with port. Types e. g. invocation role: compute. Price and callback role: provide. Invoice

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

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

BPEL- WSDL- XML Schema

WS-BPEL primitive activities Process Partner Links Variables Correlation Sets Fault Handlers • • • Compensation Handlers • Event Handlers • Activities Receive Invoke Reply • 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 structured activities Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities Receive Invoke Reply • 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 correlation sets Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Event Handlers Activities Receive Invoke Reply • 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.

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

BPEL design tools • • Eclipse. BPEL Designer JBoss. IDE Net. Beans. IDE IBM Web. Sphere Integration Developer Microsoft Biz. Talk 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 Web. Sphere Process Choreographer Microsoft Biz. Talk Server Oracle BPEL Process Manager (Intalio n 3 Server Active. BPEL Engine JBoss Application Server with j. BPM

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, Web. Services • 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.