1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15

Network services and architecture

As the environment becomes more complex, we are seeing a movement away from application “stovepipes” towards a decomposition of applications, so that they can be recombined to meet emerging needs more flexibly. Think of this as repurposing for architectures. An architectural perspective becomes interesting as a way of visualizing the system components and the relationships between them. A simple architectural perspective is presented here as a way of framing some discussion about interoperability.

Content services	Application services	Common services	Presentation
Content management services: repository architectures, preservation, knowledge organization, retrieval… e.g., OAIS, DSpace, Fedora, LCSH, Dewey… Packaging: OAIS SIP/AIP/DIP, METS, RSS, SCORM, IMS-CPS Information resources: text, static images, moving images, audio, multimedia… HTML, PDF, JPEG, GIF, MPG… Metadata: discovery, technical, administrative, structural DCMI, MARC, MODS, MIX, EAD, LOM…	Generic Web services: UDDI, WSDL, SOAP, XSLT… Discovery services: Xquery, SRW/SRU, Z39.50… Aggregation services: OAI, RSS, Web services, Semantic Web… Transaction services: exchange, billing, delivery NCIP (circulation, ISO-ILL)...	Terminology services Metadata schema registries Directories rights, people, organizations, collections… Identity management: Shibboleth Resolution services: OpenURL, identifiers (PURL, DOI)	Rendering: browser, database interfaces, media players… Content views: personalization, visualization… End-user support: searching, ordering and delivery, technical support

This perspective is based on the JISC Information Environment, which looks at how a set of national services might be developed collaboratively, in the United Kingdom, but which has become more widely influential.18 Effectively, it describes an environment onto which a portal provides a view. Some other architectural perspectives are available. At a high level these architectural initiatives are quite similar, they discuss similar services and seek to facilitate similar types of design and discussion.

What this architectural perspective shows are the following types of services:

• Presentation services: these are responsible for accepting user input and rendering system outputs. Typically, services are presented to a Web browser, but other environments (cell phone, PDA, collaborative environments, and so on) are possible. As discussed above, library services may be made available at their own interface, within a library portal, but also increasingly in other environments such as learning management systems, virtual exhibitions or campus portals. The presentation layer may be a “portlet,” a channel in some other environment.
• Application: these are services responsible for managing transactions between components. In business terms, these are the “business logic.” We have already discussed metasearch and resource-sharing applications. Another emerging application is aggregation, where metadata or content is “harvested” into a repository. A question broker is an application, which drives virtual reference services.
• Content services: these are repositories of data and metadata. Libraries have always managed large metadata repositories. In the last few years, more libraries are now also managing growing repositories of content. This poses a range of technical and service challenges, as well as preservation challenges.
• Common services: these are services that are potentially shared by several applications. They include things like directory or registry services, authentication and so on. A union catalog could be considered a “common service,” particularly when it is thought about as a way of locating items through holdings lookup. The need for directory services (for data about policies, collections, rights, organizations, people) grows as we move towards a distributed environment. These are effectively “intelligence” that applications need to work smoothly and avoid redundant development effort. An example of such a directory is OCLC’s ILL Policies Directory. Another is the “knowledge base” that is configured into current portal and resolver services. At the moment, each vendor or implementer creates a knowledge base with significant redundant cost. The knowledge base contains such data as descriptions of available resources, technical information about how to connect, and rights data. There is growing interest in making such data available nonredundantly as a “shared service.” This idea makes technical sense, although it is not yet clear whether economic incentives exist to bring it about. “Registry” services typically allow applications to discover technical details that are needed about registered entities. So, for example, OCLC runs a pilot OpenURL registry—this allows implementers of the new OpenURL specs to find authoritative data about identifiers and metadata schemas. Again, this type of application becomes more important as we move to distributed environments.

An example: Think about using a portal. Typically, the user will see a screen and can search several databases.

However, if we look “behind” or “through” the screen we see a potentially complex range of interactions. For example, consider a typical set of interactions to support a cross-searching application. The portal interface will give a view to the user of what is available. It will accept input and will pass to a metasearch engine. This in turn may need to look in a knowledge base to see how to interact with a particular resource. Authentication and authorization may be required at several stages. When some metadata is returned and the user selects an item it may be passed to an OpenURL resolver. This description simplifies the process, and there may be many other interactions. There may in fact be a range of other fine-grained services. Some metasearch engines merge and enhance metadata from third-party resources. Because of the heterogeneity of potential targets, there is a need for terminology services, where an application can interact with a service that maps vocabularies, expands searches and so on.

Say the item returned to the searcher of a portal was a book record and the user wants to initiate an interlibrary loan request. Then the portal might interact with a request broker service. It might have to select a library to send a request to based on a directory of rules, consult an ILL policy directory and send a request. It may have to interact with a common billing service.

It should be clear at this stage that this is an idealized schematic: in fact these systems are much more monolithic, enclosed and Tower-of-Babel-like than this representation suggests. However, the interconnected environment described in the last section suggests that there will have to be more decomposition of systems if we are to build flexible digital environments. This in turn suggests that we need effective and efficient links between the various components: they need to “click.” This then raises the question of ensuring an appropriate standards framework to make this happen.

Library Landscape: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15