info:sid/localhost:CollectionRegistryFramework:ApplicationFramework info:sid/localhost:CollectionRegistryFramework CollectionRegistryFramework http://alcme.oclc.org:80/wikid/search/WikiDb.localhost ApplicationFramework display Registry Framework Information about the Registry Framework userAssigned mailto:jyoung@oclc.org no info:sid/localhost:CollectionSimpleSchemas:wiki info:sid/localhost:CollectionExternalSchemas:xhtml info:sid/localhost:CollectionExternalSchemas:xhtml 1.1 1 4rzxmf 300 http://www.oclc.org/schemas/WikiRepository xml http://alcme.oclc.org:80/wikid/docs/WikiRepository info:sid/localhost:CollectionRegistryFramework:ApplicationFramework anonymous CollectionRegistryFramework 2007/05/01/12 inf_3asid_2flocalhost_3aCollectionRegistryFramework_3aApplicationFramework_5f20070501121257028 text/xml CollectionRegistryFramework:ApplicationFramework 2007-05-01 2007-05-01 1 1.1 repos.hasDate = "hasdate" and oai.identifier exact "info:sid/localhost:CollectionRegistryFramework:ApplicationFramework" cql.any = huh? 1 1 xml default 2007-05-01 http://alcme.oclc.org:80/wikid/docs/WikiRepository/2007/05/01/12/inf_3asid_2flocalhost_3aCollectionRegistryFramework_3aApplicationFramework_5f20070501121257028 The application framework (named “OpenURL Object Model” or “OOM”) that we used to implement the Registry Framework Architecture needs to be justified since it probably could have been built using other, more popular frameworks like Spring. Here, then, is some background. The Registry Framework Architecture (described earlier) is an abstraction and synthesis of almost every project I’ve worked on at OCLC for the last 20 years. The primary catalyst of this conceptual synthesis was OpenURL. Unfortunately, the brand name “OpenURL” has two very distinct meanings that have caused needless confusion and need to be clarified. The original version, OpenURL 0.1, was specified as a citation-linking protocol. This caught on well in the library community and is what most people think of when you mention “OpenURL”. The subsequent OpenURL 1.0 specification, however, took a different approach. Rather than defining an explicit protocol, OpenURL 1.0 defines a framework for specifying protocols in general. The basic model in this framework is simple and intuitive, but suffers from two problems. First, the model is very abstract. For example, OpenURL 1.0 revolves around the intuitive but vague concepts of “what”, “who”, “where”, and “why”. The second problem is that the OpenURL 1.0 specification gave these simple concepts obfuscated names like “referent”, “requester”, “referring entity”, and “service type” respectively. The second problem can be overcome by keeping a printout handy of the terminology mapping. The first problem takes some getting used to, but should quickly become second-nature. Given this clarification, I would assert that OpenURL 1.0 represents a simple, intuitive, flexible, and lightweight model for specifying web services. This is achieved by normalizing the inputs of an operation into generic “what”, “who”, “where”, and “why” containers. Operations can be implemented against this normalized representation, with one or more bridges created between the normalized representation and the protocols that could be used to invoke it. Because these categories are so abstract, it should be possible to imagine that almost any web service could be represented in this way. Another problem with OpenURL 1.0 needs to be pointed out. The conventional way to manifest an OpenURL 1.0 application is to create entries in the OpenURL Registry (http://www.openurl.info/registry/''''''). This isn’t the only way, however. The OpenURL Object Model (OOM) takes a different approach. OOM is to OpenURL as DOM is to XML. For example, the XML specification defines concepts like “element”, “attribute”, “node”, etc. just as the OpenURL specification defines concepts like “entity”, “descriptor”, “transport”, etc. OOM maps its concepts to the programming space in a language-independent way just like DOM does. The expectation is that these conceptual models would get mapped to specific languages in similar ways. For example, in the case of Java, the classes for DOM have been specified by a set of interfaces under the org.w3c.dom.* package. Something analogous has been done for OOM under the info.openurl.oom.* package (http://pubserv.oclc.org/oom-j/jars/docs/dist.html''''''). If you examine the classes in this package, they should all map quite literally to the OpenURL spec. Likewise, there can be many implementations of these interface classes. In the case of DOM, we can look at Xerces and Crimson as alternative implementations of this interface set. In the case of OOM, I have written OOMRef-J as a reference implementation (http://pubserv.oclc.org/oomRef-j/jars/dist/docs/dist.html''''''). (Caveat: the OOM-J and OOMRef-J distributions at these locations are slightly stale. They should be updated before anyone gets too serious about using them.) The unexpected surprise that was revealed by this exercise was that OOMRef-J turned out to be a simple, lightweight, flexible, and intuitive application framework. This fact wasn’t anticipated by the committee that developed the OpenURL 1.0 specification, and few people outside the Registry Project team realize this yet. The Registry Framework is the first practical demonstration of its potential, and with that experience I now feel confident that it can and should be promoted more widely. The application framework (named “OpenURL Object Model” or “OOM”) that we used to implement the Registry Framework Architecture needs to be justified since it probably could have been built using other, more popular frameworks like Spring. Here, then, is some background.

