W3C home > Mailing lists > Public > www-tag@w3.org > December 2005

RE: State and EPRs

From: David Orchard <dorchard@bea.com>
Date: Fri, 2 Dec 2005 19:08:27 -0800
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF14C02215@ussjex01.amer.bea.com>
To: <noah_mendelsohn@us.ibm.com>
Cc: <www-tag@w3.org>


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.



> -----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
> see whether he will confirm or deny it.  Specifically, my impression
> 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
> binding in the WSDL will include
>   <wsa:UsingAddressing wsdl:required="true"/>
> but that's it.  Typically no details on headers resulting from
> 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)
> value of some response, then the WSDL will type that value as
> 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
> 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/
> the communicating with a stateful resource.  Almost every
> 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:
> identifier, an expiry, a coordination type, a registration service
> and an extensibility point.  There is a protocol for creating,
> 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
> something like "do message 1, then do message 2".  For example, it
> say getContext which returns a contextResponse containing a context
> contains an EPR.  Choreography languages, like BPEL, WS-Choreography,
> allow the developer to specify in a machine readable language the
> 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
> 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
> have to specify the messages and sequence for doing the
> then the GetQuote(EPR).  It would at least do this in a text
> of some kind but could also use a choreography language.  The analogy
> the Web is exactly the same, you go to a "getStock" page, ie cnnfn,
> 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
> nothing stopping a Web service from doing the same. The crucial thing
> would be that the GetStockQuoteEPR response would have to contain a
> body.
> This works in the case of where the stock quote does *not* have a
> 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
> 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
> 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
> example) are at all typical of EPR usage, and this makes the EPR
> look contrived and overly complicated
> Cheers,
> Dave
Received on Saturday, 3 December 2005 03:08:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:10 UTC