D-Lib Magazine
July/August 2006

Volume 12 Number 7/8

ISSN 1082-9873

A Service Framework for Libraries

Brian Lavoie
OCLC Online Computer Library Center, Inc.
<lavoie@oclc.org>

Geneva Henry
Rice University
<ghenry@rice.edu>

Lorcan Dempsey
OCLC Online Computer Library Center, Inc.
<dempseyl@oclc.org>

I. Introduction

Much progress has been made in aligning library services with changing (and increasingly digital and networked) research and learning environments. At times, however, this progress has been uneven, fragmented, and reactive. As libraries continue to engage with an ever-shifting information landscape, it is apparent that their efforts would be facilitated by a shared view of how library services should be organized and surfaced in these new settings and contexts.

Recent discussions in a variety of areas underscore this point:

• Institutional repositories: what is the role of the library in collecting, managing, and preserving institutional scholarly output, and what services should be offered to faculty and students in this regard?
• Metasearch: how can the fragmented pieces of library collections be brought together to simplify and improve the search experience of the user?
• E-learning and course management systems: how can library services be lifted out of traditional library environments and inserted into the emerging workflows of "e-scholars" and "e-learners"?
• Exposing library collections to search engines: how can libraries surface their collections in the general Web search environment, and how can users be provisioned with better tools to navigate an increasingly complex information landscape?

In each case, there is as yet no shared picture of the library to bring to bear on these questions; there is little consensus on the specific library services that should be expected in these environments, how they should be organized, and how they should be presented.

Libraries have not been idle in the face of the changes re-shaping their environments: in fact, much work is underway and major advances have already been achieved. But these efforts lack a unifying framework, a means for libraries, as a community, to gather the strands of individual projects and weave them into a cohesive whole. A framework of this kind would help in articulating collective expectations, assessing progress, and identifying critical gaps. As the information landscape continually shifts and changes, a framework would promote the design and implementation of flexible, interoperable library systems that can respond more quickly to the needs of libraries in serving their constituents. It will provide a port of entry for organizations outside the library domain, and help them understand the critical points of contact between their services and those of libraries.

Perhaps most importantly, a framework would assist libraries in strategic planning. It would provide a tool to help them establish priorities, guide investment, and anticipate future needs in uncertain environments.

It was in this context, and in recognition of efforts already underway to align library services with emerging information environments, that the Digital Library Federation (DLF) in 2005 sponsored the formation of the Service Framework Group (SFG) [1] to consider a more systematic, community-based approach to aligning the functions of libraries with increasing automation in fulfilling the needs of information environments. The SFG seeks to understand and model the research library in today's environment, by developing a framework within which the services offered by libraries, represented both as business logic and computer processes, can be understood in relation to other parts of the institutional and external information landscape. This framework will help research institutions plan wisely for providing the services needed to meet the current and emerging information needs of their constituents.

A service framework is a tool for documenting a shared view of library services in changing environments; communicating it among libraries and others, and applying it to best advantage in meeting library goals. It is a means of focusing attention and organizing discussion. It is not, however, a substitute for innovation and creativity. It does not supply the answers, but facilitates the process by which answers are sought, found, and applied.

This paper discusses the SFG's vision of a service framework for libraries, its approach to developing the framework, and the group's work agenda going forward.

II. A Vision for a Service Framework

This section discusses the SFG's vision of a service framework, with an emphasis on some of the key principles on which such a framework should be based. For a detailed discussion of why a service framework is important for libraries, see Dempsey and Lavoie (2005) [2].

Before proceeding further, it is useful to state explicitly the SFG's definition of a service framework:

A service framework is a set of reference models, along with a set of concepts and vocabulary for expressing and relating them. The service framework – i.e., vocabulary and reference models – covers the range of entities relevant to the articulation of library business goals at varying levels of granularity, as well as the services that support these goals.

For the purposes of this discussion, a reference model is defined as a formal description of a library activity, expressed using consistent, well-defined terminology and relationships. The Open Archival Information System (OAIS) [3] reference model is a useful example of what a reference model might look like, and the benefits it confers. OAIS describes a particular library activity: digital preservation. It provides a broad sketch of what digital preservation is intended to accomplish, the major processes involved, and even some of the more granular functionalities that comprise each process. It also defines some of the information objects that flow through the preservation process. OAIS provides a means of understanding and expressing the digital preservation problem space. This in turn has galvanized discussion in an extremely diverse global digital preservation community, and facilitated the development of international standards and technologies built around the understanding of digital preservation expressed by OAIS.

