Explanation / Defense of "+5"

> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Sunday, June 01, 2003 7:12 PM
> To: www-ws-arch@w3.org
> Subject: RE: Counting noses on "is SOAP and/or WSDL intrinsic to the
> definition of Web service" 
> 
> 
> I also think that, using Mike's words, "there is not much 
> difference between the +5 and the +10 positions, because SOAP 
> 1.2 and WSDL 1.2 are rich and extensible enough to encompass 
> things like RESTful and Semantic Web applications". In fact, 
> SOAP 1.2 Web Method feature supports a RESTful model, and the 
> WSD group is discussing how to integrate RDF in WSDL 1.2 as we speak.

Good points.  I have two concerns with "+10" that maybe some discussion
could alleviate.  First, I hope that a language that is rich enough to
contain WSDL's conceptual model but might have different syntax or
additional semantics would be considered in scope for WSA.  The obvious
example that we discussed in Rennes during Bijan's presentation is DAML-S.
In general, DAML-S descriptions seem to start by "importing" a WSDL
definition and then elaborating / annotating the semantics.  Thus, it's
clear that DAML-S is rich enough to contain WSDL's conceptual model.  Would
a WSD authored natively in DAML-S have to be translated to WSDL to be an
in-scope Web service? Or if, hypothetically, some Choreography spec built
its own description language into the choreography language rather than
extending WSDL, would those Web services be compliant / in-scope?  That's
why I am more comfortable with talking about the WSDL *concepts and
relationships* than "WSDL" per se.  I really don't want to make a big deal
out of this, however, it seems like it might be an excessively pedantic
distinction, but it's what I'm thinking now :-)

The other concern is SOAP.  There's a "what do I really need SOAP for"
permathread all over the place.  The response I'm most comfortable with is
"you don't REALLY need SOAP if you're doing simple, non-secure, non-mission
critical services using only HTTP.  You will find that you need SOAP *badly*
[1] once you start doing:  more complex things (e.g. involving message
correlation or transations); secure services where SSL doesn't do the job;
mission-critical stuff where you need reliability, routing or whatever; and
you start having to support multiple protocols or bridge across protocols
(SMTP/POP, JMS-interface proprietary protocols, MQ, or whatever).   So, I
don't want to say that people who don't really need SOAP must use SOAP (as
opposed to plain XML over HTTP) in order to be WSA-compliant.  Again, as Ugo
and Chris mentioned, it's possible that "SOAP" can be abstract enough to
cover such cases with the web-method stuff and perhaps more sophisticated
HTTP bindings than the one in 1.2, so this may be a red herring.  I can also
accept "put in some weasel words saying that this you can have web services
without SOAP but they are too unconstrained to analyze for the WSA." But
again, it's where my head is right now, and I would appreciate some
argument/explanation. 

[1] I am of  course aware of the RESTifarian counter-argument that all this
stuff is the application's job not the infrastructure's.  I just think
that's a non-starter for this group and for the industry we represent.

Received on Sunday, 1 June 2003 19:35:11 UTC