Note | ||
---|---|---|
| ||
Under construction, please come back soon! |
JMS-based messaging for the Fedora Commons repository which is based on sending messages notifying consumers that content items within a Fedora Repository have been modified, identifying with URIs the item that has changed and the location of the modified content.
Important Note: This is pre-alpha code published to encourage discussion on this topic to work towards a consensual agreement on a generic messaging and Fedora implementation pattern suitable for all kinds of potential consumers of Fedora messages. Particularly see the list of known issues.
Fedora includes JMS-based messaging capabilities. Messages are dispatched on every Fedora API-M method invocation, and contain details of the method name and parameters. Messages are therefore closely coupled to Fedora's API-M.
There exists a class of potential consumers of Fedora messages with responsibilities for indexing or otherwise manipulating and persisting the content within Fedora. These clients in general are interested in knowing when content within Fedora changes, and what those changes are.
These consumers currently have to "decode" the API-M messages received via JMS to identify what the message means to them in terms of modifications to the content within Fedora.
Hence Fedora Content Change Messaging. The messages are designed to be deliberately agnostic to Fedora's API, and instead represent, using a generic message format (encapsulated within AtomPub), additions, deletions and modifications to content within Fedora; identifying the item using an HTTP URI, and providing a "callback" HTTP URI from which the new or modified content can be accessed.
The source code is hosted on Github. See the README file for instructions on installing and using.
Consumers of messages can make use of the following classes:
net.acuityunlimited.fedora.messaging.AtomContentChangeMessage
which can be used to deserialize the AtomPub message to net.acuityunlimited.gen.messaging.ContentObjectModification
.
This is a module that utilises Fedora's decorator pattern, in the same way as the current JMS messaging module. It can either be used alongside the existing messaging plug-in, or as an alternative to it.
API-M methods are handed off to an implementation of org.fcrepo.server.management.Management
which constructs the appropriate message, and then passes the method down the decorator chain.
(In the future other architectural patterns might be considered, eg there may be more appropriate places to hook in notification with High-Level Storage.)
A message represents a concurrent set of changes to a Fedora digital object. Changes may be either modifications of content (create, update, delete) or modifications of state.
In essence it encapsulates one or more datastream updates and/or state changes for a single object, corresponding to a single API-M method invocation.
For example, for an ingest operation, it represents a set of Add operations for each datastream created on ingest; for a modifyDatastream operation it represents an Update for the datastream if the API-M method parameters include updated content.
Messages are only dispatched for modifications to the latest versions of datastreams; it is assumed that consumers are only interested in the current, and not historic, versions of content.
A ContentObjectModification is used to encapsulate a set of ContentItemModifications
A ContentObjectModification represents:
Each ContentItemModification represents:
Wiki Markup |
---|
The state change of the datastream, specifying the previous and new states \[1\] |
Wiki Markup |
---|
\[1\] So the consumer of the messages doesn't have to track the state of individual items but can for instance remove an item from an index if the state has changed from Active to Deleted or Inactive, but can ignore a state change from Inactive to Deleted (but see Issues on modelling state) |
The above are represented as:
ContentObjectModification
implements Iterable\<ContentItemModification\>