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 14:58:43 UTC