State and EPRs

A few points about EPRs and state.  In general, EPRs are used after an
initial message, rarely if never as a start message in an ST.  The
typical flow is

 

1. Client sends message to Service

2. Service responds with EPR

3. Client(s) use EPR.

 

Note that in step 3, it may be different clients than the original
requesting client.  The WS-Tx/Co specs define a protocol for how client
1 gets an EPR to a tx context then sends it to clients 2...n.

 

In almost all cases, the EPR is just the reference/identifier/address/
for the communicating with a stateful resource.  Almost every
specification that uses EPRs "wraps" the EPR up in a context of some
kind, with a protocol for managing that context.  For example, WS-Co
context has: an identifier, an expiry, a coordination type, a
registration service EPR, and an extensibility point.  There is a
protocol for creating, modifying, and terminating the WS-co context.
Same for WS-RM, -Eventing, -Notification, etc.

 

The actual specification of the state transition in the messages is
usually done in a spec of some kind.  Each WS- spec that uses EPRs says
something like "do message 1, then do message 2".  For example, it could
say getContext which returns a contextResponse containing a context
which contains an EPR.  Choreography languages, like BPEL,
WS-Choreography, allow the developer to specify in a machine readable
language the sequence of messages.  

 

I would say the most common case for EPR Reference Parameters is to
contain some kind of session ID information, just like cookies
containing http session ids.  Many of the examples even have very
"session-like" names for the reference params, eg ws-tx
"myapp:PrivateInstance".

 

To bring it back to the stock quote example, the stock quote service
will have to specify the messages and sequence for doing the
GetStockContext then the GetQuote(EPR).  It would at least do this in a
text specification of some kind but could also use a choreography
language.  The analogy on the Web is exactly the same, you go to a
"getStock" page, ie cnnfn, enter the ticker parameter and get back a
Content-Location header (aka wsa ReplyTo) for the resource.  Of course,
the Web example would probably return you an actual stock quote after
the ticker parameter, and there's nothing stopping a Web service from
doing the same. The crucial thing would be that the GetStockQuoteEPR
response would have to contain a quote body.  

 

This works in the case of where the stock quote does *not* have a
context, such as an EPR in a ReplyTo.  But if there is any kind of
context associated with the EPR, then you can't "double-up" the body to
contain both the context AND a state of the thing the context
represents.  

 

The separation between getting the context and getting the state that
context represents is a crucial part of the message flow.  The Web Stock
quote works in 1 message because URIs have no context associated and
there's an HTTP header that can store the location.  

 

I don't think that context-free identifiers (aka IBM in the stock quote
example) are at all typical of EPR usage, and this makes the EPR example
look contrived and overly complicated

 

Cheers,

Dave