1 University of California California Digital Library The Costs of Containment: Frameworks and the...
Embed Size (px)
Transcript of 1 University of California California Digital Library The Costs of Containment: Frameworks and the...
- Slide 1
Slide 2 1 University of California California Digital Library The Costs of Containment: Frameworks and the Web Peter Brantley BL l London l 2006 Slide 3 2 Huh? What the heck? Outline: 1.SoA as accommodation to a changed world 2.CDL's Common Framework as example of SoA 3.Some pitfalls with SoA found in practice 4.Wriggling out of new straightjackets Slide 4 3 Transformations Its not about libraries any more: Scholarly work and communication are being transformed by new innovations and practices. Users seek not just content, but the ability to create and annotate, and a way to contribute within their own community. The optimum place for social software in IR domains is undiscovered, but of great interest. Slide 5 4 MySpace Slide 6 5 YouTube Slide 7 6 Social apps popular With nearly 60 million registered users, 15 billion page views per month, and more than 150,000 new users signing up every day, MySpace is that rare social networking contagion that keeps spreading and growing. Robert Young, in Om Maliks Blog, 26 Feb 2006 Slide 8 7 YouTube as a model YouTube has captured the hearts and minds of the people as the place they go to post videos and find videos. Content owners should pay attention to what consumers want to do with their content and find ways to satisfy these desires that can fit into a business model. Fred Wilson, in A VC, 20 Feb 2006 Slide 9 8 Where in the Market? Slide 10 9 CDL Common Framework The CDL is building an open, services oriented technical architecture that we call the Common Framework (CF). The CF provides an integration framework for DL services And supports the integration of local and third- party tools/services via plug-in functions. Slide 11 10 Services are layered The CF is a layered architecture, separating: Front-end tools from Back-end services from Underlying data storage. The CF presents itself via both machine interfaces (web services through SOAP & Java APIs) and human interfaces (command line & browser tools). Slide 12 11 CF in Flavors The CF supports several DL data models: Archival (objects stored locally) Metadata only (MD stored locally) Portal (no data stored locally) Examples: UC Digital Preservation Repository (Archival) American West (MD only) MetaSearch Infrastructure (Portal) Slide 13 12 Bundle of Concepts The CF: Is a philosophy governing software development A conceptual design for services A specific technical architecture A set of on the wire services A growing number of applications Slide 14 13 CF: Philosophy Composite, modular, lightweight are good. Design and implement services quickly. Reduce the need for application specific tweaking, twiddling. Make replacement and enhancement easy. Integration trumps re-invention. Slide 15 14 CF: Design Applications are independent of services. Design atomic services to enable the easy construction or rebuilding of applications. New application reuse existing services (or minor mods). Build for scale. Slide 16 15 CF: Schematic Slide 17 16 CF: Services > Apps Slide 18 17 CF: Defined Services CF Services: Available now - Ingest, Indexing, Access, Admin and Account mgmt. In development - Search and Browse, Harvest and Capture, Rights mgmt, Collection mgmt, and MetaSearch Slide 19 18 CF: Plug-Ins Local - NOID (Nice Opaque IDentifier, for the generation of ARK persistent identifiers) XTF (eXtensible Text Framework, for text indexing, searching, and browsing) Metadata Normalization and Enrichment (currently, primarily Date normalization) Slide 20 19 CF: Ext Plug-Ins Third-Party - JHOVE (for validation and technical MD) SRB (for archival storage of bitstreams) MySQL (for MD and admin data storage) Heritrix (for web crawling) Ex-Libris MetaLib (for metasearch) Slide 21 20 There be dragons! Slide 22 21 No Greenfields Our SoA did not arise on a empty prairie. Existing applications and services must be rebuilt, or integrated through abstractions. Impacts on service delivery: Should we implement with old tech immediately, or wait for the new Framework version? Planning costs are (sometimes very) high. Slide 23 22 It takes a while Slide 24 23 SoA drawbacks SoA implementations are thorny roses: SoA internalizes enterprise sware dev. Development focuses on specification. Project interdependency can lead to resource contention and gridlocks. Technical barrier for software re-sellers is high and usually must be arbitrated. Slide 25 24 Building for whom? CDL is struggling to define acceptable support commitments for various CF bundled services. Internally: how much do we encourage distributed adoption vs. our current centralized hosted model? Externally: how much support do we provide within an OSS environment? How much interoperation do we bake-in, both among CF installs and with foreign services? Slide 26 25 We are not alone *.edu is not the only service provider for the academic community any more. Silicon Valley is busy building services for everyone - who are DLs building for? Insular frameworks are inexcusable. We work in a services ecosystem. Slide 27 26 Virtual architecture Hypothetical BL Google-PAC: Indexes BLs local library catalog, and a UK OpenCourseWare site and IRs Stores metadata structures in Google Base Integrates with Google Books and the OCA Links to journals in Google Scholar via SFX Queries OCLC WorldCat for branch locations.... Its possible now. Slide 28 27 Rapid dev on foot Integration is fast; SoA development is not. Difficult (although not impossible) to rapidly prototype within SoA architectures. Pace of new feature accretion in SoA must be inherently slower than silo app development. New SoA srvcs require staff/resource coord. SoA is like building a CBD, vs. Quonset huts. Slide 29 28 The Lessons for CDL Work hard at defining the Framework core, but leave it a bit porous at the boundary. Push on the edge with rapid dev, internal to the CF when possible, external when not. When prototyping is possible: Throw the first one away and then integrate into CF. Loosely-couple external services. Slide 30 29 Fast dev example CDL Re lvyl Recommender system - A Mellon-funded project to explore relevance ranking and recommending for library OPAC. Built on top of XTF-standalone (no CF). XML files-based system created through a merge of multiple source extracts. New features added to XTF for extra crunchy relevance and recommending goodness. Slide 31 30 Re lvyl search Slide 32 31 Results by Relevance Slide 33 32 Recommended Results Slide 34 33 Framework accretion Re lvyl is designed to be calved off as a separate set of services, i.e., ranking and recommending. Easy to incorporate into the Common Framework. Could work with a range of backend data inputs, or be integrated into external applications. SoA allows us to scope narrowly at first (biblio. services) and then expand utilization over time. Slide 35 34 An integrative service Hypothetical service : Take Google Book Search, and add Re lvyl- type recommendations. All Google Book Search users get expert (i.e., research university) recommendations. If authenticated as a UC user, could get extra toppings, such as inline pointers to catalog records for recommended items, maybe via SFX linking. Slide 36 35 Future for services Polygamous recombination may be the most likely future for library services. Be open to integration with diverse actors, both.ac/.edu and among.com information and service providers. Portal to info services can be anywhere. Libraries: The Data of Choice.