Re: Explanation / Defense of "+5"

I go back to tooling. We want to make sure that developers have a choice of
tools for building Web services. Tools require a standard description
language (as well as a standard protocols).

While I agree that it's useful to be able to support DAML-S in place of
WSDL, the "better" way would be to have DAML-S extend WSDL rather than be an
alternative to WSDL.

Our other alternative is to name more than one description language (but we
definitely want to limit the number of standard description languages).

Anne

----- Original Message -----
From: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
To: <www-ws-arch@w3.org>
Sent: Sunday, June 01, 2003 7:34 PM
Subject: 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 Monday, 2 June 2003 08:10:02 UTC