Just as OAIS provides a means for understanding and discussing digital preservation, a service framework for libraries would provide a similar platform for understanding and discussing the transitions shaping the general library landscape. The framework would be a tool with which to 1) understand and communicate the "business logic" needed to support library goals, and how this business logic must change as library goals and environments change, and 2) support the design and implementation of flexible, recombinant, and interoperable systems to support library goals. The framework will be a shared point of reference for libraries, and is expected to help:

• Cultivate a shared, consistent vocabulary to discuss library goals and services;
• Communicate library goals and library value to other communities;
• Encourage consensus and large-scale collaborations;
• Benchmark the current state of library service development, and identify critical needs and gaps;
• Promote the design of re-usable, recombinant, and interoperable library services, and minimize reinvention of wheels across library development efforts;
• Align business planning with systems development.

It is useful at this point to mention a few things that the service framework is not about:

• Technology choice: the framework is not a statement about the specific ways services, applications, or library systems should be implemented;
• Application design: the framework is not about specifying the specific ways, or architectures, used to bundle services together to form more complex applications;
• "Starting from scratch": the framework will not provide an exhaustive description of all aspects of a library, but instead, concentrate on key areas of need. It will not re-invent libraries from the ground up.

The service framework is not a process modeling or systems design methodology. It is, however, a means of organizing and expressing in a consistent way the output of process modeling or systems design activities. It is a way for libraries to organize and express their collective understanding of how library activities should be presented in changing information environments, as well as a context within which to sustain an ongoing dialog to further that understanding.

The grand theme underpinning the framework is that library service development should be driven by library business goals, and conversely, functionality embedded in existing library systems should be "mappable" back to the business logic – i.e., the library's business processes and workflows – it is intended to support. The framework needs to encompass, therefore, concepts for expressing business logic, as well as concepts for mapping the business logic to the technical or engineering logic of library service provision. This will help decision-makers understand how the needs and goals of the library inform the design of systems.

In keeping with this theme, the SFG identified several important principles that would guide its work:

(1) Service-orientation: Systems development, both within the library community and beyond, is increasingly based on service-oriented concepts and design methodologies. A service is a discrete piece of functionality, manifested in the form of a technical implementation, and deployed for use, usually on a network (e.g., as a Web service). Looking ahead, there is every indication that more and more library processes and workflows will take the form of automated systems built by combining a variety of services. Service orientation is a modular approach to systems development, through the combination and recombination of component services from possibly numerous sources. This permits flexible development strategies responsive to constantly shifting information environments. It organizes community-wide development efforts in ways that promote re-usability and avoid duplicative effort, enhance interoperability, and ultimately, lower costs. All of these factors are essential ingredients for library system development in increasingly complex network environments, where responses to change must be rapid and economical.

(2) Consistency and Cohesiveness: Libraries have invested considerable effort into thinking about how their services should be organized and presented in changing environments. However, very little has been documented in ways that promote convergence of thinking, and perhaps even standardization. Libraries therefore lack consistent ways of presenting their services and communicating their value in new environments. The service framework aims to rectify this through the accumulation of reference models that provide a consistent view of library activities, and a shared means of expressing them. However, the service framework needs to be more than just a disjointed set of reference models. There must be a way to create useful relationships across the reference models – that is, to move both horizontally (across library activities) and vertically (across different levels of granularity within the same activity) – within the service framework. In short, the service framework must have an internal structure that supports a cohesive, "big picture" view of the library service landscape.

