Skip to main content

Objects, Components, Web Services and BPEL

Posted by johnreynolds on February 2, 2005 at 8:32 PM PST

Robert Sessions has published a good article discussing the
“fuzzy boundaries” between object, components, and web
services
. The following table from his article pretty much sums
up the key differences with respect to performance:











































Comparison of Objects, Components and Web Services Attributes
by Robert Sessions, Objectwatch


Objects


Components


Web Services


Locality


In the same process as its client



In a different process then its client



In a different organization then its client



Environment

In the same environment as its client



In the same environment as its client



In a different environment then its client



Speed


Very fast communications with its client



Slow communications with its client



Very slow communications with its client



Builder Relationship


Probably built by the same person that built its client



Probably built by the same group that built its client



Probably built by a different company then built its client



Quantity


Tons – every place you look



Quite a lot – at least one for each process



Hardly any – perhaps one per major software subsystem




This table can be useful in determining whether or not you should provide a Web Services interface for a particulatr Object or Component, and as Robert points out, myriad tools are available to generate the necessary wrappers. All you need to do is to determine whether or not the wrapper is appropriate.


Pondering these differences once again prompts me to beat on a
dead horse: Something's just not right about BPELJ.


Standard BPEL allows you to orchestrate distinct Web Services into
Business Processes. The Web Services protocols are the only means by
which standard BPEL engines can interact with Services. If one of
your Services is written in Java, you will have to wrap it in a Web
Service to add it to your Buisness Process, and you will suffer the
performance penalty associated with Web Services.


BPELJ was developed to give developers the ability to directly
invoke Java Services from within BPEL “scripts”. No need
to wrap your Service, and no performance penalty of marshalling and
unmarchalling XML. Nice idea, and if you are using tools such as
those from BEA, IBM, and Oracle you won't even have to deal with ugly
syntax.


My beef, legitimate or not, is that BPELJ a myopic solution.
BPELJ works because the developer has prior knowledge that a specific
Service has a Java interface. If an instance of the Service is ever
created without a Java interface, then that version won't be eligible
to be incorporated into the Business Process (unless the process is
edited).


Here's a scenario; You write a BPELJ process for your company
using a Service from ACME corporation that is written in Java.
Another company, EMCA, comes on the scene, but they implement the
Service as a Web Service. You might consider this scenario as job
security since you get to go back and update your BPELJ script, or
you may consider this scenario a pain. I hold the latter view.


Forget BPELJ; We should make BPEL engines smarter. BPEL engines
should optimize performance based on “learning about” the
interfaces that are available for specific Services. To make this
work, each Web Service would have to indicate alternate interfaces
that it supports (Java RMI, C#, Jini, etc). In my example, the ACME
Service provides both a Java and a Web Services interface, while the
EMCA Service only provides a Web Services interface. When “talking”
to the ACME Service, the “smart” BPEL engine can use Java
protocols to speed things up.


Returning to Robert Sessions' observations, BPEL engines should be smart enough to use Component protocols (rather then Web Service protocols) when they are available (and we need conventions for publishing each of the protocols that our Services support).

BPEL is about Business Processes. From the perspective of the
Business Process Author, the implementation of the Services is
immaterial. No company is going to change a Business Process because
one partner likes Java and another likes .Net. Implementation
details, such as the interface that is used to interact with a
Service, just don't belong at this level.


Programmer's have been very successful in automating optomization
in the past. Witness the JIT compilers and the optimization logic in
modern processors. Why should BPEL engines be any different?




Update: Antony Reynolds (no relation)outlines the use of the Web Services Invocation Framework (WSIF) to access Java from BPEL in his blog entry: BPEL - More than Web Services.

Related Topics >>