RE: WSDL and Asynchronous Messaging

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Monday, July 08, 2002 10:08 AM
> To: Naresh Agarwal; www-ws-desc@w3.org
> Subject: Re: WSDL and Asynchronous Messaging
> 
> 
> "Naresh Agarwal" <nagarwal@in.firstrain.com> writes:
> >
> > Hi
> 
> Sorry for not replying earlier; I saw this note, but didn't
> get a chance to reply until now.


thanks a lot for replying!

 
> > WSDL 1.1 supports four transmission primitives
> >
> > * One-way. The endpoint receives a message.
> > * Request-response. The endpoint receives a message, and sends a
> correlated message.
> > * Solicit-response. The endpoint sends a message, and receives a
> correlated message.
> > * Notification. The endpoint sends a message.
> >
> > Do these define only *synchronous* calls, or they also define
> *asynchronous* calls.
> >
> 
> The bindings that have been published for request-response ops
> have been synchronous bindings. However, in principal, there's no
> difficulty with doing an asynch binding for request-response ops.
> However, one would need a way to pass a "service reference" in
> order to do it. So for example, one can consider a binding for
> request-response where the request is one HTTP POST and the
> response is a later HTTP POST to the "service reference" given
> by the requestor.
> 

Do you mean to say that current bindings (WSDL1.1) does not support
asynchronous messaging but there are work arounds to get this working.

Can the current WSDL1.1 bindings (alongwith suitable work-around) can
represent asynchronous messaging between two peers, such that any of the two
could initiate and send notification to the other peer. If yes, which of the 
four primitives would be used to represent such a messaging.

Also i believe, "service reference" (the correlation id), is something, 
applications would take care.  

Does the WSDL bindings need to be modified suitable to incorporate "service reference"?


> > Consider the following scenerio-
> >
> > "X" is a peer, which expose a function 
> "GetTodaysTotalSales". Any other
> peer (say *Y*) can establish a permanent session with *X* 
> (some how) and can
> call the function
> > "GetTodaysTotalSales". Now *Y*  can send the result of 
> these call to *X*
> asychronously (say after 2 hours).
> 
> Did you mean to say "*X* can send .. to *Y*" (and not the way
> you wrote it)?? If X offers the service then that's the one
> that generates the response right?

Yes, you are absolutely right!..i'm sorry..it was just a typo error..

> I don't think you need to assume that the connection is held open
> during this time. If you are then its more like a sync call with a
> long wait .. what you want I believe is the kind of binding I
> described above.

This may be desirable in several circumstances like PubSub (Instant Messaging etc.)
For instance, consider an Instant Messaging WebService, which uses *SOAP over BEEP* as
the transport protocol. SOAP clients, in this case, may use *SOAP over BEEP*, to 
access the WebService. SOAP clients, would maintain a permanent session with WebService
server using BEEP, and can send and recieve messages to/from the Instant Messaging 
WebService. This would be substaintially better in terms of performance than 
establishing a *transient* session, each time, SOAP client or the WebService 
need to send a message to the other.


> > How would we represent such a function using WSDL1.1
> >
> > Can the above mentioned primitives represent such a function?
> >
> > Also in general, can i use WSDL1.1 to define *asynchronus messaging*
> between two peers (which may be using SOAP over SMTP or SOAP 
> over BEEP)?
> 
> I believe the basic concepts of input-only operations and
> input-output operations (now using the terminology of the
> upcoming draft of WSDL 1.2) are capable of describing
> asynchronous operations as well.
> 
> There are other patterns like pub-sub (or events) that are
> also asynchronous in nature that are not quite well captured
> by WSDL. We have an open issue on whether to introduce an
> event mechanism to WSDL to address that.

This means that WSDL1.2 has better support for asynchronous messaging
than WSDL1.2, but still it does not, completely address the asynchronous
messaging. 

> 
> > If WSDL1.1  does not support this, is this taken care of in WSDL1.2
> >
> > Any help would be greatly appreciated.
> 
> Again, the published bindings of WSDL 1.1 does not cover this case.
> However, I don't believe there's any problem with doing additional
> bindings that do.
> 
> Are you asking us to do such bindings in WSDL 1.2?

Yes, i would be glad if such bindings could be provided in WSDL1.2, looking
at the fact, that, in the future, more and more WebService would be *asynchronous*,
using transport protocols like BEEP, SMTP, MQ etc..


thanks,

regards,
Naresh Agarwal

Received on Monday, 8 July 2002 10:20:26 UTC