GX WebManager’s WCB Dependency Management

March 1, 2009 – 1:54 pm

It’s been far too long since I posted on here, so after an upgrade to WP 2.7 (or something), here’s a new post. The title may be a tad confusing, so I’ll try to explain that (and the abbreviations) first now.

I’m currently doing a 20-week internship at Oberon Interactive, a largely web-oriented company that does webdesign, online campaigns, that kinda stuff, all from their HQ in Amsterdam. It’s got about 12 or so employees (including myself), but I’m not sure yet because there’s almost always someone missing. On there, I’ve been assigned with the task of making development of WCB’s easier.

Before I throw in more TLA’s though, I’ll explain what I’m working with. I’m working with a pretty extensive enterprise content management system called WebManager, made by Dutch company GX. Since WebManager is the only piece of software GX seems to be developing, I’ll probably often confuse WebManager with GX and vice-versa, so if I use GX in reference to an item, I mean WebManager.

Anyways, since version 9 (I believe) of WebManager, GX has added the ability for developers to add functionality to WebManager through a plug-in-like system. This functionality is packaged in bundles called WebManager Content Bundles, aka WCB’s. These WCB’s are basically OSGi modules, built on top of Apache Felix, an implementation of OSGi’s service platform.

Now, Oberon has received at least one assignment from a large Dutch football site (i.e. the football type with the round ball, not the oblong one) that, at least for now, involves creating two of these WCB’s to be included into their site. The visible bit of a WCB can easily be inserted into existing WebManager pages through WebManager’s Edit Environment, a back-end that looks an awful lot like Microsoft Word.

Anyways, I’m working with that currently, and my primary internship assignment is to make WCB development a lot easier, reliable, and faster. There’s several aspects of WCB development that have to be improved, as I’ve discovered / determined for myself so far, and this article is about one of them: Dependency management. I’m sure I’ll be writing more posts during my internship on a range of (WCB development) related subjects, so be sure to hang around.

For this first installment, I’ve taken a closer look on how the WCB API’s handle dependency management, also comparing it with other, more formalized approaches. I’ve put the report into a neat, 10-page Word document, which I’ll link to below. Here’s a summary though, and you’re going to have to visit the internets to figure the terms I use out or read the .doc itself in order to find out what is what.

A WCB is built out of separate Components, like a Form, an Element, a Servlet, etc. Each Component has one central class of sorts that is initialized by some obscure part of WebManager, i.e. out of the programmer’s control. In order to be able to use, for example, the Authorization Service, with which you can check access permissions for users for a certain access, you have to pass a string value containing the class name of said Authorization Service to a new instance of a ServiceDependency object, then pass that to a ComponentDefinition object which is passed back to WebManager when your WCB is installed / initialized.

There’s loads of problems with this approach:

* No typesafe checking, so you’ll only see if you’ve entered the wrong classname at runtime (whilst one could pass a Class object, much more typesafe).

* It’s hard to get to the central object to get the service(s), you either have to call a getComponent() method from the controller class and cast that into the specific class, or implement the class as a singleton.

* No control over the dependencies’ lifecycle - you can only pass the class you’d like to initialize to WebManager, can’t pass any parameters or whatever.

* You can only inject services into that one Component object.

* Injection is (usually) done using reflection on a class’s private fields, obliterating the meaning of the ‘private’ keyword, and preventing the usage of setter methods (and additional behaviour one could associate with that).

All in all, they do use the term ‘dependency injection’ a few times in their official documentation, but in practice all you do is pass the names of the classes you’d like to have created, have WebManager inject those into an object that acts as a hard-to-access Service Locator, and be done with it. The Service Locator isn’t a bad choice per sé, but since the dependencies contained in the SL are injected somewhere at runtime, after all the objects (Controller, for example) are created, you’d only be able to access the dependencies at runtime of an object, through accessor methods. I’d much prefer if an object’s dependencies were injected at construction-time, through constructor injection, etc.

But all that, and then some, is all described in the document. Read it and let me know what you think - I’d love a second opinion on the matter, or alternative solutions to solving this problem.

http://greatjustice.info/files/dependency-management.doc

Edit: Small update, if this topic interests you, make sure to read Fowler’s article on the subject - it helped me formalize the different techniques used. Also, I should seriously buy / read his book(s), fgj.

Obligatory list of social network links: