1 / 14

Key Fedora 3.0 offerings

Key Fedora 3.0 offerings. JMS messaging service All write-only Fedora operations are published to subscribed clients Messaging system can be durable – if client/consumer/subscriber fails, messaging server will queue messages. JMS server is pre-packaged with Fedora

antoniob
Download Presentation

Key Fedora 3.0 offerings

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Key Fedora 3.0 offerings • JMS messaging service • All write-only Fedora operations are published to subscribed clients • Messaging system can be durable – if client/consumer/subscriber fails, messaging server will queue messages. • JMS server is pre-packaged with Fedora • Fedora may be configured to use external JMS server, and function as a client itself

  2. Key Fedora 3.0 offerings • CMA (Content Model Architecture)‏ • Users may define their own content models • Define structure of objects in the model • Enumerate all service interfaces available on all objects • One object may have multiple models • Adding/removing service interfaces to entire classes of objects is easy • Current repository uses only one service interface, for Metadata • Easy to deploy incremental changes at will in Fedora 3.0. Very hard in 2.2.x

  3. Moving to Fedora 3.0 • Three levels of Fedora 3.0 adoption. Done incrementally, each level brings in certain costs/benefits • Simple Fedora 3.0 migration • Gives us CMA and messaging for tying in services • CMA modeling with read-only service interfaces • Gives us partial consistency between Fedora & NDR API • CMA modelling with fully read/write service interfaces • Full consistency between API and Fedora • Many new modes of interaction with repository

  4. (1) Simple Fedora 3.0 migration • What does this entail? • Minimum set of changes required to upgrade to Fedora 3.0 • FOXML format change • Automated process – minimum changes required to function under Fedora 3.0 • Rebuild object registry, triplestore • While this is happening, Freeze changes to production repository • Estimated 3 days to completion. • No changes to NDR API

  5. (1) Simple Fedora 3.0 migration • What can this enable? • via Messaging • Replace expensive polling by OAI service • Real-time updates of Search index • Transitive relationship service (Mr. Hierarchy)‏ • Prerequisite to initial proposal for blacklisting/de-accessioning resources from the library • via CMA • Reduce complexity of current middleware

  6. (1) Simple Fedora 3.0 migration • Work involved • Minor updates to repository middleware (removing code!)‏ • Configure & deploy new fedora-3.0-aware OAIprovider service • FOXML upgrade process • Enable Fedora's internal messaging service • Can be run externally in future if needed • Misc. clean up of existing data • Purge de-accessioned collections?

  7. (2) CMA + read-only services • What does this entail? • Representing core object types (Resource, Aggregator, etc) as Fedora Service definitions (i.e. interfaces)‏ • Representing higher order concepts (such as collections) as Fedora service definitions • Splitting middleware into API and Business Logic web applications. B.L. Application will provide implementation for these services. • Possible additions to NDR API • Service interfaces are not currently part of NDR API

  8. (2) CMA + read-only services • A brief example... • NCore:Object (Service definition)‏ • Relationships (service)‏ • All relationships in the object • Properties (service)‏ • All object properties • Datastreams (service)‏ • All datastreams in the object • Ancestors (service)‏ • All ancestors of the object (implementation provided by transitive relationsship service, Mr. Hierarchy)‏

  9. (2) CMA + read-only services • NCore:Resource (Service Definition)‏ • Content (Service)‏ • Fetches the resource content (or redirects to it)‏ • Metadata (Service)‏ • Retrieves all metadata describing the resource • Format given as an argument • Ncore:Native-Resource-1 (Content Model)‏ • Has services NCore:Resource, Ncore:Object • Enumerates required datastreams in resource data objects

  10. (2) CMA + read-only services • What can this enable? • Search indexes directly off NDR instead of through OAI* • Makes it possible to distribute Ncore models + business logic application in a nice package • Better interoperability with Fedora-aware applications • Consistency. Instead of applications drawing (different) conclusions from raw data, they read what they need from the appropriate service.

  11. (2) CMA + read-only services • Work involved • Refactor middleware into separate API and Logic components • Create Service Deployment objects connecting Service Definitions (interfaces) with appropriate implementation in logic engine. • Create toolkit driver that takes advantages of these interfaces • Decide how/if to integrate services into existing API.

  12. (3) CMA + Read/Write services • What does this entail? • Using services to write to the repository. • This functionality does not currently exist within Fedora • Explore the possibility of exposing Fedora to the outside world • Slightl paradigm shift. • Lots of theoretical issues explored. This would represent a major change in thinking in Fedora design

  13. (3) CMA + Read/Write services • What can this enable? • Allowing full interaction with the repository without the API/Middleware • Service interfaces exist as resources on the web • Allow standards-based or RESTFul interaction with services, instead of Fedora or NDR APIs. • Ex. Atom Publishing Protocol to control the membership of a collection • Adding functionality to Fedora, the API, or the Client can be made lightweight and modular.

  14. (3) CMA + Read/Write services • Work involved • Major changes to Fedora codebase to allow read/write services • Consensus building among interested Fedora community members • e.g Ross Wayland, Matt Zumwalt • Re-evaluate current engineering practices

More Related