info:sid/localhost:CollectionRegistryFramework:RfaFaq info:sid/localhost:CollectionRegistryFramework CollectionRegistryFramework http://alcme.oclc.org:80/wikid/search/WikiDb.localhost RfaFaq 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 3huo4y 300 http://www.oclc.org/schemas/WikiRepository xml http://alcme.oclc.org:80/wikid/docs/WikiRepository info:sid/localhost:CollectionRegistryFramework:RfaFaq anonymous CollectionRegistryFramework 2007/02/16/16 inf_3asid_2flocalhost_3aCollectionRegistryFramework_3aRfaFaq_5f20070216162407276 text/xml CollectionRegistryFramework:RfaFaq 2007-02-15 2007-02-16 1 1.1 repos.hasDate = "hasdate" and oai.identifier exact "info:sid/localhost:CollectionRegistryFramework:RfaFaq" cql.any = huh? 1 1 xml default 2007-02-16 http://alcme.oclc.org:80/wikid/docs/WikiRepository/2007/02/16/16/inf_3asid_2flocalhost_3aCollectionRegistryFramework_3aRfaFaq_5f20070216162407276 = Registry Framework FAQ = == What is the Registry Framework? == The Registry Framework is a customizable and extensible platform for managing arbitrary collections of items online. == So what you are saying is that the registry architecture is basically a generic web app framework? (A framework that internally uses the openURL and SRW standards?) == Let me put a slightly different spin on it. Think of OpenURL as the generic app framework. There are no services implied at this level. In contrast, the registry architecture is a set of generic collection-based web services built on this generic framework. These generic services assume SRW as the database abstraction layer. == If another application is using the registry as basically a web service to get some data that it is going to format and display itself, is this still a good fit for the registry architecture? == Some services in the registry framework are geared towards automated clients, and other services are geared towards humans (esp. browsers). Many are designed to serve both purposes by delivering XML+XSL to clients. The intent of the registry framework is to provide a generic set of services that can provide 50-80% of the functionality needed to manage arbitrary collections of items online. It’s certainly possible to re-implement some of this functionality in a parallel framework, but this would tend to undermine the promise of commonality and reusability that has attracted management’s attention. == What are the benefits over another web service framework? Is it the fact that it does use standards? == In general, such a set of services probably could have been implemented using almost any framework. It’s worth noting, though, that just because developers use this or that framework doesn’t mean they’re building reusable systems. In that sense, it’s not the framework that’s the key innovation here, it’s the data models and set of services we’re providing. At a superficial level, the reason this was developed using the OpenURL framework is because it was an evolution of my research and involvement with that standard. More substantively, the OpenURL standard provides an intuitive and comprehensive set of abstractions for how to represent and implement interoperable web services. Of particular interests is the ability to decouple a service implementation from the request structure (SOAP, REST, XML-RPC, etc.) The appeal to developers is that you can take some arbitrary bit of business logic, add a thin OpenURL wrapper, and drop it on the classpath to make it available as a new web service. Last but not least, OpenURL is a web service standard that the community will expect us to support going forward. It will be easier to satisfy these expectations if OpenURL is integral to our systems rather than tacked on as an after-thought. As the community develops new service standards (e.g. OAI-PMH), it should be possible to download a new open-source jar file containing the new set of services, and simply drop them onto the classpath to have them integrated into our systems. == What if our database access does not fit SRW very well? (Meaning, what If we are doing only relational db type searches? Does CQL handle this very well?) == The key requirement of the registry framework is that it must be possible to represent the data as a collection of discrete identifiable items. This isn’t always possible, in which case the registry framework isn’t an appropriate solution (although the OpenURL framework probably would be). OTOH, we build a lot of custom applications against custom relational databases that could easily fit into the model given a little bit of fore-thought. The institution registry is a case in point. Assuming that the data can be represented as items in a collection, SRW/CQL should be adequate for almost any need. For those rare cases where nothing less than SQL will do, the framework can easily be extended to support it from custom services.

Registry Framework FAQ

What is the Registry Framework?

The Registry Framework is a customizable and extensible platform for managing arbitrary collections of items online.

So what you are saying is that the registry architecture is basically a generic web app framework? (A framework that internally uses the openURL and SRW standards?)

Let me put a slightly different spin on it. Think of OpenURL as the generic app framework. There are no services implied at this level. In contrast, the registry architecture is a set of generic collection-based web services built on this generic framework. These generic services assume SRW as the database abstraction layer.

If another application is using the registry as basically a web service to get some data that it is going to format and display itself, is this still a good fit for the registry architecture?

Some services in the registry framework are geared towards automated clients, and other services are geared towards humans (esp. browsers). Many are designed to serve both purposes by delivering XML+XSL to clients. The intent of the registry framework is to provide a generic set of services that can provide 50-80% of the functionality needed to manage arbitrary collections of items online. It’s certainly possible to re-implement some of this functionality in a parallel framework, but this would tend to undermine the promise of commonality and reusability that has attracted management’s attention.

What are the benefits over another web service framework? Is it the fact that it does use standards?

In general, such a set of services probably could have been implemented using almost any framework. It’s worth noting, though, that just because developers use this or that framework doesn’t mean they’re building reusable systems. In that sense, it’s not the framework that’s the key innovation here, it’s the data models and set of services we’re providing.

At a superficial level, the reason this was developed using the OpenURL framework is because it was an evolution of my research and involvement with that standard. More substantively, the OpenURL standard provides an intuitive and comprehensive set of abstractions for how to represent and implement interoperable web services. Of particular interests is the ability to decouple a service implementation from the request structure (SOAP, REST, XML-RPC, etc.) The appeal to developers is that you can take some arbitrary bit of business logic, add a thin OpenURL wrapper, and drop it on the classpath to make it available as a new web service.

Last but not least, OpenURL is a web service standard that the community will expect us to support going forward. It will be easier to satisfy these expectations if OpenURL is integral to our systems rather than tacked on as an after-thought. As the community develops new service standards (e.g. OAI-PMH), it should be possible to download a new open-source jar file containing the new set of services, and simply drop them onto the classpath to have them integrated into our systems.

What if our database access does not fit SRW very well? (Meaning, what If we are doing only relational db type searches? Does CQL handle this very well?)

The key requirement of the registry framework is that it must be possible to represent the data as a collection of discrete identifiable items. This isn’t always possible, in which case the registry framework isn’t an appropriate solution (although the OpenURL framework probably would be). OTOH, we build a lot of custom applications against custom relational databases that could easily fit into the model given a little bit of fore-thought. The institution registry is a case in point.

Assuming that the data can be represented as items in a collection, SRW/CQL should be adequate for almost any need. For those rare cases where nothing less than SQL will do, the framework can easily be extended to support it from custom services.