RE: SOAP bindings with "Asynchronous" protocols

Naresh,

Systinet WASP supports SOAP over asynchronous transports, including SMTP,
IMAP, POP3, and JMS. (No one has attempted to build a BEEP transport plug-in
for WASP yet, but I'm sure it wouldn't be difficult.) Our customers have
expressed interest in these transports mainly in pursuit of reliable
messaging.

The transport mechanism is orthogonal to the communication style. You can
perform blocking and non-blocking RPC-style request/response invocations and
document-style request/response messages, as well as non-blocking one-way
messaging over both synchronous and asynchronous transports.

A couple of comments on your questions:
- RPC style doesn't necessarily equate to encoded, and messaging doesn't
necessarily equate to literal. RPC style simply means that you're using the
RPC convention defined in the SOAP spec, which says that the SOAP message
body is viewed as a single structure consisting of a method name and a set
of parameters with accessors for each of the parameters. SOAP messaging or
"document" style means that the SOAP message body doesn't use this structure
convention. This message structure convention is orthogonal to your encoding
scheme. Literal means that the message contents are encoded according to a
specified XML Schema. Encoded means that the message contents are encoded
using a specified encoding style, such as the one defined in section 5 of
the SOAP specification. Although you don't see it often, you can send RPC
messages encoded using literal encoding. You can also send document messages
encoded using SOAP Section 5 encoding (which you see a lot more often).

- The WSDL spec defines various communication styles, including
request/response, soliciti-response, one-way messaging, and notification.
The first two styles imply that a response is expected. The second two
styles do not expect a response. Generally, the RPC convention is used only
to perform request/response style. But there's no reason why you can't
perform request/response operations over an asynchronous transport. The
transport layer just needs to provide a mechanism to associate the request
and response messages and deliver the response to the sender.

Best regards,

Anne Thomas Manes
CTO, Systinet

> -----Original Message-----
> From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
> Naresh Agarwal
> Sent: Friday, March 08, 2002 6:20 AM
> To: www-ws@w3.org
> Subject: SOAP bindings with "Asynchronous" protocols
>
>
> Hi
>
> Today, most of the Soap implementations use HTTP for transport
> protocol..However, in the near future, we expect more support for
> "Asynchronous" transport protocol like SMTP,  JMS, BEEP etc.
>
> I have following concern in this regard:
>
> 1) Does the "Aynchrony"  make sense in "RPC" (encoded) style of SOAP or
> it would be only useful for "messaging" (literal) style of  SOAP?
>
> 2) Are RPC *synchronous* per se, or does it make sense to have RPC
> *asynchronous*?
>
> 3) What exactly do we want to achieve by using SMTP, JMS, BEEP etc., as
> transport mechanism for SOAP?
>
> I would appreciate any comments on the above.
>
> thanks,
>
> regards,
> Naresh Agarwal
>
>
>

Received on Friday, 8 March 2002 08:14:06 UTC