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

Steve,

Let me repeat that my only concern is if this definition is "too" broad.
I think this concern was also voiced by Roger Cutler very eloquently in
this explanation of the "flood-gate" comment. The lowest common
denominator approach will muddle the field for anyone trying to gain any
insights into web services from this definition. My belief is the
definition must serve a useful purpose beyond casting a wide conceptual
net that is indisputable. It should contribute towards better
understanding the beast. It will be a disservice if we leave folks
wondering if an ftp server is a web service, an smtp server is a web
service etc. While conceptually they are services, they might not help
anyone understand web services any better. 

The only reason I want to "tweak" the definition is to raise the bar a
little more in terms of what characterises web services, so the
definition is not too general/abstract, and so its easier to relate to. 

I can understand your preference for not mentioning technologies. I can
live without mentioning XML myself. The reason I did is because it will
indubitably be the glue that holds web services architecture together,
and therefore might be considered a required characteristic of web
services.

--Srinivas

-----Original Message-----
From: Vinoski, Stephen [mailto:steve.vinoski@iona.com]
Sent: Thursday, February 28, 2002 4:08 PM
To: Srinivas Pandrangi
Cc: www-ws-arch@w3.org
Subject: RE: Web Service Definition [Was "Some Thoughts ..."]


Comments embedded below.

> I like Steve's definition of a web service. It captures some 
> of the most
> important aspects of a WS. My only concern is if it is too broad to be
> useful. If we turn the question around, is everything that 
> qualifies as
> a web service according to this definition actually a web service? For
> example, a "hello world" cgi program can be a web service according to
> this definition.

Sure, and why not? If I have an application that interacts with that
"hello world" CGI program, then that program is providing a service to
that application. I deliberately worded my definition to account for
this.

> A couple of options to narrow this definition:
> 
> I think emphasising the "component" aspect of web services can help
> narrow this definition further. I think the fact that web 
> services lend
> themselves to aggregation/composition is an important aspect of
> web-services.

Nothing in the definition disallows aggregation or composition.

> Emphasisng the use of XML for communication would also 
> differentiate web
> services from "any old services".

XML is a technology, and we don't want to define web services in terms
of technologies that might be used to implement them.

> I appreciate the fact that it is not easy to come up with a reasonably
> simple definition that is not too broad, not too narrow and fits in
> 50-100 words :) Thanks very much Steve/Mark/Joe et al., for 
> the proposed
> definition.

You're welcome. I'm still not sure why people feel the need to
continually try to tweak the definition that Mark and I have provided
(starting from Mike's original definition), however, because it's really
about as simple and complete as it can get.

--steve

> 
> --Srinivas
> 
> -----Original Message-----
> From: Vinoski, Stephen [mailto:steve.vinoski@iona.com]
> Sent: Thursday, February 28, 2002 2:03 PM
> To: Joseph Hui
> Cc: www-ws-arch@w3.org
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
> 
> 
> And as I explained on the teleconference: discovery isn't a necessary
> part of the definition, because I can write a system where 
> applications
> access web services via URIs and communicate with them via standard
> protocols, all without the aid of any discovery service such 
> as UDDI or
> WS-Inspection. I have real-world proof of this: some of 
> IONA's customers
> have web services in production right now and are not using a 
> discovery
> service in their systems.
> 
> As for description: the fact that XML-RPC has been around for several
> years now and has facilitated the creation of web services without the
> need for a description language ala WSDL should be proof enough that
> description is not a necessary part of the definition, either.
> 
> On another note, in another email, you said:
> >WSP08 is necessary because the property to be described
> >and to be discovered differentiates the Web Service computing
> >model from other contenders, such as EDI, CORBA, ...
> 
> Just wanted to correct you: CORBA allows services to be described and
> discovered. Description has always been a part of CORBA via its
> Interface Definition Language (IDL), and discovery occurs through
> standard services such as Naming (like telephone white pages) or a
> Trader (like telephone yellow pages).
> 
> --steve
> 
> > -----Original Message-----
> > From: Joseph Hui [mailto:jhui@digisle.net]
> > Sent: Thursday, February 28, 2002 4: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:53:23 UTC