The Registry Framework Architecture (described earlier) is an abstraction and synthesis of almost every project I’ve worked on at OCLC for the last 20 years. The primary catalyst of this conceptual synthesis was OpenURL. Unfortunately, the brand name “OpenURL” has two very distinct meanings that have caused needless confusion and need to be clarified.

The original version, OpenURL 0.1, was specified as a citation-linking protocol. This caught on well in the library community and is what most people think of when you mention “OpenURL”. The subsequent OpenURL 1.0 specification, however, took a different approach. Rather than defining an explicit protocol, OpenURL 1.0 defines a framework for specifying protocols in general. The basic model in this framework is simple and intuitive, but suffers from two problems. First, the model is very abstract. For example, OpenURL 1.0 revolves around the intuitive but vague concepts of “what”, “who”, “where”, and “why”. The second problem is that the OpenURL 1.0 specification gave these simple concepts obfuscated names like “referent”, “requester”, “referring entity”, and “service type” respectively. The second problem can be overcome by keeping a printout handy of the terminology mapping. The first problem takes some getting used to, but should quickly become second-nature.

Given this clarification, I would assert that OpenURL 1.0 represents a simple, intuitive, flexible, and lightweight model for specifying web services. This is achieved by normalizing the inputs of an operation into generic “what”, “who”, “where”, and “why” containers. Operations can be implemented against this normalized representation, with one or more bridges created between the normalized representation and the protocols that could be used to invoke it. Because these categories are so abstract, it should be possible to imagine that almost any web service could be represented in this way.

Another problem with OpenURL 1.0 needs to be pointed out. The conventional way to manifest an OpenURL 1.0 application is to create entries in the OpenURL Registry (http://www.openurl.info/registry/). This isn’t the only way, however. The OpenURL Object Model (OOM) takes a different approach. OOM is to OpenURL as DOM is to XML. For example, the XML specification defines concepts like “element”, “attribute”, “node”, etc. just as the OpenURL specification defines concepts like “entity”, “descriptor”, “transport”, etc. OOM maps its concepts to the programming space in a language-independent way just like DOM does. The expectation is that these conceptual models would get mapped to specific languages in similar ways. For example, in the case of Java, the classes for DOM have been specified by a set of interfaces under the org.w3c.dom.* package. Something analogous has been done for OOM under the info.openurl.oom.* package (http://pubserv.oclc.org/oom-j/jars/docs/dist.html). If you examine the classes in this package, they should all map quite literally to the OpenURL spec.

Likewise, there can be many implementations of these interface classes. In the case of DOM, we can look at Xerces and Crimson as alternative implementations of this interface set. In the case of OOM, I have written OOMRef-J as a reference implementation (http://pubserv.oclc.org/oomRef-j/jars/dist/docs/dist.html). (Caveat: the OOM-J and OOMRef-J distributions at these locations are slightly stale. They should be updated before anyone gets too serious about using them.)

The unexpected surprise that was revealed by this exercise was that OOMRef-J turned out to be a simple, lightweight, flexible, and intuitive application framework. This fact wasn’t anticipated by the committee that developed the OpenURL 1.0 specification, and few people outside the Registry Project team realize this yet. The Registry Framework is the first practical demonstration of its potential, and with that experience I now feel confident that it can and should be promoted more widely.