Table of Contents

INTRODUCTION 2

LITERATURE SURVEY 3

Section 0.1 Workflows 3

Section 0.2 SOA: Service Oriented Architecture 7

Section 0.3 Web Services Protocols and Technologies 10

Section 0.4 BPEL: Business Process Execution Language 19

Section 0.5 BPEL solution for a Business Process 23

CHAPTER 1: ANALYSIS & REQUIREMENT SPECIFICATION 26

Section 1.1 Problem Statement 26

Section 1.2 Main Goals of the system 26

Section 1.3 Hardware & software requirement specification 26

Section 1.4 Use Case Analysis 26

DESIGN AND IMPLEMENTATION 29

Section 1.5 Design Strategy 29

Section 1.6 Architecture 30

Section 1.7 Sequence Diagrams 32

Section 1.8 Implementation Strategy 33

TEST CASES AND RESULTS 38

Section 1.9 Test Cases 38

Section 1.10 Snap Shots 39

CONCLUSION AND FUTURE SCOPE 45

Section 1.11 Conclusion 45

Section 1.12 Future Scope 45

REFERENCES 46

INTRODUCTION

Some of the primary objectives of any organization for involving IT infrastructure in its business processes are to:

Several tools/architectures have been envisaged to cater for the above needs of the industry, among which the quintessential winner is SOA or Service Oriented Architecture.

Currently most of the architects and developers are addressing the complexity of their application and IT environments with SOA, which facilitates the development of enterprise applications as modular business services that can be easily integrated and reused, creating a truly flexible, adaptable IT infrastructure.

Each industry, maintains a few divisions would be earmarked to cater for specific needs of the employees within it. Some such typical divisions are:

Each of these teams has specific functionality and offers them as business services to the whole employee community including other such teams and its own team members.

Corollary to these services, each employee may participate in some specific workflows, based on his/her designation and role.

Ex: Manager approves or rejects specific requests for training/vacation/leave by an employee reporting to him.

Most of the above processes are usually unstructured and are either paper and/or mail based.

This project, Implementation of Workflows Using Business Process Execution Language, aims to automate some of these services like ‘HelpDeskServiceRequest’, ‘VacationRequest’. It also stands as a POC for the capabilities of BPEL language to automate, and orchestrate such business processes and corresponding workflows.

LITERATURE SURVEY

Section 0.1Workflows

Workflow [4], at its simplest form is the movement of documents and/or tasks through a work process. More specifically, workflow is the operational aspect of a work procedure:

As the dimension of time is considered in Workflow, Workflow considers "throughput" as a distinct measure.

In general we can classify workflows in to two paradigms:

Scientific Workflows:

Scientific Workflows [4] are mostly concerned with throughput of data through various algorithms, applications and services,

Scientific workflows found wide acceptance in the fields of Bioinformatics and Cheminformatics in the early 2000s, where they successfully met the need for multiple interconnected tools, handling of multiple data formats and large data quantities. Also, the paradigm of scientific workflows was close to the well-established tradition of Perl scripting in life-science research organizations, so this adoption represented a natural step forward towards a more structured infrastructure setup.

Business Workflows:

Business workflow [4] concentrates on scheduling task executions, including dependencies, which are not necessarily data-driven and may include human agents.

Business workflows are more generic, being able to represent any structuring of tasks, and are equally applicable to task scheduling within a software application server and organizing a paper or electronic document trail within an organization. Their origins date back to the 1970s, when they were purely paper-based, and the principles from that period made the transition to modern IT infrastructure systems.

Note: For the purpose of this project we would limit our scope to business workflows. Reference to workflow from here on would be to business workflows alone.

  1. Workflow process definition:

A workflow process definition, is an aggregation of

Main concepts for the description of the dynamic aspects of a workflow system are activities and transitions.

Workflow Process activity: An activity is a given unit of work, which will be executed by a participant using computer applications and relevant data Additionally, every activity is characterized by a start- and end-time as well as the fact whether it can be executed automatically or manually by a workflow participant

Workflow Process Activity subtypes can be classified as

Workflow transitions: The transition information specifies the control flow between activities. It consists of a

  1. Workflow Patterns

In this section, Workflow patterns [3] capturing elementary aspects of process control are discussed.

Some of the basic workflow patterns are:

Sequence

Description: An activity in a workflow process is enabled after the completion of another activity in the same process.

Synonyms: Sequential routing and serial routing.

Examples:

Implementation: The sequence pattern is used to model consecutive steps in a workflow process and is directly supported by each of the workflow management systems available. The typical implementation involves linking two activities with an unconditional control flow arrow.

Note: The next two patterns can be used to accommodate for parallel routing.

Parallel Split

Description: A point in the workflow process where a single thread of control splits into multiple threads of control which can be executed in parallel, thus allowing activities to be executed simultaneously or in any order.

Synonyms: AND-split, parallel routing, and fork.

Examples:

Implementation:

All workflow engines known to us have constructs for the implementation of this pattern. One can identify two basic approaches: explicit AND-splits and implicit AND-splits.

Workflow engines supporting the explicit AND-split construct (e.g. Visual WorkFlow) define a routing node with more than one outgoing transition which will be enabled as soon as the routing node gets enabled.

Workflow engines supporting implicit AND-splits (e.g. MQSeries/Workflow) do not provide special routing constructs - each activity can have more than one outgoing transition and each transition has associated conditions. To achieve parallel execution the workflow designer has to make sure that multiple conditions associated with outgoing transitions of the node evaluate to True (this is typically achieved by leaving the conditions blank).

Synchronization

Description: A point in the workflow process where multiple parallel sub processes/activities converge into one single thread of control, thus synchronizing multiple threads. It is an assumption of this pattern that each incoming branch of a synchronizer is executed only once

Synonyms: AND-join, rendezvous, synchronizer.

Examples:

Implementation:

All workflow engines available support constructs for the implementation of this pattern. Similarly to Pattern 2 one can identify two basic approaches: explicit AND - joins (e.g. Rendezvous construct in Visual WorkFlow or Synchronizer in Verve) and implicit joins in an activity with more than one incoming transition (as in e.g. MQSeries/Workflow or Forte Conductor).

