What are ReferenceParameters for?
What are ReferenceParameters for?
This mini-rant was inspired by the W3C Workshop on Enterprise computing
You get ReferenceParameters in WS-Addressing EndpointReferences, also known as EPRs. Kinda like this:
<wsa:EndpointReference>
<wsa:Address>http://www.crapola.com/SoapSink</wsa:Address>
<wsa:ReferenceParameters>
<SessionID>25324523</SessionID>
<ResourceID>1434123421</ResourceID>
<UserID>mark</UserID>
<UserServiceRating>Gold</UserServiceRating>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
A few things about ReferenceParameters. First, given an EPR you should treat the ReferenceParameters as opaque; you should not reason about them. Second, the ReferenceParameters get stuffed into SOAP Headers, and are sent along to the service that the EPR addresses. Third, the thing in the wsa:Address is an identifier, not a location, you de-reference the identifier to a location before sending the message.
So what might you do with ReferenceParameters? Well, if you are using WSRF you might use them for a bit of identification. Have all the SOAP messages arrive at the endpoint identified by the wsa:Address element, then direct the messages to particular WS-Resources based on the ReferenceParameters; ResourceID in the example.
Or you might decide to use ReferenceParameters to support sessions. You want to track a particular client's usage of a service, then give him an EPR with a session identifier, SessionID in the example, embedded in the ReferenceParameters. The session identifier will be carried in the SOAP header each time the client sends a message to the service. You could even carry some information to identify the client; UserID or UserServiceRating in the example.
All these uses of ReferenceParameters are possible, though the W3C TAG frowns on the first. ReferenceParameters are a bit like HTTP cookies in functionality; cookies can do all the above for HTTP. So, what is the problem?
Well, given an EPR that has ReferenceParameters you should NEVER share it with anyone else. You cannot know what those ReferenceParameters are for. They could be there for some identification purpose, in which case it would be OK to share them, but you cannot know that for sure. They could actually be for identifying a particular session, or client. Sharing EPRs with ReferenceParameters would be like sharing your HTTP cookies; you simply wouldn't do it. Now, imagine a Web were you were not able to share URIs.
This mini-rant was inspired by the W3C Workshop on Enterprise computing
You get ReferenceParameters in WS-Addressing EndpointReferences, also known as EPRs. Kinda like this:
<wsa:EndpointReference>
<wsa:Address>http://www.crapola.com/SoapSink</wsa:Address>
<wsa:ReferenceParameters>
<SessionID>25324523</SessionID>
<ResourceID>1434123421</ResourceID>
<UserID>mark</UserID>
<UserServiceRating>Gold</UserServiceRating>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
A few things about ReferenceParameters. First, given an EPR you should treat the ReferenceParameters as opaque; you should not reason about them. Second, the ReferenceParameters get stuffed into SOAP Headers, and are sent along to the service that the EPR addresses. Third, the thing in the wsa:Address is an identifier, not a location, you de-reference the identifier to a location before sending the message.
So what might you do with ReferenceParameters? Well, if you are using WSRF you might use them for a bit of identification. Have all the SOAP messages arrive at the endpoint identified by the wsa:Address element, then direct the messages to particular WS-Resources based on the ReferenceParameters; ResourceID in the example.
Or you might decide to use ReferenceParameters to support sessions. You want to track a particular client's usage of a service, then give him an EPR with a session identifier, SessionID in the example, embedded in the ReferenceParameters. The session identifier will be carried in the SOAP header each time the client sends a message to the service. You could even carry some information to identify the client; UserID or UserServiceRating in the example.
All these uses of ReferenceParameters are possible, though the W3C TAG frowns on the first. ReferenceParameters are a bit like HTTP cookies in functionality; cookies can do all the above for HTTP. So, what is the problem?
Well, given an EPR that has ReferenceParameters you should NEVER share it with anyone else. You cannot know what those ReferenceParameters are for. They could be there for some identification purpose, in which case it would be OK to share them, but you cannot know that for sure. They could actually be for identifying a particular session, or client. Sharing EPRs with ReferenceParameters would be like sharing your HTTP cookies; you simply wouldn't do it. Now, imagine a Web were you were not able to share URIs.