RE: Some proposed definitions of "web service" based on the call toda y

> -----Original Message-----
> From: Cutler, Roger (RogerCutler) 
> [mailto:RogerCutler@chevrontexaco.com]
> Sent: Friday, April 18, 2003 9:11 AM
> To: Champion, Mike; www-ws-arch@w3.org
> Subject: RE: Some proposed definitions of "web service" based on the
> call toda y
> 
> 
> Now, if I am reading this right it seems that the WG, or some 
> portion of it, has somehow gotten the idea of defining Web services in a 
> way which is specific not only to a spec, WSDL

Please recognize that there is a genuine dilemma here, the depth of which
anyone on the call yestday may have gotten a deeper appreciation for :-)  

If we define "Web services" in a way that covers all or most of the ways
that this vague, marketing-generated term is used today, then it is going to
be impossible to define an architecture (i.e., a set of constraints) for Web
services ... because it means different things to everyone...

If on the other hand, we define a rigorous set of constraints that covers
what *we* mean by Web services, and presumably "blesses" the W3C versions of
the SOAP and WSDL specs, then there are currently few (perhaps no)
implementations that meet the strict definition.  I'm not sure this is such
a terrible problem, because we are chartered to develop a *reference*
architecture.

So, do we choose to define the fuzzy constraints of a large body of vapor,
or the hard constraints of an idealized vision?  As a pratical matter, the
former is impossible IMHO ... the WSA document would be so full of "may do
this, could do that, must do whatever your marketing weasels tell you to do"
that I'm not sure what good it would do anyone.   I'm sympathetic to the
position that some advocate that we just fuggidabout defining the term "Web
services," but that strikes me as a copout ... we're implicitly surrendering
to the "fuzzy constraints on vapor" approach if we can't define what it is
we're defining. 

So, I see two basic approaches (and as best as we could tell from a series
of straw polls, the WG is split down the middle on which is better): 

1) sieze the term "web services" for what we are defining (with proper
genuflections and apologies, e.g. "Many people use this term in different
ways, but FOR THE SAKE OF THIS DOCUMENT the term 'Web services' means blah
blah blah ...") 

2) let the term "Web services" belong in the realm of mist and vapor, and
use a more specific term (let's call is "X-WS" as a placeholder) in the WSA
document when we refer to the constraints of the somewhat idealized
architecture we are devising.

Probably the main reason  we didn't make much progress on the call was, as
Roger's post reminds us, what we *call* WS is intimately wrapped up in how
we formally define it, and we haven't decided whether WSDL, for example, has
a critical place in the constraint system.   Using, for the momment, the
"X-WS" placeholder, I'd ask the question:  "Do we impose the constraint that
X-WS MUST have a formal description in WSDL (or a language at least as
strong as WSDL)?   I think some weasel words are possible, e.g. "MUST have
or be able to produce on demand" to cover cases where producers and
consumers "just know" the X-WS interface, perhaps from shared source code,
an ontology, or whatever.  I got the impression from our discussion
yesterday that this would cover the cases that Roger has mentioned, since
WSDL could be generated "on demand" [in principle, anyway] to describe the
URI of the JPEG file being retrieved.

So, I think we can be rigorous in X-WS about WSDL and still include HTTP
GETs of XML and RESTful Web services, with some flexibility in the "supply
on demand" wording.  I don't know if this will cover ebXML as within the
scope of the WSA.  I'll guess that is will ... or at least will allow the
ebXML folks to rigorously define how they differ from WSA v 1.0, and perhaps
WSA v 2.0 and ebXML v. whatever could be architecturally compatible down the
road.  I'm leery of taking ebXML compatibility on as a requirement, however.

Received on Friday, 18 April 2003 09:58:20 UTC