Re: SOAP concerns

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 07:55:44 UTC