RE: State and EPRs

Close...

An EPR can be used to address a message with just WS-Addressing MAPs, ie
ReplyTo, when the UsingAddressing is engaged.  But an EPR can also be
used to address a message via the same (ReplyTo) or other (RM's AcksTo)
properties if specified using another specification.  So UsingAddressing
gives the low bar of ReplyTo/FaultTo/Action, etc., and then another spec
can do more.  The other spec may or may not use WSDL, though usually
does when the EPRs are passed as part of the soap body (whereas WS-A's
usages are entirely header blocks).  

I wouldn't look at it as a line between "EPR to address" or not, I'd
look at it as a line between just WS-A (and it's headers) versus a
layered spec that may or may not use the WS-A headers and will pass it's
EPRs + context in either headers or body.  

Just to clarify things about WSDL and RefP's a bit more, WS-A does allow
you to specify reference parameters in the WSDL as an extension element
of the wsdl2:endpoint or wsdl11:port [1].  We thought about re-using the
wsdl2:binding's header extension, but it was more complicated than
necessary.  Personal note: if we had headers in interface operations as
I've wanted forever, it might have been more tractable.

Cheers,
Dave

[1]
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html
?content-type=text/html;%20charset=utf-8#refpinwsdl



> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Friday, December 02, 2005 3:48 PM
> To: David Orchard
> Cc: www-tag@w3.org
> Subject: 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
> etc.
> 
> 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
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> "David Orchard" <dorchard@bea.com>
> Sent by: www-tag-request@w3.org
> 12/02/2005 03:11 PM
> 
>         To:     <www-tag@w3.org>
>         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
> 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

Received on Saturday, 3 December 2005 03:08:40 UTC