Re: SOAP concerns

His reply was:

Thanks Marwan!  I really appreciate your comments.  I hope we can get a
real good conversation going on this. I would like to carefully analyze
your comments:

> SOAP provides a standard envelope ( and therefore
> standard tools) for message flow between two
> communicating parties.

I agree that a well-defined format is important and I admit that SOAP
does provide a (very) loose framework for sending data.

> Without SOAP, a publisher who wishes to publish his
> data on the Internet needs to worry about how to
> encode his data in XML.

I have not yet read the encoding spec.  I believe that the encoding
specified there is optional, correct?

In the other spec (the messaging framework spec) it says nothing about
the semantics of the Body element.  That is, it does not say "the
immediate child of the Body element must be the name of a method which
must correspond to a method in an application, and its child elements
must be parameters of the method". No, it doesn't say this at all.  It
says nothing, other than "Body must contain zero or more child
elements".  If I am a vendor wishing to implement this spec, I will look
for the spec to state the semantics of the Body element and its
children.  Just like the XSLT and XML Schema specs do.  They clearly,
unambiguously state the semantics of each element that you can use in a
stylesheet or schema, respectively.

In any case, let's assume that the encoding spec describes the semantics
of how to process the Body element's children.  Then yes, I agree that
it is beneficial that a SOAP client implementation can transparently
serialize to an XML encoding, and then a SOAP server and transparently
invoke a method in an application, and deserialize the XML.

I would like to consider the Header element.  The SOAP spec simply says
that it can contain zero or more elements.  It says nothing about the
semantics of those elements.  It does hint, however, that this section
may be used for achieving authorization, transactions, etc.  Really,
how?  Since the SOAP spec defines no elements then SOAP vendors must
define their own.  Let's consider providing functionality to support
virtual sessions, such as you might see on a web site which implements
shopping carts.  Suppose that vendor A implements sessions by defining
an element <SessionID>.  The vendor fully defines the semantics of this
element, and even defines that SOAP client implementations will
transparently store this element (just like browsers transparently store
cookies), and the SOAP client implementation will automatically forward
the SessionID (in the SOAP header) whenever a client application invokes
the server (just as a browser automatically forwards cookies to a
server).  That's how vendor A implements sessions.  It is totally vendor
proprietary and non-interoperable with any other vendor's implementation
(unless the other vendor happens to implement sessions in the same
fashion).  This is all due to the fact that the spec says nothing about
the semantics of elements within the Header element.

Moving to another topic (sorry, my thoughts are not cohesive yet.
Clarity is coming, however).  I would contend that the world is moving
more and more to document-based architectures.  I believe that SOAP is a
regression.  It is moving us back into API-based architectures.  Here's
how a client application uses SOAP today: "I need to invoke the method
on that server over there.  That method takes three parameters - the
first is an integer, the second a boolean, and the third a float."
Contrast that with a document-based architecture, where we would pass an
(XML) document to the server side.  Now I know what you are thinking,
"but  SOAP does use documents.  It is a document-based
architecture".  Wrong!  It is not a document-based architecture.  A
document-based architecture is one where the client creates a document.
In the SOAP paradigm the client does not create a document.  Rather, the
client assigns values to parameters.  The fact that SOAP converts the
method call and parameters to an XML document is irrelevant.  The form
of the transport is immaterial.  What characterizes a document-based
architecture is that at both ends (client-end and server-end) you are
dealing with documents.  The form of the request in-between those end
points is immaterial.

I think that todays HTML-based architecture has gotten it right:  You
send an HTML document to a server, and the server processes the
document.  The HTTP header contains info about the client and the HTTP
payload.  The semantics of all the elements in the HTML document is
clearly defined (not left up to the vendors to invent).  What the world
needs now is to move from HTML documents to XML documents.  SOAP is not
taking us in that direction.