Note: The next two patterns are used to specify conditional routing. In contrast to parallel routing only one selected thread of control is activated.

Exclusive Choice

Description: A point in the workflow process where, based on a decision or workflow control data, one of several branches is chosen.

Synonyms: XOR-split, conditional routing, switch, decision.

Examples:

Implementation:

Similarly to Pattern 2 (Parallel split) there are a number of basic strategies. Some workflow engines provide an explicit construct for the implementation of the exclusive choice pattern (e.g. Tibco Staffware, Visual Workflow). In some workflow engines (MQSeries/Workflow, Verve) the workflow designer has to emulate the exclusiveness of choice by specifying exclusive transition conditions. In another workflow product, ‘Eastman’, a post-processing rule list can be specified for an activity. After completion of the activity, the transition associated with the first rule in this list to evaluate to true is taken.

Simple Merge

Description: A point in the workflow process where two or more alternative branches come together without synchronization. It is an assumption of this pattern that none of the alternative branches is ever executed in parallel

Synonyms: XOR-join, asynchronous join, merge.

Examples:

Implementation:

Given that we are assuming that parallel execution of alternative threads does not occur, this is a straightforward situation and all workflow engines support a construct that can be used to implement the simple merge. It is interesting to note here that some languages impose a certain level of structured-ness to automatically guarantee that not more than one alternative thread is running at any point in time. Visual WorkFlow, for example, requires the merge construct to always be preceded by a corresponding exclusive choice construct. In other languages workflow designers themselves are responsible for the design not having the possibility of parallel execution of alternative threads.

 Section 0.2SOA: Service Oriented Architecture

SOA [1] is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused. Applications in SOA are built based on services.

  1. Service

A service [2] provides a specific function, typically a business function, such as analyzing an individual's credit history or processing a purchase order. A service can provide

Services that perform a related set of business functions, as opposed to a single function, are said to be "coarse grained".

Multiple services can be used together in a coordinated way. The aggregated, or composite, service can be used to satisfy a more complex business requirement. In fact, one way of looking at an SOA is as an approach to connecting applications (exposed as services) so that they can communicate with (and take advantage of) each other. In other words, a service-oriented architecture is a way of sharing functions (typically business functions) in a widespread and flexible way.

  1. Web Service

A web service [2] is a service that communicates with clients through a set of standard protocols and technologies. These web services standards are implemented in platforms and products from all the major software vendors, making it possible for clients and services to communicate in a consistent way across a wide spectrum of platforms and operating environments. This universality has made web services the most prevalent approach to implementing an SOA.

  1. Advantages of SOA

SOA allows for the reuse of existing assets where new services can be created from an existing IT infrastructure of systems. In other words, it enables businesses to leverage existing investments by allowing them to reuse existing applications, and promises interoperability between heterogeneous applications and technologies. SOA provides a level of flexibility that wasn't possible before in the sense that:

SOA uses the find-bind-execute paradigm as shown in below figure. In this paradigm, service providers register their service in a public registry. This registry is used by consumers to find services that match certain criteria. If the registry has such a service, it provides the consumer with a contract and an endpoint address for that service.

Figure 2-1: Find-Bind-Execute Paradigm

SOA-based applications are distributed multi-tier applications that have presentation, business logic, and persistence layers. Services are the building blocks of SOA applications. While any functionality can be made into a service, the challenge is to define a service interface that is at the right level of abstraction. Services should provide coarse-grained functionality.

There are many reasons for an enterprise to take an SOA approach, and more specifically, a web services-based SOA approach. Some of the primary reasons are:

Reusability:

Reusing functionality that already exists outside or inside an enterprise instead of developing code that reproduces those functions can result in a huge savings in application development cost and time. The benefit of reuse grows dramatically as more and more business services get built, and incorporated into different applications.

A major obstacle in taking advantage of existing code is the uniqueness of specific applications and systems. Typically, solutions developed in different enterprises, even different departments within the same enterprise, have unique characteristics.

You need to understand how and where these applications and systems run to communicate with them. The work involved in doing this analysis and the development effort in tying these pieces together can be very time consuming.

In an SOA, the only characteristic of a service that a requesting application needs to know about is the public interface. The functions of an application or system (including legacy systems) can be dramatically easier to access as a service in an SOA than in some other architecture. So integrating applications and systems can be much simpler.

Interoperability:

The objective of SOA vision of interaction between clients is for clients and services to communicate and understand each other no matter what platform they run on. This objective can be met only if clients and services have a standard way of communicating with each other, a way that's consistent across

Web services provide exactly that. They comprise a maturing set of protocols and technologies that are widely accepted and used, and that are platform, system, and language independent. In addition, these protocols and technologies work across firewalls, making it easier for business partners to share vital services.

Promising to make things even more consistent is the WS-I basic profile, introduced by the Web Services Interoperability Organization (an organization chartered to promote web services interoperability). The WS-I basic profile identifies a core set of web services technologies that when implemented in different platforms and systems, helps ensure that services on these different platforms and systems, and written in different languages, can communicate with each other.

Scalability:

Because services in an SOA are loosely coupled, applications that use these services tend to scale easily compared to those in a more tightly-coupled environment. That's because there are few dependencies between the requesting application and the services it uses. The dependencies between client and service in a tightly-coupled environment are compounded (and the development effort made significantly more complex) as an application that uses these services scales up to handle more users.

Services in a web services-based SOA tend to be coarse-grained, document-oriented, and asynchronous. Coarse-grained services offer a set of related business functions rather than a single function.

For example, a coarse-grained service might handle the processing of a complete purchase order. By comparison, a fine-grained service might handle only one operation in the purchase order process.

A document-oriented service accepts a document as input, as opposed to something more granular like a numeric value or Java object.

For example, a travel agency service that accepts as input a document that contains travel information for a specific trip request.

