RE: [wsbpel] Topics for the "Review input from TC members" session of the F2FSome

["Maciej Szefler" <mbs@fivesight.com>]

> Physically you still need to define asynchronous callback 
> (partnerLinkType,
> correlation, callback location). Logically you are also 
> better off exposing
> the asynchronous ( invoke/receive ) nature of the interaction 
> to the process
> designer because you most likely will need to handle time-outs, status
> checks, etc...
> 
> I am not sure to understand how having invoke/receive instead 
> of a single
> invoke increases the complexity of nesting processes. Could you please
> clarify?
> 
> Thanks,
> 
> Edwin
> 
Those partner links and correlation sets would not need to be defined: the message correlation in a synchronous interaction occurs at the protocol level (in HTTP by the response message being received on the same socket, in JMS by the response message having the matching correlationId property), thereby reducing the complexity at the process layer (by eliminating those correlation sets). Response messages in such a synchronous interaction can be simpler as the data that would be required to match a correlation set need not be present. Timeouts can be implemented at the protocol layer and exposed to the process engine through faults without much problem. As far as I can tell status checks pose the same difficulties whether the interaction is synchronous or asynchronous. 

As to the issue of nesting, the problem is one of having to make the nested process aware of the nesting process through a an explicit service reference. In the synchronous case it is only the nesting process that needs to have a service reference to the nested process (in the nested process the "reply" action implicitly knows where the response message should be sent), in the asynchronous case the nested process needs a service reference to the particular process that invoked it, and the nesting process must provide an accessible portType of the type expected by the nested process. This makes both processes more complex. 
-Maciej Szefler