On Wed, Nov 26, 2008 at 5:09 AM, Alexey Ousov <[EMAIL PROTECTED]> 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
