Page tree
Skip to end of metadata
Go to start of metadata

Architecture Diagram

The following diagram shows the primary components that make up Fedora 4, and how they interact with each other and with external clients such as the Java client currently being developed, or a Hydra application.

Pluggable Components

  • Authentication: authenticating requests is typically handled by the servlet container running the Fedora 4 webapp, and can usually be configured to support a wide range of authentication types.
  • Authorization: there are currently modules for role-based authorization and XACML authorization, and custom authorization modules can be created to support other authorization types. 
  • PID Minter: there are currently PID minter modules that generate random UUID identifiers, or retrieve PIDs from an external web service, and custom PID minter modules can be created for other PID minting scenarios.
  • Sequencers: the Modeshape API allows creating sequencers which are tightly-coupled asynchronous modules which can be configured to automatically process new and updated content.
  • LevelDB: the default configuration uses LevelDB storage, but Infinispan supports several other storage mechanisms.
  • Other Connectors (Git, Cloud, etc.): Modeshape supports a few other storage options with connector implementations, which could be extended to support Fedora 4.  Custom connectors could also be developed to support other storage systems.
  • Custom Message Consumer: the messaging system currently has modules for Solr and Elasticsearch indexing, triplestore synchronization using SPARQL Update, and serializing JRC/XML to disk.  Custom modules can be created to support syncing with other systems, or performing a broader array of tasks such as format migration or fixity monitoring.
  • No labels


    1. Unknown User (, can we get a raw file for this diagram posted here, for further emendation? Thanks!
    2. It would be worth getting the auth machinery added here, perhaps on a "zoom-in" subdiagram. For some use cases, access/management policies are a crucial part of durability/preservation.


    1. Raw files are available as attachments to this page:
    2. Unknown User (

      A. Soroka: good points all around.  For this diagram, would it be enough to just have another block on top of the REST API called "Access Control (optional)"?  Then somebody who knows how the access control works can create a second diagram of it?

      1. Sure-- that's a good way to "set a bit" for it. Maybe Greg Jansen is the person to put details into it?

  1. It would be good to start noting where components are reasonably "pluggable" now (e.g. LevelDB) and where they are not (e.g. ModeShape). Perhaps with some simple coloring?

  2. For public consumption, I think we need to diagram the architecture sans Hydra. It would be good to have "Fedora-with-Hydra" diagrams available, for exposition, but showing Hydra alongside the basic architecture is going to confuse people.

  3. The "Access Control" box should likely be split into two:

    • "Authentication" above the REST-API
    • "Authorization" below the REST-API, as the underlying JCR machinery is what manages the authorization flow (i.e. authorization logic is in affect when calling Fedora objects directly).
  4. Perhaps we should break out a "Connectors" box (pluggable) to include "Filesystem Connector"? There are other connectors and could be more of them, and that might be of interest to folks.

  5. Should we notate the REST API as being an HTTP API that subsumes LDP?

  6. From TWG 8/20:


    Indexer API: is it a generic mechanism, or tied specifically to indexing? It could be made generic, but depends on additional implementations.

    Rename indexer box to e.g. “message consumer” to indicate the concept has broader applicability?

    1. If we renamed the Indexer, we should rename packages and classes in the code to remove the many mentions of "indexing".

  7. Distinguish between core vs pluggable components to show the decoupled model.