Notes on BPEL

Learning BPEL

There are three kinds of learning, Kinesthetic-Auditory-Visual. Every individual have their own learning pattern that is most suitable to them by nature's law. If and only if you learn any concept the nature's way you will imbibe the concept and make it part of your system. So identifying the pattern that is most suitable to you and then when any concept in that way makes learning easy and enjoyable otherwise the stint would be rather boring, tiresome and we tend to loose interest pretty quickly.

I learn any thing the VA (Visual – Auditory) way, this pattern interestingly needs the person to see running picture with dialogues, so any concept can only be with me if I see them as a running video. At the same time expression anything other than writing is pretty tough for me, since what ever I talk I need to see as a picture again while putting it verbal and obviously there is a lag while making the picture into sound (Encoding is pretty tough... eh ... ).

Though I am from SeeBeyond acquisition till recently I tried little in understanding BPEL. When I started looking at the spec I was seeing it pretty tough to understand by reading. Surprisingly the people who have worked there also does not seem to understand its ethos while I was asking them a few questions. So I went ahead and put my way of thinking and understanding correlating (again a BPEL term...) the concepts with already learned ones like UML, Java and WSDL, while reading the spec, and finally had my own video (.avi) of BPEL, which I'd like to share. This might span over few sessions as this is a language and has its syntax and semantics were to be understood apart from constructing meaningful conversations, which can't be done in a single session.

Need for BPEL:

The whole of world runs on interactions between two or more entities or individuals who/which forms the partners for that interaction. When multiple partners are involved, who are disperse and varied with respect to time and space (Both Software and Hardware in our terms, loosely coupled heterogeneous systems) we need a common language to talk, the common ground for talking is Web Services (WS). WS operates on the standards

  • XML - for definition of variables/types/containers which carry the data and also defining any languages since the same is extendable.

  • WSDL – for describing the service contract between the client and server or the partners involved in the interaction.

  • UDDI – for search, location and publishing of the service/contract over a space.

  • SOAP – This aids in message interoperability amongst the partners of the service. consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses. This can run potentially on any protocol like HTTP/FTP/SMTP etc...

The above infrastructure gives the Business the power to talk to heterogeneous systems but at the same time the process is not complete till the moment we have the other partner too has the same infrastructure and can talk to us in a meaningful way. Above this WS infrastructure offers essentially either stateless-synchronous or asynchronous-uncorrelated models. But in real world in any business process which involves multiple partners need the qualities – long running, stateful, both synchronous as well as asynchronous and can be modeled as sequence of partner interactions. For realizing this we need a description of Message Exchange Protocols (MEP) amongst the partners and model the interactions too. The definition of such protocol must be of mutually visible MEP with out revealing underlying implementation with proper security for the participating systems/partners. So the essential aspects of the new language that should facilitate interaction amongst the diverse participants needs to have the following characteristics:

  • Platform independent since the participants are from diverse and heterogeneous

  • Cater to diverse business scenarios since the partners are geographically diverse and business runs on the law of the land. We must understand that any business or interaction depends on the ecosystems of the partners involved.

  • Business processes are data dependent. Integrity and the stateliness of the data is of utmost importance in any process. This requires state on which conditions the data operates. We have to distinguish here the data here from “on the wire” and “off the wire”. “on the wire” data is the BP relevant data where as the “off the wire” data is protocol relevant data. We have many standards here again like x12, Rosetta net etc which are of B-B nature, they describe how does the transaction happen amongst the Business partners. There must be provision for physical differentiation of these data.

  • There should be provision for exceptions or unforeseen circumstances where in the participants wants to BP to compensate for such conditions. This needs proper sequencing for compensating over an agreed protocol.

  • Support for long running and scope (a Sub BP or a portion of BP which should be worked as a Unit) work and compensation rules for the scope work.

  • Feature for providing precise predictable service behavior for “cross – enterprise” systems which requires rich process describing notation.

  • Above all it should be extendable.

All the above needs can be categorized into 2 aspects

  1. Abstract process – this defines the partners, their roles in any particular context, Relationships amongst the partners, business abstraction at the message level. In fact this portion talks about protocol relevant data.

  2. Execution of the process – this talks about the logic, stateliness, sequencing or the orchestration of the calls amongst the business partners. This portion should not talk about the implementation portion of the same but should rather be portable modeled from the WS artifacts listed above so that the heterogeneous partners can participate seamless in that process.

The protocol which serves the purpose of abstraction and execution of business process and is extendable is BPEL4WS.

I would like to conclude this note here and will continue the thread in my next post.


Post a Comment:
Comments are closed for this entry.

I was part of Sun R&D in Java CAPS and later Glassfish ESB. I moved from R&D to Consulting. I am currently working as a Solution Architect in Oracle Consulting Services (India). I was sharing my experience w.r.t. Java CAPS and other technologies during Sun period. Now in Oracle world I share my experiences with Oracle FMW product line as well as other Oracle Technologies and products.


« June 2016