Use case similar to #6, but sync/async decision is made at deployment time, not run-time

This is inspired by the way BPEL works.

I define an abstract WSDL interface to represent one of the services
exposed by the BPEL process:

<operation name=A>
    <input ...>
    <output ...>
<operation>
 
I also have two possible bindings supported by that service:

<binding name=b1>
    single HTTP request/response connection
<binding>

<binding name=b2>
    two HTTP connections, one for request, one for response
<binding>

The definition of the BPEL process does not know anything other than the
abstract interface, operation A.

At deployment time, I can make the BPEL process interact either with a
client C1 that only handles binding b1, or with a client C2 that only
handles binding b2.

As far as I can see, there would be no way to achieve this type of
functionality if I had started with two one way operations in the
abstract WSDL interface. In that case, I would only be able to use two
separate HTTP connections for my bindings, so my BPEL process would only
be able to interact with clients like C2.


Ugo

Received on Wednesday, 9 February 2005 22:11:53 UTC