ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: calling BPEL from another BPEL
Date Wed, 26 Nov 2008 14:18:07 GMT
On Wed, Nov 26, 2008 at 5:09 AM, Alexey Ousov <aousov@gmail.com> wrote:

> I noticed interesting thing: if one BPEL process calls another BPEL process
> on the same ODE instance, ODE engine recognizes local call and routes
> message straight to calling process without doing HTTP
> serialization/deserialization etc.. Both processes are in-memory processes
> if this important. Is that so? Is it bug or feature? Can it be turned off?

Yes, process-to-process communication happens directly in the engine and
bypasses the integration layer (JBI, Axis2, ...).  It applies both to
in-memory and persistent processes and is an optimization (so yes, it's a
feature) which cannot be turned off via configuration at the moment.

I've just added a section in the User Guide to document this feature.  It
will be mirrored on the web site in the next 24 hours.

This causes some interesting features/bugs in my code.
> 1. I have authorization handler, which is made in form of
> "org.apache.axis2.engine.Handler". This caller intercepts all outgoing
> calls, and adds authorization information. If BPEL process calls local java
> service, this handler called, and process authorized. But in case of
> inter-process calls this handler never called, so authorization info is not
> added. This is not problem, just feature to remember about.

Yes, this is the most important impact of the optimization.

> 2. Strange bug. Both caller and calling processes seems to share cached
> data, especially this concerns xslt stylesheets. So if caller and calling
> processes both have xslt stylesheet with *the same name*, doing
> bpws:doXsltTransofrm from both processes with xslt url relative to process
> (just file name) can take wrong stylesheet (in fact stylesheet of last
> deployed process). It took a lot of time to track this down.

This is unrelated to process-to-process communication but is nonetheless a
bug.   I thought we had an outstanding  Jira issue about it (it was reported
before on the mailing list) but I couldn't find it so I created a new one:

3. Cached wsdls are also take place. So if caller and calling processes both
> use same but little modified wsdl (in my case fault names were different)
> BPEL process cannot find fault by name, because wrong wsdl were cached and
> used.

Again, probably unrelated to process-to-process communication and more about
the isolation between deployment packages.   I'm not aware of any bug in
this area (WSDL caching or sharing) so if you have a reproducible test case,
it would make it easier for us to track down and fix.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message