RE: Stranger in a Strange Land

Roger,

Well, in a sense, these things *are* SOAP. SOAP defines an extensibility 
model that allows for
metadata to be attached to the message as header blocks, it then defines a 
processing model
for the message that specifies the rules by which a SOAP processor must 
abide (e.g. that it operates
in one or more defined roles. It provides the mustUnderstand attribute 
that a SOAP node uses to
communicate (in a standard way) whether the metadata carried in a header 
must be understood
and processed by a receiving node operating in the role that is either 
implied or specified (using the
role attribute (actor in SOAP1.1))  This allows the extensibility model to 
be consistently applied, which 
is an important point to achieving extensibility. 

The binding framework comes into play in the process of serializing the 
XML Infoset of the SOAP message
and binding it to the underlying transport/transfer layer. It provides for 
some of the features to be bound either
at the SOAP level (as SOAP header blocks that must be processed by the 
SOAP processor layer of software)
or at the protocol level, to take direct advantage of the protocol 
implementation of the feature, etc. An example
here might be the use of headers such as those specified by 
WS-ReliableMessaging to effect a SOAP level
implementation, or direct use of WebSphere MQ to effect the same level of 
quality of service required, etc.

I could go deeper, but the fact remains that SOAP is much more than *just* 
an envelope.

I believe that the SOAP1.2 specifications and the SOAP1.2 primer are the 
best sources of understanding
of the SOAP protocol. While I don't imagine or expect that the casual 
developer need necessarily read and
completely comprehend these specs, I do think that those of us who are 
crafting the WSA *should* do so.

Whether we like it or not, SOAP and WSDL are the technologies that the W3C 
has chosen to noodle on
in our sister WGs. IMO, the WSA should, nay MUST, recognize this fact and 
IMO focus its attentions on
defining an architecture that has these technologies in its realization. 
Our job should be to ensure that 
the specifications being developed in our sister WGs, and to the extent 
that we can influence, those being
developed elsewhere, satisfy the constraints that we define so that the 
properties we seek are realized.
Additionally, we should be seeking to understand and call out areas of 
conflict, gap or whatever between
these other specifications so that they can work towards resolving those 
issues.

Cheers,

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

"Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com> wrote on 
04/17/2003 08:30:19 AM:

> 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.