An asynchronous service performs its processing without forcing the client to wait for the processing to finish. A synchronous service forces the client to wait. The relatively limited interaction required for a client to communicate with a coarse-grained, asynchronous service, especially a service that handles a document such as a purchase order, allows applications that use these services to scale easily.

Flexibility:

Loosely-coupled services are typically more flexible than more tightly-coupled applications. In a tightly-coupled architecture, the different components of an application are tightly bound to each other, sharing semantics, libraries, and often sharing state. This makes it difficult to evolve the application to keep up with changing business requirements.

The loosely-coupled, document-based, asynchronous nature of services in an SOA allows applications to be flexible, and easy to evolve with changing requirements.

Cost Efficiency:

Other approaches that integrate disparate business resources such as legacy systems, business partner applications, and department-specific solutions are expensive because they tend to tie these components together in a customized way. Customized solutions are costly to build compared to SOA based solutions because

 Section 0.3Web Services Protocols and Technologies

The web services approach is based on a maturing set of standards that are widely accepted and used. This widespread acceptance makes it possible for clients and services to communicate and understand each other across a wide variety of platforms and across language boundaries. This section briefly describes the protocols and technologies that constitute these web services standards, some of which are mainstays of working on the World Wide Web. In addition to these standards, other web services standards are emerging to meet additional requirements -- especially in the areas of security and management. This section also covers some of these emerging web services standards.

  1. XML

eXtensible Markup Language (XML) [2] has become the de facto standard for describing data to be exchanged on the Web. As its name indicates, XML is a markup language.

XML involves the use of tags that "mark up" the contents of a document, and in doing so, describe the contents of a document. An XML tag identifies information in a document, and also identifies the structure of the information. For example, the following XML markup identifies some information as bookshelf. The XML markup also describes the structure of bookshelf. The bookshelf structure includes a subordinate item identified as book. Each book has three subordinate items identified as title, author, and price.

<bookshelf><book><title>My Life and Times</title>      

      <author>Felix Harrison</author><price>39.95</price>

</book></bookshelf>

Table 2-1: Bookshelf XML Example

Although tags such as <book> and <title> might appear to inherently give meaning to the information they identify, they really don't. Information tagged with XML tags has meaning only if people associate a particular meaning with a particular tag. If people

Their applications can send XML documents to each other, and process the information in those documents, relying on the commonly understood meanings associated with the XML tags. Applications capable of interpreting these tags can then process the information according to the meaning of the information and its organization.

XML documents have a well-formed structure, for example, each XML tag must have an ending tag (such as <bookshelf>...</bookshelf>) and any tag that begins within another tag must end before the end of the other tag, and must be completely nested within that other tag. So that </title>, </author>, and </price> all come before </book>, and in that relative order.