(3) Outward-Facing: Library services will not always be accessed in library-controlled environments and systems; instead, they will often be surfaced in, and accessed through, non-library environments. For example, the library catalog may take the form of a search service embedded in a course management system; similarly, reference desk services may take the form of an "ask-a-librarian" service available with the click of a button on a Web browser tool bar. Libraries need to make their services available at the point of need, whether it be in course management systems, e-learning materials, collaboration tools, or even the general Web search environment. It is important, therefore, that the service framework facilitate communication, collaboration, and interoperability not just between libraries, but also between libraries and other domains. It needs to be outward-facing, in the sense that it serves as an aid for communicating a consistent view of library services in non-library domains, and identifying key points of contact across domain boundaries. The framework should help libraries interact seamlessly with other parts of the information landscape, and help them actively define their role in new information environments, rather than having it defined for them, or being excluded entirely.

In summary, the SFG will lay the foundations for a framework that is service-oriented, consistent and cohesive, and outward-facing. More than this however, the framework should be facilitating rather than prescriptive, flexible rather than constraining, and a catalyst for, rather than an obstacle to, understanding and innovation.

III. A Structure and Vocabulary for the Framework

The SFG's activities to date have focused on articulating the case for a service framework for libraries; compiling and reviewing related initiatives, including direct discussions with several projects (more on this below); and sketching out a structure and vocabulary for representing library business logic in the context of the service framework. The latter is illustrated in Figure 1.

Figure 1: Decomposing the Library's Business Logic

Figure 1 embeds several key concepts that can be used to decompose and describe a library's business logic:

• Business Requirement: identifiable segment of an organization's overall mission. Example: Preserve Digital Resources
• Business Process: identifiable portion of a business requirement. Example: Ingest Digital Resources into Repository
• Business Function: identifiable portion of a business process. Example: Validate Format of Ingested Resource

A library can be viewed as a set of activities which, taken together, define what the library is and what it is expected to do to fulfill its mission. In some instances, these activities are defined broadly – for example, "collect, organize and preserve". This may be useful in some contexts, but not in others. For instance, if the goal is to build a digital library system, simply asserting that the system must support the collection, organization, and preservation of digital resources provides little information for the system architect. There is also little assurance that two different systems, both supporting the preservation activity, will offer the same, or even similar, functionality.

In order to cultivate a shared view of library services, it is useful to follow a process of decomposition, beginning with broad library requirements and ending with self-contained units of specific functionality. This is illustrated in Figure 1: the library's business logic – its broad statement of mission – is decomposed, or factored, into a set of business requirements needed to accomplish overall objectives. The business requirements attach more specificity to the library's objectives, and convey more detail about what must be done to achieve these objectives. A business requirement is in turn decomposed into a set of constituent processes, each of which are broken down into one or more business functions. With each decomposition step, the library's business logic is broken down into smaller and more specific descriptions.

Boundaries between requirements, processes, and functions can be arbitrary, but the downward progression through several levels of granularity helps simplify decomposition by allowing it to occur in stages on units of manageable size. In contrast, attempting to decompose a broad requirement into a set of "atomic" functionalities in a single step would be complex and difficult. Moreover, it is often the case that the boundaries between levels are quite natural, and in this sense, may give useful hints to system architects as they design automation logic to implement the business logic. For example, decomposition could help identify instances where the same functionality appears in multiple contexts, and can therefore be re-used; it might also help isolate functionality that could be stripped out of local implementations and deployed instead as a shared service infrastructure. In either case, this would help reduce local development effort and costs.

The structure and vocabulary represented in Figure 1 convey a misleading sense of simplicity; in fact, while the structure and concepts were intentionally kept simple and straightforward, they were the product of much discussion and analysis. The SFG membership brought a variety of perspectives, and means of expressing these perspectives, to their work; crafting these into a single model was both a challenging and interesting process. Figure 1 represents a convergence of views among the membership on some basic concepts with which to express a consistent view of library services. This in turn can aid in communicating these services across a variety of boundaries – within libraries, between libraries, and between libraries and other domains – as well as inform a flexible, service-oriented approach to library systems development.

Decomposing library activities into granular, self-contained functions helps us better understand libraries, and in doing so, helps in the development of flexible, consistent library services. Recall that a service is a discrete piece of functionality, manifested in some form of technical implementation, and deployed for use, usually on a network. In this sense, a service embodies two aspects: a description of a functionality, and a technology choice for implementing that functionality. As the latter aspect suggests, there are often multiple ways to implement a given functionality, and so a service may be manifested in different ways. But there should be a way to express the underlying functionality, independent of technology choice. In the SFG's vocabulary, this is handled through the concept of an abstract service:

