Re: targetResource and relationships

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 UTC