• Created by Unknown User (escowles@ucsd.edu), last modified on Aug 20, 2014

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

13 Comments

  1. A. Soroka

    1. Unknown User (escowles@ucsd.edu), 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. Andrew Woods

      Raw files are available as attachments to this page:

      https://wiki.duraspace.org/pages/viewpageattachments.action?pageId=61572679&metadataLink=true

      1. A. Soroka

        Thanks, Andrew Woods!

    2. Unknown User (escowles@ucsd.edu)

      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. A. Soroka

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

  2. A. Soroka

    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?

  3. A. Soroka

    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.

  4. Andrew Woods

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

  5. A. Soroka

    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.

  6. A. Soroka

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

  7. Chris Beer

    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. A. Soroka

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

  8. Chris Beer

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

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.