RE: Web Service Definition [Was "Some Thoughts ..."]

The flood-gate comment was not about trust -- I was trying to point out that
some of these definitions seem so general to me that they would include
things that did stuff that has absolutely nothing to do with the web or
anything that a reasonable person would consider the function of a web
service -- like having a person drive a car somewhere or fly a kite or make
a telephone call to his grandmother.  Or open the sluice gate of a dam.  

It seems to be a position that isn't getting a lot of agreement here, so I
guess I won't push it, but I would be happier with a definition that
sacrifices a little generality in order to say in simple, understandable
terms what these things are.  It seems to me that one way to do that would
be to say that these things accept requests that are XML messages and
respond with XML messages.  Since the XML thing is in our charter -- and
since every reference I have been able to find says that this is what web
services do -- I don't see that this limits anything unduly, and it makes
perfectly clear, to me at least, that a whole bunch of perverse things are
NOT web services.  Add that the web service is addressed by a URI and you
eliminate a bunch of other things, like orchestrations, that are not web
services per se.  It seems to me that then you would have a definition that
it would be easy to use to answer the question: "Is XYZ a web service?"
without getting involved in difficult discussions like whether the thing is
intended for machines or people, or people interacting through machines, or
machines using people, or ... 

-----Original Message-----
From: Sandeep Kumar [mailto:sandkuma@cisco.com] 
Sent: Thursday, February 28, 2002 3:53 PM
To: Joseph Hui; Vinoski, Stephen
Cc: www-ws-arch@w3.org
Subject: RE: Web Service Definition [Was "Some Thoughts ..."]


I agree with Joe.

A WS should be Discoverable (either by using standards based protocols or
via an out-of-band information) and is Described using a standards based
approach (what its capabilities are something that an API captures, or a
service contract). In the case of the an Intermediary WS, it does the same
thing and is well-understood and the description is implicit.

Whether one WS trusts the WS description or not is a different story (we
cannot solve the problem someone mentioned about opening a flood-gate).

Regards,

Sandeep Kumar
sandeep.kumar@cisco.com



-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Joseph Hui
Sent: Thursday, February 28, 2002 1:45 PM
To: Vinoski, Stephen
Cc: www-ws-arch@w3.org
Subject: RE: Web Service Definition [Was "Some Thoughts ..."]


> -----Original Message-----
> From: Vinoski, Stephen [mailto:steve.vinoski@iona.com]
> Sent: Thursday, February 28, 2002 12:06 PM
> To: Joseph Hui
> Cc: www-ws-arch@w3.org
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
>
> I still have to agree with Mark that you're defining requirements, not 
> creating a web services definition. I suggest again, as Mark did, that 
> we work from the one that he and I put together. Is there something 
> wrong with it? Is ti missing something?

Suffice to say my response to Mark the other day also applies here.

Per discussion on WS Def during today's telconf, I believe D&D ought to be
in.

Joe Hui
Exodus, a Cable & Wireless service
===============================================
>
> --steve
>
> > -----Original Message-----
> > From: Joseph Hui [mailto:jhui@digisle.net]
> > Sent: Thursday, February 28, 2002 2:59 PM
> > To: www-ws-arch@w3.org
> > Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
> >
> >
> > > From: "Anne Thomas Manes" <anne@manes.net>
> > [snip]
> >
> > Hi Anne,
> >
> > > I'm a bit averse to using the terms MUST NOT, SHOULD, and MAY.
> >
> > They were tided over from IETF.  Their virtue in standards discourse 
> > lies in the technical vigor as defined in RFC 2119.  They do tend to 
> > stiffen up sentences, to the detriment of their literary appeal. :-(
> >
> > > I'm not sure
> > > that we should impose the constraint defined by WSP04.
> >
> > WSP04 slams a door (a door, not all doors) at those who have funny 
> > ideas about hacking into a host via web services.  It also takes 
> > away a big rope (not all ropes, a rope nonetheless) that some 
> > implementors/deployers may hang themselves by accident. WSP04 pretty 
> > much conveys "web services have a property of being hacker 
> > unfriendly."  (BTW, "safe" could supplant "hacker unfriendly" with a 
> > leaning toward generality.)
> >
> > > I think it's useful
> > > to include WSP05, although I don't think it's an essential
> > aspect of what
> > > makes a web service a web service. I'm ambiguous about WSP06.
> >
> > WSP06 may be thought of as a clause of self-preservation (or 
> > robustness by agnosticism. ;-)
> >
> > > I think WSP07 goes into too much detail.
> >
> > Point well taken.  Indeed we can do away with the embellishment -- 
> > the last phrase of the first sentence and the parenthesized text, 
> > unless others object.
> >
> > > I think WSP08 gets too much into architecture,
> > > and isn't an essential aspect of what makes a web service a
> > web service.
> >
> > WSP08 is about D&D, which differentiates the web service model from 
> > the rest.  That is, D&D is one of the properties that WS are made 
> > of.
> >
> > [snip]
> > > One recommendation that I would make to Joseph's definition
> > is that we not
> > > call out any specific technologies (WSDL, UDDI, etc.) in the core 
> > > definition. Our architecture should provide
> recommendations on which
> > > technologies to use, not the definition.
> >
> > I can go along with not calling out specific technologies, and also 
> > to err on the side of generality (as opposed to specificity) if 
> > that's the WG's consensus.  As stated in a previous message, I'd 
> > like to also reiterate my position that we should be as specific as 
> > feasible.
> >
> > > I'd also prefer to use the more generic term "contract"
> > rather than "well
> > > defined input/output parameters".
> >
> > "Contract" can mean different things to different folks in WS. Thus 
> > one has to be overtly conscious of the context when "contract" is 
> > invoked.  Right off the bat, XLang comes to mind.
> >
> > Cheers,
> >
> > Joe Hui
> > Exodus, a Cable & Wireless service
> >
> >
>

Received on Thursday, 28 February 2002 17:55:32 UTC