Re: State and EPRs

Dave is the expert on this, but I'd like to add one detail, at least to 
see whether he will confirm or deny it.  Specifically, my impression is 
that when an EPR is actually used to address a message, WSDL typically 
plays little if any role in specifying the details of the EPR.   The SOAP 
binding in the WSDL will include

  <wsa:UsingAddressing wsdl:required="true"/>
but that's it.  Typically no details on headers resulting from refParms 

By contrast, when EPRs are passed around for other purposes, WSDL plays a 
more typical role.  For example, if an EPR is returned as (part of) the 
value of some response, then the WSDL will type that value as complexType 
EndpointReferenceType, just as it would type an integer as xsd:integer. Do 
I have that right?  Thanks.

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

"David Orchard" <>
Sent by:
12/02/2005 03:11 PM
        To:     <>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        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 
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

Received on Friday, 2 December 2005 23:48:02 UTC