Re: Web-friendly SOAP

I am confused by this comment -- HTTP uses TCP, which is a (relatively)
reliable transport, as opposed to UDP. It's common convention to refer to
TCP as a reliable transport, particularly when comparing it with UDP.

For example (to quote from a random comparison document,
http://www.transarc.ibm.com/Support/dce/general/tcp_and_udp.html) "You may
be aware that UDP, a datagram-type communications protocol, is commonly
referred to as being an 'unreliable network transport', while TCP, a
connection-oriented protocol, is described as being a 'reliable transport'.
This is because at the OS level, no attempt is made to detect dropped or
out-of-sequence UDP packets, whereas the OS implementation of TCP makes use
of sophisticated error-correcting techniques to prevent data loss."

What do you mean by "reliable"? Transactional (e.g. like DCE RPC's
error-correcting layer that runs over both UDP and TCP)? ACID?

- Laird Popkin

On 6/19/2002 4:05 PM, "John Ibbotson" <john_ibbotson@uk.ibm.com> wrote:

> 
> Joe,
> HTTP is NOT a reliable transport.
> John
> 
> Emerging ebusiness Industry Architecture ,
> XML Technology and Messaging,
> IBM UK Ltd, Hursley Park,
> Winchester, SO21 2JN
> 
> Tel: (work) +44 (0)1962 815188        (home) +44 (0)1722 781271
> Fax: +44 (0)1962 816898
> Notes Id: John Ibbotson/UK/IBM
> email: john_ibbotson@uk.ibm.com
> 
> 
> 
>                  
>                     "Joseph Hui"
>                     <Joseph.Hui@exodu        To:       "Walden Mathews"
> <waldenm@ilx.com>, "Laird Popkin"
>                     s.net>                    <laird@io.com>, "Paul Prescod"
> <paul@prescod.net>
>                     Sent by:                 cc:       <xml-dist-app@w3.org>,
> <ice-dev@yahoogroups.com>,
>                     xml-dist-app-requ         <ice-ag@yahoogroups.com>,
> <ice-dev@yahoogroups.com>
>                     est@w3.org               Subject:  RE: Web-friendly SOAP
>                  
>                  
>                     19/06/2002 20:36
>                     Please respond to
>                     "Joseph Hui"
>                  
>                  
> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: Walden Mathews [mailto:waldenm@ilx.com]
>> Sent: Wednesday, June 19, 2002 7:40 AM
>> To: 'Laird Popkin'; Paul Prescod
>> Cc: xml-dist-app@w3.org; ice-dev@yahoogroups.com;
>> ice-ag@yahoogroups.com; ice-dev@yahoogroups.com
>> Subject: RE: Web-friendly SOAP
>> 
>> If SOAP and "web services" represent an evolutionary step from using
>> the web interactively (browser and human user) to the less constrained
>> model including non-human agents, then doesn't this strongly imply
>> a corresponding UDP binding for HTTP?  Is there anything unRESTful
>> about asynchronous or connectionless state transfer?
> 
>> Is HTTP/UDP perhaps a key missing piece?
> 
> No, it can't be.
> HTTP presumes a reliable transport, which UDP can't privide.
> 
> Joe Hui
> Exodus, a Cable & Wireless service
> ===========================================
> 
>> Is there discussion on this that anyone out there could point me to?
>> 
>> Walden Mathews
>> 
>>> -----Original Message-----
>>> From: Laird Popkin [mailto:laird@io.com]
>>> Sent: Tuesday, June 18, 2002 11:15 PM
>>> To: Paul Prescod
>>> Cc: xml-dist-app@w3.org; ice-dev@yahoogroups.com;
>>> ice-ag@yahoogroups.com; ice-dev@yahoogroups.com
>>> Subject: Re: Web-friendly SOAP
>>> 
>>> 
>>> 
>>> On 6/16/2002 11:57 PM, "Paul Prescod" <paul@prescod.net> wrote:
>>> 
>>>> 
>>>> Laird Popkin wrote:
>>>>> 
>>>>> I certainly hope that the SOAP effort retains the
>>> "transport agnostic" goal.
>>>>> One of the reasons that the ICE 2 effort
>>> (http://www.icestandard.org) is
>>>>> adopting SOAP is that it allows ICE to adopt a single
>>> messaging layer, and
>>>>> gain multiple transport bindings automagically.
>>>> 
>>>> When you use SOAP over HTTP you get one set of addressing
>>> mechanisms,
>>>> message exchange patterns and semantics. When you use
>> SOAP over UDP,
>>>> SMTP etc., you will get a totally different set.
>>>> 
>>>> If ICE is an XML vocabulary format then it will be simple
>> to send it
>>>> over all of these protocols. If it really intends to be an
>>> *application
>>>> protocol* then it is not realistic to think that you will
>>> get support
>>>> for all of those protocols just by running on top of SOAP.
>>> Really, ICE
>>>> over SOAP over HTTP will be one protocol and ICE over SOAP
>>> over UDP will
>>>> be in many ways a totally different protocol.
>>> 
>>> ICE is an application protocol. For example, a subscriber can
>>> send a message
>>> ice-get-catalog to a syndicator and receive back an
>>> ice-catalog message
>>> listing all of the content that is offered for syndication,
>>> or a syndicator
>>> could send an ice-update message (containing a bunch of
>>> content) and get
>>> back a confirmation that the content was properly received.
>>> You can get more
>>> info at http://www.icestandard.org if you're curious.
>>> 
>>> Certainly the underlying transport will affect the
>>> application level. ICE
>>> has already been mapped over UDP, SMTP, etc., by various
>>> implementers. You'd
>>> use UDP if you needed performance, and didn't mind
>> occasionally losing
>>> messages, or SMTP if you want very loosely connected
>>> messaging. So we don't
>>> expect a "silver bullet".
>>> 
>>> The reason to push those mappings down below SOAP is that the
>>> ICE standard
>>> can then be substantially simplified, and focus on the things
>>> that it cares
>>> about (managing subscription relationships and delivering
>> content) and
>>> leverage the work of a bunch of clever people working on
>>> SOAP. We'll still
>>> need to define some application-level issues in terms of the
>>> capabilities of
>>> the selected transport, but that's much better than having to define
>>> _everything_ about each transport binding.
>>> 
>>> As far as addressing mechanisms go, ICE assumes that the
>>> endpoints can be
>>> described by a URL, and all other identifiers are internal
>> to the ICE
>>> protocol. For example, if a syndicator says that their address is
>>> "https://ice.contentcorp.com" or
>> "mailto:ice@contentcorp.com" the ICE
>>> protocol doesn't care. Of course, the implementer cares (e.g.
>>> Does HTTP mean
>>> PUT or POST?), but that's defined by the particular protocol
>>> mappings, which
>>> are a separate layer from the ICE protocol. :-) The only
>>> other external
>>> identifier is the address of where to retrieve content by
>>> reference, which
>>> is also a URL.
>>> 
>>>>> ... This is better for everyone
>>>>> than if ICE defines its own bindings to each protocol, as
>>> is required by the
>>>>> pre-SOAP ICE 1.0 standard (1998).
>>>> 
>>>> Let's say that ICE has a "getFoo" method that takes a
>>> string and returns
>>>> an integer. How is that going to magically work on SOAP
>>> running over a
>>>> protocol without request-response behaviour? (like the
>>> current binding
>>>> of SOAP to SMTP).
>>>> 
>>>> Do we expect every protocol binding to implement every
>>> message exchange
>>>> protocol?
>>> 
>>> ICE needs to define its requirements of underlying
>>> transports, and/or the
>>> implications of different transport choices. For example, ICE 1.x is
>>> request/response, which can be layered on top of asynchronous
>>> transports. We
>>> haven't decided whether to loosen the request/response model
>>> in ICE 2 --
>>> it's very powerful making everything asynchronous, but that's not a
>>> programming model that's familiar to most programmers, and
>>> requires more
>>> sophisticated implementations.
>>> 
>>> So IMO (and we're still figuring this stuff out within the
>>> Ice community)
>>> the answer will be that ICE says that if you're operating over a
>>> request/reponse transport, the application semantics are X,
>>> and if you're
>>> operating over an asynchronous transport the application
>>> semantics are Y.
>>> For example, perhaps we define a layer of request/reponse over any
>>> asynchronous transport. In fact, ICE messages all indicate
>>> whether they were
>>> sent in response to another message, with unique ID's linking
>>> messages and
>>> responses, so that would drop on top of an asynchronous
>> protocol quite
>>> nicely.
>>> 
>>> There would be particular exceptions for a few cases where
>>> the "response" in
>>> ICE is a placeholder that conveys no useful information.
>>> 
>>> For example, consider the exchange:
>>> 
>>> 1. Syndicator pushes a content update to the subscriber, with a flag
>>> indicating that it wants confirmation of delivery.
>>> 2. Subscriber sends "OK" response, indicating delivery of the
>>> content update
>>> message.
>>> 3. Subscriber processes the content (including retrieving any
>>> content that
>>> was transmitted by reference instead of inline), and stores
>>> the content into
>>> the local content store.
>>> 4. Subscriber sends message confirming complete delivery of
>>> the update.
>>> 5. Syndicator sends "OK" response.
>>> 
>>> Messages 2 and 5 are probably gratuitous responses.
>>> Admittedly in either
>>> case there's a tiny percentage case of an error due to a
>>> mal-formed message
>>> or other transmission error or software failure, but those
>>> could be handled
>>> by an exception-driven error message rather than a required
>> response.
>>> 
>>> So the exchange could be rewritten asynchronously as:
>>> 
>>> 1. Syndicator pushes a content update to the subscriber, with a flag
>>> indicating that it wants confirmation of delivery.
>>> 2. Subscriber processes the content (including retrieving any
>>> content that
>>> was transmitted by reference instead of inline), and stores
>>> the content into
>>> the local content store.
>>> 3. Subscriber sends message confirming complete delivery of
>>> the update.
>>> 
>>> With two transport-specific rules:
>>> 1. Over request/reponse transports, requests that do not
>>> return a response
>>> (i.e. No ICE-defined data, error or confirmation) return a
>> placeholder
>>> response. This is the current ICE 1.x behavior over HTTP.
>>> 2. Over asynchronous transports, ICE defines an error message
>>> that can be
>>> sent whenever there is an error condition generated when
>> processing a
>>> message that does not otherwise require a "response" message.
>>> 
>>> This is "off the cuff" and probably more detail than you
>>> wanted, but I'm
>>> trying to come up with specific protocol examples to help me
>>> think this
>>> thing through.
>>> 
>>> Comments?
>>> 
>>>>> Realistically, 99% of the time ICE is used over HTTP, and
>>> I would assume the
>>>>> same for SOAP, so that combination needs to be well defined (for
>>>>> interoperability) and work reasonably well. But it's
>>> important not to always
>>>>> require HTTP, because that would prohibit the use of SOAP
>>> and SOAP-based
>>>>> protocols (e.g. ICE 2) over multicast, UDP, SMTP, etc.,
>>> all of which are
>>>>> quite valuable in certain contexts (e.g. Satellite
>>> broadcast of syndicated
>>>>> data, high-speed local data feeds, loosely coupled asynchronous
>>>>> participants, etc.).
>>>> 
>>>> There is no doubt that non-HTTP transports and
>> non-request-response
>>>> models are also important. I just don't think that you can
>>> expect for
>>>> that stuff to *automatically work* just by choosing to
>>> build on SOAP.
>>> 
>>> I agree in principle. But since ICE has already been mapped
>>> over a variety
>>> of transports, I think it's a matter of abstracting the
>>> mapping rules (e.g.
>>> The example above) and stripping out everything that SOAP
>>> will have defined
>>> already.
>>> 
>>> So I suspect we're in violent agreement. What do you think?
>>> 
>>>> Paul Prescod
>>> 
>>> --
>>> - Laird Popkin
>>> 
>> 
>> 
> 
> 
> 
> 

--

Received on Wednesday, 19 June 2002 23:17:52 UTC