• Abstract Service: conceptualization of a business function as a discrete piece of functionality (possibly networked), consisting of a description of its functional scope and an abstract model of its behavior and data.

Abstract services represent an intermediate step between defining a business function (i.e., a discrete piece of library business logic), and a technical implementation of that function. An abstract service elaborates on a business function by organizing it into a set of automatable behaviors, as well as a generic description of its input and output requirements, perhaps in the form of an abstract data model. In short, an abstract service is a way of expressing a business function as a service – but independent of technology choices for its implementation. In this way, multiple service implementations can be drawn together into a single family, each implementing the same piece of library business logic, and represented by the same abstract service. By abstracting away the specificities of technical implementation, library services can be expressed in generic terms, which in turn permits a consistent view of library services across multiple, and possibly very different, technical contexts and environments.

• Business Entity: entity of interest within the environment, usually represented by metadata. Examples: service, person, organization, collection, policy, transaction.

Library services are increasingly dependent on data about important entities in the environments in which they operate. This data will usually take the form of schematized descriptions of people, places, and things within the environment. Libraries, of course, have a great deal of experience in terms of schematized descriptions of information objects, and this kind of data will continue to play a key role in supporting library services. However, automated fulfillment of many key library functions will require much more than this: consistent ways of describing users, institutions, services, policies, and a host of other business entities will also be needed, as well as consistent ways of representing relationships between various types of entities. Library services will be increasingly data-driven, and therefore business entities must be a key element of the service framework.

Figure 1 represents a possible structure and vocabulary for the service framework. It is service-oriented in the sense that it aims to decompose library business logic down into discrete units of functionality that can be implemented and deployed as services in a variety of environments. It is consistent and cohesive, in the sense that it supplies concepts for describing library activities at various levels of granularity, independent of specific technology choices, and provides a structure for organizing and relating these concepts as a unified whole. And it is outward-facing, in the sense that it provides a means of communicating library services in non-library environments, by expressing these services in a consistent way that is independent of technical or environmental context; moreover, by taking into account key business entities library services need to understand and support – information objects, people, other services, and so on – it helps identify points of contact between libraries and other domains.

The service framework was defined above as a set of reference models, along with a structure and vocabulary for expressing them. Figure 1 is a partial fulfillment of the latter requirement. Reference models may be developed at all levels of the structure depicted in Figure 1: requirements, processes, functions, abstract services, and business entities. The structure and vocabulary is a means of expressing, organizing, and linking the reference models gathered under the umbrella of the service framework.

IV. Example: The OAIS Reference Model

As mentioned above, a good example of what the service framework hopes to accomplish is the OAIS reference model. OAIS can also be used as a means of illustrating how the structure and vocabulary of Figure 1 might be applied in practice. Figure 2 presents a decomposition of the business logic subsumed within OAIS, using the structure and vocabulary of Figure 1.

Figure 2: The OAIS "Business Logic"

In this formulation, the library activity "Long Term Preservation" is defined as a business requirement – i.e., an identifiable segment of a library's overall mission. This requirement is in turn composed of six major business processes: Ingest, Data Management, Archival Store, Preservation Planning, Access, and Administration. Each of these processes is then comprised of a series of more granular business functions. Taken together, the processes and functions provide a concise mapping of the digital preservation problem space.

OAIS is probably best construed as a reference model for a business requirement, with an emphasis on decomposing this requirement into its constituent business processes. It is at the level of business process that OAIS provides the most detail, and at which repositories typically claim to be "OAIS-conformant". Of course, there is ample room for debate concerning the way OAIS structures its decomposition: for example, while "Extract Metadata" might easily be seen as a discrete unit of functionality, "Customer Service" is probably too broad to be considered atomic. But issues such as this merely underscore the need to have a consistent structure and vocabulary with which to frame discussion and facilitate a productive exchange of views.

OAIS also provides a partial treatment of some of the key business entities relevant to preservation. OAIS defines the concept of an information package – i.e., digital content and its associated metadata viewed as a single, logical package moving into (submission information package, or SIP), through (archival information package, or AIP), and out of (dissemination information package, or DIP) the archival system. A METS object may be interpreted as a formal schematization of an information package. Abstract services can be designed that operate on information packages; actual service implementations can be designed that operate on METS objects.

