RE: Counting noses on "is SOAP and/or WSDL intrinsic to the defi nition of Web service"

hi, Chirs,

Thanks for the reply and very good explaination on SOAP. Here are my
comments:

Plain XML does not have a process model as does SOAP (or, you could say it 
has
many). 

<hh>Plain XML does not mandate a process model and in may cases, that is
what a business wants. </hh>

If there are intermediaries, how are they constrained? Is there an order to
processing aspects of the content? If I want to digitally sign the 
message, where
does that go? What if I want to target certain aspects of the message at
particular nodes acting in particular roles? How many gazillion ways do you
think  that could be expressed in plain ole XML?

<hh>You are talking about SOAP processing model again. Yet again, in many
cases, people do not need intermediaries. Plain HTTP proxies are all they
need. The point is that plain XML does not do all those things and there is
no need for those things. </hh>

Sure, I suppose you could say "use HTTP and have the entity body of the
messages be the same as the SOAP:Body content, just plain ole XML", but then
the issue of extensible HTTP header fields rears its ugly head. There's no
way to tell your 
extension header called 'foo' from mine with the same name and they could
have wildly different semantics. 
Sure, we could spend a whole lot of time and energy re-inventing HTTP to
accomodate the 
types of things that SOAP has been designed to do, but that was largely why
SOAP was created in the first place!

<hh>First, we can only put Web Service semantics into the SOAP heads.  As
soon as you start putting application specific semantics into SOAP heads,
you need an application to understand that. In this case, there is no
difference if one puts all semantics into the body. Second, SOAP was created
in the first place to do XML RPC!</hh>


With plain ole XML, what we have is total anarchy. I can tell you that 
nearly every vocabulary
has the rough equivalent of a body and headers, each with its own process 
model and each 
with its own structure. Take a look at early RosettaNet, OTA, SIF, HL7, 
and OAG work among
others. You will note a pattern, but you will also note that each had its 
own thing going on. How 
does one write software for this wide range of possible formats unless it 
is specific to a given
format?

<hh>We are not talking about semantic web, do we? If we are talking about
Web Service specific semantics, there is large base of use cases in which
one simiply gets and posts XML from/into a URL. In those cases, it does not
matter that kind of XML you are sending around. </hh>

It simply doesn't scale, and it is simply non-interoperable on a broad 
scale. Certainly,
you would not want to have to imlement an infinite number of possible 
reliable messaging
engines, one for each vocabulary that someone decided to concoct? Same for 
security,
for business process choreography, etc. That's what middleware is for, to 
do the heavy
lifting for common tasks, removing the need for the application programmer 
to deal with
such things (which are often way above their capacity to handle correctly 
and efficiently
anyway).

<hh>That is fine if we can do all those wonderful things with SOAP. All I
want is that a middleware we are getting from a vendor also supports plain
old XML, perhaps wrapping it automatically with SOAP if we need all those
features. In cases, we don't want those features, we can still send plain
old XML around, and yet to be part of the Web Service architecture. </hh>

So, in short, plain ole XML as payload is not interoperable other than the 
fact that 
XML itself, and XML parsers are (mostly).

<hh>well said. In those cases that we don't use special SOAP added features,
plain XML is just as interoperable. </hh>

Cheers,

Hao

> ok, a really dumb question: why would SOAP binding be more interoperabe 
than
> plain XML binding? 
> 
> Hao
> 
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Thursday, June 05, 2003 2:32 PM
> To: Jeff Mischkinsky; David Orchard; www-ws-arch@w3.org
> Subject: RE: Counting noses on "is SOAP and/or WSDL intrinsic to the
> definitio n of Web service"
> 
> 
> 
> Yes, that's my point too.
> 
> Ugo
> 
> > -----Original Message-----
> > From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com]
> > Sent: Wednesday, June 04, 2003 8:34 PM
> > To: Ugo Corda; David Orchard; www-ws-arch@w3.org
> > Subject: RE: Counting noses on "is SOAP and/or WSDL intrinsic to the
> > definitio n of Web service"
> > 
> > 
> > I think the point here is that for interoperability reasons 
> > we need to 
> > require at least a SOAP binding. Other bindings are possible 
> > and useful in 
> > addition.
> >    jeff
> > 
> > At 03:08 PM 6/4/2003, Ugo Corda wrote:
> > 
> > >By the same logic, would a WSDL binding to plain Java calls 
> > (sender and 
> > >receiver within the same Java process) correspond to a Web 
> > service? Or a 
> > >WSDL binding to RMI, or to DCOM, or to IIOP? Certainly possible WSDL 
> > >bindings cover a lot of territory ...
> > >
> > >Ugo
> > >
> > > > -----Original Message-----
> > > > From: David Orchard [mailto:dorchard@bea.com]
> > > > Sent: Wednesday, June 04, 2003 2:47 PM
> > > > To: 'Jeff Mischkinsky'; 'Christopher B Ferris'; www-ws-arch@w3.org
> > > > Subject: RE: Counting noses on "is SOAP and/or WSDL 
> > intrinsic to the
> > > > definitio n of Web service"
> > > >
> > > >
> > > >
> > > > Another question to the +10ers.  If a WSDL file can describe
> > > > a service that
> > > > uses HTTP GET and POST and not SOAP, as in
> > > > http://www.w3.org/TR/wsdl#_http,
> > > > is that service a web service?  Under the +10 definition, it
> > > > isn't.  So the
> > > > "Web service" description language describes Web service +
> > > > something else.
> > > > What do you call that something else that WSD can describe
> > > > but isn't a Web
> > > > service?  Which also means that we actually have a Web
> > > > Service + some other
> > > > thing Description Language.
> > > >
> > > > Dave
> > > >
> > >
> > 
> > 
> [attachment "InterScan_Disclaimer.txt" deleted by Christopher B 
Ferris/Waltham/IBM]