[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

What is SOAP?

  • To: xml-dev@l...
  • Subject: What is SOAP?
  • From: amyzing@t... (Amy Lewis )
  • Date: Thu, 21 Feb 2002 08:47:26 -0500
  • User-agent: Mutt/1.3.27i

what is soap
I'll try to keep this short, although terseness is not one of my noted
virtues.  Advance apologies.

Four months or so ago, I probably would have agreed with the
evaluations of Bruce Schneier in Crytpo-gram, and of Paul Prescod here. 
SOAP-as-marketed (and -hyped) is an RPC mechanism running over HTTP
(only) in order to defeat firewalls and allow high-school dropouts to
expose insecure ecommerce services on a shoestring budget.  Grant you,
I'm not delivering the peroration as convincingly as the PR flacks, but
it's interesting that this is a world in which those promises are
attractive.

Since then, I've had to read the various specifications and mailing
lists in support of an implementation effort.  SOAP-as-specified isn't
RPC, isn't reliant on HTTP, doesn't change current usage patterns for
services (and isn't particularly accessible to amateurs).

SOAP-as-specified isn't even an application protocol.  You don't
discover this by reading the spec, btw, you discover it by having read
application protocol specs, and then reading the SOAP spec, and
noticing what's left out.  A lot is.  SOAP isn't really able to run
over TCP (or UDP, or T/TCP, or any other transport-level protocol).  It
needs an application protocol, with existing connection semantics and
plugin style architecture, in order to work at all.  HTTP fulfils the
role best, because HTTP has traditionally hidden all sorts of
interesting cruftiness behind a single URL (servlets, ISAPI, NSAPI, CGI
... you *can* program these things so that every access has a unique
URL, but I don't know anyone who does so reliably, and I do know
several applications that provide a single access point,
differentiating only by supplied parameters, POST-only).  SMTP is also
usable, and so is JMS, or Jabber (SOAP::Lite runs over Jabber), or a
number of other possibilities.  All of those possibilities are less
attractive for sales and development because none of them offer the
equivalent of servlets/ISAPI/NSAPI plugin functionality.

SOAP *is* an extensible message format for data exchange.  It's a
formalization of what the data looks like between two application
protocols, with some semantics for processing (associated largely with
headers and faults).  SOAP+WSDL is a means of describing typed message
exchange patterns (request/response, one-way from client, notification
from server, alert/response).  (I'll agree that WSDL is unreadable, if
you'll agree that URL-encoded parameterized URLs are ... but I can read
both, without much difficulty)

As part of the specification, SOAP also suggests a means by which
object-oriented geeks can map an object graph into an XML tree,
suggests how to bind SOAP over the most available and useful protocol
(HTTP), and suggests how messages of certain patterns can emulate RPC.

None of these specifications change current usage patterns as applied
to "web applications," which already carried application-specific
information that potentially caused state changes on the server, and
could easily carry RPC, using name-value pairs as parameters.  SOAP
formalized, offered extensions (because a tree is potentially more
expressive than a bag), and divided the message into a 'main' part (the
body) and auxiliary bits (optional headers).

Message format and message exchange patterns.  Typing and
standardization of content for application protocols over which it is
delivered.

POST to a single URL, differentiating by content, probably violates
REST principles.  It's extremely common in practice.  SOAP offers, in
the main, a standardization of what that looks like--the data that your
servlet or component ought to eat, and what kind of syntax the response
ought to contain.

Amy!
-- 
Amelia A. Lewis	        amyzing@t...           alicorn@m...
The law, in its majestic equality, forbids the rich as well as the poor
to sleep under bridges, to beg in the streets, and to steal bread.
                -- Anatole France, "Le Lys Rouge"

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.