The business functions in Figure 2 can be used as starting points for defining abstract services that implement the functionality prescribed by OAIS. Note that there is not necessarily a strict one-to-one correspondence between business functions and abstract services. Behaviors embodied in a business function could be split across two or more abstract services. Figure 2 also helps identify functionalities that might be re-used in multiple contexts: for example, it might be the case that the two functions "Generate AIP" and Generate DIP" share much of the same functionality, which could then be concentrated in a single abstract service supporting both functions. Furthermore, certain processes and functions – Archival Store, for example, or "Monitor Technology" – are sufficiently generic that they can be broken out into a shared infrastructure serving multiple repositories, rather than duplicated locally. The availability of an over-arching structure within which to orient OAIS, and a consistent vocabulary for talking about its component parts, aids conversations about these kinds of issues.

Reference models could also be developed to describe in more detail the various components of the OAIS business logic, i.e., the processes and functions, as well as the abstract services that support implementation of the business functions. The structure and vocabulary of Figure 1 link all of these reference models into a cohesive whole.

Although OAIS was developed in a different context, under different assumptions, and for different purposes, it provides a useful illustration of the nature and value of reference models included within a service framework for libraries. It maps out the key components of a distinct piece of business logic, independent of actual workflow or technology choice. OAIS has concentrated discussion around a shared view of the digital preservation problem space; it has also been a valuable tool for communicating preservation needs and expectations in a variety of contexts. This in turn has fostered a consistent view, albeit at a very high-level, of preservation services, which in turn facilitates development, collaboration, and third-party service offerings.

V. Related Initiatives

The SFG has reviewed a variety of related initiatives, architectures, reference models, and frameworks, originating from a number of domains. Similarities were evident across these efforts in regard to motivation and perceived benefits, but much less so in regard to formulation. The SFG will continue to follow these and other initiatives complementary to its work. Two initiatives were identified as being particularly relevant to the SFG, and the group has pursued closer coordination with these efforts: the JISC/DEST e-Framework Initiative [4] and the DLF Aquifer Initiative [5].

The e-Framework for Education and Research (the e-Framework) is an initiative by the U.K's Joint Information Systems Committee (JISC) and Australia's Department of Education, Science and Training (DEST). The primary goal is to facilitate technical interoperability within and across education and research through improved strategic planning and implementation processes. In particular, this will mean supporting the technical needs of education and research at the national and institutional levels in a coherent, consistent manner. Five key principles are guiding its development: commitment to a service-oriented approach to system and process integration; development, promotion and adoption of open standards; community involvement in its development; open collaborative development activities; and flexible and incremental deployment. In June 2006 the SURF Foundation from the Netherlands and the New Zealand Ministry of Education joined the initiative [6].

The SFG is currently working with the e-Framework Integrity Working Group to harmonize concepts and vocabularies where possible, in order to communicate more easily across the two projects, and to promote consistency and interoperability between the two frameworks. The SFG and the e-Framework initiative will continue to share expertise going forward, and it is expected that a great deal of valuable cross-pollination will result from this collaboration.

Collaboration with the DLF Aquifer initiative will provide a means for the SFG's work to be tested in an operational environment. The testbed activities in which Aquifer is currently engaged can also help to identify key abstract services and help articulate how they map to specific pieces of a library's business logic. The SFG will continue to engage with Aquifer staff and coordinate activities where appropriate.

VI. Work Plan

Going forward, the SFG will address the following tasks:

1) Define a structure and vocabulary for the service framework
Library planners and developers need a consistent structure and vocabulary for expressing and organizing the reference models that will comprise the service framework. The structure and vocabulary represented in Figure 1 is the group's first attempt to address this task; going forward, the group will refine these concepts, develop additional concepts where needed, and provide detailed examples of their meaning and use. During the course of this work, the group will be conscious of, and seek to harmonize with, terminology from other initiatives where appropriate, in order to promote consistency and interoperability.

Related to this task, the SFG will also craft a more precise definition of a reference model. The term "reference model" is not consistently defined in the literature, so it will be important for the group to state as explicitly as possible what this concept means in the context of the service framework.

