web services development

WS-BPEL 2.0 3/13/2007

Dr. Kanda Runapongsa, Computer Engineering, Khon Kaen University 1

1

WS-BPEL 2.0

Asst. Prof. Dr. Kanda Runapongsa

([email protected])

Department of Computer Engineering

Khon Kaen University

2

Agenda

Motivation

OASIS and WS-BPEL

Main Concepts

WS-BPEL 2.0 Tutorial

Status and Support

3

Motivation Application integration is a key problem facing

businesses

Intra enterprise integration (Enterprise Application Integration)

Integrating with partners (Business Process Integration)

Web services move towards service-oriented computing

Applications are viewed as “services”

Loosely coupled, dynamic interactions

Heterogeneous platforms

No single party has complete control

Service composition

How do you compose services in this domain?

WS-BPEL 2.0 3/13/2007


4

Application Integration

Business Process

.NETApplication

Web ApplicationServer

Legacy Application

5

Two-level Programming Model

Programming in the large (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

(Implementing functions)

Function logic deals with a discrete fine-

grained task (such as retrieving an order

document)

6

Process Usage Patterns

Aiming for a single approach for both

Executable processes

Contain the partner‟s business logic behind

an external protocol

Abstract processes

Define the publicly visible behavior of some

or all of the services an executable process

offers

Define a process template embodying

domain-specific best practices

WS-BPEL 2.0 3/13/2007


7

Process Model Requirements (1/2)

Portability and Interoperability

Flexible Integration

Rich and easily adaptable to changes in the

services it is interacting with

Recursive, type-based composition,

enables …

Third-party composition of existing services

Providing different views on a composition to

different parties

Inter-workflow interaction

Increased scalability of concerns

8

Process Model Requirements (2/2)

Separation and composability of concerns

Decoupled from the supporting mechanisms (quality of services, messaging frameworks)

Stateful conversions and lifecycle management

Can carry multiple stateful long-running conversations

Recoverability

Business processes, and in particular long running ones, need a way to build-in fault handling and compensation mechanisms to handle and recover from errors

9

What BPEL Provides Define business processes as coordinated sets

of Web service interactions, recursively into new

aggregated Web services

Define both abstract and executable processes

Abstract processes for e-commerce specifications

Executable processes provide a model to integrate

enterprise applications

Create compositions of Web services

Composition based on abstract descriptions

WS-BPEL 2.0 3/13/2007


10

What BPEL Comes From

Strong roots in traditional flow models

Plus many concepts from structured programming languages

All laid on top of WSDL and core XML specifications

Merge WSFL (Web Services Flow Language) and XLANG (Web Services for Business Process Design)

11

WS-BPEL Specifications

BPEL4WS 1.0 (7/2002) Original proposal from BEA, IBM, Microsoft

Combined ideas from IBM‟s WSDL and Microsoft‟s

XLANG

BPEL4WS 1.1 (5/2003) Revised proposal submitted to OASIS

With additional contributions from SAP and Siebel

WS-BPEL 2.0

Currently in OASIS undergoing standardization

Public Review draft specification available

12

WS-BPEL in the WS-* Stack

WS-BPEL

WSDL, Policy, UDDI, Inspection

SecurityReliable

MessagingTransactions

Coordination

SOAP (Logical Messaging)

XML, Encoding

Other protocols

Other services

BusinessProcesses

Description

Quality Of

Service

Transportand

Encoding

WS-BPEL 2.0 3/13/2007


13

Agenda

Motivation

OASIS and WS-BPEL

Main Concepts


Status and Support

14

OASIS Technical Committee

Charter of the WS-BPEL Technical

Committee Standardize

Common concepts for a business process execution

language for usage patterns including both the process

interface descriptions and executable process models

Explicitly do not address

Bindings to specific hardware/software platforms and other

mechanisms required for a complete runtime environment for

process implementation

> 280 committee members, including observers

30 active voting members, attending weekly calls

15

WS-BPEL Design Goals (1/2) Business processes defined using an XML-

based language

Web services are the model for process

decomposition and assembly

The same orchestration concepts are used for

both the external (abstract) and internal

(executable) views of a business process

Both hierarchical and graph-like control regimes

are used, reducing the fragmentation of the

process modeling space

WS-BPEL 2.0 3/13/2007


16

WS-BPEL Design Goals (2/2) An identification mechanism for process

instances is provided at the application message level

The basic lifecycle mechanism is in implicit creation and termination of process instances

A long-running transaction model is defined to support failure recovery for parts of long-running business processes

Language built on compatible Web services standards in a composable and modular manner

17

Agenda

Motivation

OASIS and WS-BPEL

Main Concepts


Status and Support

18

WS-BPEL Language Structure

Process

Partner links

Data handling

Properties and correlation

Basic and structured activities

Scopes

WS-BPEL 2.0 3/13/2007


19

BPEL and WSDL

BPEL processes are exposed as WSDL servicesMessage exchanges map to WSDL

operations

WSDL can be derived from partner definitions and the role played by the process in interactions with partners

20

Partner Links

Partner link: instance of typed connector

Partner link type specifies required and/or

provided portTypes

Channel along which a peer-to-peer

conversation with a partner takes place

Process 1WSDL

portType1Partner Link Type

WSDL

portType2

Process 2

21

BPEL Data Model: Variables

Scoped variables typed as WSDL

messages or XML Schema

elements/types

Activities input and output kept in

scoped variables

Assignment activities move data

around

WS-BPEL 2.0 3/13/2007


22

Basic Activities (1/2)

receive: Do a blocking wait for a matching

message to arrive

reply: Send a message in reply to a formerly

received message

invoke: Invoke a one-way or request-response

operation

assign: Update the values of variables or partner

links with new data

validate: Validate XML data stored in variables

empty: No-op instruction for a business process

23

Basic Activities (2/2) throw: Generate a fault from inside the business

process

rethrow: Forward a fault from inside a fault handler

exit: Immediately terminate execution of a business process instance

wait: Wait for a given time period or until a certain time has passed

compensate: Invoke compensation on all completed child scopes in default order

compensateScope: Invoke compensation on one completed child scope

extensionActivity: Wrapper for language extensions

24

Structured Activities (1/2) flow: Contained activities are executed in

parallel, partially ordered through control

links

sequence: Contained activities are

performed sequentially in lexical order

while: Contained activity is repeated while

a predicate holds

repeatUntil: Contained activity is repeated

until a predicate holds

WS-BPEL 2.0 3/13/2007


25

Structured Activities (2/2) pick: Block and wait for a suitable message to

arrive (or time out)

forEach: Contained activity is performed

sequentially or in parallel, controlled by a

specified counter variable

if-else: Select exactly one branch of activity from

a set of choices

scope: Associate contained activity with its own

local variables, fault handlers, compensation

handlers, and event handlers

Nesting Structured Activities<sequence>

<receive …/>

<flow>

<sequence>

<invoke ../>

<while …>

<assign>…</assign>

</while>

</sequence>

<sequence>

<receive …/>

<invoke …/>

</sequence>

</flow>

<reply …/>

</sequence>

26

27

Agenda

Motivation

OASIS and WS-BPEL

Main Concepts


Status and Support

WS-BPEL 2.0 3/13/2007


28

What is BPEL?

Web Services Business Process

Execution Language (WS-BPEL) is an

XML-based programming language to

describe high level business processes

A “business process” is a term used to

describe the interaction between two

businesses or two elements in some

business

29

BPEL Usage Example

Company A purchases something from company B

BPEL allows this interaction to be described easily and thoroughly such that Company B can provide a Web service

Company A can use it with a minimum of compatibility issues

30

What is a Web Service?

In terms of BPEL, the term „Web Service‟

means something with which you can

interact

A Web Service is typically described using

Web Service Description Language

(WSDL)

WSDL tells you exactly how you can

interact with the web service but says

nothing about how the web service works

Force you to rely on only the description of the

web service rather than anything in the

implementation

WS-BPEL 2.0 3/13/2007


31

Analogy for “WSDL” (Programming)

WSDL is like an interface or an abstract class

It tells you what the API is to the web service but it doesn‟t tell you anything about the implementation

(Real World)

A WSDL document is like a set of instructions for a household appliance

They tell you everything you need to know about how to use an appliance but they don‟t tell you the details of how the appliance does it

32

BPEL and Web ServicesBPEL allows you to write programs that

use web services and to write programs that are web services

Using BPEL, you can write a program that

Uses a web service to fetch the weather forecast for your zip code, check whether it will be raining this weekend

Use another web service to send you an SMS message telling suggesting that you go shopping (if it‟s raining) or go to the beach (if it‟s sunny)

33

BPEL Servers

In most cases, BPEL is used as a server side programming language

A common chain of events will as follows:

Web service client (user) requests something from the server (perhaps via a browser or another server)

Client request is received by the BPEL server

Client request is identified as a new request and a new BPEL process is used to serve that client

Client continues to interact with the BPEL process, making requests etc, until the interaction is complete

BPEL process disappears and client receives response

WS-BPEL 2.0 3/13/2007


BPEL Servers Diagram

34

This automatic creation of BPEL process instances in response to client requests is called 'create on demand'.

TPTP BPEL Engine It's primary focus is to act as an execution

engine which can be programmed using BPEL.

The common chain of events for the TPTP BPEL

engine is therefore slightly different:

User writes a BPEL program as a series of steps to

carry out

User runs BPEL program

One single copy of the BPEL program is created and

immediately executed

The running program logs information via local web

services

The program finishes and the user can look at the

logs35

TPTP BPEL Engine Diagram

36

In short, the TPTP BPEL engine doesn't do 'create on demand'.

WS-BPEL 2.0 3/13/2007


37

BPEL: XML Programming Language

Programming logic

BPEL

Data types XSD (XML Schema Definition)

Input/Output (I/O)

WSDL (Web Services Description Language)

38

A Simple Example

A simple example: a Hello World

program

XSD will be used to define the types

used in the program

WSDL will be used to define the web

service that will actually print the

string for us

BPEL will put all these things together

to create the string and print it

39

Hello World BPEL Program (1/3)<?xml version="1.0" encoding="UTF-8"?>

<process

xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"

xmlns:print="http://www.eclipse.org/tptp/choreography/2004/engine/Print"



<import importType="http://schemas.xmlsoap.org/wsdl/"

location="../../test_bucket/service_libraries/tptp_EnginePrinterPort.wsdl"

namespace="http://www.eclipse.org/tptp/choreography/2004/engine/Print" />

WS-BPEL 2.0 3/13/2007


40

Hello World BPEL Program (2/3)

<partnerLinks>

<partnerLink name="printService"

partnerLinkType="print:printLink"

partnerRole="printService"/>

</partnerLinks>

<variables>

<variable name="hello_world"

messageType="print:PrintMessage"/>

</variables>

41

Hello World BPEL Program (3/3)<assign>

<copy>

<from><literal>Hello World</literal></from>

<to>.value</to>

</copy>

</assign>

<invoke partnerLink="printService" operation="print" inputVariable="hello_world" />

</process>

42

Importing WSDL and XSD Files (1/2)

The “import” statement in BPEL is a

directive to import a WSDL or XSD file

Importing XSD files allows commonly used

data types or data types required for a

particular endpoint (thing that you speak

to) to be defined in a file separate to the

BPEL file

Importing WSDL files allows endpoint

descriptions (definitions of things that you

speak to) to be defined in files separate to

the BPEL file

WS-BPEL 2.0 3/13/2007


43

Importing WSDL and XSD Files (2/2)

The benefit is that entire endpoints and any associated data types that they need can be defined outside the BPEL file

Be re-used in many BPEL files

Note that WSDL files have a similar import mechanism allowing them to import common XSD files and even other WSDL files

<import importType="http://schemas.xmlsoap.org/wsdl/"

location="../../test_bucket/service_libraries/tptp_EnginePrinterPort.wsdl"

namespace="http://www.eclipse.org/tptp/choreography/2004/engine/Print" />

44

Partner Link Definition (1/2)

Partner Links can be thought of as

placeholders for things that you actually

speak to

A web service is described in full by the

WSDL files that specify

Partner Links allow you to have something

like an instance of the web service that

you speak to

A partner link basically maps to a WSDL

web service „portType‟, so one partnerLink

maps to a single web service

45

Partner Link Definition (2/2)

In the partner link definition, a

„partnerRole‟ attribue defines the web

service that this BPEL process will speak

to

<partnerLinks>

<partnerLink name="printService"

partnerLinkType="print:printLink"

partnerRole="printService"/>

</partnerLinks>

WS-BPEL 2.0 3/13/2007


46

Variable Definition

Variables are used to contain data in BPEL

A variable can either contain an XSD value or a WSDL message

Variables are used to pass data in and out of web service endpoints

<variables>

<variable name="hello_world"

messageType="print:PrintMessage"/>

</variables>

47

Variable Assignment Variables are manipulated in BPEL either

through use via web service endpoints or by assignment

This example shows a literal value being assigned into the variable „hello_world‟ which is a WSDL message with a part called „value‟

<assign>

<copy>

<from><literal>Hello World</literal></from>

<to>.value</to>

</copy>

</assign>

48

Web Service Invocation The invoke activity in BPEL invokes a web

service endpoint

This is where the BPEL process passes the

„Hello World‟ data (stored in the „hello_world‟

variable) to the „print‟ web service

The specified parterLink tells the BPEL engine

the address of the web service you want to

invoke here

The „print‟ operation specifies what you actually

wants the web service to do

<invoke partnerLink="printService" operation="print" inputVariable="hello_world" />

WS-BPEL 2.0 3/13/2007


49

Writing a printout web service (in Java)

Now we have our Hello world BPEL process that passes a string to a printout web service

We need to have a printout web service that will print the string out for us

We must define how to use the web service and how that web service is bound in a WSDL file

It is possible to split up a WSDL file so that a web service can be described once but implemented multiple times in different ways

50

WSDL File for printout Web Service (1/3)<?xml version="1.0" encoding="UTF-8"?>

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"

targetNamespace="http://www.eclipse.org/tptp/choreography/2004/engi

ne/Print"

xmlns:tns="http://www.eclipse.org/tptp/choreography/2004/engine/Print"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:format="http://schemas.xmlsoap.org/wsdl/formatbinding/"

xmlns:java="http://schemas.xmlsoap.org/wsdl/java/">



<message name="PrintMessage">

<part name="value" type="xsd:string"/>

</message>

WSDL File for printout Web Service (2/3)

<portType name="Print">

<operation name="print">

<input message="tns:PrintMessage"/>

</operation>

</portType>

<binding name="PrintPortWsifBinding" type="tns:Print">

<java:binding/>

<format:typeMapping encoding="Java" style="Java">

<format:typeMap typeName="xsd:string"

formatType="java.lang.String"/>

</format:typeMapping>


<java:operation methodName="print"

parameterOrder="value"/>

</operation>

</binding>

51

WS-BPEL 2.0 3/13/2007


WSDL File for printout Web Service (3/3)

<service>

<port name="JavaPrintPort" binding="tns:PrintPortWsifBinding">

<java:address

className="org.eclipse.tptp.choreography.jengine.internal.extensio

ns.wsdlbinding.wsif.ports.EnginePrinterPort"/>

</port>

</service>

<partnerLinkType name="printLink">

<role name="printService" portType="tns:Print"/>

</partnerLinkType>

</definitions>

52

53

WSDL Messages

WSDL messages are used to specify what

the containers should be like that hold data

a WSDL operation is invoked

They are essentially lists of parts, each of

which is an XSD simple or complex type

In this example, the „PrintMessage‟ is

defined as having a single part „value‟

which is of type „xsd:string‟ 

<message name="PrintMessage">

<part name="value" type="xsd:string"/>

</message>

54

WSDL Port TypesWSDL Port Types describe the API or

interface to the web service

A port type is a list of operations with „input‟s and „output‟s

<portType name="Print">


<input

message="tns:PrintMessage"/>

</operation>

</portType>

WS-BPEL 2.0 3/13/2007


55

WSDL Port Type Bindings

A „binding‟ in WSDL specifies how the

web service is actually implemented

Everything up until this point has

been abstract and has dealt with only

how to speak to the web service

The binding specifies what is on the

other side that you are speaking to

56

Most Common Bindings

A web service can be bound in many

different ways. The most common

bindings are

As a SOAP/HTTP web service – whereby

some implementation would be listening on a

specified port and would accept SOAP

messages over an HTTP transport

As a Java web service – whereby some java

class is mapped to the port type and is used

directly as an implementation

57

The Binding in the Example<binding name="PrintPortWsifBinding" type="tns:Print">

<java:binding/>

<format:typeMapping encoding="Java" style="Java">

<format:typeMap typeName="xsd:string"

formatType="java.lang.String"/>

</format:typeMapping>


<java:operation methodName="print"

parameterOrder="value"/>

</operation>

</binding>

A mapping has been created which specifies

that The port type operation “print” should be mapped to a Java

method called “print” the xsd type

The XSD type “string” has been mapped to the Java type “String”

WS-BPEL 2.0 3/13/2007


58

WSDL Service

A single port is an instance of a web service,

which is implemented via a particular binding

and which is available at a given address

The address is binding specific. The Java

binding knows how to interpret the “className”

attribute as a fully qualified Java class name<service>

<port name="JavaPrintPort" binding="tns:PrintPortWsifBinding">

<java:address

className="org.eclipse.tptp.choreography.jengine.internal.extensio

ns.wsdlbinding.wsif.ports.EnginePrinterPort"/>

</port>

</service>

Partner Link Types

Partner Link Types are actually not a

WSDL construct, but a BPEL construct

WSDL was around before BPEL and is

purely designed towards describing web

services

BPEL however requires that a partner link

instance be associated with a particular

WSDL port type

59

Partner Link Types in the Example

The BPEL partnerLink definition specified

a partner link type for the partner link and

also either a „myRole‟ or a „partnerRole‟

In this example, the „partnerRole‟ was

defined as „printService‟

This is because the BPEL process will be

speaking TO the „printService‟

<partnerLinkType name="printLink">

<role name="printService"

portType="tns:Print"/>

</partnerLinkType> 60

WS-BPEL 2.0 3/13/2007


Java Web Service Implementation

package

org.eclipse.tptp.choreography.jengine.internal.e

xtensions.wsdlbinding.wsif.ports;

public class EnginePrinterPort {

public void print(String s) {

System.out.println(s);

}

}

61

62

Agenda

Motivation

OASIS and WS-BPEL

Main Concepts


Status and Support

WS-BPEL Adoption: Products Active endpoints ActiveBPEL Designer

Active endpoints ActiveBPEL Enterprise server

BEA webLogic

Bexee BPEL Execution Engine (open source)

MidOffice BPEL editor (open source)

MidOffice BPEL engine (open source)

Twister (open source)

Eclipse BPEL Project (open source)

NetBeans Enterprise Pack 5.5 (open source)

63

WS-BPEL 2.0 3/13/2007


WS-BPEL Application Areas

Business Process Design

Autonomic Computing

Grid Computing

Semantic Web

64

WS-BPEL 2.0 Schedule

December 2006

First public review completed

Approved draft for second public review

March 2007

WS-BPEL 2.0 specification has been

submitted for standarization

65

References OASIS, “OASIS WS-BPEL TC”

http://www.oasis-

open.org/committees/tc_home.php?wg_abbrev=w

sbpel

Eclipse, “WS-BPEL 2.0 Tutorial”

http://www.eclipse.org/tptp/platform/documents/desi

gn/choreography_html/tutorials/wsbpel_tut.html

Dieter Koing, “WS-BPEL 2.0”,

http://www.science.uva.nl/~adam/workshop/prese

ntations/%20Koenig-WS-BPEL%202.0.pdf

66

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel




http://www.eclipse.org/tptp/platform/documents/design/choreography_html/tutorials/wsbpel_tut.html

http://www.eclipse.org/tptp/platform/documents/design/choreography_html/tutorials/wsbpel_tut.html

http://www.science.uva.nl/~adam/workshop/presentations/ Koenig-WS-BPEL 2.0.pdf














web services development

Documents