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

Apologies for not formally introducing myself before-hand. I did join the
phone conference today and agree with moving on to requirements rather than
going back and forth on the definition of what a Web service is, and what
the Web services architecture is.

I personally agree with Sharad's definition, but see the point of other
people finding it to be too restrictive by adding D&D explicitly in the
definition.

Here's a thought at being able to achieve middle ground:

To me, the notion of loose coupling has a lot to do directly with being able
to describe, publish and therefore discover and bind to a Web service.

Therefore, without getting into all those details, may I suggest we use the
loose-coupling aspect to achieve middle ground, generality, but not too
much.

Sincerely, 
Shishir GARG 
France Telecom R&D
801 Gateway Blvd. #500
South San Francisco, Ca. 94080 
Tel: +1 650 875 1540 
Fax: +1 650 875 1505 


-----Original Message-----
From: Vinoski, Stephen [mailto:steve.vinoski@iona.com]
Sent: Thursday, February 28, 2002 2:05 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
> > > 
> > > 
> > 
>