Re: targetResource and relationships

Hello Dave, others

Apologies for a long response which follows

> > 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?

Multiple interfaces per services would allow to hide a custom relationship
between different services operating on the same targetResource. For
example,

<service qname1 interface="PrinterAll" targetResource="printers">
   printPort
   printManagePort
</service>

<service qname2 interface="PrinterAll" targetResource="printers">
   printPort
   printManagePort
</service>

<service qname3 interface="PrinterAllByThirdParty"
targetResource="printers">
   printPort
   printManagePort
</service>

The custom relationship between printPort and printManagePort is confined
within a service description element. @targetResource is used for discovery
of an alternative services operating on "printers". It relates service
qname1&qname2&qname3 as being an alternatives only.
A relationship between qname1&qname2 is easily discovered by a generic tool,
because both services implement the same interface, the relationship between
service qname3 and services qname1&2 is most probably can be discoverd
ontologically, however, assuming one company decides that within all its
wsdl documnets @targetResource identiifes alternatives only, an
ontology-unaware tool can handle it too.


Please note, that nothing prevents the following usage with multiple
interfaces per service allowed :

<service qname1 interface="Printer" targetResource="printers">
   printPort
</service>
<service qname2 interface="PrinterSuper" targetResource="printers">
   printPort
</service>
<service qname3 interface="PrinterManage" targetResource="printers">
   printManagePort
</service>
<service qname3 interface="PrinterManageGreat" targetResource="printers">
   printManagePort
</service>

One can also do the following :

<service qname1 interface="PrinterAll" targetResource="printers">
   printPort
   printManagePort
</service>
<service qname2 interface="Print" targetResource="printers">
   printPort
</service>
<service qname3 interface="PrintManager" targetResource="printers">
   printManagePort
</service>
thus making it possible to choose between services qname1&qname2, as well as
between qname3&qname1. Additionally it can help independent developers to
provide their own versions of Print and PrintManager, if they wish to
There's plenty of space for ontology here.


Thanks a lot,
Sergey Beryozkin




----- Original Message -----
From: "Dave Hollander" <dmh@contivo.com>
To: <www-ws-desc@w3.org>
Sent: Wednesday, June 25, 2003 12: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 Wednesday, 25 June 2003 06:10:43 UTC