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 Thursday, 29 May 2003 21:09:30 UTC