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

Re: targetResource and relationships

From: Sergey Beryozkin <sberyozkin@zandar.com>
Date: Tue, 24 Jun 2003 16:42:53 +0100
Message-ID: <000901c33a67$46e19fe0$1800a8c0@BERYOZKIN>
To: "Amelia A. Lewis" <alewis@tibco.com>, "Dave Hollander" <dmh@contivo.com>
Cc: <www-ws-desc@w3.org>

Hello Amelia,

> In other words, aggregation *cannot* solve the problem of multiplicity
> of service elements introduced by the single interface per service
> proposal.

I think it's a targetResource attribute which "introduces" a multiplicity
rather than a single interface restriction. Multiple interfaces per service
would still make it possible creating multiple service descriptions per
every targetResource, nor they would prevent using a single interface idiom,
that is having a separate service per a submission and management interface,
for example.
It just seems that allowing for multiple interfaces per service would make
it easier to apply @targetResource for the purposes of discovering the
*alternative ways only* of talking to the same resource (as a matter of
policy/best practices approach, etc).

Cheers
Sergey Beryozkin

----- Original Message -----
From: "Amelia A. Lewis" <alewis@tibco.com>
To: "Dave Hollander" <dmh@contivo.com>
Cc: <www-ws-desc@w3.org>
Sent: Tuesday, June 24, 2003 3:37 PM
Subject: Re: targetResource and relationships


>
> On Mon, 23 Jun 2003 16:00:20 -0700
> Dave Hollander <dmh@contivo.com> wrote:
> > I agree that there would be some simplifications if multiple
> > interfaces were allowed, however these are easily overcome by
> > creating a new service that provides a single interface to all
> > of the others.
>
> But not when it is not reasonable to aggregate these interfaces into a
> single interface, as when (for instance) a pub/sub notification
> interface exists as well as a client/server submission interface and a
> client/server management interface.
>
> Likewise, in the case of a management interface and a submission
> interface, these functions may be strictly separated (always accessed at
> different endpoints).  Forcing them into an aggregate requires the
> designer to either place both on a single endpoint, or to enable both
> endpoints to receive (and forward?) messages that should have been sent
> to the other, or (permissibly?) to actually implement only a portion of
> an interface within each endpoint.
>
> In other words, aggregation *cannot* solve the problem of multiplicity
> of service elements introduced by the single interface per service
> proposal.
>
> Amy!
> --
> Amelia A. Lewis
> Architect, TIBCO/Extensibility, Inc.
> alewis@tibco.com
>
>
>
Received on Tuesday, 24 June 2003 11:42:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:25 GMT