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 16:53:59 UTC