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 Monday, 23 June 2003 19:00:29 UTC