Re: [wsrf] Singleton Resource Pattern

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Steve,

Thanks for the detailed explanation. That was helpful.

Few questions:

1) How is a singleton pattern different than the "static association 
between the WS and the resource" as described in section 3.2 of the 
'Modeling Stateful Resource with Web Services' doc? I'm assuming that 
they are the same.

2) Since the singleton and non-singleton patterns are the same from the 
perspective of the client (the consumer of the service), is there a 
reason to distinguish between the two in the world of Web services (or 
specifically in our specs)? OR, more importantly, it seems like this is 
an implementation detail and the client cannot distinguish between the 
two patterns. Am I right?

 > c) By using reference properties, the disambiguator is in the header
 > (not buried in the address). This allows all the sorts of cool things
 > one can do with soap headers, including intermediary processing for
 > security, validation, routing, etc.

3) This implies that reference properties that identify the stateful 
resource can contain other things unrelated to identifying the resource 
(as u indicate in your email: security, routing related data). How does 
that affect composibility? For example, the reference properties may 
contain things related to security. Such things are transmitted as 
separate SOAP header blocks (in the case of SOAP binding) by the client 
and are not wrapped in a reference property specific header block. The 
client essentially is forced to send these security related SOAP header 
blocks which may interact with other security related header blocks that 
the client may want to include. But the SOAP binding of reference 
properties says that the properties are opaque to the client -- which 
means that the client is not supposed to look into them and this may 
result in composibility problems.

As a side note, given that the binding of reference properties to soap 
header blocks results in the client having to send things as separate 
header block can result in the client being forced to send things that 
are beyond its control (as there is no structured place -- perhaps in 
the SOAP body as this is application data -- where these properties are 
bound). For example, a client may be forced to send a soap header block 
(through the use of reference properties) that says:

<wsrf:IntellenceData>WMDs are hidden here</wsrf:IntellenceData> OR
<wsrf:Declaration>The king is a fink</wsrf:Declaration>

;-)

Thx.

-Anish
--

Steve Graham wrote:

