Enable Goobi-API and framework for drop-in extensions

Registered by Ralf Claussnitzer

This blueprint has been superseded. See the newer blueprint "Message Queuing Interface for Step Control" for updated plans.

Goobi-API calls external services via XMLRPC. The concept should be further modularized and extended to support downloadable plug-in packages. For example: One might extend the workflow with additional tasks or redefine whole components.

Enabling drop-in extensions would require restarting the application.

Blueprint information

Ralf Claussnitzer
Needs approval
Series goal:
Milestone target:
Completed by
Ralf Claussnitzer

Related branches



The actual XML-RPC implementation is based on an outdated concept and has to be replaced. By now, I have been told it's being used by the Zeutschel tool chain, so we might want to support it for some time.
[Can anyone from Zeutschel confirm this to have it documented here?]

We are using the current XML-RPC implementation for an interface to our scan-software to offer meta and structur data creation during the scanning. That works great with the current implementation, but we are sure there should be something more in the future. Either by extending the Goobi module API (e.g SOAP) or creating something new.
--- Frank-Ulrich Weber

Implementing a new plug-in system based on a popular framework is a great idea. Any suggestions what framework to use?

First, an approach to modularization should create functional boundaries in the existing code. Afterwards individual functionality may be externalized:

1 Identify groups of functionality within the application
2 Isolate those functional groups using interfaces
3 Distribute functional groups to isolated layers
4 Externalize selected functional groups into plug-ins

Adding functionality without restarting the application is not a goal, as it is not supported by most of current servlet containers at all.

--- Ralf Claußnitzer

From my point of view this is clearly the wrong way. There is no real life XML-RPC module out there. It is a theoretical concept that had no focus on daily use cases. The modification of this module API is lost of time, as it is way to complicated and offers only limited flexibility.

At intranda we prefer the idea of implementing a complete new plugin system. There are existing multiple frameworks for this, that could be used.

What is your use case for this modularisation? Which parts should be excluded from the core at first?

BTW: I do not know any Goobi customer that really needs adding new modules without restarting the application. This should not be the priority. Nevertheless our concept it would allow adding and removing at runtime without restarting the application.

Steffen Hankiewicz, intranda

Extending the module manager to support some other kind of web service protocol specification − such as SOAP − seems useful. Which framework do you favour?
Matthias Ronge, Zeutschel

I examindes several concepts to extend Goobi.Production. Implementing a fully generic plug-in interface, as e.g. Typo3 has one, seems unreal to me. It would be necessary for the plugin to be able to intervent in any code sequence. I have no idea how this could be realised.

The more interesting question seems to be how to allow certain changes being made form outside Goobi.Production.

Candidates for for such changes are any features which actually require access to the database, the file system or both, such as:
→ creating new processes
→ marking a step as being finished or abortive
→ adding tiff images/structural metadata/...
→ deleting processes after a successful save
→ ...

I would like to propose Apache ActiveMQ, a Java Messaging Service implementation as method of choice. It can be pictured as some kind of post office where Goobi.Production picks up jobs from a mailbox (technical term: queue) and reports the results to a message board (technical term: topic).

An example is added to the blueprint http://blueprints.launchpad.net/goobi-production/+spec/web-service-interface-to-create-processes
Matthias Ronge, Zeutschel, 04.05.2012


Work Items

This blueprint contains Public information 
Everyone can see this information.