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

I agree with Hao -- there are a lot of practical cases where the extra
features of SOAP are just not necessary, and the SOAP stuff just extra
overhead, or branding perhaps, that actually has a negative effect
because you are now forced to use software that understands it.  That
may be something that looks good to a software vendor, but not really to
an end user.

-----Original Message-----
From: Hao He [mailto:Hao.He@thomson.com.au] 
Sent: Thursday, June 05, 2003 7:29 PM
To: 'Christopher B Ferris'; www-ws-arch@w3.org
Subject: 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]

Received on Friday, 6 June 2003 12:36:42 UTC