- From: Glen Daniels <gdaniels@sonicsoftware.com>
- Date: Sun, 13 Mar 2005 21:07:47 -0500
- To: <public-ws-addressing@w3.org>
In fulfillment of my AI from the face-to-face in Boston, here is a first cut at some example text to go after the new text for sec 2.3. This gets the basic idea across but likely needs some wordsmithing/honing: ------------------- The following examples serve to illustrate both the flexibility inherent within the EPR concept and a bit more detail into the meaning of the above paragraph. For the first example, assume two different web service clients receive the following EPR as a result of some interaction (for instance each processing a SOAP response message): <wsa:EndpointReference> <wsa:Address>http://example.com/MessageBroker</wsa:Address> </wsa:EndpointReference> [caption - Example 1 EPRs 1 and 2] Despite the fact that these two EPRs are lexically identical, in this particular circumstance the EPRs may not in fact point to the same web service - for instance, the endpoint at the wsa:Address URL might be a message broker whose purpose is to provide a single outward-facing address which fronts many individual services behind the scenes. The actual service which is referenced might be determined by contextual information about the clients in question, including session state or even the client's network address. So in this case, two EPRs which might appear to be "the same" are in fact not necessarily so. Our second example involves two EPRs which are lexically very different: EPR1: <wsa:EndpointReference> <wsa:Address>http://example.com/Service1</wsa:Address> <wsa:ReferenceParameters> <cookie>chocolate-chip</cookie> </wsa:ReferenceParameters> <myExt:UUID>56433-4553-6927</myExt:UUID> </wsa:EndpointReference> EPR2: <wsa:EndpointReference> <wsa:Address>mailto:Service1@mail.example.com</wsa:Address> <myExt:UUID>56433-4553-6927</myExt:UUID> </wsa:EndpointReference> [caption - Example 2 EPRs 1 and 2] As you might surmise, we can imagine situations where these very different-seeming EPRs are in fact interchangeable - but the fact that they have this quality can only be known by using additional information, such as the fact that the <myExt:UUID> EPR extension indicates a token identifying the "service ID" and that matching service IDs mean interchangeable EPRs. This example demonstrates an example mechanism for determining EPR "sameness" which might layer on top of this specification. ------------------ Thanks, --Glen
Received on Monday, 14 March 2005 02:08:09 UTC