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
. 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



Web Services


In the same process as its client

In a different process then its client

In a different organization then its client


In the same environment as its client

In the same environment as its client

In a different environment then its client


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


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

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

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 >>