...

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:changes="http://www.acuityunlimited.net/fedora/messaging#">
  <category term="3.5-SNAPSHOT" scheme="info:fedora/fedora-system:def/view#version"></category>
  <category term="http://www.acuityunlimited.net/fedora/messaging#content-change-message-0.1" scheme="http://www.fedora.info/definitions/1/0/types/formatURI"></category>
  <author>
    <name>fedoraAdmin</name>
  </author>
  <title type="text">purgeObject</title>
  <updated>2011-08-03T08:21:32.169Z</updated>
  <link rel="via" href="http://localhost:8080/fedora/objects/demo:SmileyBeerGlass"></link>
  <id>urn:uuid:9733fc70-67e0-49ef-aa2b-e8d9c95a5db7</id>
  <entry>
    <author>
      <name>fedoraAdmin</name>
    </author>
    <id>urn:uuid:2d769c36-baba-47be-8716-524a58542063</id>
    <title type="text">purgeObject</title>
    <updated>2011-08-03T08:21:32.169Z</updated>
    <link rel="via" href="http://localhost:8080/fedora/objects/demo:SmileyBeerGlass/datastreams/DC/content"></link>
    <summary type="text">Datastream modification/state change, see content src for new content</summary>
    <category scheme="changes:ITEM:CHANGE:TYPE" term="DELETE">Fedora datastream modification type</category>
  </entry>
  <entry>
    <author>
      <name>fedoraAdmin</name>
    </author>
    <id>urn:uuid:4164cd78-1fa3-4292-bf7c-47f62bb672b7</id>
    <title type="text">purgeObject</title>
    <updated>2011-08-03T08:21:32.169Z</updated>
    <link rel="via" href="http://localhost:8080/fedora/objects/demo:SmileyBeerGlass/datastreams/RELS-EXT/content"></link>
    <summary type="text">Datastream modification/state change, see content src for new content</summary>
    <category scheme="changes:ITEM:CHANGE:TYPE" term="DELETE">Fedora datastream modification type</category>
  </entry>
  <entry>
    <author>
      <name>fedoraAdmin</name>
    </author>
    <id>urn:uuid:796c0612-171f-46ad-bcb7-e2a9a6166ae7</id>
    <title type="text">purgeObject</title>
    <updated>2011-08-03T08:21:32.169Z</updated>
    <link rel="via" href="http://localhost:8080/fedora/objects/demo:SmileyBeerGlass/datastreams/MEDIUM_SIZE/content"></link>
    <summary type="text">Datastream modification/state change, see content src for new content</summary>
    <category scheme="changes:ITEM:CHANGE:TYPE" term="DELETE">Fedora datastream modification type</category>
  </entry>
  <entry>
    <author>
      <name>fedoraAdmin</name>
    </author>
    <id>urn:uuid:64571aac-58cc-47d2-a9b6-3bf0ac870101</id>
    <title type="text">purgeObject</title>
    <updated>2011-08-03T08:21:32.169Z</updated>
    <link rel="via" href="http://localhost:8080/fedora/objects/demo:SmileyBeerGlass/datastreams/FULL_SIZE/content"></link>
    <summary type="text">Datastream modification/state change, see content src for new content</summary>
    <category scheme="changes:ITEM:CHANGE:TYPE" term="DELETE">Fedora datastream modification type</category>
  </entry>
</feed>

...

Issues

The initial implementation is based on the basic principle of sending messages that are not tightly-coupled to Fedora's API, but are a more generic representation of notifying consumers of changes of content within Fedora. The initial implementation is scoped only to provide notifications of datastream state and content changes.

Packaging

• Build separate jars for server and common classes - to enable message consumers to use the deserialisation classes without including the server integration components

Content models, object types

• A placeholder has been included to transmit the "type" of object, as the consumer may wish to make decisions based on this (eg indexing only certain categories of objects)
  • How to identify the "type" - eg URIs corresponding to the subscribed content models?
  • Or should this be something configurable, eg ability to send dc:type?
  • Should this be something configurable via the CMA?
  • Should we send the type in the message, or provide a callback for the typing information?

Message selecting/filtering

• No JMS messages properties are currently set, so no selecting/filtering is possible
  • Potentially add a new method to the Fedora messaging module to provide a set of JMS message properties; or extend the FedoraMessage base class to include these and provide an implementation for the Content change message (and modify the existing API-M message in line with this)
• No message property appears to be set for the overall type/format of the message (FedoraMessage includes getFormat(), but this is currently unused
  • Set a JMS message property to identify the overall type of message (so appropriate deserialiser can be used eg for API-M messages vs content change messages)

Data model

• Does not currently include object and datastream properties
  • Could we have a generic representation of these that isn't coupled to Fedora's representation?
  • Do we model this as a content change (so with its own content item identifier - which doesn't currently correspond to anything in the Fedora REST API) or have a separate notion of properties?
  • Do we provide a callback URL for a property change/set of property changes, or send the properties in the message?
    • The REST API doesn't have generic "properties" endpoints - but these could be added
    • There are endpoints eg for datastream profile and object profile, but these are Fedora-specific; should we treat these as content items in their own right (though I believe these don't cover every object/datastream property)?
• State changes
  • Currently only datastream state changes are sent.
  • The "meaning" of object and datastream states is implementation-dependent, Fedora doesn't define the meaning of these
  • Do we combine object and datastream states to give an overall state for the content item? (eg, object=deleted and datastream=active -> content item deleted; object=active and datastream=deleted -> content item deleted)
  • Or should this be configurable in the server plug-in?
  • Or treat the states as generic object/datastream properties, and let the consumer decide? (and remove state changes from the model)

Content Model Architecture integration

• What's the potential for this; eg using the CMA to specify what messages get sent?
• Compound and atomistic models
  • Currently a placeholder is included for the "parent" object, notionally this would be the "main" object in an atomistic model, so for instance indexing could identify the "main" object when indexing datastreams in "child" objects
  • This implies some knowledge of content models by the consumer. Should instead the CMA be used to "hide" this and provide an abstraction of objects for consumer that isn't coupled to the base Fedora object model?

Relationships and the resource index

• Fedora constructs additional relationships (outside of RELS-EXT etc), currently defined in code, eg relationships betweeen objects and datastreams
• How to notify a consumer of these? Do we need to?
  • eg a consumer that wants to maintain a "semantic index" of both Fedora's current RI and additional RDF datastreams

Initial population of indexes etc

• For a repository that is already populated, how do we transmit the already-existing content tothe consumer (and how do we rebuild indices from scratch); ie some kind of "rebuilder"

Identifiers for objects, items, and location of content

• HTTP REST API endpoints are used as object and datastream identifiers - should we instead use the info:fedora/ URI scheme? Or ...
• Content location identifiers are REST API endpoints for datastream versions - should this be configurable, eg if Fedora is not directly exposed but there is a local application API that provides alternative endpoints for serving content?

Integration patterns - Fedora receiving messages

• Potentially a message consumer could be implemented to receive content change messages; these could be translated into Fedora API methods. This could be useful in workflow, eg a service that listens for image datastream changes and creates thumbnails based on these.
• Could a synchronous pattern be implemented (would it be useful), eg a Fedora API operation doesn't finish until the message consumer has also finished.

Miscellaneous

• Fedora's fcfg specifies in the datastore configuration, a "messageTypes" parameter. This currently must be either or both of apimUpdate and apimAccess, and cannot be blank or omitted. The implication of this is that a datastore configured for content change messages will also receive these messages. See FCREPO-958.