Comments on: Intro to BPEL http://www.column2.com/2007/03/intro-to-bpel/ BPM, Enterprise 2.0 and technology trends in business. Fri, 20 Jan 2012 09:15:55 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Fred Holahan http://www.column2.com/2007/03/intro-to-bpel/comment-page-1/#comment-4965 Fred Holahan Fri, 30 Mar 2007 01:41:34 +0000 http://www.column2.com/2007/03/intro-to-bpel/#comment-4965 Sandy, as I said in a previous post here, I'm not religious about where the lines are drawn among things like BPM, EAI, B2B, workflow, etc. In contrast with the sometimes polarizing views expressed by others, I believe there are many shades of grey across these domains. That said, I have observed numerous SOA architects and developers using BPEL to build high-powered composite applications (regardless of whether one considers composite apps falling within the BPM domain), so perhaps the lines are drawing themselves. :) Sandy, as I said in a previous post here, I’m not religious about where the lines are drawn among things like BPM, EAI, B2B, workflow, etc. In contrast with the sometimes polarizing views expressed by others, I believe there are many shades of grey across these domains. That said, I have observed numerous SOA architects and developers using BPEL to build high-powered composite applications (regardless of whether one considers composite apps falling within the BPM domain), so perhaps the lines are drawing themselves. :)

]]> By: Sandy Kemsley http://www.column2.com/2007/03/intro-to-bpel/comment-page-1/#comment-4964 Sandy Kemsley Thu, 29 Mar 2007 14:51:08 +0000 http://www.column2.com/2007/03/intro-to-bpel/#comment-4964 Fred, thanks for the feedback. If you're using a process modelling tool that fully supports BPMN, then I agree that you would have to do some rework to make it work in BPEL since there are things that you can do in BPMN that just don't translate directly to BPEL -- that's one of the major criticisms of BPEL. Some BPM vendors that use BPEL as their underlying serialization and/or execution engine restrict the BPMN that's available in their modelling tool for exactly that reason: effectively, they expose the subset of BPMN that maps onto BPEL without requiring coding at the BPEL level. Orchestration of message flows in composite applications is, arguably, within the BPM domain -- it just depends where you draw the lines. :) Fred, thanks for the feedback. If you’re using a process modelling tool that fully supports BPMN, then I agree that you would have to do some rework to make it work in BPEL since there are things that you can do in BPMN that just don’t translate directly to BPEL — that’s one of the major criticisms of BPEL. Some BPM vendors that use BPEL as their underlying serialization and/or execution engine restrict the BPMN that’s available in their modelling tool for exactly that reason: effectively, they expose the subset of BPMN that maps onto BPEL without requiring coding at the BPEL level.

Orchestration of message flows in composite applications is, arguably, within the BPM domain — it just depends where you draw the lines. :)

]]> By: Fred Holahan http://www.column2.com/2007/03/intro-to-bpel/comment-page-1/#comment-4963 Fred Holahan Mon, 26 Mar 2007 17:29:30 +0000 http://www.column2.com/2007/03/intro-to-bpel/#comment-4963 Sandy, I realize that you, Bruce and others know what BPEL is and why it exists. But Bruce teed up the question “what the heck is it [BPEL] supposedly for then?”, so I thought his question should not go unanswered for those who are trying to sort out where BPEL fits. In response to your question about graphical modeling notations and BPEL, let’s look at the characteristics of BPMN and BPEL to get some perspective. While BPMN provides rich constructs for expressing conceptual models, it does not require users to create those models in structured ways. BPEL, on the other hand, is all about execution, so BPEL’s semantics are highly structured to suit its purpose. For all the right reasons, BPMN is more expressive than BPEL, and BPEL is more strictly structured than BPMN. It is easy to create conceptual models in BPMN that require significant restructuring to produce executable models in BPEL. (Note that I’m not saying BPMN inhibits structured modeling, only that BPMN does not <i>require</i> structured modeling.) While it’s true that flow path analysis and restructuring algorithms can automate some of the conversion from unstructured conceptual models to structured, optimized executable models, many conversions will require significant human re-engineering. Thus, analysts and engineers on the receiving end of a BPMN-to-BPEL conversion must be well versed in BPEL’s semantics to get their executable model to a deployable state. Looking beyond BPMN-to-BPEL conversion issues, BPEL has many uses outside of the BPM domain. An example is the orchestration of message flows in composite applications. In these applications, BPMN (and other high level modeling notations) will often not be the tools of choice, and detailed knowledge of BPEL’s syntax and semantics will be needed to get the job done properly. This is where the analogies between SQL and BPEL are most relevant. Sandy, I realize that you, Bruce and others know what BPEL is and why it exists. But Bruce teed up the question “what the heck is it [BPEL] supposedly for then?”, so I thought his question should not go unanswered for those who are trying to sort out where BPEL fits.

