RE: Announce: WS-Callback, WS-MessageData, and WS-Acknowledgement specifications

SOAP does not assume HTTP or TCP/IP, it is "protocol neutral".  More
specifically, one use case for SOAP is to logically bridge different
protocols that may not be able to represent each other's semantic
information.  For example, consider a remote client that uses SMTP/POP to
connect a mobile device to a communications server, then uses HTTP to
connect the communications service to an application running on another
machine. If one "leg" fails, the built-in failure handling mechanisms (e.g.
404 errors) don't propagate to the other leg(s).  Of course, an application
can invent some ways to propagate those errors and compensate for them (e.g.
by retrying, ignoring duplicates, etc.) but that is NOT built into the
infrastructure.

I would agree that in the common -- to many on this list, but definitely NOT
the audience of enterprise-level systems integrations -- case of simple
HTTP-based apps over the Web do not necessarily get profound benefit from
the reliability extensions to SOAP (or SOAP itself, for that matter). On the
other hand, the ubiquity of SOAP and WSDL mean that essentially every
commercially important programming environment supports them, so they may
offer convenience to the developer.  And the true benefits of SOAP and
SOAP-based extensions such as the ones discussed here start to become
apparent when one is NOT in a homogenous networking environment.

-----Original Message-----
From: Omprakash Bachu
To: www-ws-arch@w3.org
Sent: 5/15/2003 2:36 PM
Subject: Re: Announce: WS-Callback, WS-MessageData, and WS-Acknowledgement
specifications


I'm kind of curious why do we need the WS-Acknowledgement when SOAP is
over HTTP which is anyway TCP/IP based protocol ??? Is this meant for
SOAP over other protocols like UDP?
 
Cheers!!!
 Om

Received on Friday, 16 May 2003 11:51:32 UTC