W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2003

Re: proposal for restricting a service to a single interface

From: Amelia A. Lewis <alewis@tibco.com>
Date: Wed, 30 Apr 2003 13:20:42 -0400
To: "Arthur Ryman" <ryman@ca.ibm.com>
Cc: www-ws-desc@w3.org
Message-Id: <20030430132042.338391fc.alewis@tibco.com>

Dear Arthur,

On Wed, 30 Apr 2003 12:56:41 -0400
"Arthur Ryman" <ryman@ca.ibm.com> wrote:
> My reading of "alternative ways to invoke the service" is that there
> is one state machine as you call it. 

It is not so stated explicitly.  It is therefore perfectly legal to
build an aggregated WSDL that exposes only the service element for
seventeen different vendors offering semantically-equivalent services.

> Putting 17 vendors into the same <service> violates that. For example,

Violating unstated assumptions is generally considered an error in the
specification, not in the implementation.

> You may regard the proposed restriction as silly and of no value, but
> I hope you'll grant that it is at least simple and clear.

The following is simple and clear:

Every service element MUST include an attribute with the localname
"magicword" and a value from the following enumeration: "xyzzy" "plugh".

But, you know, most of the time "Nothing happens."  Clarity without
purpose is valueless.

Worse, the restriction that each service must contain ports that
implement only a single interface means that the example that I
originally gave, where a single service instance has both administration
and notification interfaces, MUST use complicated tricks in order to
create the association between these two interfaces.  Requiring that
each <service> element represent a single instance of a service is
simple and clear, and makes the relationship between differing port
types perfectly clear without forcing developers to generate bogus

Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
Received on Wednesday, 30 April 2003 13:20:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:42 UTC