Re: targetResource and relationships

+1!

I agree that targetResource can be very useful even if <service>
supports multiple interfaces. IMO the single interface approach is
simpler to understand, easier for tools and can do everything the
multiple interface version can do. Undoubtedly, it does make some
scenarios harder to describe.

Its all about 80-20 to me. I still believe that single interface /
service is the 80-20 and not the other. Thus, I like having the
approach that makes the common case simpler and yet leaves the
other cases possible. YMMV.

It appears to me that the model of a service that we developed
in Rennes still holds no matter what we decide for these issues.
IMO that would be very good as that'll allow WS-Desc and WS-Arch
to use a single view of this beast.

Sanjiva.

----- Original Message -----
From: "Dave Hollander" <dmh@contivo.com>
To: <www-ws-desc@w3.org>
Sent: Wednesday, June 25, 2003 5:29 AM
Subject: RE: targetResource and relationships


>
>
> There seems to be two issues masquerading under this subject.
>
> 1) should multiple interfaces per service be allowed?
> 2) what relationships can or should be expressed with targetResource.
>
> I slightly prefer single interface per service, but can easily see
> reasons for the other preference.
>
>
> I care a lot about the 2nd issue.
>
> > But it also would provide a way of hiding such details within a service
> description element, and thus turning @targetResource into something that
> can be used for discovery of alternative ways only of accessing the same
> resource.
>
> Um, what does that have to do with multiple interfaces per service? and
> how does that impact the relationship that could be used in discovery?
>
> What seems to be missing is the impact of having two or more service
> authors,
> the inability to modify another service providers descriptions (for
> maintenance
> and legal not technical reasons) and how to describe the real resource
that
> a service impacts.
>
> To me the relationship identified by targetResource should be exactly what
> the name implies..what resource (in the formal IETF definition) is
targeted
> by the interface. It is a transport/interface relationship because all you
> really know by comparing resource identifiers is that *someone* deemed
that
> the interfaces are related to the same resource.
>
> That relationship is worth discovery and I believe will be of significant
> value to ontology developers.
>
> Regards
> DaveH -- having to put this decision in the larger web service context---
>
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@zandar.com]
> Sent: Tuesday, June 24, 2003 3:35 AM
> To: Dave Hollander; www-ws-desc@w3.org
> Subject: Re: targetResource and relationships
>
>
> Hello,
>
> > The other purpose that I understood was to identify relationships
> > between services that may have been created at differing times or
> > by different developers. Eg:
> >
> > <service YourStatusService interface="PrinterA"
> > targetResource="HP-Printer1">
> >   endpoint1
> > </service>
> > <service My3rdPartyStatusService interface="MyPrinterInterfaceA"
> > targetResource="HP-Printer1">
> >   endpoint2
> > </service>
>
> It's an interesting example, thanks.
> Ok, because two services implement two different interfaces we can't say
> that targetResource defines a protocol/transport relationship (perhaps
> there's a better term for such a relationship). Instead, it's an
> application-level relationship, but what I think is important here is that
> semantics of it is that both services are *alternatives*.
> It's when targetResource is used for identifying custom application
> relationships, which have more meaning than simply to identify
alternatives,
> then it can become more complex.
> Having multiple interfaces per service would still allow to define such
> custom relationships, that is to use @targetResource to relate, for
example,
> Printer and PrinterManager services.
> But it also would provide a way of hiding such details within a service
> description element, and thus turning @targetResource into something that
> can be used for discovery of alternative ways only of accessing the same
> resource.
> Cheers
> Sergey Beryozkin
> ----- Original Message -----
> From: "Dave Hollander" <dmh@contivo.com>
> To: <www-ws-desc@w3.org>
> Sent: Tuesday, June 24, 2003 12:00 AM
> Subject: RE: targetResource and relationships
>
>
> >
> > 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.
> >
> > The other purpose that I understood was to identify relationships
> > between services that may have been created at differing times or
> > by different developers. Eg:
> >
> > <service YourStatusService interface="PrinterA"
> > targetResource="HP-Printer1">
> >   endpoint1
> > </service>
> > <service My3rdPartyStatusService interface="MyPrinterInterfaceA"
> > targetResource="HP-Printer1">
> >   endpoint2
> > </service>
> >
> > the relationship that says my service/interface impacts the same
resource
> > as some others. --leaves out the issue of what "same" means, but I would
> be
> > happy to leave that to the service developer to decide.
> >
> > dave hollander
> >
> > -----Original Message-----
> > From: Sergey Beryozkin [mailto:sberyozkin@zandar.com]
> > Sent: Monday, June 23, 2003 3:39 PM
> > To: www-ws-desc@w3.org
> > Subject: targetResource and relationships
> >
> >
> >
> > Hello,
> > As far as I understand, one of the main goals of a targetResource
> attribute
> > is to allow for a designer to state that some services relate to each
> other
> > in some way.
> > It seems that targetResource allows for 2 types of relationship.
> > This is first one :
> >
> > <service qname1 interface="PrinterA" targetResource="HP-Printer1">
> >   endpoint1
> > </service>
> > <service qname2 interface="PrinterA" targetResource="HP-Printer1">
> >   endpoint2
> > </service>
> >
> > Both services relate to each other, but there's no any application
> semantics
> > in this relationship, it is at the protocol/transport level. It helps in
> > choosing different endpoints/bindings, which can be useful indeed.
> > targetResource helps to discover such relationships.
> >
> > And this is another one :
> >
> > <service qname1 interface="PrinterA" targetResource="HP-Printer1">
> >   endpoint1
> > </service>
> > <service qname2 interface="PrinterManagerA"
targetResource="HP-Printer1">
> >   endpoint2
> > </service>
> >
> > Both services relate to each other, but in this case it's an
> > application-level relationship. With multiple interfaces per service
this
> > relationship was implicit.
> >
> > So, when we have something like
> >
> > <service qname1 interface="PrinterA" targetResource="HP-Printer1">
> >   endpoint1
> > </service>
> > <service qname2 interface="PrinterA" targetResource="HP-Printer1">
> >   endpoint2
> > </service>
> > <service qname3 interface="PrinterManagerA"
targetResource="HP-Printer1">
> >   endpoint3
> > </service>
> > <service qname4 interface="PrinterManagerA"
targetResource="HP-Printer1">
> >   endpoint4
> > </service>
> >
> > we can say that all the last service qname4 relates to service qname3 at
> the
> > protocol level/transport level (semantics of this realtionship are
> > well-defined), but it also relates to both qname1 & qname2 services at
the
> > application level(semantics of this realtionship may not be known).
> >
> > It can be quite confusing.
> >
> > Would it be less confusing if multiple interfaces per service were still
> > allowed, but @targetResource were also allowed ?
> >
> > For example, one could say :
> > <service qname="PrinterAll-1" targetResource="printers">
> >    printerPort
> >    printerManagerPort
> > </service>
> > <service qname="PrinterAll-2" targetResource="printers">
> >    printerPort
> >    printerManagerPort
> > </service>
> > targetResource would serve for discovering protocol/level relationships
> > only, an application-level relationship is implicit here.
> >
> > Does one want to print on and manage multiple printers the way
> > @targetResource encourages it the moment ? One can then say
> > <service qname="PrinterAll-1" targetResource="printers1">
> >    printerPort
> >    printerManagerPort
> > </service>
> > <service qname="PrinterAll-2" targetResource="printers2">
> >    printerPort
> >    printerManagerPort
> > </service>
> >
> > Any opinions ?
> > Thanks
> > Sergey Beryozkin
> >
> >
> >

Received on Tuesday, 24 June 2003 19:55:51 UTC