Re: [wsrf] WS-RAP; section 2.3 - WS-Resource definition

[Rich Thompson <richt2@us.ibm.com>]

It sounds like there are a bunch of
closely related questions here. The one I hear David raising is of the
general flavor of an inexpensive ServiceGroup where the semantics of the
WS-Resource is to apply any operation to all of its resources. This is
a specialization of the question I am raising and I would suggest we consider
the more general case first. 

Consider the scenario where an existing
system has separate resources with distinct interfaces for a power supply,
a CPU, a memory subsystem and an IO subsystem. An architect is tasked with
adding WSRF componentry to enable remote access to and management of these
resources. While it might be advisable for that architect to define separate
WS-Resources for each of the existing resources, is it required or is the
architect free to define a "BaseSystem" WS-Resources that encapsulates
all four of those resources and provides the appropriate routing of any
particular operation to the appropriate resource. While it is not likely
for this scenario, one reason an architect might want to provide such encapsulation
is when some operations will require access to (or impact) more than one
of the encapsulated resources. I do not see any reason for WSRF to eliminate
the architect having this choice available by requiring that there be a
one-to-one correspondence between resources and WS-Resources, though I
do expect that correspondence to be the most common case.

Assuming we define a WS-Resource to
be a web service interface to a set of one or more resources, consider
the endpoint reference David provided below. When the client receives this,
it can not tell if this WS-Resource is encapsulating two resources or simply
using a multi-key lookup of a single resource. Conversely, if the endpoint
only specified a single ReferenceProperty, the client is unable to tell
if there is a single underlying resource or if multiple resources will
be found using that single key. All the client knows is that in order to
properly interact with the WS-Resource, it must follow the binding rules
for the type of WS-RAP embodiment that it has been given. I think this
gives the designer of the WS-Resource appropriate flexibility without exposing
any additional complexity to clients.

The other impact this would have would
be in the construction of the properties document. I do not think that
the client should be exposed to any additional complexity should a WS-Resource
make the choice to encapsulate multiple resources, but rather that the
WS-Resource is responsible for merging the properties of the underlying
resources into a single property document.

Rich

David Snelling <David.Snelling@uk.fujitsu.com>

10/06/2004 04:03 AM

To	Rich Thompson/Watson/IBM@IBMUS
cc	wsrf@lists.oasis-open.org
Subject	Re: [wsrf] WS-RAP; section 2.3 - WS-Resource definition

Folks,

This issue has come up in other discussions I have had, particularly  
with folks less enthusiastic about WSRF. Put generally ...

If I have a WS and a bunch of resources, I have a set of WS-Resources  
with a one-to-one correspondence to the resources. Because all the  
WS-Resources share the same WS they can respond to the operations.  
Rich's question (and that of others) is, can I drive the same operation
 
on all WS-Resources at once?

Answer 1: Yes, create a new Disambiguator that refers to the whole  
collection. Steve pointed to this option.

Answer 2: Wrap the set of WS-Resources in a ServiceGroup and drive the
 
operation on all WS-Resources through an iterator operation on the  
ServiceGroup (NB: such an iterator has yet to be proposed for  
ServiceGroup).

Answer 3: Allow multiple Disambiguators in a single message. To use  
embodiment 1, create an EPR for the collection that looked like this:

<wsa:EndpointReference>
     
<wsa:Address>http://localhost:8080/axis/services/UnicorePort</wsa:
Address>
    <wsa:ReferenceProperties>
       <ns1:ResourceDisambiguator xmlns:ns1="http://arcon.fujtsu.com/">
                
    UnicorePort:E5623340-16DA-11D9-9A2A-C83D27C15A63
       </ns1:ResourceDisambiguator>
       <ns1:ResourceDisambiguator xmlns:ns1="http://arcon.fujtsu.com/">
                
    UnicorePort:0035B930-16DB-11D9-9A2A-9A608286117E
       </ns1:ResourceDisambiguator>
    </wsa:ReferenceProperties>
</wsa:EndpointReference>

The semantics would require that the client copy both Disambiguators  
into the message and the service could interpret this as "Drive the
 
same operation on all the WS-Resources referenced by the Disambiguators
 
in the message."

I kind of like this, but I have never been convinced by WSRF critic's  
use cases. Possibly the WSRP use case is a strong enough one.

Note: I don't believe this approach is as straight forward for the  
other embodiments as the above.


On 5 Oct 2004, at 23:18, Rich Thompson wrote:

>
> One of the things I appreciate about the definition set in WS-RAP
is  
> that it clearly separates a resource from a WS-Resource. I agree that
 
> the portlet is a WS-Resource, but it is encapsulating multiple  
> resources rather than multiple WS-Resources. The essence of my  
> question is whether the web service endpoint is allowed to operate
on  
> multiple resources or whether there is a strict one-to-one mapping
of  
> resource to WS-Resource. Clearly the portlet could invent a wrapper
 
> resource that merely encapsulates the underlying resources, but why
 
> should that be required?
>
> On the ramifications of allowing this broadening, I think we all agree
 