In response to your question about graphical modeling notations and BPEL, let’s look at the characteristics of BPMN and BPEL to get some perspective. While BPMN provides rich constructs for expressing conceptual models, it does not require users to create those models in structured ways. BPEL, on the other hand, is all about execution, so BPEL’s semantics are highly structured to suit its purpose. For all the right reasons, BPMN is more expressive than BPEL, and BPEL is more strictly structured than BPMN.

It is easy to create conceptual models in BPMN that require significant restructuring to produce executable models in BPEL. (Note that I’m not saying BPMN inhibits structured modeling, only that BPMN does not require structured modeling.) While it’s true that flow path analysis and restructuring algorithms can automate some of the conversion from unstructured conceptual models to structured, optimized executable models, many conversions will require significant human re-engineering. Thus, analysts and engineers on the receiving end of a BPMN-to-BPEL conversion must be well versed in BPEL’s semantics to get their executable model to a deployable state.

Looking beyond BPMN-to-BPEL conversion issues, BPEL has many uses outside of the BPM domain. An example is the orchestration of message flows in composite applications. In these applications, BPMN (and other high level modeling notations) will often not be the tools of choice, and detailed knowledge of BPEL’s syntax and semantics will be needed to get the job done properly. This is where the analogies between SQL and BPEL are most relevant.

]]> By: Sandy Kemsley http://www.column2.com/2007/03/intro-to-bpel/comment-page-1/#comment-4962 Sandy Kemsley Sat, 24 Mar 2007 16:33:32 +0000 http://www.column2.com/2007/03/intro-to-bpel/#comment-4962 Fred, Bruce and I really do know what BPEL is intended for, but thanks for the refresher course. I'm not sure that I agree, however, that IT needs to learn BPEL they way that they know SQL -- if the graphical modelling notations provide a complete representation of BPEL, why would you need to dig into the code? Fred, Bruce and I really do know what BPEL is intended for, but thanks for the refresher course. I’m not sure that I agree, however, that IT needs to learn BPEL they way that they know SQL — if the graphical modelling notations provide a complete representation of BPEL, why would you need to dig into the code?

]]> By: Sandy Kemsley http://www.column2.com/2007/03/intro-to-bpel/comment-page-1/#comment-4961 Sandy Kemsley Sat, 24 Mar 2007 16:28:43 +0000 http://www.column2.com/2007/03/intro-to-bpel/#comment-4961 Bob, hard to say how the BEE-pull versus BEH-pull pronunciation wars will be resolved. However, the Americanized PRAW-cess is just plain wrong. :) Bob, hard to say how the BEE-pull versus BEH-pull pronunciation wars will be resolved. However, the Americanized PRAW-cess is just plain wrong. :)

]]> By: Bob McIlree http://www.column2.com/2007/03/intro-to-bpel/comment-page-1/#comment-4960 Bob McIlree Sat, 24 Mar 2007 14:09:35 +0000 http://www.column2.com/2007/03/intro-to-bpel/#comment-4960 BEE-pull...is the pronunciation difference just like that concerning PROOH-ject or PROOH-cess as opposed to the obviously correct pronunciations PRAHH-ject and PRAHH-cess. :) :) BEE-pull…is the pronunciation difference just like that concerning PROOH-ject or PROOH-cess as opposed to the obviously correct pronunciations PRAHH-ject and PRAHH-cess.
:) :)

]]> By: Fred Holahan http://www.column2.com/2007/03/intro-to-bpel/comment-page-1/#comment-4959 Fred Holahan Thu, 22 Mar 2007 23:03:14 +0000 http://www.column2.com/2007/03/intro-to-bpel/#comment-4959 BEE-pull (yes, I'm one of "those") is all about orchestrating message flows across service endpoints using constructs that model many common business patterns. That's what the original spec-writers intended; that's what the OASIS WS-BPEL TC has been endeavoring to accomplish through four years of grinding effort. BPEL 2.0 will serve the IT community very well as the de facto (and soon published) service orchestration standard. What are organizations going to do with BPEL? Lots of creative and valuable things. Today, some are using BPEL as a cornerstone of EAI, replacing proprietary products with ones that offer portability of IP and knowledge. Some are using BPEL in concert with advanced UI technologies to deliver composite, service-oriented applications. Some are using BPEL to expose course-grained business services to their customers and suppliers. And, yes, some are even using BPEL to (gasp!) automate their business processes. Over the coming years, BPEL will be used (and in some cases misused) in a wide variety of applications. I believe BPEL's adoption will be extensive - perhaps not evidenced as much by a meteoric rise as a rolling thunder. Ultimately we will see many different and important applications of BPEL that help organizations close the gaps between their people, their processes, their information technologies and their extended value chains. I don't spend a lot of time worrying about BPEL's role relative to BPMN, XPDL, WS-CDL and other adjacent standards. I'm not religious that way. Organizations that need to create and manage conceptual process models are likely to do that in something like BPML, from which they will produce executable BPEL when that is their chosen deployment environment. I do believe, however, that advising IT audiences not to learn BPEL syntax and semantics (amazingly, I've read this and heard it spoken in the analyst community) is ill-advised. IT needs to learn BPEL for the same reasons it needs to know SQL - even if you're using a higher-level tool most of the time, you will eventually need to get under the hood. <blatant vendor self-promotion mode> As an aside, in Danny van der Rijn's webcast today, he (or his colleague) stated that migration from BPEL 1.1 to 2.0 is a difficult task. I would invite anyone who has an inventory of BPEL 1.1 processes to use our ActiveBPEL Designer tool (it's free) to do the heavy lifting for you. Just load up your BPEL 1.1 process definition into the tool, Save As a 2.0 process, and presto - migration problem solved! There are a couple of semantics the tool can't migrate without some human assistance, but the majority of constructs are handled automatically. Download a copy of the tool at: <a href="http://www.active-endpoints.com/active-bpel-designer.htm" rel="nofollow">http://www.active-endpoints.com/active-bpel-designer.htm</a> </blatant vendor self-promotion mode> BEE-pull (yes, I’m one of “those”) is all about orchestrating message flows across service endpoints using constructs that model many common business patterns. That’s what the original spec-writers intended; that’s what the OASIS WS-BPEL TC has been endeavoring to accomplish through four years of grinding effort. BPEL 2.0 will serve the IT community very well as the de facto (and soon published) service orchestration standard.

