Thursday, February 23, 2006
The Bootstrap Aspect
One of the advantages of living on the bleeding edge as it comes to EJB3, is that you can come up with solutions other (.NET) developers can only dream of. Such solutions to common design problems not necessarily need to be very complex. We all like to KISS every now and them, right? One such rather simple design problem is bootstrapping an application. It's like when you have a method in your code that is allowed to be executed only once. Most of the time developers go off like this:
Which, OK, works, but, on the other hand, is a very boring way of coding methods. Once you have to provide bootstrap functionality to a number of services within your system, it becomes too much of a copy-and-paste operation. It just smells bad. One way to handle such situation is to aspectize the bootstrap... aspect. The idea is that you would like to end up with something very clean like:
where you handle over the bootstrap aspect to some EJB3 default interceptor. The bootstrap interceptor uses a bootstrap service to keep track of whether a method already has been called or not. One nice thing about this design is that you have a central point within your system that can be contacted to query for bootstrap information. Suppose we annotate a method like this:
If, for some reason, we want to check that this part of the application has already been bootstrapped, we simple go to the bootstrap service and ask for it via the given A_BOOTSTRAP_ID. Lovely, isn't it? This is what I like about such designs. The basic idea is simple. The implementation can be done very quickly when you run inside of an EJB3 J2EE container. I implemented this in something like 30 minutes. (BTW: a nice definition of a container: something that manages all kinds of aspects, even the aspect of defining new aspects). And despite its simplicity, it gives you a very powerful and flexible solution to the bootstrap problem.
void bootstrapApplication(...) {
if (alreadyBeenCalled()) {
throw new IllegalStateException("bootstrapping twice");
}
doBootstrapApplication();
}
Which, OK, works, but, on the other hand, is a very boring way of coding methods. Once you have to provide bootstrap functionality to a number of services within your system, it becomes too much of a copy-and-paste operation. It just smells bad. One way to handle such situation is to aspectize the bootstrap... aspect. The idea is that you would like to end up with something very clean like:
@Bootstrap
void bootstrapApplication(...) {
...
}
where you handle over the bootstrap aspect to some EJB3 default interceptor. The bootstrap interceptor uses a bootstrap service to keep track of whether a method already has been called or not. One nice thing about this design is that you have a central point within your system that can be contacted to query for bootstrap information. Suppose we annotate a method like this:
public static final String A_BOOTSTRAP_ID = "system-x-bootstrap-id";
@Bootstrap(A_BOOTSTRAP_ID)
void bootstrapSystem(...) {
...
}
If, for some reason, we want to check that this part of the application has already been bootstrapped, we simple go to the bootstrap service and ask for it via the given A_BOOTSTRAP_ID. Lovely, isn't it? This is what I like about such designs. The basic idea is simple. The implementation can be done very quickly when you run inside of an EJB3 J2EE container. I implemented this in something like 30 minutes. (BTW: a nice definition of a container: something that manages all kinds of aspects, even the aspect of defining new aspects). And despite its simplicity, it gives you a very powerful and flexible solution to the bootstrap problem.