> that this can be done without the client being aware of it. The client
 
> is interacting with a WS-Resource and it has no idea of the meaning
of  
> the various parts (could include a separate identifier for each  
> resource) of the endpoint that it has been given, only that it has
to  
> follow the contract of the binding to the WS-Resource that is in use.
>
>  Rich
>
>
>
>
> Tom Maguire/Hawthorne/IBM@IBMUS
>
> 10/05/2004 02:56 PM
>
> To
> Rich Thompson/Watson/IBM@IBMUS
>
> cc
> wsrf@lists.oasis-open.org
>
> Subject
> Re: [wsrf] WS-RAP; section 2.3 - WS-Resource definition
>
>
>
>
>
>
>
>
>
>
>
>  So I guess I'm struggling with this a bit.  From the client's
 
> perspective
>  you have a single
>  WS-Resource.  That WS-Resource has an identifier.  As
you mentioned  
> the
>  client would
>  not need to know or care that multiple resources are involved.
 In WS
>  Remote Portlet it
>  sounds as if there is a need to do a composition of multiple
 
> (different
>  types of )
>  WS-Resources and the "portlet" endpoint is responsible
for dispatch  
> to the
>  underlying
>  "encapsulated" WS-Resources.  In this model I
think the WS-Resource  
> is the
>  remote portlet.
>  That remote portlet has its own identifier.  That identifier
is used  
> as a
>  resource disambiguator
>  to the "collection" of related WS-Resources not to
the individual
>  WS-Resources of the collection.
>
>  So I agree that clients should not care but I would also argue
then  
> that
>  from the clients
>  perspective there is just one WS-Resource and that the definition
of a
>  WS-Resource
>  is correct from that perspective.
>
>  Tom
>
>  Problems cannot be solved at the same level of awareness that
created
>  them.  —Albert Einstein
>  T o m   M a g u i r e
>
>  STSM, On Demand Architecture
>  Poughkeepsie, NY  12601
>
>  Rich Thompson/Watson/IBM@IBMUS wrote on 10/05/2004 01:43:27
PM:
>
>  >
>  > Not quite our situation. Certain operations will need to
access more
>  > than one resource during the processing of a single message.
How the
>  > set of resources is constructed and referenced by the endpoint
would
>  > be a matter between the factory and the resource disambigurator.
I
>  > would hope the client would not need to know or care that
multiple
>  > resources are involved and am raising the case seeking
that both the
>  > language and semantics permit such a pairing of a web service
and a
>  > set of resources within a single endpoint without requiring
>  > knowledgeable clients.
>  >
>  > Rich
>  >
>
>  >
>  > Steve Graham/Raleigh/IBM
>  > 10/05/2004 09:51 AM
>  >
>  > To
>  >
>  > Rich Thompson/Watson/IBM@IBMUS
>  >
>  > cc
>  >
>  > wsrf@lists.oasis-open.org
>  >
>  > Subject
>  >
>  > Re: [wsrf] WS-RAP; section 2.3 - WS-Resource definitionLink
>  >
>  >
>  >
>  > Rich:
>  > To clarify, your situation is such that a Web service deployed
at
>  > some URL is the access point for a collection (potentially
many)
>  resources?
>  >
>  > Given my assumption is true, I don't see why you have come
to the
>  > conclusion that the definition of WS-Resource precludes
it.  The
>  > examples in the WSA embodiments (sections 3.1 and 3.2)
suggest this
>  > pattern where a single web service is front ending 2 resources.
>  > Note that it is the pair (web service + resource) that
is the WS-
>  > Resource. So in the examples in the WSA embodiments contain
2
>  WS-Resources.
>  >
>  > Does this help?
>  >
>  > ++++++++
>  > Steve Graham
>  > (919)254-0615 (T/L 444)
>  > STSM, On Demand Architecture
>  > Member, IBM Academy of Technology
>  > <Soli Deo Gloria/>
>  > ++++++++
>  >
>  >
>  > Rich Thompson/Watson/IBM@IBMUS wrote on 10/05/2004 08:53:02
AM:
>  >
>  > > While I haven't finished working through exactly how
the WSRP
>  > protocol could best
>  > > leverage WSRF, I (and others on the WSRP TC) are leaning
towards
>  > the at least some
>  > > of the web service endpoints containing references
to a set of
>  > resources rather
>  > > than just one. The proposed definition ("A WS-Resource
is a Web
>  > service through
>  > > which a resource can be accessed.") excludes
such use cases. Any  
> reason
>  the
>  > > definition can not be broadened to "A WS-Resource
is a Web service
>  > through which a
>  > > set of one or more resources can be accessed."
This would carry
>  > into many other
>  > > places in the text where the resource is referred
to in the  
> singular.
>  > > Rich Thompson
>  > > OASIS WSRP TC Chair
>
-- 

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu
. com >
     Fujitsu Laboratories of Europe
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE

     +44-208-606-4649 (Office)
     +44-208-606-4539 (Fax)
     +44-7768-807526  (Mobile)