What are organizations going to do with BPEL? Lots of creative and valuable things. Today, some are using BPEL as a cornerstone of EAI, replacing proprietary products with ones that offer portability of IP and knowledge. Some are using BPEL in concert with advanced UI technologies to deliver composite, service-oriented applications. Some are using BPEL to expose course-grained business services to their customers and suppliers. And, yes, some are even using BPEL to (gasp!) automate their business processes.

Over the coming years, BPEL will be used (and in some cases misused) in a wide variety of applications. I believe BPEL’s adoption will be extensive – perhaps not evidenced as much by a meteoric rise as a rolling thunder. Ultimately we will see many different and important applications of BPEL that help organizations close the gaps between their people, their processes, their information technologies and their extended value chains.

I don’t spend a lot of time worrying about BPEL’s role relative to BPMN, XPDL, WS-CDL and other adjacent standards. I’m not religious that way. Organizations that need to create and manage conceptual process models are likely to do that in something like BPML, from which they will produce executable BPEL when that is their chosen deployment environment. I do believe, however, that advising IT audiences not to learn BPEL syntax and semantics (amazingly, I’ve read this and heard it spoken in the analyst community) is ill-advised. IT needs to learn BPEL for the same reasons it needs to know SQL – even if you’re using a higher-level tool most of the time, you will eventually need to get under the hood.

<blatant vendor self-promotion mode>

As an aside, in Danny van der Rijn’s webcast today, he (or his colleague) stated that migration from BPEL 1.1 to 2.0 is a difficult task. I would invite anyone who has an inventory of BPEL 1.1 processes to use our ActiveBPEL Designer tool (it’s free) to do the heavy lifting for you. Just load up your BPEL 1.1 process definition into the tool, Save As a 2.0 process, and presto – migration problem solved! There are a couple of semantics the tool can’t migrate without some human assistance, but the majority of constructs are handled automatically. Download a copy of the tool at:

http://www.active-endpoints.com/active-bpel-designer.htm

</blatant vendor self-promotion mode>

]]> By: Sandy Kemsley http://www.column2.com/2007/03/intro-to-bpel/comment-page-1/#comment-4958 Sandy Kemsley Thu, 22 Mar 2007 21:29:18 +0000 http://www.column2.com/2007/03/intro-to-bpel/#comment-4958 His point was that it's not a process modelling notation like BPMN, nor is it a development language for creating services like Java. Presumably, it's for orchestrating those services once they're already there. His point was that it’s not a process modelling notation like BPMN, nor is it a development language for creating services like Java. Presumably, it’s for orchestrating those services once they’re already there.

]]> By: Bruce Silver http://www.column2.com/2007/03/intro-to-bpel/comment-page-1/#comment-4957 Bruce Silver Thu, 22 Mar 2007 19:15:36 +0000 http://www.column2.com/2007/03/intro-to-bpel/#comment-4957 If it's not to create business processes or business services, what the heck is it supposedly for then? --Bruce If it’s not to create business processes or business services, what the heck is it supposedly for then?
–Bruce

]]>