firstly, apologies for mailing this - I haven't sorted myself out with
some publically available web space here yet.
Attached is a bunch of code I wrote after discussions (archived on the
wiki) with Mike about modular architecture. If you've got maven, you can
just 'maven test' to see it in action. What it covers: -
* Services defined as interfaces. No special requirements / inheritance
on the interfaces (this may have to change, for example if we need
service lifecycle control)
* Modules implement one or more interfaces. No special requirements /
inheritance on the modules. The sample test classes I've written use an
implementation that requires a certain form of constructor, but that's
the only restriction.
* Clients get Service implementations from a Manager class. The manager
actually returns proxy objects which implement something similar to the
Chain of Responsibility pattern, such that all the modules that
implement a particular service get a pop at it. The modules don't have
any knowledge that they're being used in a chain.
* Dependency Injection. Module writers don't have to know about any
particular method of finding service implementations, they just state
their requirements in terms of other services and the Manager satisfies
What it doesn't cover: -
* What any of the actual services should be
* Having two tiers of service: - Service (called by users / UIs) and
Plumbing (called by Service implementors)
(http://wiki.dspace.org/index.php/DSpaceIrc_2004_04_28). This is quite
possibly just a case of having a Manager for each tier and controlling
the PlumbingManager's visibility.
* Chains in which only one module handles a service request. I keep
going around in circles with this one. It would be desirable for the
module not to have to deal with anything framework specific (e.g. a
custom Exception class) in order to indicate that it had or hadn't been
able to handle a service request, but this might not be possible to
* Circular Dependency trapping. There are a few approaches that would
solve this, but I don't think implementing any of them would be
There are two files in src/test/espace/ that demonstrate client usage.
The java configuration classes in SampleTest.java are just for
expediency, the scope to write an xml config parser exists. The
ModuleChainTest.groovy file was just me playing around with the idea of
scripting language based config files instead of xml.
Comments appreciated to stop me contracting Happy Idiot Programmer
PS I only chose the name so I could keep dspace and Mike's nspace and
this code open in eclipse at the same time...