Re: [wsbpel] Issue - 2- sub functions

[Assaf Arkin <arkin@intalio.com>]

We need to be careful to not confuse messages that are exchanged between 
the process and other services, and between activities within the same 
process. Performance is not an issue, IPC message passing can always be 
optimized. But a modeling tool much be able to clearly distinguish 
between IPC and non-IPC messaging to determine what the control flow 
looks like. And a deployment tool needs to understand which ports are 
open to the outside world and which ports are used stirctly inside the 
process context.

Activities that deal specifically with synchronous call or asynchronous 
spawn would make that distinction easier for all the tools built around 
the specification.

arkin

Eckenfels. Bernd wrote:

>Hello,
>
>since John suggested to talk about Issue 2 (and others) in the next conf call, here is my point of view:
>
>- we do need to call synchronous and asynchronous functions by the mean of parameter passing and return values for our engine
>
>- I do not think that new BPEL language constructs are needed. One can do this simply with an One way or two way invoke. The runtime engine can optimize this to avoid web service overhead for IPC. This has the advantage that onMessage handlers can also be used, and there are no additional basic activities.
>
>So for the spec, it might only be needed to mention this possibility. Perhaps we need to givce a recommendation on the WSDL Addressing/bindig section on how to reference such an internal process port?
>
>Greetings
>Bernd
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>  
>