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

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:17:20 UTC