This document discusses technologies and approaches for automating business processes through Service-Oriented Architecture (SOA), focusing on web services, enterprise service buses (ESBs), and BPEL for process definition. It highlights the role of j-eai as an open-source integration platform and mentions various tools and frameworks such as Apache Synapse, JBoss ESB, and Oracle BPEL Process Manager. It also provides insights into service orchestration, the function of BPEL in combining services, and the infrastructure necessary for executing BPEL processes.

1. WebServices and Workflow technologies understanding document Version 1.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17. BPEL activities

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

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

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

21. BPEL process as Webservice

22. A sample BPEL activity set

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

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

25. Blueprint for building a SOA application Source : http://www.oredev.org/download/18.5bd7fa0510edb4a8ce4800019916/Tom_Stenstrom_-_BPEL.pdf

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

27. Oracle Process Manager