If BPELJ, why not BPEL.NET?

By Peter Abrahams 30 Mar 2004 | IT-Director.com, special to SearchWebServices.com

Digg This!     StumbleUpon     Del.icio.us

Market Analysis

If BPELJ, why not BPEL.NET?
BEA and IBM have just published a jointly authored white paper on a suggested extension of Business Execution Language for Web Services (BPEL4WS or BPEL for short). The introduction has a good explanation of the rationale for BPELJ so I am quoting it verbatim: "The Web Services Business Process Execution Language (BPEL) is a programming language for specifying business processes that involve Web services. BPEL is especially good at supporting long-running conversations with business partners. Even before the standard is formally released it is becoming clear that BPEL will be the most widely adopted standard for business processes involving Web services. BPEL is geared towards "programming in the large", which supports the logic of business processes. These business processes are self-contained applications that use Web services as activities that implement business functions. BPEL does not try to be a general-purpose programming language. Instead, it is assumed that BPEL will be combined with other languages, which are used to implement business functions ("programming in the small").

This white paper proposes a combination of BPEL with Java, named BPELJ, that allows these two programming languages to be used together to build complete business process applications. By enabling BPEL and Java to work together, BPELJ allows each language to do what it does best."

On the surface, this looks like a good idea. It is obvious that there is no clear boundary between programming in the large and in the small. Therefore having two completely different languages and styles supporting them will lead to artificial constructs and awkward implementations. BPELJ with its blurring of the boundary so that Java and J2EE can be seamlessly incorporated into the BPEL XML should be a good thing.

The problem is that the Java /.net divide rears its head again. One of the good things about BPEL4WS is that it is sits above these two environments and we are seeing implementations of it by Microsoft, IBM, BEA and others. This ability to share across the divide means that solutions can be built that are agnostic. BPELJ is obviously not agnostic and so implementers, especially ISVs, will have to decide which side they want to join.

Given the reasons for BPELJ are laudable it would seem that BPEL.net (or maybe it should be called BPELC#) will be developed probably with a slightly different construct. If this happens then most people will use BPELJ or BPELC#, rather than just the base BPEL. Without the benefit of being able to share code the benefit of a shared BPEL will disappear and the two camps will diverge once more. Maybe what is needed is to generalise the concept of BPELJ to support any suitable language. So that the BPEL would remain standard and C# or Java, or another language could be included, or generated, in the relevant place.

This sort of extensibility of BPEL could also be useful in the rules engine environment. Business rules are an example of a concept that works both in the large and in the small so it should be easy to include the rules either in the BPEL orchestration level or at the algorithmic language level.

Even with these concerns, I generally welcome BPELJ and hope it generates lots of debate about programming models and artificial boundaries.

For more information:

• Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
• Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
• For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
• Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.

• Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
• Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
• Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
• Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
• Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.

Tags: BPEL,  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT BPEL BPMN with BPEL a debated topic among experts Oracle SOA Suite Developer's Guide by Matt Wright BPEL tutorial Co-evolution of BPMN and BPEL drives BPM in SOA settings UML modeler includes BPMN support BPM Special Report: What you model is what you monitor Verizon uses BPEL app to cut down on code, check for fraud, and go green Visual orchestration tool addresses event processing and SOA SOA, BPEL working on the railroad UML and SOA the Microsoft way BPEL Research

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary BPEL  (SearchSOA.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary