calling BPEL from another BPEL

[Alexey Ousov <ao...@gmail.com>]

Hello All!
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?

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

Regards,
Alexey

Re: calling BPEL from another BPEL

[Alexey Ousov <ao...@gmail.com>]

Hello Alex.
>> 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:
> https://issues.apache.org/jira/browse/ODE-439
>   
You were right, there is nothing about interprocess communication. I 
attached simple test processes to bug report in case you need it.
> 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.
>   
It is still complicated and not unclear to me, what is happening. If 
I'll have clear test case, I'll write it down here.
> alex
>
>   

Re: calling BPEL from another BPEL

[Alex Boisvert <bo...@intalio.com>]

On Wed, Nov 26, 2008 at 5:09 AM, Alexey Ousov <ao...@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:
https://issues.apache.org/jira/browse/ODE-439

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.

alex