1. 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

2. 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 Key Fedora 3.0 offerings

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