Hi, Matthieu Riou wrote: > On Wed, Oct 1, 2008 at 6:47 AM, Jean-Claude Moissinac <[EMAIL > PROTECTED]>wrote: >> So, it is not the BPEL which must wait for the external process called >> by the BPEL, but the caller of the BPEL >> But, how the caller of the BPEL will know how many external services >> are called by the BPEL? >> > > The caller of the process doesn't know but the process does (or more > accurately the process designer). Knowing that you're invoking long-lasting > operations, you should model your process to only accept an asynchronous > invocation and then call back the client later on when the processing is > finished.
>From a pure web services point of view there is also the possibility to use asynchronous bindings, e.g. the JMS binding. That way the process modeler can consider other services as black boxes (with respect to their response time). Then it depends on your modeling style. If there is a need for a complex conversations between process and services, you should use invoke/receive pairs (i.e. use the . If its a logical atomic invocation, you can fairly use two-way invokes with asynchronous transports. Depends on your taste (i.e. how high/low level your process model should be, business people don't care about time outs, developers do) and whether async transports can be used in your setting. Tammo
