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:29:25 UTC