Re: /service/@targetResource ?

On Fri, 30 May 2003 09:12:46 -0700
"Jonathan Marsh" <jmarsh@microsoft.com> wrote:
> One problem we tried to address at the FTF was distinguishing in the
> WSDL between three cases not previously distinguishable:
> 
> 1) When a set of endpoints represent "alternative" bindings for the same
> interface acting on the same "thing" (e.g. SOAP and HTTP bindings as two
> ways to access the interface).

Perfectly feasible previously, and strengthened by the ability to do
interface inheritance, without restricting services to a single
interface.

> 2) When a set of endpoints represent different interfaces to the same
> "thing" (e.g. normal interface and a management interface).

Perfectly feasible previously, and unaffected by interface inheritance,
without restricting services to a single interface.

> 3) When endpoints are related in some other way (e.g. your use case, I
> think).
> 
> The terminology we developed is that a "service" is an interface on a
> thing, that can be accessed through various mechanisms.  Thus the term
> "service" and the "<service>" element have been clarified to cover case
> (1).  This is of course extremely useful for tooling.

Why?

This has been asserted repeatedly, but repeated assertion is *not* proof.

If a service contains two endpoints, which are associated with two
different bindings, then comparison of the interfaces associated with
the bindings yields equal/not equal.  If the stipulation is made that a
service represents a single service (in the new, more wonderfully
confusing terminology, a single "resource"), then identical interfaces
are necessarily simply different bindings for the same service.  The
only stipulation previously lacking was that a service element is to
represent a single service.

Equally, if a service contains two endpoints, which are associated with
two different bindings, and comparison of the interfaces associated with
those bindings yields not equal, then they offer different forms of
address to a single service, without introducing the term "resource" or
forcing a single service to be represented in multiple service blocks. 
Again, all that is required is the stipulation that a single service
element represents a single service.

What is lacking in this model is the ability to equate two separate
service elements that, in fact, represent the same service, either with
the same interface or with different ones.  By introducing confusion in
the name of simplicity, this use case has dropped off the map.  Or, as I
stated when this was originally proposed, the proposal not only fails to
add value, it removes it.  It confuses the meaning of the term
"service", it places a completely unnatural restriction on the service
element, it introduces a new term "resource" with ill-defined meaning,
and it fails to establish a comprehensible mechanism for expressing the
relationship between related services.

Had you gathered, by this point, that I find this change to be poorly
motivated and worse implemented?  If not, please be aware that that is
my opinion.

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 30 May 2003 12:56:36 UTC