Re: [wsrf] Singleton Resource Pattern

[Steve Graham <sggraham@us.ibm.com>]

Hi Anish:
In response to your thoughtful questions:

1) Yes.  This "singleton resource
pattern" is a term that has been used to describe the notion contained
in the last paragraph of 3.2.  This email was an expansion on this
rather terse point in the Modelling Stateful Resources with Web Services
paper.  Thanks connecting those thoughts.

2) This notion is very much isolated
to the service provider side of the relationship.  The requestor has
an EPR and simply needs to deal with it according to the WSA spec.  The
reason for bringing this point up is that there have been some discussions
questioning whether this is a valid "case" of the "implied
resource pattern".  I responded to Susan Malaika's posting with
a bit of a long winded explanation of where my thoughts were on this matter,
hoping to generate this kind of discussion.  It continues to be reinforced
in my thick skull that, at certain times, illuminating an architectural
discussion with a bit of design consideration can be helpful to tease out
architectural concepts.

3) requires a little bit more of a point
by point discussion, see <sgg>comments</sgg>:
>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). 
<sgg>ah, sorry, my tangential
comment was too terse.  My points on security and routing
did not necessarily imply that security
and routing information were actually in the ref prop header. In fact I
would
claim (as would most people) that for
composability reasons, it would not be a best practice to include
security and that sort of information
in ref props.

My point was,  the ref prop information
appearing as a soap:header could be used IN CONJUNCTION
with other routing and security information.
 Let me expand a bit.  Say I have a PurchaseOrder application,
and
I have a PONumber ref prop.  I
could imagine having intermediaries (say Apache Axis handlers) that could
examine the ref prop header,  use
the contained PONumber ref prop as a lookup key in some sort of
private implementation table to determine
security and routing information associated with Web service
messages for PONumbers of this type
(eg range, quality of service, etc.). I would then use this information
to choose which server to route this
request to (for affinity with the database server containing the PO) or
I could use this information to examine
other headers, such as security headers, to see if the user identified
as being the source of this message
is authorized to manipulate a WS-Resource disambiguated by a
PONumber of this value, etc.</sgg>

>How does that affect composibility? For example,
the reference properties may 
>contain things related to security. 
<sgg>indeed, my terse comment
on security and routing was too easily misinterpreted.  Hopefully
my comments above indicate that indeed,
composability is very important and that I have clarified
what my thoughts were.</sgg>

>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.

<sgg>yep, agreed, I would recommend
against inserting security header blocks into a reference
property related header </sgg>

>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. 
<sgg>yes, I see why my terse comment
lead to this confusion and it is not what I was suggesting.</sgg>

>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.
<sgg>Indeed, the authentication
related headers would be separate from the reference properties
header and clearly the client needs
to form the contents of the authentication headers. </sgg>

>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>

<sgg>indeed.  If you, as
a requestor, are worried that the service you are interacting with might
give you nefarious ref props, you have
a larger trust issue to deal with.  Further, if you are concerned
that there might be intermediaries that
tamper with the EPR being sent to the requestor, then you
should use some sort of tamper proofing
(digital signatures or perhaps encryption) </sgg>

sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

Anish Karmarkar <Anish.Karmarkar@oracle.com> 07/12/2004 03:31 AM

To:        Steve Graham/Raleigh/IBM@IBMUS         cc:        Susan Malaika/Santa Teresa/IBM@IBMUS, wsrf@lists.oasis-open.org         Subject:        Re: [wsrf] Singleton Resource Pattern

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