I am becoming increasingly convinced that using SOAP to implement web
services is a bad idea.  I see no reason for not using a document-based
architecture, such as HTML plus Java servlets, to implement web
services.  I am strongly tempted to advise my clients to dump SOAP.
However, I am open to be convinced otherwise.

Sorry for such a long message.  Anyone still reading? :-)

Marwan Sabbouh wrote:

> Sir;
>
> SOAP provides a standard envelope ( and therefore standard tools) for
> message flow between two communicating parties.  Without SOAP, a publisher
> who wishes to publish
> his data on the Internet needs to worry about how to encode (represent) his
> data in XML.  Having figured out how to encode the data in XML, he needs to
> provide tools that understands
> the encoding, and  APIs for programmers to call to extract the data.  A user
> of this service would have to use these tools to connect to the publisher
> service.  He might need to
> use a different set of tools to connect to somebody else 's service, and so
> on...With SOAP, standard tools for sending and receiving XML messages are
> available.
>
> Your claim that you can put anything into an envelope is correct!, But this
> is exactly the point.  Similarly, you can put any data ( in any format)
> into the Dublin Core Standard
> element.  TCP can transmit any types of data, etc..  My point is this is a
> good thing.
>
> The body is there is to distinguish it from the header.  A body is intended
> to the ultimate recipient.  A header can be processed by an intermediary,
> such as an authentication
> service that may exist without the sender knowing about it!
> in that sense, SOAP can be viewed as a peer-peer messaging layer( protocol)
> or a multi- participant protocol.  The Header mechanism is there to allow
> for extensibility and
> modularity of the protocol
>
> You r assertions:"  This is useless.  This leaves
> implementors clueless of what to do with the contents of a Body
> element.  Worse, it leaves every implementor free to do anything they
> want.  This makes all SOAP implementations non-interoperable."
>
> Who is the implementor? if you mean the SOAP processor implementor, then the
> spec says it is perfectly legal to have multiple children for the body
> element.  All the
> implemetor has to do is to pass the children to the application implementor
> who know what to do with them.  If by implementor you mean the SOAP
> application implementor,
> then it should process them according to the application semantics.  Recall
> SOAP does NOT define any application semantics!
>
> Soap allows for   semantics thru the use of SOAP modules.  Modules are not
> currently defined for this version of the spec.  Future versions do just
> that.
>
> Finally, SOAP interoperability is a major concern of mine.  But I am not
> sure we are in agreement on what is meant by interoperability.. Let me
> elaborate please.
>
> I publish my Soap service usin Microsoft tools.  Any SOAP consumer must be
> able to consume the service using  tools from any vendor ( not just MS).
> The problem with
> SOAP 1.1 was that it was silent on lots of issues.  An example would be Soap
> Action.  Soap 1.2 is clearing up lots of these issues.
>
> I hope this helps
> marwan
>
> Marwan Sabbouh wrote:
>
> > I recieved this email questioning the value of SOAP.
> >
> > Hi Folks,
> >
> > Some concerns that I have with SOAP ...
> >
> > I have taken a look at the latest draft of SOAP.  As far as I can tell,
> > SOAP now defines a shell into which you can put anything.  No semantics
> > are defined for any of the elements.  For example, the Body element is
> > defined to contain zero or more children.  That's the extent of their
> > definition of the Body element!  This is useless.  This leaves
> > implementors clueless of what to do with the contents of a Body
> > element.  Worse, it leaves every implementor free to do anything they
> > want.  This makes all SOAP implementations non-interoperable.
> >
> > I am all in favor of extensible schemas, but you've got to first have
> > something concrete to extend.
> >
> > At this time I am hard pressed to see any utility for SOAP.  Why would I
> >
> > use something that is devoid of substance, when I can already implement
> > (HTML) text-based Web services using Java Servlets, CGI, JSP, APS, etc?
> >
> > Just a few thoughts...  Your comments are eagerly welcome.

Received on Thursday, 11 October 2001 08:02:53 UTC