W3C home > Mailing lists > Public > www-ws-arch@w3.org > April 2003

RE: Stranger in a Strange Land

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Thu, 17 Apr 2003 07:38:05 -0400
To: www-ws-arch@w3.org
Message-ID: <OFB278DF29.2A7144E7-ON85256D0B.003E764F-85256D0B.003FE758@us.ibm.com>
I think that it is important to keep in mind the fact that SOAP is *much 
more* than
simply an envelope. It is also a processing model, an extension and 
binding framework.
It describes a graph serialization and RPC stylized usage and has a 
defined HTTP binding.

SOAP is intended to be used with more protocols than simply HTTP, although 
for interoperability,
HTTP will likely be the predominant usage for some time to come. However, 
as I said, there's 
more to SOAP than simply an envelope. 

When I was first introduced to SOAP, I had the same thoughts;  "What's the 
point?" I too thought
to myself on occasion in the early days "I don' need no steenkin' 
baadgess"

I believe David Burdett, Eric Newcomer and others have pointed out, it is 
when you start thinging 
about standardized headers for things such as security, reliability, 
correlation, etc... the metadata 
that typically accompanies messages except in the most simplistic uses, 
that SOAP, with its well defined
processing model, extension and binding framework, etc. can yield 
significant benefits.

I am not just saying this because of the fact that I work for a large 
vendor. I came to this point of
view after cherishing all that I learned participating in the XMLP WG and 
then finally grokking what all
the fuss was about. 

I can say with some confidence that I now "get it" and no longer think to 
myself "what's all the fuss about".
SOAP is an important aspect. Certainly not "the" most fundamental aspect, 
but an important one none
the less. I do think that it is the ability to also describe, in a 
standardized way, using an XML vocabulary
that is also a fundamental characteristic of Web services, and that it is 
some synergy of these that
is really what makes Web services important.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-arch-request@w3.org wrote on 04/17/2003 04:21:26 AM:

> Roger, David:
> 
> In addition to these points, I would add that there is already a set of 
actors and roles (i.e. 
> useful, active things that we don't want to reinvent) that understand 
SOAP envelopes - the idea of
> just throwing that away is saddening.
> 
> Jim
> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On 
Behalf Of Burdett, David
> Sent: 17 April 2003 01:54
> To: 'Cutler, Roger (RogerCutler)'; www-ws-arch@w3.org
> Subject: RE: Stranger in a Strange Land

> I can't resist replying to this, and I will probably regret doing it, 
but here goes ...
> 
> Let's start with a question ... why does the USPS like envelopes with 
addresses on them in a standard place.
> 
> The answer (I guess) is so that they can more easily offer a lower cost 
postal delivery service to
> anyone who complies with their envelope standard. If there was no 
standard envelope format, then 
> they would have to do more work which would cost more - it's the usual 
"standards lead to lower 
> costs" argument.
> 
> Let's also face it we have envelopes already on the web, e.g. for HTTP 
and SMTP, people find them 
> useful but they only contain an address (e.g. a URL) and not much else.
> 
> So perhaps the real question is what reason is there to use a SOAP 
envelope over and above their 
> simpler HTTP or SMTP equivalents?
> 
> I think there is only one reason and its the same reason as for the 
USPS, i.e. it enables (or 
> perhaps more accurately will enable) a lower cost delivery service for 
electronic message.
> 
> Time for another a question. Why do FedEx and UPS exist and why can't 
they just use the same 
> envelope as the USPS or no envelope at all.
> 
> Again the answer is that for FedEx and UPS exist because they offer 
additional services at a 
> reasonable cost. They each have standard envelopes as they need 
additional information and putting
> that information on the envelope in a standard way makes it easier for 
them to offer the 
> additional services at a lower cost - just like the USPS
> 
> So what things could go in the SOAP envelope that allows additional 
value-added services to be 
> provided at lower cost through the use of standard infrastructure. The 
list I can think of includes:
> 1. Security - you can put a digital signature in there to secure the 
whole message
> 2. Reliable Delivery, you can use the headers for a RM protocol in there 
so that the application 
> need not be bothered to do the same
> 3. Conversation tracking. By using ids on a conversation you can have 
standard software that 
> routes where a message goes to when it is received - again the 
application need not bother
> 4. Choreogrphy checking, so that you can check that the sequence of 
messages in a business 
> transaction are being followed correctly.
> 
> OK you don't have to use SOAP for this, but it exists and, I think, 
meets the needs described 
> above quite nicely so why bother inventing anything else.
> 
> Right now we are designing: a) the equivalent of the FedEx and the UPS 
enevelopes, and b) the 
> infrastructure required to use them for a good purpose.
> 
> But I can *exactly* see why people say, I don't need envelopes now, 
since the infrastructure 
> hasn't been built out so the value is not there for people to see and 
use.
> 
> ... but I bet that when it is built out, people will use it because it 
provides value, for exactly
> the same reasons that people use FedEx and UPS and their standardized 
envelope formats today.
> 
> My $0.02c
> 
> David
> 
> -----Original Message-----
> From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@ChevronTexaco.com]
> Sent: Wednesday, April 16, 2003 4:54 PM
> To: www-ws-arch@w3.org
> Subject: Stranger in a Strange Land

