W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

Re: Two uses of SOAP

From: Francis Norton <francis@redrice.com>
Date: Mon, 30 Jul 2001 20:23:43 +0100
Message-ID: <3B65B43E.106CA86F@redrice.com>
To: Kurt Cagle <cagle@olywa.net>
CC: xml-dist-app@w3.org, "Frank D. Greco" <fgreco@crossroadstech.com>
Hello co-author!

Another thing that "just doesn't feel right" is the lack of clarity
caused by the encoding and
RPC options. I think it would be really easy to sell and use a
technology for which the message is "this is optimised to send and
receive XML documents" but as it is there are too many complexities,
there's a fundamental vagueness about what it actually deals in - 

5)      What does it transport: Is it XML documents (provided they don't
contain PIs - but are there any other limitations)? Or is it XML
serialisations of program data structures (which can be expected to
conform to tighter syntax constraints)? And how do SOAP encodings apply
non-RPC usage? And how does RPC apply to non-encoded data? And is there
a documented method of stating that the payload is plain XML?


Kurt Cagle wrote:
> The disadvantages? Oh, I can think of a few on that one:
> 1) Because it is essentially a large clear-text message, it requires
> encryption of the message for anything involving secure information; for a
> p2p chat system the overhead that this imposes is fairly minimal, for a
> large-scale e-commerce envelope used in RPCs the construction of the
> message, the encryption, the increased size for often relatively small
> amounts of data moving either way and the parseing of XML structures on both
> ends brings a significant cost to the total transaction.
> 2) I worry about putting an RPC mechanism into the hands of VB scripters and
> HTML coders who have absolutely no clue about handling distributed
> asynchronous messages, or worse, that do but have malicious intent. I worry
> that there is no checksum or integrity checking.
> 3) MustUnderstand could prove to be a significant hurdle across multiple
> peers.
> 4) I worry about the plethora of namespaces that we're introducing. While it
> may make sense to separate functionality into distinct messages, I can't
> help but think about the problems attendant when Netscape moved their RSS
> spec around -- we may be introducing dependencies here that are neither
> necessary nor intended.
> Just a few of my thoughts. I'm definitely still something of a newbie when
> it comes to SOAP, so some or perhaps all of these issues may already be
> resolved, but I think it might be worth asking this question of other people
> who aren't so close to the issue or the specification.
> -- Kurt Cagle
> -- Co-author, XML Schema, Wrox Press
> ----- Original Message -----
> From: "Frank D. Greco" <fgreco@crossroadstech.com>
> To: <xml-dist-app@w3.org>
> Sent: Monday, July 30, 2001 6:45 AM
> Subject: Re: Two uses of SOAP
> > At 09:49 PM 7/27/2001 -0400, Mark Baker wrote:
> >  >Just thought I'd write down more about the two uses of SOAP that
> >  >I'm familiar with.
> >
> > Actually, anyone have any thoughts (or URL's) of the
> > disadvantages of SOAP?  Something just doesn't feel right
> > about it.
> >
> > Frank G.
> > +======================================================================+
> > | Crossroads Technologies Inc, 55 Broad Street, 28th Fl, NYC, NY 10004 |
> > |    Mobile Java Application Engineering                               |
> > | Email: fgreco@CrossroadsTech.com         Web: www.CrossroadsTech.com |
> > | Pager: 800-495-6244                   ePager: 4956244@skytel.com     |
> > | Voice: 212-482-5280 x229                 Fax: 212-482-5281           |
> > +======================================================================+
> >
> >
Received on Monday, 30 July 2001 15:24:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:14 UTC