BPEL in a nutshell

BPEL (Business Process Execution Language) is a language that can be used to model business process flows. BPELScript is an XML schema based script that is used to write or generate process flow steps (activities). A runtime interpretor aka BPEL Engine executes the BPEL scripts. A Partner Link contains the context or role of the BPEL script and the application(s) interactions. Partner Links are present as tags in the BPEL script. Client and Service Provider (Server) are a few roles that can be defined using a Partner Link.

Anatomy of a BPEL Script
A BPEL script, in general, consists of:

1. A root tag named Process
2. Required WSDL or other schema imports
3. Partner Links to establish the role of this BPEL script (process) and the interacting applications
   
4. Variable definitions
5. Fault Handlers and Event Handlers
6. A sequence containing any of the activities defined below.

Activities
Process modeling in BPEL is done using activities and there are four main types of activities in BPEL.

1. Communication: These activities are for receiving input messages or text from other applications or invoking methods in other applications to get input.
2. Control: Control activities are the control structures in BPEL. Switch, Case, Otherwise, While, Flow and Wait are the activities available.
3. Fault: Fault activities are used to handle errors and exceptions. Throw, Catch, CatchAll, Terminate and Compensate are the activities available.
4. Other: Other activities are available for assigning, copying or transforming variables and returning their values

In order to better understand the capabilities of BPEL, I hope to model a process using the different Partner Links and activities available in BPEL. I will do a post on the outcome of that activity here. Lack of time led to the Cape Clear license getting expired, so no more BPEL :(

SOA - So what's new?

I was talking to a colleague on SOA, ESB and other related stuff that I've blogged here. He gave me a patient hearing and asked, "so what's new?" He said that all this SOA stuff was already being done in the EAI space for a long time now, even before the term SOA was coined. "An adapter is a service, right?", he asked and I said yes and went back to square one - asking myself, so what is an SOA? More importantly, what is a "service"?

[Update]
After posting on my state of mind above, I went ahead Googling for SOA definitions and reasons, hoping to find better meaning and purpose for its existence. I found John Reynolds' post "The SOA Elevator Speech" very satisfying. The perspective on SOA is that while normal integration focusses on the technical aspects, SOA does that at a business level - all services are described at a business level rather than a technical level (to paraphrase John: processing an order is a service in a SOA while updating a record in a database is not).

I hope that I am now better prepared to take on that colleague of mine.

Routing in Cape Clear 6

According to Gartner, an ESB should provide the following features:

1. Transportation
2. Routing
3. Transformation
4. Web Services

Let us examine the Routing features in Cape Clear 6. Routing in Cape Clear 6 can be setup in the Cape Clear Manager by adding "Routes". Routes are made up of "destination endpoints" that could either be HTTP/HTTPS URLs or JMS (JBoss/IBM MQ) destinations. Complex routing (similar to having a hub/router) can be setup as a composition of multiple routes.

Content based routing is accomplished using a XPath or a regular expression match. The messages are searched for the expression and routed to the web service subscribing to that expression. The expressions are set at the "Route" level.

The source for an integration is always a Web Service where as the destinations could be HTTP URLs or JMS destinations (topic or a queue) endpoint, as mentioned previously.

Cape Clear 6 provides a service for transformation to/from multiple formats including Excel, Flat files, HTTP Post, Custom Java and XML. XSLT is used to develop the mappings.

Buy vs. Build Strategies

I have always been in favour of the "Buy" approach for integration projects rather than "Build" considering the many advantages that it brings. Ronan Bradley, CEO of Polar Lake has written a good blog entry at the Integration Consortium Soapbox. Do take a look at it, it makes interesting reading.

Hello Cape Clear 6!

I was playing around with Cape Clear 6, an Enterprise Service Bus (ESB), to understand web services better and to get to know the concepts of an ESB. My first impression was that it was remarkably easy to understand and use. Though I only went through the Hello World tutorial, I thought the concepts of Design, Develop, Deploy and Test were mapped clearly to the product GUI. Following are the points that I learnt from the Hello World tutorial on building web services. The corresponding phases in the Web Services Development cycle are mentioned within brackets in bold.

1. Generate a WSDL (Design)
2. Add operations in the WSDL for accepting request and sending a response (Design)
3. Generate Java server code (Develop)
4. Edit the server code to add business logic corresponding to step 2 (Develop)
5. Rebuild the server jar (Develop)
6. Deploy the web service (includes packaging the server jar file into a WSAR) (Deploy)
7. Generate and deploy a JSP web client for testing the web service (Deploy)
8. Test the web service through the JSP web client (Test)

The next task is to actually build a BPEL based Orchestration Service and use Cape Clear 6 as an ESB. BPEL - Business Process Execution Language based on WSDL, would probably replace Java in steps 3 and 4 mentioned above. An XML based language that can actually be executed, should be fun!

IBM's SOA seminar - A Construal

I had attended a seminar by IBM on Service Oriented Architecture (SOA) sometime last month and thought that I should share my comprehension on the points that I thought were interesting:

1. IBM mentioned that SOA was more suitable for migrating existing architectures rather than building new applications from scratch
2. Web Services Gateway can be used for routing; as an interface between a web services client and a legacy application that was being web enabled. Enterprise Service Bus (ESB) can be used as a broker and it appears to be a successor to the broker architecture.
3. An overview of BPEL4WS (Business Process Execution Language for Web Services) was provided. It is a language for business process modeling similar to collaborations in IBM WBI Interchange Server.
4. The site http://www.ws-i.org details the Web Services interoperability standards.
5. For transporting large volume of data, JMS queues could be used instead of HTTP for reliable delivery
6. Security aspects related to Web Services were touched upon and it was mentioned that standards present for HTTPS would possibly be adopted for Web Services
7. New tags such as would be present in the SOAP header to indicate if the SOAP envelope was signed
8. SOA Design Patterns and Anti-Patterns were discussed. Following are the details:

Patterns

1. Unified Logical View: Facade pattern - presents one service to the external world and routes the request internally to the appropriate subsystem
2. Adapters for legacy code - This is similar to the EAI adapters. Web services are exposed as adapters.
3. Composable components (BPEL) - Using BPEL, each process could be modeled as a task
   
4. Replaceable components - Develop components that are implementation independent

Anti-Patterns

1. SOAP over HTTP or XML should not be used within layers of an application
2. It should be used only when exposing a layer of the application to other applications

I would like to add a general disclaimer that the above points are according to my understanding, it is possible that I might have misinterpreted some of the points (but it is highly unlikely :)).

MQ 6.0 Open Beta Available

Looks like the IBM WebSphere MQ Open beta v6.0 has been available for a while now. I am excited to learn that there would be integrated support for web services, which probably means that there would be some intelligence built into the product to understand SOAP requests. Another feature that caught my eye was that the new administrative GUI for the product is built on the Eclipse platform. I will hopefully download the product soon and try these new features out. Stay tuned for a review.

Update: Laziness and other higher priority tasks have made this activity a non-starter.

Integration Architect? Who's that?

I've searched the web a good deal to find out an Integration Architect's role and responsibilities, and found quite a few definitions. But most of them seem to be specific to a requirement, so I thought I should create one that is more generic. According to me, an Integration Architect would be the one who defines the architecture for integrating applications (using a tool or a framework) and creates a methodology for implementing "Integrations" or "Interfaces" between applications using the defined architecture.

He/she would typically go through the standard development lifecycle from inception to delivery. The involvement from the architect's perspective would be heavy during inception, light in the middle and moderate towards the end. Tasks the architect would perform in the large middle period would be guiding the implementation team and towards the end would largely be validating the solution against the requirements.