Re: targetResource and relationships

Hello Sanjiva,

> IMO the single interface approach is
> simpler to understand, easier for tools and can do everything the
> multiple interface version can do.
> 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 seems to me (but i may be wrong) that the same can be said with respect
to the
multiple interface version. In 80%s it will be used for combining multiple
access routes to the same interface only, and only in 20%s it will be used
for putting orthogonal interfaces, like print and printManager together.
I agree with you that having a single interface per service is easier for
tools, because they know in advance that they can only expect a single
interface there, but mainly when this interface does not inherit itself from
multiple interfaces.
At the same time, IMHO,  it could be easier for a human reader to understand
a non-alternative relationship between multiple interfaces when they're part
of a single service description rather then of, for ex, two service
descriptions.
As far as targetResource is concerned, I think now one should look at this
as a discovery token only, but not as a means of creating solutions for
printing at and managing multiple sets of printers, for example, which are
completely orthogonal to the problem of discovery.
 Multiple interfaces per service might make it easier, IMHO, to use
targetResource to identify alternatives only, for those who wish so,  and as
such, help in automating the discovery process, while also allowing for a
single interface per service and defining custom relationships explicitly
with targetResource. They won't make it easier to print at and manage
multiple sets of  printers.

Thank you
Sergey Beryozkin


----- Original Message -----
From: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
To: "Dave Hollander" <dmh@contivo.com>; <www-ws-desc@w3.org>
Sent: Wednesday, June 25, 2003 12:55 AM
Subject: 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 Wednesday, 25 June 2003 06:58:47 UTC