WebServices and Workflow technologies understanding document

Version 1.0

The SOA approach for efficient automation of business processes requires:

• Standardized way to expose and access the functionality of applications as services

• Enterprise bus infrastructure for communication and management of services, including message interception, routing, transformation, etc.

• Specialized language for composition of exposed functionalities of applications into business processes

• The first requirement is fulfilled by Web services.

• The second requirement is fulfilled by the ESB (enterprise service bus), which provides support for centralized, declarative, and well-coordinated

management of services and their communications.

• The third requirement, composition of services into processes, is fulfilled by BPEL, the commonly accepted specialized language for business process definition and execution.

Service oriented Approach

• A shift of software engineering towards a component-based approach to software development requires the development of higher level programming systems supporting the development of systems from components.

• For software developers the challenge will no longer be the coding of the required functionality but the orchestration of already existing Web services to executable business processes .

• This approach has commonly been referred to in relevant literature as “Programming in the Large” whereas the development of core Web Services is known as “Programming in the Small” .

Programming in the Large

EAI - Enterprise Application Integration Platform

• An Enterprise Application Integration platform is a central tool to organize data and information streams.

• Enterprise Application Integration are sometimes called Enterprise Service Bus (ESB), when the data stream organization is based on standard protocol and XML-based information exchange.

• J-EAI is a complete integration platform that can be compared to application servers. This is a complete infrastructure that provides services to application that connect to the bus.

• Once the information system is built around an XML bus such as J-EAI, we generate a number of opportunities to connect and exploit those data stream.

ESB - Enterprise Service Bus

An ESB is actually the next generation of EAI - better and without thevendor-locking characteristics of old.

Many of the capabilities of a good ESB mirror those of existing EAIofferings:

• Business Process Monitoring,• Integrated Development Environment, • Human Workflow User Interface, • Business Process Management, • Connectors, • Transaction Manager, • Security, • Application Container, • Messaging Service, • Metadata Repository, • Naming and Directory Service, • Distributed Computing Architecture.• An ESB is part of an SOA infrastructure.

J-EAI (Jabber based Enterprise Application integration)

• J-EAI is the first standard-based Open Source Applications integration platform.

• J-EAI is built on: XML and XMPP ( XMPP stands for extensible Messaging and Presence Protocol. It is standardized by the IETF and is extremely extensible)

• J-EAI has been designed to enable applications integration in process that are not limited to the boundary of a single organization.

• Its routing mechanism allows several instances of J-EAI managed by different organization to be interconnected while keeping all the systems independent.

J-EAI (interconnection 0f J EAI instances across different organizations)

• A J-EAI cluster can serve a single domain

• J-EAI works as a cluster to ensure scalability and high-availability. This is an important feature as organization deploying EAI data bus become highly dependant of the system: high-availability and scalability is thus a must.

J-EAI (Jabber based Enterprise Application integration)

• J-EAI can be seen as a service hub where client use existing service plugged on the J-EAI bus.

• They do not have to know where the service is located, who is running it, and even if it is currently online. All they have to do is know what is the service contract and what is the service identifier.

• J-EAI can then transform and route the given messages to the proper end application, that can process the message. The same message can be routed to one or several applications based on publish and subscribe distribution mechanisms (Channel based or content based).

• With this kind of architecture, the bus is an abstraction layer between all the application / service connected to the hub.

• Each one can address each other, using a service of the platform, without even having to know who is handling the service.

J-EAI as a service hub

• Synapse, an Apache project proposal, focusing a Web Services Mediation framework

• ServiceMix, within the Codehaus repository, is focusing a JBI-based ESB

• Mule, within the Codehaus repository, is focusing on a ESB messaging framework

• JBI Reference Implementation, by Sun

• Open ESB project, by Sun, implementation of an ESB on the top of JBI

Other Products similar to J -EAI

Features in the latest release of JBoss ESB

• support for general notification framework. Transports supported include JMS (JBossMQ, JBoss Messaging, Oracle AQ and MQSeries), email, database or file system. JBoss Messaging 1.2.0GA is now the recommended default JMS implementation.

• jBPM integration. • WS-BPEL support. • Web Services support. • Improved deployment and configuration, using a specific ESB server. • Groovy support. • support for data transformations using Smooks or XSLT. • listeners and action model to support loose-coupling of interaction

steps. • content based routing using JBoss Rules or XPath. • support for registries, using JAX-R and jUDDI out-of-the-box. • gateways to allow non-ESB aware traffic to flow into the ESB. • graphical configuration editor. • high performance and reliability (in use by a large insurance company

for 3 years).

JBoss ESB

Service orchestration

• How simple (or existing) Web services can be used to construct complex Web services.

• This process includes defining the business logic in terms of execution order and conditions for the invocation of orchestrated Web services.

• Web services are reused and combined into more complex services that provide a higher value to the customer.

Service orchestration