2) Decompose several key library areas
The working group will select two or three critical library service areas, formulate them as business requirements, and then decompose these requirements into processes, functions, and abstract services.

3) Formalize these decompositions into a set of reference models
The working group will develop a detailed definition of a reference model to be used in context of the service framework, and with this in hand, formalize the decompositions in (2) above as reference models, expressed and linked using the concepts and vocabulary defined in (1). The reference models will not dictate an architecture or technology choice; instead, they will serve as guides for service-oriented development. As mentioned above, it is not the intention of the group to produce a reference model for every aspect of a library. However, producing a small set of "example" reference models will provide a template to guide future efforts to develop additional models for inclusion in the service framework.

VII. Conclusion

Looking down the road, one can imagine several possible directions in which a service framework for libraries might lead. One possible end point of this work could be a convergence toward process standardization in libraries – in other words, the emergence of widely accepted definitions of certain library processes in terms of scope, functionality, input/output, and so on. These standardized processes would facilitate trusted third-party provision, substitutable systems, communication across internal and external boundaries, consistent performance measures and benchmarks, and interoperability. This end point is some way away: it is first necessary to identify and understand requirements and processes, and to have consistent ways of talking about them. This is the purpose the framework will serve.

Another possible end point of this work is the development of a service-oriented architecture for library systems. We are some way away from this as well; moreover the term "service-oriented architecture" is itself ill-defined and used inconsistently [7]. However, one could imagine a service-oriented architecture for libraries as one that represented the library as a collection of autonomous yet linkable services, deployed and discoverable on the network through Web service technologies.

Libraries are undergoing foundational change, which is at once challenging and rife with opportunity. Coping with these changes in ways that underscore and communicate the value of library services will be a vital task for library planners and system developers. A service framework for libraries will assist them in that task, allowing them to organize and express a consistent view of library services, that will in turn support the development of library systems that are flexible and responsive to the emerging needs of changing research and learning environments.

Acknowledgement

This article was written on behalf of the DLF Service Framework Group, comprising Geneva Henry (DLF Distinguished Fellow; Rice U.), Sayeed Choudhury (Johns Hopkins U.), Lorcan Dempsey (OCLC), Dale Flecker (Harvard U.), Brian Lavoie (OCLC), Krisellen Maloney (Georgetown U.), James Michalko (RLG), Andy Powell (Eduserv), Daniel Rehak (e-Framework for Education and Research; U. of Memphis), David Seaman (DLF), MacKenzie Smith (MIT).

Notes

[1] DLF Services Framework home page. Available at: <http://www.diglib.org/architectures/serviceframe/>.

[2] Dempsey, L. and Lavoie, B., "DLF service framework for digital libraries: a progress report for the DLF Steering Committee." May 2005. Available at: <http://www.diglib.org/architectures/serviceframe/dlfserviceframe1.pdf>.

[3] Consultative Committee for Space Data Systems, Reference Model for an Open Archival Information System (OAIS). CCSDS 650.0-B-1, Blue Book, National Aeronautics and Space Administration, Washington, D.C. January 2002. Available at: <http://public.ccsds.org/publications/archive/650x0b1.pdf>.

[4] e-Framework for Education and Research home page, Available at: <http://www.e-framework.org/>.

[5] Acquifer project, <http://www.diglib.org/aquifer/>. For an update on current progress, see: Kott, K., Dunn, J., Halbert, M., Johnston, L., Milewica, L., and Shreeves, S., "Digital Library Federation (DLF) Aquifer Project." D-Lib Magazine, v.12, no.5, May 2006. Available at: <doi:10.1045/may2006-kott>.

[6] For the full description, see <http://www.e-framework.org/about/>.

[7] For a good introductory treatment of service-oriented architectures, see Erl, T., Service-Oriented Architecture (SOA): Concepts, Technology, and Design. Prentice Hall PTR, Upper Saddle River, NJ, 2005.

Top | Contents
Search | Author Index | Title Index | Back Issues
Previous Article | Next Article
Home | E-mail the Editor

D-Lib Magazine Access Terms and Conditions

doi:10.1045/july2006-lavoie