You are here

Block title
Block content

Fedora4 Beta Phase Sprint Ten: Federation; Clustering; Pluggable Framework

Winchester, MA  The Fedora team has concluded the tenth sprint within the "Beta Phase" of Fedora4 development. The work of this and each sprint is planned and completed thanks to the contributions of Fedora stakeholder institutions which allocate developer time. If you would like to be involved with Fedora4 development, please send an email to Andrew Woods, or to If you have comments on the work from this sprint, please also send an email or comment directly on the wiki.

Read the the Sprint B10 summary:

About Sprint 10, Beta Phase

Development Team

Frank Asseg - FIZ Karlsruhe

Adam Soroka - University of Virginia

Sprint themes

1) Federation

One of the Fedora 4 features that holds significant potential for addressing several use cases, including "large files", "managed external datastreams", and a variety of other scenarios where content already exists in a backend storage system, is Federation [1] (aka Projection). This sprint enhanced the "file system federation" connector to act on federated content in a manner more similar to how direct repository assets are managed. Specifically, the ability to add/update/delete properties on federated resources was added. Additionally, the ability to perform the repository's native fixity checks over federated content was implemented.

2) Clustering

Clustering of Fedora 4 in support of horizontal application scalability, geographic distribution, high availability, etc. is one of the driving motivations for the architectural shift from Fedora 3. This sprint continued the effort of determining a clustering configuration that can demonstrate increased ingest performance over a single-server installation. Initial configurations towards this goal have been documented in the wiki [2]. The capability will continue to receive development attention.

3) Pluggable Framework

Some features add value by lowering the bar to entry for new developers as well as by simplifying the process of integrating new functionality. Additionally, basic architectural foundations are almost always easier to establish earlier in an application's evolution than later. Investigations were made in this sprint towards an architecture that enables development of new features without requiring a developer to understand/build the entire codebase. Additionally, these investigations lead to the ability to deploy/undeploy functional modules at runtime.

4) House-Keeping

As with previous and future sprints, on-going improvements were made to the codebase and supporting documentation.

• External triplestores now completely remove related triples on a "resource delete" event
• Kernel interfaces factored out of implementation classes
• Build artifact names updated for readability