An XML document is typically associated with a schema that specifies its "grammar rules." In other words, the schema specifies what tags are allowed in the document, the structure of those tags, and other rules about the tags, such as what type of data is expected in a tag (or no data if it's an empty tag). Because valid XML documents must be well-formed and conform to the associated schema, it makes it relatively easy to process XML documents. As a result, XML has been generally adopted as the data language for web services.

  1. SOAP: Simple Object Access Protocol

Though agreeing on the meaning and structure of XML tags makes the use of XML an effective way to exchange data, it's not sufficient for data interchange over the Web. For instance, you still need some agreed-upon protocol for formatting an XML document so that the receiver understands what the main, "payload," part of the message is, and what part contains additional instructions or supplemental content. That's where Simple Object Access Protocol (SOAP) [2] comes in.

SOAP is an XML-based protocol for exchanging information in a distributed environment. SOAP provides a common message format for exchanging data between clients and services.

The basic item of transmission in SOAP is a SOAP message, which consists of

Envelope:

The envelope specifies two things:

The XML namespace specifies the names that can be used in the SOAP message. Namespaces are designed to avoid name clashes, the same name can be used for different items, provided that the names are in different namespaces.

The encoding style identifies the data types recognized by the SOAP message. If a header is provided, it extends the SOAP message in a modular way.

SOAP Header:

As a SOAP message travels from a client to a service, it can pass through a set of intermediate nodes along the message path. Each node is an application that can receive and forward SOAP messages. An intermediate node can provide additional services such as transform the data in the message or perform security-related operations. The SOAP header can be used to indicate some additional processing at an intermediate node, which is, processing independent of the processing done at the final destination. Typically, the SOAP header is used to convey security-related information to be processed by runtime components.

Body:

The body contains the main part of the SOAP message, that is, the part intended for the final recipient of the SOAP message.

Figure 2-2: SOAP Message Structure

Here's an example of a SOAP message designed to retrieve the price of a book. Notice the <SOAP-ENV: Envelope>, <SOAP-ENV:Header> and <SOAP-ENV: Body> elements that mark the envelope, header, and body parts of the SOAP message, respectively. The attribute value mustUnderstand=1 in the header means that the receiver of the SOAP message must process it.

<SOAP-ENV: Envelope xmlns:SOAP-ENV=

"http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Header>

<t:Transaction xmlns:t="some-URI">

SOAP-ENV:mustUnderstand="1">

</t:Transaction>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<m:GetBookPrice xmlns:m="some-URI">

<title>My Life and Times</title>

<author>Felix Harrison</author>

</m: GetBookPrice>

</SOAP-ENV:Body>

</SOAP-Envelope>

Table 2-2: SOAP Message Example

A related standard, SOAP Messages With Attachments, specifies the format of a SOAP message that includes attachments (such as, images). SOAP messages (with or without attachments) are independent of any operating system or platform and can be transported using a variety of communication protocols, such as HTTP or SMTP. WS-I Basic Profile 1.0 references SOAP 1.1.

  1. WSDL: Web Service Description Language

How does a client know what format to use in making a request to a service? How do the client and the service know what the request means? The answers to these questions are provided by information in an XML document, called a WSDL document

A WSDL document contains a description of the web service's interface. It contains information specified in Web Service Description Language (WSDL) [2], as defined in the WSDL specification. WSDL defines an XML schema for describing a web service.

To uncover the description for a Web service, a client needs to find the service's WSDL document. One way, perhaps the most typical way, to do this is for the client to find a pointer to the WSDL document in the web service's registration, which can be in a UDDI registry or an ebXML registry/repository.

A typical scenario is that a business registers its service. The registry entry includes a pointer to a WSDL file that contains the WSDL document for the service. Another business searches the registry and finds the service. A programmer uses the interface information in the WSDL document to construct the appropriate calls to the service.

Ports:

A WSDL document describes a web service as a collection of abstract items called "ports" or "endpoints."

Operations:

A WSDL document also defines the actions performed by a web service and the data transmitted to these actions in an abstract way. Actions are represented by "operations," and data is represented by "messages."

Port Type:

A collection of related operations is known as a "port type." A port type constitutes the collection of actions offered by a web service.

Binding:

What turns a WSDL description from abstract to concrete is a "binding."A binding specifies the network protocol and message format specifications for a particular port type. A port is defined by associating a network address with a binding. If a client locates a WSDL document and finds the binding and network address for each port, it can call the service's operations according to the specified protocol and message format.

For example, here is a WSDL document for an online book search service.

<operation name="getBooks" ...

Table 2-3: Example of Operation specification in WSDL

The input message for the operation, BookSearchInput contains a string value named isbn:

<complexType><all><element name="isbn" type="string"/></all>

Table 2-4: Example of Web service Input Message Structure

The output message for the operation, BookSearchOutput returns a string value named title:

<complexType><all><element name="title" type="string"/></all>

Table 2-5: Example of Web service Output Message Structure

WSDL document specifies a SOAP protocol binding. The style attribute in the binding element specifies that the receiver should interpret the payload in the SOAP message as an RPC method call:

<soap:binding

transport="transport=http://schemas.xmlsoap.org/soap/http" style="rpc"/>

Table 2-6: Example of SOAP binding

Alternatively, the style attribute in a binding element could specify "document". In that case, a complete document (typically an XML document) would be exchanged in the call. In fact, the document style of binding is more typical of services in an SOA. One of the advantages of passing an XML document to a service instead of an RPC-style message is that it tends to be easier to validate and to apply business rules.

The WS-I Basic Profile 1.0 specifies the constructs in WSDL 1.1 that be can be used to ensure interoperability. It also clarifies some of the construct descriptions in the WSDL 1.1 specification.

  1. UDDI and ebXML

SOA can also include a service that provides a directory or registry of services. how can a service be described in a registry so that a program looking for that service can easily find it and understand what it does? The Universal Description, Discovery, and Integration (UDDI) [2] specifications define how to publish and discover information about services in a UDDI-conforming registry.

More specifically, the specifications define a UDDI schema and a UDDI API. The UDDI schema identifies the types of XML data structures that comprise an entry in the registry for a service. Think of a UDDI registry as a "Yellow Pages" for web services. Like the Yellow Pages directory for phone numbers, a UDDI registry provides information about a service such as the name of the service, a brief description of what it does, an address where the service can be accessed, and a description of the interface for accessing the service.

Here is an example that shows part of a complete BusinessEntity structure for a hypothetical company named BooksToGo. The company provides various web services, including an online book ordering service.

<businessEntitym businessKey="35AF7F00-1419-11D6-A0DC-000C0E00ACDD" authorizedName="0100002CAL"

operator="www-3.ibm.com/services/uddi">

<name>BooksToGo</name>

<description xml:lang="en">The source for all professional books

</description>

<contacts><contact><personName>Benjamin Boss</personName>

<phone>(877)1111111</phone></contact></contacts>

Table 2-7: Business Entity Structure

The API describes the SOAP messages that are used to publish an entry in a registry, or discover an entry in a registry. Here, for example, is a message that searches for all business entities in a registry whose name begins with the characters "Books":

<find_business generic="2.0" xmlns=um:uddi-org:api-v2">

<name>Books%</name>

</find_business>

Table 2-8: Search SOAP Message Example

 UDDI 2.0 is part of the WS-I Basic Profile 1.1. Also other registry approaches, with their own specifications, exist.

For example, ebXML [2] is a comprehensive business-to-business framework that includes a registry as well as other information needed for business collaboration in a global electronic marketplace.

The ebXML framework was developed as a joint effort between the Organization for the Advancement of Structured Information Standards (OASIS) and United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), and includes representation from an extremely wide set of businesses and other entities around the world (including standards bodies). The registry contains a

A CPP is an XML document that contains information about a business (in ebXML terms, a business is referred to as a "Party") and the way it exchanges information with another Party.

A CPA is an XML document that describes the specific capabilities that two Parties have agreed to use in business collaboration.

  1. Emerging Standards

Standards such as XML, SOAP, UDDI, and WSDL address the basics of interoperable services. They ensure that a client can find a needed service and make a request that both the client and service understand, irrespective of where the client and service reside or what language the client or service is coded in. But for a web services-based SOA to become a mainstream IT practice, other standards (what many people consider "higher-level" standards) need to be added and adopted. This is especially true in the areas of web service security and web service management. Various standards organizations, such as the World Wide Web Consortium (W3C) and (OASIS), have drafted standards in these areas that promise to gain universal acceptance.

Two emerging standards considered here are WS-Security and WS-BPEL.

 WS-Security

WS-Security [2] is a standard released by OASIS in March 2004. It describes security-related enhancements to SOAP messaging that provide for

Integrity:

Integrity means that a SOAP message is not tampered with as it travels from a client to its final destination.

Confidentiality:

Confidentiality means that a SOAP message is only seen by intended recipients.

Security Tokens:

WS-Security uses security tokens to enable SOAP message security and integrity. A security token is a collection of claims made by the sender of a SOAP message (such as the sender's identity). A sender is authenticated by combining a security token with a digital signature -- the signature is used as proof that the sender is indeed associated with the security token.

The standard also provides a general-purpose mechanism for associating security tokens with messages, and describes how to encode binary security tokens.

WS-Security is quite flexible and can be used with a wide variety of security models and encryption technologies, such as

SAML:

One of the other emerging technologies in security area is Security Markup Assertion Language (SAML). As described by the OASIS Technical Committee responsible for it, SAML - "SAML is an XML-based framework for exchanging security information. This security information is expressed in the form of assertions about subjects, where a subject is an entity (either human or computer) that has an identity in some security domain."

Through SAML, multiple services can exchange security information. As a result, services could do things like enable a single sign-on approach, where a single security entry (of say a user ID and password) could be used to sign in to multiple, related services.

Building on web services security standards such as WS-Security and SAML, the Liberty Alliance Project, a global consortium for open federated identity standards and identity-based web services, has delivered a number of specifications for identity-based web services. Conformance to these standards will enable web services to use a single identity framework. This will support, among other things, single sign-on, that is, a user will only have to sign in once, even if the user's request invokes a number of services, each requiring authentication.

 WS-BPEL

Many business processes, such as the handling of a purchase order, involve multiple steps performed in a specific sequence, potentially requiring the invocation and interaction of multiple services. For this to work properly, the service invocations and interactions need to be coordinated (also known as "orchestration") WS-BPEL [2] (Web Services Business Process Execution Language), also identified as BPELWS, BPEL4WS, or simply BPEL, is an XML-based language that is used to coordinate web services across a single business process.

WS-BPEL uses WSDL to describe the web services that participate in a process and how the services interact. For example, the following WSDL entry describes one of the services in the purchase order process:

<portType name = "purchaseOrderPT"><operation name = "sendPurchaseOrder"><input message = "pos:POMessage" /><output message = "pos:InvMessage"/><fault name = "cannotCompleteOrder" message = "pos:orderFaultType" /></operation> </portType>

Table 2-9: WSDL entry for purchase order process

The following entry describes part of the flow of the purchase order process:

<sequence><receive partnerLink = "purchasing" portType = "lns:purchaseOrderPT" operation = "sendPurchaseOrder" variable = "PO"></receive><flow><links><link name="ship-to-invoice"/><link name="ship-to-scheduling"/></links>

Table 2-10: Snapshot of Purchase order process flow

An OASIS Web Services Business Process Execution Language Technical Committee has been established to continue work on the BPEL specification.

 Section 0.4BPEL: Business Process Execution Language

Business Process Execution Language for Web Services (BPEL or BPEL4WS) is a language used for the definition and execution of business processes using Web services.

BPEL enables the top-down realization of Service Oriented Architecture (SOA) through composition, orchestration, and coordination of Web services. It provides a relatively easy and straightforward way to compose several Web services into new composite services called business processes.

BPEL builds on the foundation of XML and Web services; it uses an XML-based language that supports the Web services technology stack, including SOAP, WSDL, UDDI, WS-Reliable Messaging, WS-Addressing, WS-Coordination, and WS-Transaction.

BPEL represents a convergence of two early workflow languages;

BPEL combines both approaches and provides a rich vocabulary for description of business processes.

Within an enterprise, BPEL is used to standardize enterprise application integration as well as to extend the integration to previously isolated systems. Between enterprises, BPEL enables easier and more effective integration with business partners.

BPEL stimulates enterprises to further define their business processes, which in turn leads to business process optimization, reengineering, and the selection of the most appropriate processes, thus further optimizing the organization.

Definitions of business processes described in BPEL do not affect existing systems, thereby stimulating upgrades. BPEL is the key technology in environments where functionalities are already or will be exposed via Web services.

BPEL aims to enable programming in the large’. The concepts of ‘programming in the large’ and ‘programming in the small’ distinguish between two aspects of writing the type of long-running asynchronous processes that one typically sees in business processes.

Programming in the large: Generally refers to the high-level state transition interactions of a process, BPEL refer to this concept as an Abstract Process. A BPEL Abstract Process represents a set of publicly observable behaviors in a standardized fashion. An Abstract Process includes information such as

Programming in the small: deals with short-lived programmatic behavior, often executed as a single ACID transaction and involving access to local logic and resources such as files, databases, etc.

Note:

  1. Orchestration versus Choreography

Web services usually expose operations of certain applications or information systems. Consequently, combining several Web services actually involves the integration of the underlying applications and their functionalities.

Web services can be combined in two ways:

Orchestration:

In orchestration [5], which is usually used in private business processes, a central process (which can be another Web service) takes control of the involved Web services and coordinates the execution of different operations on the Web services involved in the operation. The involved Web services do not "know" (and do not need to know) that they are involved in a composition process and that they are taking part in a higher-level business process. Only the central coordinator of the orchestration is aware of this goal, so the orchestration is centralized with explicit definitions of operations and the order of invocation of Web services.

Figure 2-3: Composition of Web services with orchestration

Choreography:

Choreography [5], in contrast, does not rely on a central coordinator. Rather, each Web service involved in the choreography knows exactly when to execute its operations and with whom to interact. Choreography is a collaborative effort focusing on the exchange of messages in public business processes. All participants in the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges.

Figure 2-3: Composition of Web services with choreography

From the perspective of composing Web services to execute business processes, orchestration is a more flexible paradigm and has the following advantages over choreography:

BPEL supports two different ways of describing business processes that support orchestration and choreography:

  1. BPEL Design Goals

There are ten design goals associated with BPEL:

Goal 1: Define business processes that interact with external entities through Web Service operations defined using WSDL 1.1, and that manifest themselves as Web services defined using WSDL 1.1. The interactions are “abstract” in the sense that the dependence is on portType definitions, not on port definitions.

Goal 2: Define business processes using an XML based language. Do not define a graphical representation of processes or provide any particular design methodology for processes.

Goal 3: Define a set of Web service orchestration concepts that are meant to be used by both the external (abstract) and internal (executable) views of a business process. Such a business process defines the behavior of a single autonomous entity, typically operating in interaction with other similar peer entities. It is recognized that each usage pattern (i.e. abstract view and executable view) will require a few specialized extensions, but these extensions are to be kept to a minimum and tested against requirements such as import/export and conformance checking that link the two usage patterns.

Goal 4: Provide both hierarchical and graph-like control regimes, and allow their use to be blended as seamlessly as possible. This should reduce the fragmentation of the process modeling space.

Goal 5: Provide data manipulation functions for the simple manipulation of data needed to define process data and control flow.

Goal 6: Support an identification mechanism for process instances that allows the definition of instance identifiers at the application message level. Instance identifiers should be defined by partners and may change.

Goal 7: Support the implicit creation and termination of process instances as the basic lifecycle mechanism. Advanced lifecycle operations such as "suspend" and "resume" may be added in future releases for enhanced lifecycle management.

Goal 8: Define a long-running transaction model that is based on proven techniques like compensation actions and scoping to support failure recovery for parts of long-running business processes.

Goal 9: Use Web Services as the model for process decomposition and assembly.

Goal 10: Build on Web services standards (approved and proposed) as much as possible in a composable and modular manner.

  1. Business Process Modeling Notation

The Business Process Modeling Notation (BPMN) [6] is a standardized graphical notation for drawing business processes in a workflow. Business Process Management Initiative developed BPMN.

The primary goal of BPMN is to provide a notation that is readily understandable by

Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.

Note: An informal mapping from BPMN to BPEL 1.1 is currently available.

 Section 0.5BPEL solution for a Business Process

A BPEL process specifies the exact order in which participating Web services should be invoked, either sequentially or in parallel. With BPEL, one can express

  1. Conditional behaviors. For example, an invocation of a Web service can depend on the value of a previous invocation.
  2. Construct loops,
  3. Declare variables,
  4. Copy and assign values,
  5. Define fault handlers, and so on.

By combining all these constructs, you can define complex business processes in an algorithmic manner. In fact, because business processes are essentially graphs of activities, it might be useful to express those using Unified Modeling Language (UML) activity diagrams.

In a typical scenario, the BPEL business process receives a request. To fulfill it, the process invokes the involved Web services and then responds to the original caller. Because the BPEL process communicates with other Web services, it relies heavily on the WSDL description of the Web services invoked by the composite Web service.

A BPEL process consists of steps; each step is called an "activity." BPEL supports primitive as well as structure activities.

Primitive activities represent basic constructs and are used for common tasks, such as the following:

  1. Invoking other Web services, using <invoke>
  2. Waiting for the client to invoke the business process by sending a message, using <receive> (receiving a request)
  3. Generating a response for synchronous operations, using <reply>
  4. Manipulating data variables, using <assign>
  5. Indicating faults and exceptions, using <throw>
  6. Waiting for some time, using <wait>
  7. Terminating the entire process, using <terminate>

We can then combine these and other primitive activities to define complex algorithms that specify exactly the steps of business processes. To combine primitive activities, BPEL supports several structure activities. The most important are

  1. Sequence (<sequence>), which allows us definition of a set of activities that will be invoked in an ordered sequence
  2. Flow (<flow>) for defining a set of activities that will be invoked in parallel
  3. Case-switch construct (<switch>) for implementing branches
  4. While (<while>) for defining loops
  5. The ability to select one of several alternative paths, using <pick>

Each BPEL process will also define partner links, using <partnerLink>, and declare variables, using <variable>.

Example:

To understand how business processes are described with BPEL, you will define an oversimplified business process for employee travel arrangements:

We will assume that the Web service for checking the employee travel status is synchronous. This is reasonable because such data can be obtained immediately and returned to the caller. To acquire the plane ticket prices we use asynchronous invocations. Again, this is a reasonable approach, because it might take a little longer to confirm the plane travel schedule. We assume that both airlines offer a Web service and that both Web services are identical (i.e. provide equal port types and operations) to simplify our example.

When you define a business process in BPEL, you essentially define a new Web service that is a composite of existing services. The interface of the new BPEL composite Web service uses a set of port types through which it provides operations like any other Web service. To invoke a business process described in BPEL, you have to invoke the resulting composite Web service.

Figure 2-4: Schematic view of the business process

 CHAPTER 1:ANALYSIS & REQUIREMENT SPECIFICATION

Section 1.1Problem Statement

BPEL implementations should automate the business processes HelpDeskServiceRequestand ‘VacationRequest’. The solutions must ensure high flexibility and configurability, such that the Business Analysts can modify the BPEL solutions themselves as and when required. Also the solution should provide features to allow monitoring of the business activities performed within these processes and take corrective actions if required.

 Section 1.2Main Goals of the system

 Section 1.3Hardware & software requirement specification

Hardware:

Software:

Section 1.4Use Case Analysis

Owing to their simplicity and comprehensiveness, use cases have been chose to capture the requirements of the project.

  1. HelpDeskServiceRequest:

Figure 3-1: Employee Use Cases

Figure 3-2: AssignedUser Use Cases

  1. VacationRequest:

Figure 3-3: Employee Use Case

Figure 3-4: Manager Use Case

DESIGN AND IMPLEMENTATION

Section 1.5Design Strategy

  1. HelpDeskServiceRequest

Oracle BPEL PM provides the following features to facilitate workflow based application.

  1. WorkList - a web service designed to interact with BPEL processes that require user intervention.
  2. BPEL Console - Web services to start, stop, monitor and debug BPEL processes.
  3. TaskManagerService – a web service, which maintains the structure of the task data, including details like task title, task assignee etc.
  4. TaskActionHandler - a web service, handles the operations like sending task to WorkList, receiving the updated task etc.
  5. IdentityService – a web service, which provides the user, accounts details.

Also Oracle BPEL PM maintains all the user accounts of BPEL user in the database associated with it, typically Oracle Lite.

Utilizing the above features, HelpDeskServiceRequest process can be implemented as follows:

Also since HelpDeskServiceRequest can run independently while ‘AssignedUser’ is servicing the request, it may keep count of the elapsed time and escalate the request if needed. And through the BPEL console, an employee can withdraw the request at any point in the processing.

  1. VacationRequest

Design Strategy for VacationRequest is very similar to that in the above process; it can be sequenced in the following steps:

Section 1.6Architecture

  1. HelpDeskServiceRequest

Figure 4-1: Architecture diagram for HelpDeskServiceRequest process

The above architecture can be elucidated in the following steps:

  1. Employee’ logs in to the BPEL console while ‘AssignedUser’ logs into the BPEL WorkList.
  2. Employee’ initiates the ‘HelpDeskServiceRequestService’ process deployed in Oracle BPEL process Manager, by raising a help desk request in BPEL console.
  3. HelpDeskServiceRequestService’ initiates ‘TaskManagerService’ process.
  4. HelpDeskServiceRequestService’ initiates ‘TaskActionHandler’ process.
  5. TaskActionHandler’ sends the help desk service request to ‘WorkList’ application.
  6. The ‘AssignedUser’, for the help desk service request, approves/denies/updates the request or reassigns it to another user.
  7. TaskActionHandler’ receives the updated request message.
  8. TaskActionHandler’ updates ‘HelpDeskServiceRequestService’ with the updated request message.
  9. If help desk service request times–out then ‘HelpDeskServiceRequestService’ escalates the same to another user through ‘TaskRoutingService’.

Note: At any step ‘HelpDeskServiceRequestService’ may withdraw the request as well.

  1. VacationRequest

Figure 4-2: Architecture diagram for VacationRequest process

The above architecture can be elucidated in the following steps:

  1. Employee’ logs in to the BPEL console while ‘Manager’ logs into the BPEL WorkList.
  2. Employee’ initiates the ‘VacationRequest’ process deployed in Oracle BPEL process Manager, by raising a vacation request in BPEL console.
  3. VacationRequest’ identifies the manager by invoking ‘IdentityService’ process.
  4. VacationRequest’ initiates ‘TaskManagerService’ process.
  5. VacationRequest’ initiates ‘TaskActionHandler’ process.
  6. TaskActionHandler’ sends the vacation request to ‘WorkList’ application.
  7. Manager’, of the employee, approves or denies the request.
  8. TaskActionHandler’ receives the updated request message.
  9. TaskActionHandler’ updates ‘VacationRequest’ with the updated request message.

 Section 1.7Sequence Diagrams

Figure 4-3: Sequence diagram for HelpDeskServiceRequest process

Figure 4-4: Sequence diagram for VacationRequest process

 Section 1.8Implementation Strategy

To develop the BPEL processes; the following steps were identified:

  1. Identify the involved Web Services.
  2. Define the WSDL for the BPEL process.
  3. Define partner link types.
  4. Develop the BPEL process:
  1. Define partner links.
  2. Declare variables.
  3. Write the process logic definition.
  1. Identify the web pages to be developed and enabled in WorkList.
  2. Develop the web pages.

  1. HelpDeskServiceRequest

Step 1: Inventory the Involved Web Services

The following Web Services have been identified:

  1. TaskManagerService
  2. TaskActionHandler
  3. TaskRoutingService
  4. IdentityService

Step 2: Define WSDL for the BPEL Process

In this step we define the WSDL for the HelpDeskServiceRequest BPEL process so as to enable it as a web service once deployed into Oracle BPEL PM.

Step 3: Define Partner Link Types

The third step is to define the partner link types. Partner link types represent the interaction between a BPEL process and the involved parties, which include the Web services the BPEL process invokes and the client that invokes the BPEL process. For this web service there are no new PartnerLinkTypes as built-in WebServices are being used.

Step 4: Create the Business Process

In our project, there are four different partners:

  1. The TaskManagerService,
  2. The TaskActionHandler,
  3. The TaskRoutingService, and the
  4. IdentityService.

For these four web services, partner links are defined. For example, for IdentityService following is the partner link.

<partnerLink name="IdentityService" partnerRole="IdentityServiceProvider" partnerLinkType="identityservice:IdentityService" plext:wsdlloc="LocalIdentityService.wsdl"/>

Table 4-1: A Partner Link Declaration

Inbound /outbound message variable are defined for each of the partner links are defined here. For example, for inbound message to TaskManagerService following is the message variable declaration.

<variable name="oraBPMTaskMessage" messageType="taskmngr:taskMessage"/>

Table 4-2: A Variable declaration

Complete Process logic is developed here. For example, following code snippet sets the Task Title:

<copy><from expression=""Help Desk Service Request""/><to variable="SimpleWorkflowWithAutomaticEscalationVar1" query="/task:task/task:title"/>

</copy>

Table 4-3: A Process Logic step

Step 5: Identify the web pages to be developed and enabled in WorkList.

  1. SimpleWorkflowWithAutomaticEscalation1_WF_Form.jsp’ is identified, as the single web page required allowing the ‘AssignedUser’ to provide his responses on the HelpDeskRequest raised by employee.

Step 5: Develop the web pages.

  1. Utilizing the WorkList API provided by WorkList web page is developed.

Figure 4-5: Snapshot of HelpDeskServiceRequest BPEL process

  1. VacationRequest

Step 1: Inventory the Involved Web Services

The following Web Services have been identified:

  1. TaskManagerService
  2. TaskActionHandler
  3. IdentityService

Step 2: Define WSDL for the BPEL Process

In this step we define the WSDL for the VacationRequest BPEL process so as to enable it as a web service once deployed into Oracle BPEL PM.

Step 3: Define Partner Link Types

The third step is to define the partner link types. Partner link types represent the interaction between a BPEL process and the involved parties, which include the Web services the BPEL process invokes and the client that invokes the BPEL process. For this web service there are no new PartnerLinkTypes as built-in WebServices are being used.

Step 4: Create the Business Process

In our project, there are four different partners:

  1. The TaskManagerService,
  2. The TaskActionHandler, and
  3. IdentityService

For these four web services, partner links are defined. For example, for TaskManagerService following is the partner link.

<partnerLink myRole="TaskManagerCallbackListener" name="TaskManagerService"

partnerRole="TaskManager" partnerLinkType="taskmngr:TaskManager"

plext:wsdlloc="TaskManagerService.wsdl" plext:runtimeloc="${domain_url}/TaskActionHandler/TaskManagerService.wsdl"/>

Table 4-4: A Partner Link Declaration

Inbound /outbound message variable are defined for each of the partner links are defined here. For example, for inbound message to BPEL process itself following is the message variable declaration.

<variable name="inputVariable"

messageType="client:VacationRequestRequestMessage"/>

Table 4-5: A Variable Declaration

Complete Process logic is developed here. For example, following code snippet sets the Task pattern:

<copy><from expression="string('SINGLE_APPROVAL')"/>

<to variable="SimpleWorkflowVar1" query="/task:task/task:pattern"/>

</copy>

Table 4-6: A Process Logic step

Step 5: Identify the web pages to be developed and enabled in WorkList.

  1. taskConfigSimpleWorkflow1_WF_Form.jsp’ is identified, as the single web page required allowing the ‘Manager’ to provide his responses on the HelpDeskRequest raised by employee.

Step 5: Develop the web pages.

  1. Utilizing the WorkList API provided by WorkList web page is developed.

Figure 4-6: Snapshot of VacationRequest BPEL process

TEST CASES AND RESULTS

Section 1.9Test Cases

Test Case Name

Test Case Description

Expected Result

Obtained Result

Standard success case

Employee raises a request and AssignedUser approves

No exceptions are thrown and process completes successfully reporting approval

No exceptions are thrown and process completes successfully reporting approval

Standard Reject case

Employee raises a request and AssignedUser rejects it

No exceptions are thrown and process completes successfully reporting rejection

No exceptions are thrown and process completes successfully reporting rejection

Standard Reassign case

Employee raises a request and AssignedUser reassign it.

No exceptions are thrown and process completes successfully as directed by the new AssignedUser

No exceptions are thrown and process completes successfully as directed by the new AssignedUser

Standard Timeout case

Employee raises a request and AssignedUser does not respond.

No exceptions are thrown and process completes after escalating to the designated official.

No exceptions are thrown and process completes after escalating to the designated official.

Withdraw case

Employee raises a request and withdraws after a while.

Process ends giving a warning that the request will not be valid anymore.

Process ends giving a warning that the request will not be valid anymore.

Table 5-1: HelpDeskServiceRequest Test Cases

Test Case Name

Test Case Description

Expected Result

Obtained Result

Standard success case

Employee raises a request and Manager approves

No exceptions are thrown and process completes successfully reporting approval

No exceptions are thrown and process completes successfully reporting approval

Standard Reject case

Employee raises a request and Manager rejects it

No exceptions are thrown and process completes successfully reporting rejection

No exceptions are thrown and process completes successfully reporting rejection

Table 5-2: VacationRequest Test Cases

 Section 1.10Snap Shots

Figure 5-1: HelpDeskServiceRequest and VacationRequest BPEL processes.

Figure 5-2: Initiating HelpDeskServiceRequest

Figure 5-3: Initiating VacationRequest

Figure 5-4: AssignedUser home page

Figure 5-5: HelpDeskServiceRequest – Standard time out case

Figure 5-6: VacationRequest – Standard Approve case

CONCLUSION AND FUTURE SCOPE

Section 1.11Conclusion

This project titled ‘Implementation of Workflows using Business Process Execution Language’ automates and improves greatly on the standard business processes ‘HelpDeskServiceRequest’ and ‘VacationRequest’. The major advantages of BPEL processes developed under this project over the existing manual business processes are that BPEL process is:

These BPEL processes uniquely stand out as an illustration of SOA architecture principles based BPEL implementation of human workflows.

Section 1.12Future Scope

One of the main objectives of this project is also to stand out as a Proof-Of-Concept for using BPEL implementations to complex business process with/without human workflows.

Some areas of future enhancements are:

Some applications that can be developed based on the current project are

REFERENCES

  1. Qusay H. Mahmoud. Service-Oriented Architecture (SOA) and Web Services: The Road to Enterprise Application Integration (EAI). http://java.sun.com/developer/technicalArticles/WebServices/soa/index.html

  1. Ed Ort. Service-Oriented Architecture and Web Services: Concepts, Technologies, and Tools. http://java.sun.com/developer/technicalArticles/WebServices/soa2/SOATerms.html

  1. W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. WorkFlow Patterns. http://is.tm.tue.nl/research/patterns/download/wfs-pat-2002.pdf.

  1. Wikipedia. Workflow. http://en.wikipedia.org/wiki/Workflow.

  1. Matjaz Juric. A Hands-on Introduction to BPEL. http://www.oracle.com/technology/pub/articles/matjaz_bpel1.html

  1. Wikipedia. Business Process Modeling Notation. http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation.

  1. Deanna Bradshaw, Mark Kennedy et al. Oracle® BPEL Process Manager Developer’s Guide. October 24, 2005.

APPENDIX

JDeveloper BPEL Designer Activities

JDeveloper BPEL Designer includes a series of activities that are available for dragging and dropping into a BPEL process. These activities enable you to perform specific tasks within a process. This section provides a brief overview of these activities [7]:

Assign Activity:

This activity provides a method for data manipulation, such as copying the contents of one variable to another. This activity can contain any number of elementary assignments.

Figure 1: Assign activity

Invoke Activity:

This activity enables you to specify an operation you want to invoke for the service (identified by its partner link). The operation can be one-way or request-response on a port provided by the service. You can also automatically create variables in an invoke activity. An invoke activity invokes a synchronous service or initiates an asynchronous Web service.

The invoke activity opens a port in the process to send and receive data. It uses this port to submit required data and receive a response. For synchronous callbacks, only one port is needed for both the send and the receive functions.

Figure 2: Invoke activity

Partner Link Activity:

This activity enables you to define the external services with which your process interacts. A partner link type characterizes the conversational relationship between two services by defining the roles played by each service in the conversation and specifying the port type provided by each service to receive messages within the context of the conversation.

For example, if you are creating a process to interact with a Credit Rating Service and two loan provider services (United Loan and Star Loan); you create partner links for all three services.

Figure 3: Partner Link

-1-