RE: Stranger in a Strange Land

Good points.  However, to some extent I don't "get it".  If you have the
time and inclination, could you explain the first paragraph in more
detail?  I don't understand some of those phrases -- or at least how
they apply here.  And, I guess if I don't understand and assuming that
I'm not all that atypical, perhaps a fuller explanation could be
usefully harvested.
 
-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
Sent: Thursday, April 17, 2003 6:38 AM
To: www-ws-arch@w3.org
Subject: RE: Stranger in a Strange Land



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.