David Chappell

  • September 2020
  • November 2017
  • April 2017
  • October 2016
  • March 2016
  • February 2016
  • August 2015
  • April 2015
  • December 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • July 2012
  • June 2012
  • May 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006
  • March 2006
  • February 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • March 2005
  • February 2005
  • January 2005
  • December 2004
  • November 2004
  • October 2004
  • September 2004
  • August 2004
  • July 2004
  • June 2004
  • May 2004
  • April 2004
  • March 2004
  • February 2004
  • January 2004
  • December 2003

Opinari

Get the Feed! Subscribe

Why BPEL is Like Bytecode  
# Sunday, May 28, 2006
 
I'm not convinced that BPEL has much of a future as an executable language (see here for why). Still, plenty of people think otherwise, and most of the discussion around BPEL assumes this perspective. Even if you accept this view, however, I'd still argue that the typical take on BPEL is inaccurate.

People tend to think of BPEL as a programming language. The expectation is that a developer writes process logic in BPEL just as she writes object-oriented logic in a language such as Java. But unlike Java and every other mainstream programming language, BPEL is defined using XML. Accordingly, it was designed to be generated by tools, not written directly by developers. Whatever BPEL aficionados believe, masses of developers are never going to work directly in a complex XML-based language.

In fact, as an executable language, BPEL's primary goal is to provide a portable description of logic. Isn't this exactly what Java bytecode strives to do? BPEL focuses on process logic, while bytecode takes on a broader problem space. Yet the two are quite analogous: both are tool-generated languages (bytecode by a Java compiler, BPEL by some graphical process design tool) and both can potentially foster portability.

If BPEL is analogous to Java bytecode, what in the BPEL world is analogous to the Java language itself? The answer must be the thing from which BPEL is produced, i.e., the graphical process description format. Today, different vendors take different approaches to doing this. There is an impending standard, however, in the Business Process Modeling Notation (BPMN). Just as lots of people know Java, lots of people may one day know BPMN. And just as almost nobody except tool vendors works directly in or even thinks much about Java bytecode, the day may come when almost nobody except tool vendors works directly in or thinks much about BPEL.

If you believe that BPEL has a future as an executable language--and again, this is an open question today--viewing BPEL as more analogous to bytecode than to Java gives a clearer view of the role this language plays.


11 comments :: Post a Comment

 


Comments:

Whether it is a language (compared to Java) or not, BPEL gives you process oriented support as first class members (such as links for synchronization). And most important, you can run it!
 

But if these things are useful--and they are--why not add them to a mainstream language, e.g., Java or C#, rather than creating a new language with BPEL? And if you like the idea of creating a new language, why not make it approachable for developers rather than XML-based?

If BPEL is generated from another representation, such as BPMN, there are sensible answers to both of these questions. If you view it as a programming language, however, you're left with a needlessly complex way of describing process logic that's unlikely to ever gain wide developer support.
 

Object oriented languages can certainly be used in a process centric design model, but is it optimal for a language with its roots in a data centric one?

BPEL is small, compact and sort of domain specific. C# has a history, it's huge, versatile and it's expanding conceptually.

I agree with you in respect to the complexity of describing process logic using BPEL. But wouldn't a process oriented language do better bridging the communication gap between business and tech.

While BPMN is a 1 to 1 abstraction to the underlying runtime model, an object oriented language will have a long and winding road (via case tools, patterns, etc) trying to map to the business.

Btw I see no reason why new languages can't be accepted among developers (even though they are XML-based).
 

New languages certainly can be adopted by developers, and the idea of a process-oriented language is appealing.

But is that language really for developers? If the goal is to help bridge the gap between business and IT, a graphical language is much more useful. The language that people actually work in should be BPMN or something like it, not a conventional programming language. And it certainly shouldn't be an XML-based language like BPEL. (We'll have to agree to disagree here, I think--I believe that XML-based programming languages just aren't feasible for mainstream developer use.)

Bytecode is useful, and BPEL is useful, too. But neither one has their primary value as a language in which developers directly write logic.
 

I would say that a process oriented language executing in a runtime environment with process oriented service would be appealing even to developers. Why not?
 

Watching these guys do magic with message cordination makes me believe in common languages.

http://channel9.msdn.com/ShowPost.aspx?PostID=143582
 

I think you're right, Jonas: there certainly are cases where a programming language with process-oriented constructs would be useful. I just don't believe BPEL is the right choice for this language.
 

I for one could not agree more. If BPM = Human Workflow + Service Orchestration then, BPEL did not have much future to begin with since its initial focus was too much on system to system integration, requiring solid IT programmers to figure out all the complicated and highly theoretical constructs that it presented. I guess, this is what happens when you involve industry heavy weights (a la IBM/Microsoft) who dont agree with one another, but still have to work jointly on a "standard". BPM is all about putting the power back of process automation back in the hands on the business. The other thing is, even now BPEL does not have a standard for the key component of BPM (i.e. Human Workflow).

In summary, I think BPEL is a child of one un-happy union. (i.e. IBM and Microsoft).

On another subject, I have been following the BPMS space for quite sometime and have seen many entrants come and go. Recently I was introduced to the CEO of Selcian, the latest entry in this space. While the company is still in its infancy and quite small,I must say, it was quite refreshing to see a completely independent and business focused approach to product development. In addition to having a just exceptional technical team, their product seems to offer features that many of the existing products dont. They seem to have taken the "3rd Wave" of BPM message to heart. One caveat I have to add is, while Selcian seems to be off to a great start and doing all the right things, time will only tell where they end up in the long run.
 

Anonymous, from where did you get your definition of BPM?

Could you give examples where BPEL lacks due to its purpose?
 

Hi Jonas,

I am sure, there are many definitions of BPM, but this is the one I choose to use. Whats yours ?

For BPEL, here are the issues with it.
1) It lacks support to activities involving human workflow.
2) BPEL is not a programming language, but a runtime representation of process logic. If that is correct, then why would I want to 1) write this myself 2) why do I care, what language is used at runtime
3) BPEL has developed un-necessarily complex constructs which are not easy to understand even for those with a technical bent of mind. The whole appeal of BPM is to the business analyst, who wants to make quick changes to the process, without having to know what an "endpoint" or a "port" or a "pipeline" is. BPEL by definition defeats this purpose.
 

FYI, this blog triggered my to write a blog response. I'm always interested in your comments.

http://jboss.org/jbossBlog/blog/tbaeyens/2006/07/05/About_BPM_miracles_and_what_you_can_expect_in_real_life.txt
 

Post a Comment


<< Home