- From: Amelia A. Lewis <alewis@tibco.com>
- Date: Tue, 24 Jun 2003 12:01:41 -0400
- To: "Sergey Beryozkin" <sberyozkin@zandar.com>
- Cc: dmh@contivo.com, www-ws-desc@w3.org
Sergey, On Tue, 24 Jun 2003 16:42:53 +0100 "Sergey Beryozkin" <sberyozkin@zandar.com> wrote: > > 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. I largely agree. The *requirement* that each service have a single interface, though, is what drives the multiplicity (in my opinion). > 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). Agreed. Amy! -- Amelia A. Lewis Architect, TIBCO/Extensibility, Inc. alewis@tibco.com
Received on Tuesday, 24 June 2003 12:00:54 UTC