Re: SOAP concerns

>In the other spec (the messaging framework spec) it says nothing about
>the semantics of the Body element.


That is precisely the point.  SOAP does not define any application semantics.  A
SOAP vendor does not care about the semantics of the body element.  However, SOAP
provides you a mechanism by which A SOAP vendor defines the semantics for a
particular application (extension).  This is the purpose of the XML namespaces
(right?) . That is how
SOAP achieves extensibility.  Additionally, the SOAP encoding section, which is
optional, defines the serialization rules. .   Here is an example.  In this
example the semantics of
the children of the body element are specified in the m qualified namespace.  The
application defines that namespace, not the SOAP vendor.


POST /StockQuote HTTP/1.1
Host:
www.stockquoteserver.com
Content-Type: text/xml;
charset="utf-8"
Content-Length: nnnn
SOAPAction:
"Some-URI"

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <SOAP-ENV:Body>
       <m:GetLastTradePrice xmlns:m="Some-URI">
           <symbol>DIS</symbol>
       </m:GetLastTradePrice>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>



>>>>>  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.
>>>>>>

Let us consider the above example.  A SOAP vendor wishes toprovide an added value
to his customers, so he implements the virtual session mechanism you described
above.
Here is what the vendor does.:
1- The vendor defines a virtual session model by defining a <sessionID> header
block using XML schema with it a target URI.  The vendor then uses the
SOAPencoding
attribute on the SessionID element with that URI.  In this case the SOAP envelope
migjht lookmlike this:


<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/SessionID">
<SOAP-ENV:Header>
<SessionID>
.....
<\SessionID>
<\SOAP-ENV:Header>


IMPORTANT

The SOAP processor did not change.  It is the same code as it was before defining
the SessionId header block.  This is the value of SOAP.  It
permits other vendors to provide added value.  All the vendors need to do is agree
on the same encoding which is defined outside the SOAP
processor.


<SOAP-ENV:Body>
  .......
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

>>>>>>
 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."
>>>>>>>>>>>

This is just one example of SOAP.  Biztalk document 2 is a document based
architecture using SOAP.

Marwan

Marwan Sabbouh wrote:

> 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:08:35 UTC