September 10, 2006
Two Levels of OpenURL
The models defined by OpenURL can be applied at two separate levels: the network level and the application level. The enduring legacy of OpenURL 0.1 is that most people still envision OpenURL as a linking mechanism between clients and servers (the network level) with ContextObjects as the intermediary. The OpenURL Object Model (OOM) tackles the application level. In addition to accepting ContextObjects from the client, it also uses them within the application as a bridge between the decoupled server and pure business logic. Here's the general flow:
- The client "serializes" a ContextObject and "transports" it to a OOM-compliant server
- On the server, an OOM Transport extracts an OOM ContextObject and optionally enriches it with additional information (e.g. from session data or cookies)
- OOM relays the enriched ContextObject to the requested OOM Service class for processing
- The Service class extracts descriptors from the enriched ContextObject, uses it to invoke some business logic, and transforms the business logic response into a standardized response
There are several points worth highlighting.
- In bullet 1, the client doesn't need to know that the server is OOM-compliant because the ContextObject is a general abstraction
- Likewise in bullet 3, the server doesn't need to know the specifics of the Services because the ContextObject is a general abstraction
- I also want to remind people not to think too narrowly about the meaning of "serialization" and "transport" in bullet 1 because these are extensible in the OpenURL Registry. In other words, practically any imaginable web service request can be made OpenURL-compliant by adding a few entries to the registry.