xml-dev - RE: More analysis of XML messaging protocols

[johns@syscore.com (John F. Schlesinger)]

Henrik said:
"...transactions (TIP) - all of which are application layer features."

Although the ACID transaction is an application level concept, there is a
transaction concept in the synchronization capabilities of the session
level.

Admittedly, the session is a layer above the transport layer, in the OSI
model, but it is below the application.

Arguably, SOAP serialization is a presentation layer concept and so also
below the application. HTTP's use of MIME is also arguably a presentation
layer concept.

Yours,
John F Schlesinger
SysCore Solutions
212 619 5200 x 219
917 886 5895 Mobile

-----Original Message-----
From: Henrik Frystyk Nielsen [mailto:frystyk@microsoft.com]
Sent: Monday, August 28, 2000 12:35 AM
To: jicondon@us.ibm.com; gvh@progress.com
Cc: xml-dev@lists.xml.org
Subject: Re: More analysis of XML messaging protocols


Thanks for sending a link to this article. I would like, however, to point
out what I consider to be misunderstandings regarding HTTP and SOAP:

* HTTP is not a transport protocol - it is an application layer protocol
which provides a set of services that can be used for exchanging
information on the Web. As the Web has grown, HTTP has been enhanced with
a set of core features that made it better suited to handle this exchange
as well as scale better. It has also been enhanced with features for
dealing with distributed authoring and various other services including
transactions (TIP) - all of which are application layer features.

* Neither is SOAP a transport protocol - it also is an application layer
protocol. The main difference between HTTP/1.1 and SOAP/1.1 is that SOAP
barely contains any semantics at all whereas HTTP has a large set of
features. However, there are a lot of similarities between the message
model provided by SOAP and by HTTP - much more than between SOAP and
XML-RPC.

* Where HTTP has trouble is to support rich, nested parameters, and this
is where SOAP provides a benefit. Especially because SOAP has a very
flexible extensibility model that in many ways is a generalization of the
HTTP message model: It has a multihop message path model which provides
for flexible use of intermediaries and it has a modularized extensibility
model within a single message that allows for decentralized extensibility.
It is in other words exactly designed to accommodate the types of
interactions that are described in the article.

* None of the features that are put forward in the article are core
features for a widely deployed Web infrastructure - these are features
that are needed in specific environments but are clearly at a higher layer
than a basic message model. This is not to say that we don't need
standards for dealing with security, privacy, transactions etc. but these
services do not have to be part of the core protocol but rather can be
layered above or wrapped - SOAP and HTTP support both.

* SOAP is not an abstraction of a distributed object system. SOAP doesn't
know about objects (despite the word object in its name). There is no
assumed programming model or implementation language requirement behind
SOAP. It is strictly a wire based protocol that can be implemented any way
you like.

* There is no core reliance in SOAP on RPC whatsoever and SOAP is not tied
to HTTP any more than it can be tied to many other protocols - including
real transport protocols. SOAP is fundamentally a one-way message and so
can be used for whatever can fit within that paradigm.

Henrik Frystyk Nielsen
mailto:frystyk@microsoft.com

----- Original Message -----
From: <jicondon@us.ibm.com>
To: <xml-dev@lists.xml.org>
Sent: Wednesday, July 26, 2000 15:17
Subject: More analysis of XML messaging protocols


More analysis of XML messaging protocols



IBM Article: Analyzing XML messaging protocols

Messaging: The Transport Part of the XML Puzzle
--------------------------------------------------------------------------
--------------------
A follow up to the last few discussions,  this technical article explores
the more recent focus of how to transfer XML between parties as part of a
meaningful, reliable exchange. This article looks at major transport-level
options and compares how they  accomplish transferring XML between parties
reliably. You'll find an overview of the approaches of XML-RPC, SOAP,
WDDX,
ebXML, and JMS as they apply to XML transport, with simple example code.

Read full article from developerWorks:
http://www-4.ibm.com/software/developer/library/xml-messaging/?open&l=136,
t=gr,p=XMLmes

Other related article:
Globalizing ecommerce through XML and Unicode:
http://www-4.ibm.com/software/developer/library/globalsoft.html?open&l=136
,t=gr,p=XMLmes