• Service orchestration is to be seen in the context of an Enterprise Service Bus. An enterprise service bus is a central communication backbone on a corporate level. It integrates many diverse systems and it is based on XML technology.

• The most recognized name in service orchestration languages is BPEL.

• Suppose you have services A, B and C on your enterprise service bus. Service orchestration is a graph based execution language for writing a new services as a function of existing services. E.g. A new service D can be written as a function of existing services A, B and C in an orchestration script.

Source :http://docs.jboss.org/jbpm/v3/userguide/graphorientedprogramming.html

• One of the main reasons people buy an ESB is so that they can surface many of their existing software assets as “Services”.

• But once you have a collection of services then you want to be able to combine them together into higher value services! This is exactly what BPEL does -- furthermore it is what BPEL was uniquely designed to do.

• There is no other technology that naturally lets you orchestrate services together.

BPEL and ESB

• BPEL is a web services programming language.

• You can write new web services as a function of other web services.

• Interface to a BPEL process is XML based (WSDL to be pore precise) and the variables inside of a BPEL process are XML snippets.

• Oracle is currently the main force pushing BPEL in the marketplace.

BPEL

BPEL

Source : http://www.oredev.org/download/18.5bd7fa0510edb4a8ce4800019916/Tom_Stenstrom_-_BPEL.pdf

BPEL activities

A BPEL process consists of steps.Each step is called an activity. BPEL supports primitive and structure activities.

Primitive activities represent basic constructs and are used for commontasks, such as those listed below:

<invoke> - used to invoke other web services

<receive> (receiving a request) - waiting for the client to invoke the

business process through sending a message

<reply> - generating a response for synchronous operations

<assign> - manipulating data variables

<throw> - indicating faults and exceptions

<wait> - waiting for some time

<terminate> - terminating the entire process

BPEL primitive activities

We can then combine these and other primitive activities and define complex algorithms, which exactly specify the steps of businessprocesses.

To combine primitive activities BPEL supports several structuredactivities. The most important are:

Sequence ( <sequence>), which allows us to define a set of activities

that will be invoked in an ordered sequence

Flow ( <flow>) for defining a set of activities that will be invoked in parallel

Case-switch construct ( <switch>) for implementing branches

While ( <while>) for defining loops

Pick <pick> ability to select one of a number of alternative paths

BPEL structured activities

BPEL infrastructure

BPEL Designer

BPELEngine

ProcessFlow

Template

generates executes

Design Time Run Time

Business Expert User / Application

Createsworkflows

Calls a BPEL process

BPEL process as Webservice

A sample BPEL activity set

BPEL processes require a runtime environment—a BPEL server or a BPEL execution engine deployed in another server, which gives us goodcontrol over their execution.

• Typically, BPEL servers provide control over process instances that are executing and those that have finished.

• They support long-running processes and can dehydrate process state to save resources.

• Some servers provide control over process activities and allow their monitoring.

• Finally, using a BPEL server, all our processes are deployed centrally, which simplifies maintenance.

Some of the most popular BPEL servers that are based on J2EE includeOracle BPEL Process Manager, IBM WebSphere Business IntegrationServer Foundation, BEA WebLogic Integration, and AquaLogic.

There are also at least four open source BPEL servers available: ActiveBPEL Engine, FiveSight PXE, bexee, and Apache Anglia.

BPEL runtime environment

JBoss jBPM

• JBoss jBPM is a platform for process languages. At the base there is a java library to define and execute graphs. The actual

process constructs like e.g. send email, user task and update database are defined on top of this.

• Every process language is made up of a set of such process constructs. And that is what is pluggable in this base library.

• On top of the JBoss jBPM base library, several process languages are implemented as a set of process constructs: jPDL, BPEL and SEAM pageflow:

• jPDL is a process language with a clean interface to Java and very sophisticated task management capabilities. There is no standard for Java process languages, so it is proprietary. (for workflows in java)

• BPEL is a service orchestration language. As said before, in BPEL, you can write new services as a function of other services. This is typically a component of an Enterprise Service Bus (ESB).

• SEAM pageflow is a language that allows for the graphically define the navigation between pages in a SEAM web application.

Blueprint for building a SOA application

Source : http://www.oredev.org/download/18.5bd7fa0510edb4a8ce4800019916/Tom_Stenstrom_-_BPEL.pdf

• Oracle BPEL Process Manager supports WSBPEL 1.1, including Adapter Services (J2CA), Human Workflow and several other components. Runs as J2EE application on top of the Oracle Application Server, JBoss, BEA Weblogic and IBM Websphere

• JBoss jBPM - is open source workflow engine from Red Hat. Supports BPEL4WS 1.1 and WS-BPEL 2.0 as well as workflow and page flow. Uses jPDL for POJO-centric workflow. Includes a graphical process designer based on Eclipse and a web management and monitoring console built on JSF technology.

• A full list of other BPEL engines is available at http://en.wikipedia.org/wiki/List_of_BPEL_engines

JBoss jBPM and Oracle Process Manager

Oracle Process Manager