Issue #1 proposed resolution

Following the (informal) action item we took to discuss issue 1, we

(David and Paco) have had some discussion on the topic of identifiers

and on use cases for EPRs; we have converged on a few clarifying

conclusions. The main point is the fact that the full extent of possible

usages of EPRs and Ref. ps. is a larger and richer mechanism than a view

that a generic EPRs are to be treated as an identifier. The fundamental

semantics of EPRs are defined by the need to pass the Reference portions

back in messages sent to the target endpoint. This core semantics

support a multitude of use cases.

 

1. Consider a stateful interaction model where ref. properties are

interaction data and the full state of the interaction (in the form of

actual business data: a shopping cart, for example); this usage follows

the canonical stateless implementation that http cookies allow. In fact,

the semantics of ref props in this usage case are not very different

from cookie semantics except for the fact that WS-Addressing does not

define an EPR lifecycle. The EPR in this situation acts as a mere

packaging mechanism for transmitting to the service requester the URI

address + state that is characteristic of a particular interaction. In

particular, there is only one identifier involved here, the URI

providing the network address. The state represented by the ref. props.

has no identification function in this case.  The EPR is nothing but an

XML envelope for the two.  To reiterate, the EPR is not an identifier

but a container used to specify echoed state information.  

 

2. The use of EPRs and ref props as a server side "identifier"

(as opposed to client side identifiers) is another possible and probable

use case. Here, the combination of URI and ref. props. is used by the

infrastructure to retrieve stateful artifacts associated with the

interactions. Typically, in these cases the internal implementation of

the server side provides for mechanisms to compare two EPRs for

"sameness" and can operate with proper id semantics internally.

Reference properties carry server side specific data (not business data

as before).  

 

In this scenario, the client is not allowed to determine the semantics

of different EPRs.  It is worthwhile to observe that virtually all the

Web Services specifications that use WS-Addressing - such as

WS-Eventing, WS-ReliableMessaging, WS-Enumeration, WS-ResourceFramework,

etc. - create a container construct (ie WS-ReliableMessaging sequence)

and provide a protocol for updating the container.  To the point, there

is no WS- specification that gives the client latitude to interpret EPRs


without also providing a protocol.  We believe that this emergent
layering 

pattern proves the power of EPR semantics based on an echoing mechanism
alone. 

 

We believe that this emergent layering pattern 

that utility of WS-Addressing EPRs as just an echoing mechanism can be

encapsulated by other specifications that formally specify the

interpretation of sameness or differentness of EPRs.

 

Of course, many other usage patters of EPRs are possible and we cannot

expect that every application or vendor will necessarily support every

model. Still, the basic semantics of WS-A should enable interoperability

between the parties without requiring higher level agreements on the EPR

minting model being used. The key to this is to carefully define the

common semantics shared by all these use cases. We think this is

essentially the requirement that ref. ps. need to be "echoed" back with

messages sent to the server. Some considerations on the opaqueness issue

(discussed in a different thread) may be also pertinent here. What seems

to clearly fall outside the common minimum core is formal identifier,

as well as Web identifier semantics.

 

Dave and Paco