RE: /service/@targetResource ?

One problem we tried to address at the FTF was distinguishing in the
WSDL between three cases not previously distinguishable:

1) When a set of endpoints represent "alternative" bindings for the same
interface acting on the same "thing" (e.g. SOAP and HTTP bindings as two
ways to access the interface).
2) When a set of endpoints represent different interfaces to the same
"thing" (e.g. normal interface and a management interface).
3) When endpoints are related in some other way (e.g. your use case, I
think).

The terminology we developed is that a "service" is an interface on a
thing, that can be accessed through various mechanisms.  Thus the term
"service" and the "<service>" element have been clarified to cover case
(1).  This is of course extremely useful for tooling.

For case (2), we provided a mechanism for identifying the "thing" using
a web-friendly concept - a URI which we now call the "targetResource".
While not as directly related to tooling, this provides, for example, a
hook for discovery.

We have not provided any mechanism for describing case (3) yet.
Services can be grouped within a single WSDL file, with no semantics
suggested by that grouping.  Likewise, resources related in case (2)
need not be in the same WSDL.  There were some proposals to add a place
for another URI describing various relationships but the Working Group
did not find this too compelling, as it can be addressed by a variety of
external ways.

I don't see why Philippe's first proposal doesn't address your specific
example.

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of Sedukhin, Igor S
> Sent: Thursday, May 29, 2003 6:09 PM
> To: Philippe Le Hegaret
> Cc: www-ws-desc@w3.org
> Subject: RE: /service/@targetResource ?
> 
> 
> Philippe,
> 
> Your solution to my example won't work. Both services have different
> bindings and different requirements. E.g. one requires WS-Security and
> reliable messaging (A1) and the other does not (B1). I need to still
have
> two partial bindings on the aggregated service. Those two won't bind
the
> whole inherited interface, but rather respective inherited parts (B1
and
> A1). The interface F will not be bound to an endpoint.
> The two services solution is even worse. I want to offer one service
to my
> parther. I'll give him URL to the WSDL and Qname of the service. The
rest
> is mechanics. I'll define an SLA and security in regards to that
partner
> for that ONE service. This is not a crazy scenario and I want it to be
> natural.
> 
> <service name="C">
>  <endpoint name="a" interface="A" binding="SOAPHTTP.restricted">
>    <http:address href='http://www.example.com/A'/>
>  </endpoint>
>  <endpoint name="b" interface="B" binding="SOAPHTTP">
>    <http:address href='http://www.example.com/B'/>
>  </endpoint>
> </service>
> 
> So then in the program at the partner's side I can do something like
> 	C.a.mymethodA(...)
> 	C.b.mymethodB(...)
> Where a and b would be implementations of the interface A and B
> respectively.
> 
> This decision to constrain is like twisting arms. Yes we all know that
it
> is possible to write programs in a language without loops and model
them
> with gotos. Why does WSDL have to be similar?
> 
> targetResource is such a foreign construct that I have doubts anyone
would
> ever figure out what to set it to. It will be one of those things that
> noone has any idea how to deal with in the implementations. It would
be
> better left to extensions or to something like properties/features.
Base
> WSDL may not be a good place to model relationships between services
and
> resources that way. It is getting very hairy...
> 
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> 
> 
> -----Original Message-----
> From: Philippe Le Hegaret [mailto:plh@w3.org]
> Sent: Thursday, May 29, 2003 5:43 PM
> To: Sedukhin, Igor S
> Cc: www-ws-desc@w3.org
> Subject: RE: /service/@targetResource ?
> 
> 
> On Thu, 2003-05-29 at 16:52, Sedukhin, Igor S wrote:
> > What is the difference between targetResource and target namespace
of
> > the <service> element? Aren't they identifying "functionality" and
all
> > the other things related to the service "semantics"? Why two
> > identifiers are so necessary?
> 
> targetResource doesn't identify a functionality but a resource. It is
> orthogonal to the target namespace. Two services may use the same
target
> namespace and still work on a different resource. Two services could
> provide access to the same resource using two differents interfaces.
In
> such case, you can express the relation between the two services using
the
> targetResource attribute.
> 
> Your previous example:
> >  There is a service A that has an endpoint that binds the interface
> > A1. There is a service B and interface B1 similarily. Those are
> > internal services. I'd like to offer service C that is an aggregate
> > of two functionalities to a partner. I may have an intermediary that
> > may merely represent an aggregate. So, in the WSDL I'd have service
C
> > that has two endpoints, one binds interface A1 and another binds
B1.
> > Both may or may not share the same address.
> 
> transform into:
> 
> <service name="C.1"
>      interface="A1"
>      targetResource="http://www.example.com/C">
>  <endpoint ... >
>    <http:address href='http://www.example.com/myService'/>
>  </endpoint>
> </service>
> <service name="C.2"
>      interface="B1"
>      targetResource="http://www.example.com/C">
>  <endpoint ... >
>    <http:address href='http://www.example.com/myService'/>
>  </endpoint>
> </service>
> 
> or you can also create an interface F, that inherits from A1 and B1:
> 
> <service name="C.3"
>      interface="F">
>  <endpoint ... >
>    <http:address href='http://www.example.com/myService'/>
>  </endpoint>
> </service>
> 
> Philippe
> 
> 
> >
> >
> > -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> > -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> >
> >         -----Original Message-----
> >         From: Arthur Ryman [mailto:ryman@ca.ibm.com]
> >         Sent: Wednesday, May 14, 2003 11:11 AM
> >         To: www-ws-desc@w3.org
> >         Subject: /service/@targetResource ?
> >
> >
> >         In the discussion with the architecture group today, there
> >         seemed to be confusion between a service and the resource is
> >         acts on. The architecture group defines a Web service to
have
> >         something that has a URI, but that URI is not the same as
the
> >         resource that the Web service acts on.
> >
> >         For example, a bank might have a personal banking Web
service.
> >         The account Web service acts on the bank.
> >
> >         We can build a URI from the QName of the personal banking
Web
> >         service, e.g.
> >         http://xml.fredsbank.com#service(PersonalBanking). The bank
> >         itself might have the URI http://fredsbank.com.
> >
> >         We agreed to add an optional @resource attribute to
<service>.
> >         I suggest it would be clearer to rename that attribute to
> >         @targetResource to make it clear that the service acts on
that
> >         resource as opposed to it being the URI of the Web service.
> >
> >         Arthur Ryman
> 
>

Received on Friday, 30 May 2003 12:13:02 UTC