> Once again I feel like I am torn between different universes.  It would 
be a lot easier for me, 
> and certainly more comfortable, if I spent my all my time in a single 
environment where everyone 
> comfortably accepts the same assumptions and values.
> OK, let's be more specific.  I have learned that a company which I think 
is much larger than any 
> represented in the W3C has forced another company that I think is larger 
than any in the W3C to 
> accept XML payloads (lots of them) totally without envelopes.  "I don't 
need no stinking SOAP". 
> Moreover, I find that many small to medium sized companies are objecting 
to the expense of 
> creating envelopes that they feel do not benefit them, and also wish to 
send bare XML payloads.  A
> very large company which has implemented an XXXX standard with envelopes 
(which we have also 
> implemented) has subsequently implemented an XXXX-lite -- which is just 
the body without any 
> envelope whatsoever.  Signing and so on, of course, are possible in this 
scenario.  Again, "We 
> don't need no stinkin SOAP".
> I find also that a company that is trying to make a business out of 
collecting and routing 
> business transactions has found itself under increasing pressure from 
the market and its clients 
> not to use envelopes.  They think that envelopes are very good things -- 
but they are moving 
> toward offering services that are envolope-free.
> So I ask, "What is the benefit of the envelopes"?  I ask people in my 
company who have implemented
> a business transaction project including envelopes and they tell me that 
envelopes are very good 
> and very forward looking -- they should be very useful for creating 
supply chain processes and 
> keeping track of what transactions have occurred, not to mention dealing 
with complex routing 
> situations -- but in fact they have not really done very much with the 
envelopes.  Well, exactly 
> what HAVE they done?  Well, they have made them and received them.  And 
I infer that they have 
> felt virtuous in the process.  Well, maybe they have looked at some 
statistics based on the 
> envelopes from the middleware a few times, and they feel good that they 
have been able to purchase
> middleware products based on the envelopes.  Perhaps this has saved 
development effort.
> I ask other people what the benefit is of envelopes, and I receive no 
answer that indicates to me 
> any benefit whatsoever to a small to medium sized company that does not 
have elaborate and 
> expensive middleware systems.  Envelopes seem to make it easy for 
expensive middleware in big 
> companies to keep track of things (although as far as I can tell most of 
the big companies are not
> really exploiting this for much) -- but for the little guys they appear 
to be pretty much 
> something that is being forced on them by the big guys.
> Except that the biggest of the big guys seems to be saying that they 
don't need no stinkin envelopes. 
> I think there is something wrong here, folks.  It seems to me that we 
may be seeing the beginnings
> of a market rebellion.  It would really, really be helpful to me if 
someone could remind me why 
> envolopes are so great.  I sort of have forgotten, as has everyone else 
I have been talking to 
> around here.  Just about everybody seems to agree that they are 
absolutely necessary -- but they 
> all seem to have forgotten exactly why.
> I don't have a good feeling about this, folks. 
Received on Thursday, 17 April 2003 07:38:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:17 GMT