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

Comments embedded below.

> 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.  

Given that the definition that Mark and I've developed specifies URIs
and standard internet protocols as key parts of what constitutes a Web
Service, it clearly avoids the generality you fear. I assume therefore
that your paragraph above is talking about other proposals.

> 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.

XML is a technology that can be used to implement web services, but we
don't want to define Web Services in terms of technologies. Do we define
objects in terms of Java or C++? Do we define a network in terms of
Ethernet or CAT-5?

> 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.

I disagree. I am a big fan of orchestrations as related to Web Services,
and thus would not promote a definition that disallows them. URIs do not
disallow orchestrations.

> 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 ... 

In web terms, a Web Service *is* defined by the fact that it evolves the
Web beyond browser/web server interactions to true
application-to-application interactions that do not directly involve
humans. You can't define Web Services without addressing this key
element.

--steve


> 
> -----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 19:50:47 UTC