I had some interesting thoughts on comparing reference propertes in EndpointReferences to URI fragment identifiers. EndpointReferences (EPRs) are defined in the WS-Addressing specification.
Frag-ids identify a secondary resource that is related to a primary resource. In fact, they aren't even sent from the client to the server when the resource is requested, they are strictly for client-side usage. The interpretation of the frag-is governed by the media-type metadata returned wth the representation.
Now a lot of web sites use HTTP Cookies for doing secondary resource identification. This can be done through session ids, ip addresses, etc. They are sent as HTTP headers. Of course, there's often some amazingly breaking of orthogonality when the application then does a getCookie to retrieve part of it's state from the header. But that's a separate article. What is interesting is that one of the main reasons that cookies are used is to identify secondary resources on a server, versus frag-ids which are under client control.
WS-Addressing gives us an incredibly useful mechanism for doing secondary resource identification. An EndpointReference contains reference properties, which are required to be echoed as SOAP headers by an EPR holder whenever it communicates. Many of us call this "SOAP cookies".
The neat thing that I was thinking about is that EPRs give us bidirectional secondary resource identification. Now the obvious comparison is with cookies - and I've been working on that - but a comparison can be made with URI frag-ids. Identifiers for secondary resources can either flow with a message (cookies, EPRs) or not (frag-ids). Given that a secondary resource identifier will flow, it's going to be in a message header or a body. I think bi-directional use of SOAP headers is a really elegent solution and enables us to bring both the power of frag-ids and cookies to both sides as well as fully utilizing XML infrastructure. But I'm leaping to the conclusion and I still need to do the a comparison of frag-ids with ref properties.
In the same way that a frag-id is opaque to a server, an EPR reference is opaque to a sender. It is meant for consumption by the "interpreter" of the reference. In an example web context, a web page links to a section of a document using a frag-id. The client invokes a GET operation and the server returns the entire representation. The refering web page also has a pretty good idea of what the media type of the retrieved representation will be. Woe to any server that doesn't ensure that the frag-ids are uniform across the media-types.
HTTP is fundamentally a request response protocol. So if we do any kind of asynchrony, such as a callback, how does the "receiver" know which secondary resource is being used? This is exactly what ref properties provide. As a Web browser wll be able to "keep" the frag-id for interpretation in a response, an asynchronous message needs to "keep" the secondary resource identifier. As soon as the "request/response" exchange pattern is broken, the secondary resource identifier must be sent in a message.
Now what about media-types and reference properties? For a web browser to correctly interpret formats, it has to "know" about the various media-types, or be able to hand-off to an application that does. The browser author looks up the media type information in the IANA registry. XML changes the landscape completely. Instead of having a small number of types that are registered through a centralized authority, authors can create arbitrary vocabularies and even application protocols through XML and Schema. In the same way a client has to be programmed for media types, a client must be programmed for xml types and wsdl operations.
So how does a web service tell a client that it ought to be prepared for various formats and protocols, and which are the particulars of a given service? Through WSDL and EPRs. EPRs have the ability to provide information about the binding and the interface that are related to an address and reference properties. The creator of an EPR has knowledge of any secondary resource identification that may be needed relating to the particular endpoint and it's interface and address.
In an interesting way, we've taken advantage of the decentralized ability to describe languages and protocols, and then provided the ability to specify which types are related to a specific resource and secondary resource. A Web browser doesn't need the ability to combine the frag-id for a given resource with a media-type. But this does't seem to be the case for what we're going to be doing with distributed application design, specifically the movement towards bi-directional asynchrony.
I think it's pretty interesting to think of frag-ids and reference properties as the same architectural concepts, observe the parallels between media-types/iana and xml schema/wsdl, compare the process of minting and intepreting URIs with frag-ids compared to EPRs, and understand the necessity of different mechanisms because of Asynchrony.
Leave a comment