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
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
WHAT
Bindings Port Service
HOW
WHERE
5
Interoperability
WSDL description
Client1
Service1
J2EE ltVendor Agt
ltVendor Cgt
WSDL description
Client2
Service2
.NET ltVendor Bgt
ltVendor Dgt
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
• gt APIs 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) gt 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
ltwsdlmessage name"addIntResponse"gt
ltwsdlpart name"addIntReturn" type"xsdint" /gt
lt/wsdlmessagegt ltwsdlmessage
name"addIntRequest"gt ltwsdlpart
name"a" type"xsdint" /gt ltwsdlpart
name"b" type"xsdint" /gt lt/wsdlmessagegt ltwsdl
portType name"AddFunction"gt
ltwsdloperation name"addInt" parameterOrder"a
b"gt ltwsdlinput message"impladdIntRe
quest" name"addIntRequest" /gt
ltwsdloutput message"impladdIntResponse"
name"addIntResponse" /gt
lt/wsdloperationgt lt/wsdlportTypegt
// possible implementation of WS //
AddFunction.jws public class AddFunction int
addInt(int a, int b) return(ab)
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//localhost8080/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.WSDL
2Java \ http//localhost8080/axis/AddFunction.j
ws?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//localhost8080/axis/AddFunction.jws?wsdl"
String nameSpaceUri "http//localhost808
0/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 APIs 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 APIs, 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

activity1
input data1
activity3
output data
activity2
input data2
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 Partici
pants perform the work represented by a workflow
activity instance and can be human or machine
resources
23
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

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

• 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

• 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

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

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
• gt 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
• gt Definition of a Choreography
• Still BPEL is not used for choreography
• WS-CDL (Choreography Description Language)
• A choreography is not an executable process -gt
  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
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

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

Web Service
WSDL Loan Approval PortType
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
Web Service
Web Service
WSDL Loan Approval PortType
Loan Approval Process
receive
Financial Institutions Web Service (Loan
Approver)
invoke
reply
40
WS-BPEL PartnerLinks
Process

• 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

Partner Links
Variables
Correlation Sets
Fault Handlers
Compensation Handlers
Event Handlers
Activities
Receive
Reply
Invoke
41
Composition of Web Services
Service P
Service A
Service B
receive
invoke
receive
invoke
invoke
As WSDL
Ps WSDL
Bs WSDL
F
Partner Link Type
Partner Link Type
42
WS-BPEL variables
Process

• Variables
• Save data which is exchanged within processes
• Activities access data stored in variables

Partner Links
Variables
Correlation Sets
Fault Handlers
Compensation Handlers
Event Handlers
Activities
Receive
Reply
Invoke
43
BPEL- WSDL- XML Schema
44
WS-BPEL primitive activities
Process

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

Partner Links
Variables
Correlation Sets
Fault Handlers
Compensation Handlers
Event Handlers
Activities
Receive
Reply
Invoke
45
WS-BPEL structured activities
Process

• 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

Partner Links
Variables
Correlation Sets
Fault Handlers
Compensation Handlers
Event Handlers
Activities
Receive
Reply
Invoke
46
WS-BPEL correlation sets
Process

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

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

51
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

52
Disadvantages of WS-BPEL

• Static process composition.
• Process participants (partners 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.

53
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

54
Construction by composition
55
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

56
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

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

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