Lifecycle Hooks

Lifecycle Hooks

The DSpace 3-5 year vision document provides good fodder for mds innovation and experimentation, since it is a considered reflection on existing limitations and hopes for future functionality. It embraces the idea of a comparatively small core, that provides extension points (plug-ins, add-ons, etc) to grow functionality.

DSpace/mds today has a few extension mechanisms, but more work in this area is needed. A quick survey:

Event System

This defines an interface (basically the event 'consumer') whereby code can be defined to receive content model events. The system can wire these consumers to families of events (e.g. all item creation events), so they can do work that logically is required by content model changes. This is how, e.g. search and browse indexes are maintained. The event system thus provides some degree of modularity, since one can simply unwire consumers that aren't desired.

But there are some significant limitations in event consumer behavior: foremost is the requirement that consumers cannot themselves make any content model changes. This is done to avoid circularity: if event consumers generate events, then they effectively can create infinite loops. There are other reasons having to do with transaction scope, but the gist is that event handling should react to content changes, not cause them.

Curation Framework

Curation tasks are 'add-ons' that can cause content model changes. They thus represent a complementary set of duties: a task could cause an content event that a consumer could react to. But tasks also have their own limitations: while they can be wired to specific points in an object's lifecycle (e.g. in workflow steps), in general they life outside the object lifecycle.

Lifecycle Hooks

This analysis suggests a need for a different sort of extension point that combines the tight coupling of events to the object lifecycle, with the full updating (content model changeability) of objects. Roughly and intuitively, we want a way to attach optional behavior to the regular lifecycle. And by optional, we mean that we should not be required to to fork the DSpace API code to accomplish it. Are there any good examples of this sort of functionality in DSpace today? One that springs to mind is embargo, where clearly we need to have the content restriction applied within the lifecycle, but it is a completely optional behavior. Depending on the repository, there may be no need whatsoever for embargo.

A First Stab

mds has defined a new facility for lifecycle hooks, and the first implementation of said facility is embargo. That is, embargo has been removed from the kernel, but is available in a separate, optional module, which when installed in an instance will integrate embargo into the lifecycle actions. The programming model is very simple: to define a lifecycle handler (which means that it will be called whenever an object undergoes a lifecycle transition), one only needs to expose one annotated public method in a POJO:

class MyHandler {
    @Subscribe
    public void handleStuff(LifecycleEvent event) {
        ....your logic here
    }
 }

The code in the handler method (and any changes it makes to the object or other objets) is guaranteed to execute in the same transaction that the lifecycle change occurs in: i.e. they will succeed or fail together. See the EmbargoHandler for a sample implementation.

Further Work

The notion of DSpace Object lifecycle, is important, but not rigorously defined or enforced in the current codebase. There are a few well-defined points however, such as item installation (when an item exits workflow), and indeed the embargo lifecycle hook operates at exactly that point. But we are left to codify most of the others.