> 
> Susan:
> I am not aware of a formal definition.  Maybe we should have some sort 
> of note on this.
> Here are my thoughts on the "singleton resource pattern".
> 
> *Definition:*
> The singleton resource pattern is a "special case" of the implied 
> resource pattern, wherein the address of the Web service and the 
> disambiguator of the stateful resource are not distinguished. This can 
> be done by URL encoding some sort of "identity" of the stateful resource 
> in the wsa:address element information item of the endpoint reference.
> 
> 
> *Example:*
> 
> 
> *Discussion:*
> In this example, there is a Web service whose address is an HTTP URL at 
> www.sgg.com/services
> There are two stateful resources, that can be disambiguated by two 
> strings "A" and "B".  Note, these are simple types, which is not always 
> the case for disambiguators.
> 
> There are a couple of approaches to using the singleton resource pattern 
> in this case:
> a) use a param on the url
> so the endpoint reference to A would look like:
> <wsa:EndpointReference>
>   <wsa:Address>
>     http://www.sgg.com/services?res=a
>   </wsa:Address>
> </wsa:EndpointReference>
> 
> or
> 
> b) use a path node on the url itself
> <wsa:EndpointReference>
>   <wsa:Address>
>     http://www.sgg.com/services/a
>   </wsa:Address>
> </wsa:EndpointReference>
> 
> With the "singleton" pattern, the illusion to the client is that the Web 
> service and the stateful resource are indistinguishable.  This does not, 
> however imply a constraint on the server side, that is that there MUST 
> be a 1 to 1 correspondence between the Web service and the stateful 
> resource. From the picture, it is clear that the single Web service at 
> www.sgg.com/services is associated with two resources.  But from the 
> client's point of view, it has an endpoint reference and that is all it 
> cares about.  Further note, that if the implementation CHOOSES to 
> enforce a 1-1 restriction, it can clearly do so.
> 
> Contrast this with the reference properties approach to this situation. 
>  The EPR to A looks slightly different:
> <wsa:EndpointReference>
>   <wsa:Address>
>     http://www.sgg.com/services
>   </wsa:address>
>   <wsa:ReferenceProperties>
>      <tns:disambiguator>A</tns:disambiguator>
>   </wsa:ReferenceProperties>
> </wsa:EndpointReference>
> 
> The difference is where the additional information about how to 'locate' 
> the stateful resource is included.  With the singleton resource pattern, 
> it is smashed into the address of the Web service.  With the more 
> "traditional" Web service, it is separated into reference properties. 
> Both approaches are valid uses of WS-Addressing, both approaches are 
> valid applications "implied resource pattern".  In most of the WSRF 
> normative and non-normative text, we have been over emphasizing the use 
> of reference properties and not legitimatizing the use of the singleton 
> resource pattern.
> 
> *Several points on this:*
> a) Whether the singleton resource pattern or "traditional" 
> reference-properties approach to the implied resource pattern is used 
> makes no difference to the client.  The client's runtime needs to 
> receive an EPR, and be compliant with WS-Addressing, including handling 
> reference properties for those EPRs that may contain them.  Using 
> singleton resource pattern does not make the client any "lighter" or 
> "less coupled" with respect to the Web service.
> 
> b) The client doesn't need to know which implementation of the "implied 
> resource pattern" (singleton or traditional) is chosen by the server. 
>  The interaction is the same.  Client gets EPR to a service, client uses 
> EPR to make a proxy to the service, client sends messages through that 
> proxy to the service, client's WSA middleware makes sure the WSA rules 
> are conformed to.
> 
> c) The singleton resource pattern does not change the coupling on the 
> server side.  By this I mean the collaboration between the component 
> that produces the EPR (eg a factory or a registry lookup) and the Web 
> service pointed to by that EPR. These two components always needed some 
> form of coordination.  In the "traditional" reference-properties 
> approach, the choice of reference property (both element and value) made 
> by the "factory" or "registry" in forming the EPR must be coordinated 
> with the Web service targeted by that EPR.  If the factory chooses to 
> use <tns:foo> with value "bar" as the reference property, then the Web 
> service targeted by the wsa:address component of the EPR better darn 
> well know what <tns:foo> semantics are, and how to use the value 'bar' 
> to locate/lookup/constitute/activate etc. the stateful resource that the 
> factory/registry imagined was associated with 'bar'.  
> A similar point holds for the singleton resource pattern.  If the 
> factory produces an EPR containing the address 
> http://www.sgg.com/services?res=a, then the web service at 
> www.sgg.com/services darn well better know what the res parameter 
> semantic is, and what the value "a" means.
> 
> So, to the question, doesn't the choice of singleton resource pattern 
> complicate the coupling between components?  The answer is no. It 
> doesn't help or hurt the existing loose coupling between requestor and 
> service provider (point a and b).  It doesn't complicate nor simplify 
> the coupling between the components on the service provider side that 
> produce the EPR and consume messages targeted by that EPR (point c).
> 
> *Reference Properties are still important:*
> a) The singleton resource pattern can only be used when the 
> disambiguator is simple types and when the addressing scheme, eg HTTP 
> can conveniently encode the disambiguator in the address. Otherwise, 
> reference properties offer a much more flexible means of communicating 
> the disambiguator.
> 
> b) By using reference properties, the disambiguator can be any arbitrary 
> XML structure.  Furthermore, the implementation need not rely on the 
> addressing scheme to provide the right hooks for the disambiguator (sure 
> this can work for certain circumstances) in HTTP, but what about other 
> transports?
> 
> c) By using reference properties, the disambiguator is in the header 
> (not buried in the address). This allows all the sorts of cool things 
> one can do with soap headers, including intermediary processing for 
> security, validation, routing, etc.
> 
> Therefore the singleton resource pattern does not lead us to the 
> conclusion to abandon reference properties.  We still need them.
> 
> Is this useful discussion of singleton resource pattern? Is this enough 
> detail to be illustrative?  Are there other areas that we need to 
> describe with this detail?  
> 
> sgg
> 
> ++++++++
> Steve Graham
> (919)254-0615 (T/L 444)
> STSM, On Demand Architecture
> Member, IBM Academy of Technology
> <Soli Deo Gloria/>
> ++++++++
> 
> 
> 
> 	*Susan Malaika/Santa Teresa/IBM@IBMUS*
> 
> 07/10/2004 05:13 PM
> 
> 	       
>         To:        wsrf@lists.oasis-open.org
>         cc:        
>         Subject:        [wsrf] Singleton Resource Pattern
> 
> 
> 
> 
> I've heard the term "singleton resource pattern" in conversations 
> relating to WSRF. Is there a definition?
> 
> Susan Malaika