WebServices and Workflow technologies

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 - E nterprise A pplication I ntegration 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 - E nterprise S ervice B us
An ESB is actually the next generation of EAI - better and without the
vendor-locking characteristics of old.
Many of the capabilities of a good ESB mirror those of existing EAI
offerings:
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)

J-EAI (Jabber based Enterprise Application integration)
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 as a service hub
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.

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 common
tasks, 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 business
processes.
To combine primitive activities BPEL supports several structured
activities. 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 BPEL Engine Process Flow Template generates executes Design Time Run Time Business Expert User / Application Creates workflows 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 good
control 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 include
Oracle BPEL Process Manager, IBM WebSphere Business Integration
Server 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

WebServices and Workflow technologies

by Nitin Pande

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 14

Statistics

WebServices and Workflow technologies Presentation Transcript

http://www.slideshare.net	12
http://www.linkedin.com	2