Dynamism in Web Services Workflows
Abstract:
The objective of this article
is to report on the seminar topic "Dynamic Web Services Workflow based
System". In traditional [33] workflow based systems the various
participants that take part in a specific business process are pre-determined,
but the new proposals in the area of Web Services workflows propose the dynamic
lookup of the participants. This will lead to a Dynamic Workflow based Web
Services system. This article introduces and elaborates on these aspects in
detail.
|
Seminar Presented by / on |
Suresh Chande / 19 May 2003 |
|
Course |
58303108 - Modeling Workflow |
|
Handled by |
Juha Puustjärvi PhD |
|
Article Submitted by |
Suresh Chande |
|
Email Contact |
|
|
PDF Format |
|
|
Presentation |
1. Introduction
Workflows are
semi-automised processes whose execution is carried out in an engine ensure
proper execution of a specific business process. The traditional definition of a
Business Process and Workflow are as defined here below:
Business Process: "A set of one or more linked procedures or
activities which collectively realize a business objective or policy goal,
normally within the context of an organization structure defining functional
roles and relationships"[33]
Workflows: "The automation of a Business Process in whole
or a part, during which documents, information or tasks are passed from one
participant to another for action, according to a set of procedural rules
"[33]
To a great extent in
the current and the traditional Workflow systems the various participants that
take part in a specific business process are pre-determined, but the new
proposals in the area of Web Services workflows propose the dynamic lookup of
the participants. This will introduce dynamism into Workflow system. We will
investigate this aspect in the article.
We will begin with an
introduction to Workflows and provide a need for them in the Web Services arena
after briefly introducing the Web Services. We will then continue to discuss
the available workflow technologies and make brief comparisons between them. We
will continue to look into what it means in bringing dynamism into Workflows.
We will look into DAML-S and understand how it enables dynamism in Workflows
and finally conclude with a look into the future directions of dynamic
workflows.
2. An Introduction to Workflows
Workflow technologies have been applied to business process automation for several years now and close to a decade since WfMC[33] has started to develop a standardized approach to provide a solution to semi-automise business processes. The Business Process as defined previously consists a several smaller activities or procedures that need to be processed together to achieve a business goal. The smaller activities or procedures could involve processing carried out by software components, human users, and interaction with physical entities from the external world to the software world. These together when processed will achieve a specific business objective.
In order to automise the processes involved within an organization, it is required to be able define the steps that could be interpreted by computer in order to automise parts of the processes. Process Definition establishes this. The Process Definition encapsulates each individual steps involved in completing or achieving a specific objective. The steps in this case are termed as Activities. The several activities are linked together to represent the order of processing of these activities that is carried out in a process. The Figure 1 below provides a pictorial representation of a Business Process Definition.
Figure 1: Business Process Definition
The Process Definition is pictorially represented as Acyclic directed graph. A node in the graph depicts each of the activity, while the edges of graph represent the Transition from one activity to another. The transition is guarded by a Transition condition that is to be evaluated and once it is being satisfied the phase of execution of a particular process step is transitioned to the next activity.
The Process is normally represented by an acyclic graph; if there
are requirements for cyclic graph it is dealt with very carefully so as to have
clear exit condition
A Process can also contain sub processes,
which are the same as processes but are utilized as part of another process.
For example: A purchase order process consisting of sub-processes such as:
Inventory Check, Payment Control and Goods dispatch sub-processes. The
sub-processes can be processes by different mechanism:
- Blocking:
Makes the parent process wait until the completion of the
Sub-Processes
- Non-Blocking: Where either of the process (parent
& Sub-process) can complete independent of each other.
Figure 2:
Business Process and Sub Processes
Figure 3:
Business Process and Activities
Activity is a single step of execution
within a business process definition and is usually denoted by the node in a
graph. Activities can be of two types namely: Atomic Activity, which cannot be
broken down further into smaller tasks. The Nodes 1, 3, 4 and 5 in the Figure 3 can be considered atomic activities. The Complex
Activity can contain few other Activities as depicted by the node 2 in Figure 3, which basically contains 4, 5 and 6 or then
containing a sub-Process as depicted in the Figure 2.
Transition is the flow of
execution or control and data from one Activity to another. Transition is usually guarded by a condition
and this is typically a logical condition which when satisfied will advance the
process execution from one activity to another.
Activity Execution: When we consider the
execution of the activities in a process, the execution can be carried out four
different styles, namely: sequential, parallel, conditionally and iteratively.
- Sequential:
Execution is transitioned to only one Activity after the currently
executing Activity is completed, for e.g. 1->2->5
- Parallel:
There could more than one activity simultaneously executed within the
process execution, for e.g. Activity 1 is to Activities 2 & 3. When we
consider the node 7 in the Figure 3, the nodes 3 and 4 are considered to be joining
nodes. These usually is the case when the execution of the process is
concurrent, i.e. more than one activity are executed at a particular
instance of time.
- Conditional: Decides which activity executed is on
the next transition based on pre-determined conditions, for e.g. After
Activity 1 either Activity 2 or then Activity 3 is transitioned to.
- Loop:
Execution to Activities is iteratively, with the Loop guarded by an Exit
Condition, for e.g.: 1->2->6->1->2 ->...
Transition condition is evaluated on
various states of the process:
·
Once an
Activity has completed its execution.
·
Once all the
joining activities have finished and reached this part of the graph.
·
Once a set
number of joining activities have completed their execution.
The Process Definition, Activities and the
transition currently discussed defines the flow of execution and the data
within a Workflow based system. There are several other runtime key
functionalities within a process execution, such as:
·
Exception
Handling
·
Transactions
Handling
·
Compensation
Handling
·
Property
·
Fault Triggers
·
Service
Lookups
·
Multiple
Service Interactions
We will discuss each of them in the
following text
Exception Handling: The execution of a Process requires handling any possible failures to carry out the execution of the process. This is handled by the Exceptions in the workflow. They are responsible to handle the possible error or fault conditions that may occur during the execution of the complete process. The handling of the Exception condition could themselves be the execution of further activities to overcome the exception that has occurred. These exceptions are usually handled by:
· Retrying the similar activities that failed to execute
· Perform a clean up operation to revert the state of the process execution so as to undo the affects of the Activities processed so far in the complete process execution
· Notify the corresponding recipient of the failure to continue the process execution
Transactions handling: The
execution of a set of activities within a process execution is considered to a
single consistent unit of execution and any success or failure is applied to
this complete set of activity execution. The completion of the execution of all
the activities together is reflected to the external world only once all the
activities are executed successfully, incase of failure of any single activity
is considered to fail the complete transaction and hence the effects of the
already executed activities is undone to put the state of the process back to
the state it was in prior to the execution of the transaction.
Compensation Handling: This contains execution of a set of activities, which will perform part
of task which will try to rollback the system as best possible to the original
state prior to the start of the Transactions.
Property: This functionality allows alter and refer
the values of a property within context of execution of a specific Business
process instance. The property represents the state parameters of the execution
of a specific process.
Fault Triggers: Allows raising a fault condition during the execution of the Business Process
. The faults are
handled by the Fault handlers within a process execution, similar to Exception
handling.
Multiple Service Interactions: The atomic activities within a process
are considered to invoke a specific service of that particular business
organization. This feature enables the definition of the interconnection between the different
Services (operations within as well).
Service Lookup: This is an advanced feature not available
in any traditional workflow based systems. They are being defined under the Web
Services Workflows, which will be discussed in later sections. This feature facilitates dynamic lookup into a public
and business specific registry to identify the next activity within the
execution of the Business Process.
In this we had
A
very brief introductions of Workflows, Process definition and the runtime
functionalities of a workflow based systems. We will in the next section
discuss in brief about Web Services and the basic elements that consists of a
Web Services solution. We need to understand this in order to understand
dynamism in Web Services workflows.
3. An Introductions to Web Services
Web Services have been applied
in wider solutions today than a year ago, but they are still not available and
deployed widely in commercial solutions. In this section we will briefly discuss
about the basic of Web Services. To start with let us look at the definition of
Web Services; Web Services
are the means of exposing an organization's services to its end-user consumers
or partners over the Web utilizing open Web-based standards, which are agnostic
to development platform used, vendor tools and the underlying implementation
specifics. The
Core Web Services standards are being specified by the W3C [34]. The definition of Web Services as specified by W3C is: “A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML-based messages conveyed by Internet protocols. [34]
”
The basic elements of Web
Services are a Messaging Framework and a Service Description Framework. The
Message Framework provides a mechanism for two peer computing systems to
exchange messages in-order to communicate and exchange the requests and
optionally the responses to perform their own required set system objectives.
The Message Framework in specified by the SOAP protocol (previously known as
Simple Object Access Protocol). The Service Description Framework specifies the
services interfaces and the set of messages that can be exchanged with a
specific service interface. The service description is specified by WSDL (Web
Services Description Language). XML [2] and XML schema [3] form the core of these framework, where XML is
utilised for Data encapsulation and structuring, while the XML Schema is
utilised for data setting, formatting and validation purposes. We will continue
to discuss SOAP and WSDL in the following sections.
SOAP
SOAP defines a simple and lightweight mechanism for exchanging structured and typed information between peers over the web in a decentralized, distributed environment using XML
SOAP Message
Structure
SOAP message consists of mainly
there different parts: Envelope, Header and Body. Envelope is top-level root element of a SOAP
Message, which contains the Header and Body element. Header is a collection of zero or more SOAP header blocks each
of which might be targeted at any SOAP receiver within the SOAP message path.
Header contains information about processing the SOAP message and specifically
about the information contained in the Body. The Body is a collection of zero
or more element information items targeted at an ultimate SOAP receiver
in the SOAP message path. The SOAP message path contains zero or more inter-mediaries nodes and
a single ultimate recipient of the SOAP message. The Figure 4 depicts the SOAP message structure. The nodes to
express a fault that is occurred in processing the SOAP message utilize the
SOAP Fault in the SOAP message.
Figure 4: SOAP Message Structure
SOAP
specification supports two styles of handling the SOAP messages received at the
Nodes, namely RPC and Document style:
- Remote Procedural Call (RPC) Style:
This enables the SOAP engine to directly invoke the underlying software system, without any major efforts from the developer in translating the message to underlying system specifics
- Document Style:
This enables the SOAP engine to deliver the Message to the corresponding Message Handler. The developer takes the responsibility to handle the messages accordingly within such handlers.
The closer the system is to the Message structure the better the overall performance. If it needs further transformation or translation it will affect the overall system performance
The Figure 5 and Figure
6 show an example of SOAP request and a response
Message expressed in a RPC styled message. The mandatory parts of the SOAP
message are shown in colour red. The headers are optional and are expressed in
blue colour. The Body contains the message part meant for the final and
ultimate recipient of this SOAP message. The RPC\style of the message is
represented by the element, which is in green colour.
Figure 5: SOAP Request Message Figure 6: SOAP Response Message
SOAP
Processing Model
The SOAP message processing is as depicted in the Figure 7. The basic steps involved in handling a SOAP message
is as described below:
- Determine the set of roles in which a specific
node is to act. The contents of the SOAP envelope, SOAP header
blocks and the SOAP body are inspected in making such determination.
- Identify all header blocks targeted at the node
that are mandatory.
- If one or more of the SOAP header blocks
identified are not understood by the node then generate a single SOAP
fault with the Value of Code set to "env:MustUnderstand". If
such a fault is generated, any further processing MUST NOT be done.
- Process all mandatory SOAP header blocks targeted
at the node and, in the case of an ultimate SOAP receiver, process the
SOAP body as well. A SOAP node MAY also choose to process non-mandatory
SOAP header blocks targeted at it.
Figure 7:
Message processing Model
WSDL
WSDL defines an XML based grammar to define
web services as a collection of the communication end points capable of
exchanging messages (procedural or document oriented), which follow a specified
message structures in order to satisfy the functioning of a software system
over a networked environment.
The description is modeled into
abstract and concrete parts. The
abstract part contains end points and messages and the concrete part binds
these endpoints and messages to a concrete network deployment and data format
bindings
WSDL provides a means of specifying Data types used Messages
Endpoints of a Web Services
Endpoints are defined by a set of
Input messages Output messages Fault
messages.
These end points are then bound to a messaging
framework such as SOAP. The messaging framework is finally bound to a concrete
instance of the service by specifying the addressing and the transport
protocols. (for example: HTTP based URIs).
WSDL Document Structure
The Figure 8 provides a pictorial representation of the WSDL document structure. The root element
Definitions contains the complete web service definition. The Documentation element is an optional sub-element used for the documentation purposes, which is human readable. The Types contains the data type definitions ( based on the XML Schema datatypes[19]). The Messages is the abstract definition of the data being transmitted between two Web Service nodes. The PortType helps specify a set of abstract Operations, where the Operation refers to Input, Output and Faults messages that can be exchanged with a specific Web Service endpoint. This is very similar to Interfaces when considering Object Oriented Programming. The Binding element as the name suggest specifies a concrete protocol and data format specifications for the operations and messages defined by a particular portType. This is where the abstract service definition is bound to a concrete Messaging framework. In the case of typical Web Services as defined by the industry it is bound to SOAP messaging framework. The binding can also be done to alternative web protocols such as HTTP, SIP, etc. The Service element is utilized to aggregate a set of related ports to specific addressable locations. The Port is used to specify a concrete implementation specific address for a binding
. For example an URL.
Figure 8:
WSDL Document Structure
Here is an overall WSDL
skeleton document shown in the Figure 9.
Figure 9: WSDL Skeleton Document
Web Services
Model
The Web Services consists of several key players
such as Web Services Provider, Broker and finally a Consumer. The complete
process that is involved in Web Services is developing, deploying, publishing,
Discovering and consuming. These process steps are carried out by each of the
players specifically responsible for a particular activity. The Service
provider develops and deploys the Web Service in a particular web enabled infrastructure
(portal), after which he publishes the information about the Web Service with a
Web Services broker or a registry (UDDI), which is locally or globally hosted.
The Web Services consumer uses the services of a WS Broker or a registry, if
the consumer does not already have the information about a particular WS the
user would like to utilise, to search for a relevant WS. Once the particular WS
is found the WS consumer invokes the specific WS end points to access the
required service functionality. Inspecting the WS description, as specified by
the WSDL, identifies the Services functionality
Document. This complete process is depicted in the
Figure 10
Figure 10:
Web Services Process
Let us now consider an example of a travel agency
who wants to provide a Web Service, which utilises the existing legacy,
services which are not exposed to the web world. The organization decides a set
of services (language, weather, comparison, ticketing, etc) that need to be
included to enable a particular service functionality (personalized tourism).
The Web Service is defined based on the service
requirements identified by the organization deciding to provide the services.
The developer implements the Web service utilising the existing services, which
are either internal services developed using legacy technologies or existing
Web Service itself, by looking up a public registry. Once such a service is
implemented, the developer can expose the Web Service to the external world by
deploying this into a portal. Then later by publishing the service definitions
into a UDDI registry this service can be discovered by external partners. This
Web Service can be utilised by its partners or also within the same
organization to develop a web application with UI on top of the existing WS to
provide appealing services to the human user directly. The Figure 11 shows the above described scenario.
Figure 11: Web Services Model
4. Web Services Workflows
The basic Web Service standards
provide only the means of exchanging messages and description only the simple
interfaces or end points with which the corresponding messages are required to
be exchanged. They miss out very many important aspects to provide a complete
software solution. The Web Services rely on the fact that the Web Services
descriptions are interpreted by human beings, analysed and then included into
their business logic to consume the Web Services. This does not seem to add any
greater value from the Web Services consumer point of view and as well as to
utilise software system to simplify the consumption of such Web services.
The software systems can
simplify WS consumption process and even automise in some cases if the Web
Service can provide greater details about the runtime processing information on
how to utilise the Web Service endpoints. The Web Services can be utilised within
a workflow-based system
The current standards have
several limitations and do not completely specify in a system interpretable
form. Few of these limitations are:
- Inter-relation
between the Web Services The Service interfaces are exposed as end points
for a set of services. There is no method to relate these interfaces to
each other.
- Exception
handling, how to address this can there be a number of re-tries?
- Can
we describe compensations to be executed as a failure recovery; these
cannot be done with the current standards. They have to be explicitly
coded within the client implementation. Here we are moving the complete
logic to the client side implementations.
- The interfaces exposed to the client are too granular when we are considering SOAP/RPC oriented WS Exposure.
- How can we reduce this? Can we not provide a Composite Service, which will allow batch-processing sort of functionality? This can not be done with the help of current standards
- .
- Transactions,
is not emphasized in the basic WS standards. There are proposals (BTP [19] / WS-Transaction [22]), but we see that they are being applied more
in context to the Workflow system functionality.
- How can we provide value-added services on top of our current simple WS interfaces? There is not much provided by the current WS standards, the functionality such as Reliability / Guarantees can be built on top of this by providing a Workflow based Engine which can persist the communication within a context of service invocations and maintain the level of guarantees.
The basic Web Service standards miss out several key details required for the Web Services
Consumers to utilise a Web
Service in non-ambiguous manner. The information regarding these in
standardized manner will enable several tools and applications to simplify the
consumption of a Web Services. Few of the missing elements from the Web Service
standards are:
·
Order of end
point execution of a specific WSI
·
Message
Correlation between the Service interfaces / endpoints
·
Inter-relation
between services interfaces
·
Status of the
asynchronous request
·
Transaction
handling
·
Error Handling
·
Composition of
service interactions
·
Exceptions
& Compensations
·
Simplified
interfaces (Composite Services)
Conversation State\ Context management
Not all of these issues are to be addressed for service consumptions; some are addressed today with the help of
Developer Guides, Message Level
Conventions, but they still make it laborious process in developing systems
utilizing existing WSI’s
Workflows for Web Services
The industry has identified that the best way
to approach these limitation as discussed in the previous section is by develop
workflow technologies for Web Services. The industry has several terms listed
for this, such as Web Services Choreography, Orchestration, Conversation, and
Flow Languages.
As we can see from the Figure 12 that the WS Workflow is being proposed as higher
level abstraction on top of the current Web Services standards. This
specification will utilize the WSDL and SOAP as the underlying WS core
standards. There are several proposals
currently brought forward by industry players, consortiums and standardizations
forums. The outstanding ones being the WSCI [30] from the W3C and the BPEL4WS [24] from OASIS standardization efforts. The BPML [27] is also another technically potential standard being
proposed by the BPMI [10].
As we can see from the Figure that the proposals build
on top of the existing WS standards they enable smooth development and backward
compatible. The Workflow technologies
applied to Web Services provides several benefits in filling the gaps and
limitations demonstrated by the basic Web Service standards.
Web Service Workflow provides several benefits, such
as:
·
Enables the
exposure of a process oriented model to Web Service Interfaces
·
Provide a
simplified interface to a set of interfaces; Facilitate simplified packaging of
a set of interfaces.
·
WS with
choreography defined can be better managed when compared to current WSIs,
specifically when there exists inter-dependent set of WSIs (Payment, Profile,
Delivery & Presence).
·
Provides a
clear usage model for a set of WSIs.
·
Allows
creation of composite services
·
Enables
specify design patterns depicting the best practices of using a set of WSI's
·
Allows
Provisioning of an execution environment which can guarantee execution of the
complex/composite service invocation with compensations etc (for e.g. Delivery
& Payment)
·
Provides a good environment for Long Running Middleware infrastructure.
Where there can be pre-defined set of operations that need to be performed over
a period of time (even Scheduled). This will simplify the client interactions
with the WSIs, but in turn needs to interact with the process to manage and
monitor the status of such execution.
·
The most
important factor is also that it helps define a coarse grained interfaces to
the existing granular interfaces (RPC / Document style), reducing the
interactions between the WSC and Choreography provider.
·
Helps monitor
that status of the request and even manage the lifecycle of the process
Figure 12: Web Services Workflows
There are several industry
proposals for Workflows and specifically for Web Services Workflows. In the next
section we will try to compare them from the functionality point of view.
The traditional workflow
systems, which are non-web Services enabled, are:
- Workflow
Management Coalition (WfMC), which is a 285 Member consortium
- Web
Services Conversation Language (WSCL), a primitive with a very basic
functionality specified utilizing a XML based workflow language, which was
proposed by Hewlett Packard
- Business
process Specification Schema (BPSS) proposed by the ebXML set of
standards, specified at OASIS standardization body.
- Extended
Distributed Object Computing (EDOC), specified at OMG.org is currently
planning to propose a Web Services profile to EDOC.
- WS
- Conversation Protocol, currently proposed by (IBM) – and is for Java Connector Architecture
JCA Implementation to work along with J2EE servers
- Business Process Management Language (BPML) which is specified by a industry consortium namely BPMI – Instalio
The workflow proposal currently including
Web Services are as listed below:
- XLANG
– which was proposed by Microsoft and utilized in their product namely the
BizTalk, this has currently been obsolete by the new proposal BPEL4WS
- Web
Services Flow Language (WSFL) – This was proposed by IBM and was utilized
in IBM’s product Web
Sphere MQ Workflow Product
this has currently been obsolete by the new proposal BPEL4WS
- Web Services Choreography Interface (WSCI), which was originally proposed by BEA Systems, Intalio, SAP & Sun Microsystems and is currently being taken as the basis of the W3C standardization efforts along with the WSCL.
- BPEL4WS (v1.1) + WS Coordination + WS Transaction are a set of specifications proposed originally by IBM, Microsoft, Seibel Systems, SAP & BEA Systems and is currently being standardized at the - OASIS Web Services for Business process and Execution Language (WSBPEL) Technical Committee
- DAMLS
– is the DARPA Agent Markup Language for Services supported activity by Defense Advanced Research Projects Agency
(DARPA- Agent Markup Language, DAML+OIL, W3C,)
We will compare the WSCL, WSCI, BPEL4WS, XLANG, BPML and DAMLS
Proposal in
the following sections, as they are proposals that might be suitable to
compare, as they are relevant when compared to the Web Services Workflows.
