140 likes | 155 Views
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
E N D
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
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
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
(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
(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
(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?
(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
(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)
(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
(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.
(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.
(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
(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.
(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