Re: [pxe-devel] native invocation

[Alex B. <boi...@in...>]

Janarthanan Poornavel wrote:
> i have two clarifications to ask for,i would highly appreciate if 
> there are any suggestions on these two issues quoted in an article
>
> 1)The performance overhead of invoking Web service operations is 
> several orders of magnitude larger than that of invoking native Java 
> classes, and an order of magnitude larger than that of invoking EJBs 
> or other native Java resources.

This is no surprise.  BPEL is language for doing work "in the large", 
providing and invoking coarse-grained services.  BPEL inherits and 
leverages the same architecture that make web services compelling, 
namely loose-coupling,   If invocation costs prove to be prohibitive in 
your application, you might want to reconsider the granularity of your 
services.

This is not to say that invocation performance is of no concern.  It 
certainly is an important aspect of any BPEL engine and we'll try as 
much as possible to make invocation as efficient as possible for the 
integration layers that we support (currently JBI and Axis2).

As a colleague of mine said recently: "You build to scale first, then 
you optimize".   And in most deployments I've seen, the bottleneck is 
rarely in the process engine;  it's usually between the web services and 
the database backend.

> 2)Web services invocations lack the important capability to propagate 
> contexts during transactions. In contrast, when using Java resources 
> directly transaction context can be propagated automatically, if the 
> Java resource provides such support (as EJB and JCA do, for example).

This is simply not true.  There are different ways to propagate 
transactions to local and remote services.   It all depends on what kind 
of services you have.  JBI defines semantic for propagating transactions 
to other services on a JBI bus.  There's also WS-AtomicTransaction for a 
more generic and platform-independent solution.

We have begun work to allow PXE/Ode to define transaction boundaries and 
propagate those transactions across the integration layer.  This work 
should materialize before the end of the year.

cheers,
alex