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

+1

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

Ugo Corda wrote on 06/06/2003 01:17:05 PM:

> 
> I don't think anybody who voted +10 denies any of these points, or wants 
to prevent people from 
> taking these different approaches, or says that these alternative 
approaches are bad in their own 
> application domains.
> 
> The only real point here is whether, when it comes to define what the 
label "Web services" exactly
> means and what should be the scope of WSA's work, these alternative 
approaches by themselves qualify or not.
> 
> Again, it's not a matter of judgment. It's a matter of labeling and 
scoping.
> 
> Ugo 
> 
> > -----Original Message-----
> > From: Cutler, Roger (RogerCutler) 
> > [mailto:RogerCutler@chevrontexaco.com]
> > Sent: Friday, June 06, 2003 9:33 AM
> > To: Hao He; 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"
> > 
> > 
> > 
> > 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 13:25:51 UTC