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:

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.

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?