Saturday, July 16, 2005
it's the aspect, stupid!
My infatuation with Spring is official. My significant other knows. We have an understanding. (Which is a lot of fun, since it makes my fellow programmers quite jealous.)
It turns out that the way to coder's heart goes through aspect oriented programming. This great technique, let's you solve one problem at a time. And Spring empowers you to use it.
Let's say you have this lengthy operation that should be done asynchronously. In sipXconfig world it usually means replication and until recently no-one dared to speak this term aloud without paying tribute to programming gods. By I digress...
I get to work. I write the tests. I write the code. After couple of iterations things start working. And now for something completely new. I cannot possibly run replication - which involves opening HTTP connection to sipX servers - in the same thread that builds WEB pages. The last thing our users need is extra coffee breaks, while they wait for page refresh. So I dig out my Java and threads books and start worrying... And then it hits me. The fact that my code runs in a different thread in not a property of my code. It's not even the property of the code that calls my code. It's a different ASPECT (and when I say ASPECT you need to visualize it as a fifth spatial dimension in the coding time-space). I repeat this couple of times in my head. Then I repeat this couple of times to lazyboy, who - as usual - looks unfazed. Just in case he might want to say something, I pretend that I am really busy and I run back to my computer.
It turns out Spring lets me to write little pieces of code called interceptors. I can intercept any method call and do something extra. For example spin the thread, or even better tell a thread pool to do something for me.
The callers do not see anything different. They call the functions as they always did. Just by changing Spring beans configuration I can change all my beans to asynchronous. Aspect of replicating data is isolated from aspect of doing things in the background. And you code, test and implement one aspect at a time.
This experience comes handy couple of days later when I integrate Apache XML/RPC client. This is how sipXconfig will communicate with sipX servers in future. But I do not want to expose this fact in every sipXconfig corner. I do not want to write entire isolation layer of code either. Turns out I do not have to. Again thanks to the ASPECT. Just as calling stuff asynchronously, calling stuff through XML/RPC can be handled by Invoker. Good Spring people do not have XML/RPC invoker, but writing one turns out to be trivial.
And again - the code that calls my beans does not even know that implementation of the interface lives on sipX server. Xmlrpc-iness is magically injected in the configuration file.