11 February 2007 - 13:41The emergence of the transparent container

I planned to write this post after a series of posts about unusual uses of the Spring framework. I have written so far only one post and I have 2 more started. I don’t have enough time to finish them (I have a small backlog of posts that I started, some 6 months ago) so I thought I just write this one.
My posts are focused on transparent coding: how you would take your current application and apply various business concerns to it transparently without disrupting its normal state. It is a great programming technique which lets you inject new behavior into your application at small costs. It lets you make a small investment and back out of it quickly if this investment turns sour. I look at the transparent container as a binding management tool: it displays you the components of you application and lets you bind one component to another, swap one component for another, bind an advice to a series of methods, etc… It happens that some of the above features are the features of an IoC container but there is much more to this than plain inversion of control.
If I see any problems with this transparent coding (I’ll use this name for lack of a better one) is that there are not that many modelling tools out there because it is a fairly new and unexplored phenomenon. Another problem that I see with it is that the behavior is injected transparently via configuration files. This approach has quite a few management problems, stemming mainly from problems in collaboration (imagine an piece of functionality whose spring.xml files are edited by a few dozen developers). The approach usually taken for this which is to specify these concerns declaratively in a Spring configuration file doesn’t scale as the number of concerns increases, it serves only as a purpose of displaying a new technique. However, Spring could be used as the basis of a platform that would manage all these concerns.
As a sidenote: I see that Spring has got into allowing code for configuration, basically right now you have the option of configuring you application via code rather than simply thru XML descriptors. At the first sight this would simply mean that application configuration has gotten so complex that it requires code for doing it. I think that it also means that the bindings between various components in an application (bindings previously implemented in configuration) have got so complex that they require code for managing them. The configuration file is simply a way to manage these bindings, right now these bindings are becoming overly complex and managing them takes a lot more than configuration. I would say this version of configuring-thru-code (which is actually binding-management thru code) could be where the most interesting Spring development would occur. Code-based configuration would allow for more complex interactions between various components.

I would give this example to display the benefits of code-based “configuration”: let’s say that you have a work-flow engine which models work-flows as a series of tasks, a work-flow engine that currently uses Spring for configuring the work-flows, for defining the flow sequences, etc… You become pretty successful and you sell your engine to a company that uses it for managing dozens of work-flows made up of dozens of tasks.
Now, your customer would like to have some business analysts create new work-flows on the fly (let’s say for simulating a business process), in other words they would need to create, test, discard, record dozens of work-flows looking for, let’s say, the business process with the lowest cost. It is obvious that the configuration file approach (declaring the relationships in spring.xml) is not going to do it because what is required over here is actually implementing a whole work-flow testing process. Now, your work-flow engine revolves around configuring work-flows, so one approach would be to develop or buy an app for testing workflows (any workflow, not necessarily from your application) that would be used by the business analysts looking for the lowest-cost flow and then plug this application into your work-flow configuration via Spring’s new code-based configuration.
The code-based configuration would actually act as a bridge between the work-flow testing system and the work-flow engine itself.
The whole theme of this example is that you are given the option to manage the configuration of your application how you want to (in the above example you wold manage the configuration of your work-flows by piggy-backing on a work-flow testing app), once this configuration cannot be met by the usual spring.xml file. This approach should be taken only when the complexity of the configuration raises to the point where it warrants this investment.

One last point about the transparent container called spring. It has been argued very well that Spring is non-intrusive in the application code. Well, it is intrusive, not in code, but in your application management process. If you are using spring for bindings management you are so dependent on it, you may not be able to continue functioning about it. But about this, maybe some other time.

The transparent container is a container that manages bindings between components and let’s you do it in the manner that you consider best suited to your needs: thru config files, code, etc… This manner is transparent to the component themselves.

Later Edit: I think that managing components relationships in Spring thru code is where the next cool things will occur in the Spring framework.

Later Edit 2: While I have not tried managing complex relationships in Spring thru code I think that this should be an easy process with a low entry-barrier. If this process requires a deep understanding of the Spring framework I’m afraid that it will never be used on the scale it could and it should.