Discussions

News: BPEL Update: An interesting week

Bookmark and Share Get thread feed

  1. BPEL Update: An interesting week (13 messages)

    • Posted by: Dion Almaer
    • Posted on: April 23 2004 07:30 EDT
    Jeff Schneider has put together a round-up which tries to summarize where the main players stand with respect to BPEL, and JSR-207. He talks about IBM, BEA, and the Microsoft machine.

    Excerpt
    So, what can we expect? Here are my predictions:
    1. BPEL continues to move forward and serves as the primary foundational technology for executable business process descriptions.
    2. A variant of BPELJ becomes JSR207.
    3. Microsoft never budges off of X/Lang as their base language
    4. The OMG guys create an enhanced Activity Diagram that is 'close enough' to stubbing out BPEL.
    Read more in BPEL4XLang, BPEL4Java BPEL4*
    Reply to this

    Threaded Messages (13)

  2. I don't agree[ Go to top ]

    Actually, I don't agree with these conclusions at all.

    Business process management *languages* are still in puberty. All the players in the BPM market (vendors, standardisation bodies and the academic world) have a completely different point of view.
    I'm not alone with this opinion. Also Wil van der Aalst and John Pyke have some serious criticism on the current webservice standards related to process management.

    BPEL and BPELJ have some serious drawbacks in the language and in the technical details. In the language : BPEL(J) does not have the notion of a process state, which is fundamental in modelling business processes. On a technical level : BPEL(J) has a 'hard-coded' relation to web-services. Though web-services are a promising technology the interface of a process engine should not be limited to web-services alone. A process engine should also be accessible through a plain-old-java-API, a remote object (RMI), a session EJB, ... BPEL(J) forces development teams to acquire web-services competence and forces the use of a heavy-weight-protocol with a performance impact.

    From experience, I know that it is possible to create an easy-to-use and yet really powerfull process language. In my opinion, the first thing that vendors need to do is discuss the process language concepts. Only when a minimal agreement is achieved on the process language we should start the standardisation process.

    Tom Baeyens
    Founder of Java Business Process Management (jBpm), the open source workflow engine
    tom@jbpm.org
    Reply to this Reply to original

  3. I don't agree[ Go to top ]

    In my opinion, the first thing that vendors need to do is discuss the process language concepts. Only when a minimal agreement is achieved on the process language we should start the standardisation process.
    You switched from "language concepts" in the first sentence, to "agreement is achieved on *the* process language" in the next sentence. Presumably you intend an XML dialect. I propose Ant. There's already Globus's GridAnt. The advantage of Ant as a process language is that Ant can be extended arbitrarily with Java, XSLT, Groovy, and Jython. So Ant is language-neutral. Ant is also a scripting engine relied on by most enterprise hackers. Ant has earned tremendous good will amongst them enterprise hackers.

    What really interests me is your phrase, "process language concepts", for which UML has a rich mix of diagrams. Maybe you'd agree that services deserve more than just an external coordination model. A state model improves the quality of behavior. An information model is crucial for understandability when the WSDL includes a complicated custom schema for data exchange, with advanced features such as polymorphism and graph serialization. Hence, SOA needs model diagraming in a general sense, and UML has the most momentum for this. UML has arguably the best "process language concepts" of any meta-language.
    Reply to this Reply to original

  4. Ant versus BPEL[ Go to top ]

    Brian,

    If you take a closer look at BPEL, you will notice that it is not very different from ant: where ant executes a task, BPEL send and receives messages/events. Similar to ant, BPEL could be executed/interpreted by code written in an language. Also the source and the targets of the messages produced by a BPEL process can be implemented in any language and bound to using any type of protocol, invocation framework using a WSDL binding.

    Edwin
    Reply to this Reply to original

  5. Ignorance?[ Go to top ]

    Tom,

    I am not sure I agree with some of your points.

    Point 1: Modelling process flow using state is an OLD approach that works well for simple user workflow but does not work well in a distributed environment. The approach promoted by XLANG, WSFL and BPML and converged into BPEL is based on interactions (message exchanges) and proves to be much more powerful when the goal of the process flow is to coordinate a *network* of services.

    Point 2: BPEL is indeed based on XML and WSDL. It is amazing how we are 4 years into the "Web Services/SOA" era and WSDL is so badly understood: WSDL offers a very flexible binding framework: SOAP over HTTP is only one binding. Other bindings allow developers of reach out to EJB/RMI components, JMS destinations or even POJOs without any performance degradation. The only constraint is that the input and output parameters have to be describable using XML schema. But this is a very good constraint because it creates an important abstraction which allows for better tooling. So here again bashing BPEL for it being only Web service centric is more ignorance from your part than a reality.

    BPEL is very young and not far from being perfect. If you have ideas on how to improve it, become active and join the OASIS working group!

    Edwin
    Reply to this Reply to original

  6. Typo[ Go to top ]

    I meant not/far from being perfect! :-) -Edwin
    Reply to this Reply to original

  7. Ignorance?[ Go to top ]

    Modelling process flow using state is an OLD approach that works well for simple user workflow but does not work well in a distributed environment.
    Sure, coordination is paramount. But state models sanitize the orchestration, which boosts quality and reduces time-to-market. The lowest levels of the OSI network stack were described with state models for a reason: state models better constrain remote communication.
    BPEL is indeed based on XML and WSDL. It is amazing how we are 4 years into the "Web Services/SOA" era and WSDL is so badly understood...
    I disagree. Most developers who try WSDL RPC find it easy and familiar. Document orientatin is a wee more elusive, but still like an abstraction of RPC and just as object oriented. So it isn't WSDL that is misunderstood. The awareness gap has more to do with the aspects of SOA that only proved essential more recently: autonomic redundancy, discovery, pipelining, multicasting, relaying, etc. Of the many awarenesses we tend to lack about SOA, autonomic redundancy is the greatest missed opportunity. It is what most boosts the traditional metrics of Reliability, Availability, and Serviceability.

    But your quote above starts with a compositional analysis of BPEL. One big flaw of BPEL is its embrace of UDDI for discovery. In terms of market momentum, UDDI is a runt amongst standardized discovery alternatives such as JXTA, Jini, OGSA, and many others. This directly relates to clustering and RAS.
    So here again bashing BPEL for it being only Web service centric is more ignorance from your part than a reality.
    I dig the "ig-" word, but in this case you've missed Tom's point. Spring proves that SOA isn't only for remoting. As a (HTTP/WSDL) grid service developer, I found that most of the core and custom grid services rely on other core grid service instances co-located in the same Apache Axis container. Just as with EJB, the notion of a local interface would have value. And AOP threatens to dispel the container entirely in some cases. An integration language (eg, BPEL) that can't accomodate in-process embedding might be disadvantaged. It'll be interesting to see what eventually emerges for this.
    BPEL is very young and not far from being perfect. If you have ideas on how to improve it, become active and join the OASIS working group!
    Whatever happened to W3C's WSCI? Are SOA standards exclusively incubated by vendors now, so that open standardization only follows much later?
    Reply to this Reply to original

  8. Re: Ignorance[ Go to top ]

    I am not sure how to argue about your point regarding WSDL and Web Services being restricted to RPC and distributed object. The highest value of Web services/SOA relay in its ability to provide an architecture/set of blue prints around application integration/EAI (a space there solutions have been historically proprietary and rather complex). Document orientation, asynchronous messaging and flow coordination are the key concepts of EAI so it is very natural that we see the very same stack emerge in the Web services and SOA space. JSR-208 and Microsoft Indigo are additional evidences of this point.

    I am not sure by what you mean by BPEL being tied to UDDI. Could you please clarify? We have actually examples of BPEL used to coordinate Jini Services (thanks to the WSDL binding feature I described in my previous post). In that case the binding component uses the Jini discovery service to locate the dynamically locate the end point.

    Regarding local versus remote interactions, most mature BPEL server will bypass SOAP/HTTP when interacting with local resource and try to use a more efficient binding instead.

    To the best of my knowledge the W3C Choreography workgroup is work on a language (WS-CDL) that can be used to model the behavior/interface of a service/a set of services. WS-CDL references BPEL when it comes to defining executable processes.

    Finally, your point about WS-* needing to mature is well taken. My point is that within this stack, there is a high need for orchestration (coordinating the flow of messages exchange across a set of document-oriented sync and async services) and that what makes BPEL compelling is that for one of the first time in the workflow/BPM/Orchestration space, the industry is coming together to define a solution that will prevent developers to be locked into a proprietary solution/framework.

    Edwin
    Reply to this Reply to original

  9. UDDI, Re: Ignorance[ Go to top ]

    I am not sure by what you mean by BPEL being tied to UDDI.
    UDDI is listed in the "References, Normative" section of last week's draft of the Oasis BPEL specification. The overt selling of UDDI within the BPEL specification is what tipped me off to BPEL's bias towards one discovery protocol:

    "WSDL introduces a common grammar for describing services. UDDI provides the infrastructure required to publish and discover services in a systematic way. Together, these specifications allow applications to find each other and interact following a loosely coupled, platform independent model."

    Since I don't know UDDI, but I know it's unpopular, I have to wonder about BPEL and discovery. I'm glad you found Jini discovery works well with BPEL. Why didn't you use UDDI? Was it technicly inferior?
    Reply to this Reply to original

  10. BPEL and UDDI[ Go to top ]

    Brian,

    I am not a big fan of UDDI neither: I think that the initial versions were over engineered and focused to much on public global repositories. We actually start to see traction in the enterprise for private implementation of UDDI repositories used to promote collaboration across development teams. So I would not count UDDI dead.

    Regarding BPEL and UDDI, I would recommend that you actually try to scan through the spec and you will see that there are no traces in the constructs of the language for UDDI: as far as BPEL is concerned, all discovery mechanisms are peer.

    Regarding Jini, the reason why the customer was looking at Jini for implementing their services is that Jini offers a very advanced and secure approach to distributing what I call "smart proxies/binding components" to a service. There are use cases where this is very compelling. Once you have selected Jini as the framework for implementing your services, using the Jini discovery and binding frameworks was a no brainer.

    Web Services (WS-*) are slowing maturing with regarding to policies and management. Once that fabric is in place, I expect that you will be able to achieve the same level of smart proxi-ing/message filtering that is today available with Jini, except that the proxies will be driven by policies instead of code.

    Edwin
    Reply to this Reply to original

  11. BPEL and UDDI[ Go to top ]

    Regarding Jini, the reason why the customer was looking at Jini for implementing their services is that Jini offers a very advanced and secure approach to distributing what I call "smart proxies/binding components" to a service. There are use cases where this is very compelling.
    I used to believe that smart stubs were compelling (eg, noticing failover on a WAN), but Sun's JXTA-Grid paper cured me of that. The premise is that JXTA peer groups give redundancy needed to achieve autonomic computing, thereby obviating the need for a smart stub. UDDI might be an alternative for this. So many non-Java discovery protocols have emerged in the last few years, that it's difficult to say which will prosper.
    Once you have selected Jini as the framework for implementing your services, using the Jini discovery and binding frameworks was a no brainer.
    Of course. But BPEL should refer to standards that don't need Java. UDDI is neither new nor hot. Will BPEL's users switch to WS-Discovery or WS-Resource?
    Reply to this Reply to original

  12. Revealing my ignorance[ Go to top ]

    Modelling process flow using state is an OLD approach that works well for simple user workflow but does not work well in a distributed environment.
    This question exposes my ignorance of BPEL; so be it.

    Presumably BPEL defines the set of events/messages (plus associated parameters) that can occur in a given workflow. Does BPEL constrain the subset of events/messages that are expected/allowed at each "stage" of the entire process/workflow? If there aren't any such constraints, then I (ignorantly) doubt its practicality; if there are such constraints then BPEL is (implicitly? explicitly?) defining state machines.

    Of course, that leaves open the question of how such state is shared/transmitted between the various parties in the process/workflow. (Is it that such state is encoded in the messages/parameters, thus enabling each receiver to be internally stateless, at the BPEL level?)
    Reply to this Reply to original

  13. BPEL and state[ Go to top ]

    Hi Tom,

    By using "ignorance" I did not mean to be rude but simply point out that there is a lot of confusion about BPEL and that a lot of people of un-aware of the capability of the language and the flexible binding offered by WSDL. With that said, let's get to your specific questions.

    BPEL is a XML-based language for describing a flow of messages across a set of services.

    Example:
    first send messageA to serviceA
    then wait until you receive messageB from serviceB
    then tranform messageB into messageC
    then send messageC in parallel to serviceD and ServiceF
    etc.

    BPEL has support for both structured flows (sequence, while, swith, flow(=parallel), links) and unstructured flows (event handlers, try catch and pick).

    As you can see, the meat of BPEL is about the private implementation of a process. Private because you do not expose those details to the clients participating in the flow.

    The public interface (also know as choreography) is defined at the most basic level using WSDL. If you need more information about the interface, you can use abstract BPEL processes or WS-CDL contract definitions.

    Finally, regarding the stateless-ness of the services participating in the flow, BPEL includes support for variables that hold to the context of the process and some basic assignment capability. If more complex transformation is needed, you can easily call out to transformation libraries/services (XSLT, XQuery, CAM, etc...).

    I hope this helps. I am happy to follow up in more details offline if you wish.

    Edwin
    edwink..@..collaxa.com
    Reply to this Reply to original

  14. BPEL and State[ Go to top ]

    Hi,
    I'm new here and forgive me if this is a silly question. Here goes...
    I am currently deciding on the process modelling techniques to be used for our project which is very much about EAI, messaging (legacy formats to legacy systems, waiting on acknowledgements from systems, etc.)
    What seems natural is that we specify a lot (if not all) the busines process in terms of the core objects and state machines built around them. I would like to use BPEL to model this but am struggling a bit because I don't see exactly how to model FSMs using BPEL. If BPEL isn't yet the perfect way to capture FSMs I probably still need to use it anyway so I would appreciate tips on how to achieve this.
    I read some of the discussions here already. Couldn't quite see the asnwer to my questions but I do still believe that there are many business process that are natural to define in terms of FSMs. Also when dealing with message handling on platforms like MQ and XA transactions across the messaging system and RDBMS then state machines seem a pretty useful. That is a different subject but it's my twopence on that one.
    My main need is to model an FSM using BPEL and I don't mind contraining the way in which BPEL is used inthis project if it helps me to achieve my goal. Any hints appreciated.
    Cormac Keogh
    Reply to this Reply to original