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 05:38:38 UTC