By Doug Drechsel on Jul 17, 2013
I guess that is what this blog will be covering. My ramblings with regards to Java Modular Frameworks and Inversion of Control containers. I am finding that a well prepared, well thought out blog post is just not going to happen. Throwing down my thoughts in a "devil may care" frame of mind should get me going and something is better than nothing, hopefully.
A ways back I was a member of the Core Engine team. Core Engine was a Server kernel based on OSGi. OSGi is an example of a Java Modular Framework and my first exposure to those concepts. A common OSGi euphemism is "SOA in a JVM". Core Engine is currently the kernel for Oracle Event Processing.
OSGi follows the publish find and bind model with the registry within the JVM instance. Using OSGi required writing to the API's to publish a service when playing the role of service provider or using the find/bind API's when being a client. Using an Inversion of Control container that supplies annotations to publish and find/bind makes this process much simpler. This also makes Unit Testing simpler because IOC supports the ability to inject Mocked Objects for testing. I have worked with Mockito and PowerMock (helps with all that old legacy code).
Dependency Injection is a type of IOC Container (at least according to Wikipedia). For this and all future blog posts, unless noted otherwise, any IOC Container is implemented via Dependency Injection .
Another past project I worked on was rewriting WebLogic Server Server Lifecycle using OSGi. This was intended to support WebProfile but could easily be extended to support multiple server configurations (Maybe that's a future post). Around this time Oracle acquired Sun.
Do you know what Oracle has that supports OSGi and provides Inversion of Control with Annotations and came with the Sun acquisition? HK2.
The rewrite of WebLogic Server Server Lifecycle code moved from being strictly OSGi based with our own home grown IOC container to HK2. Glassfish also uses HK2 as the kernel for the Server. Migrating legacy lifecycle code proved an interesting task (Maybe the leanings of migrating legacy code to a Modular Framework with IOC is another future Blog Post). I found that these techniques helped reduce code complexity, increase code re-usability, better support true Unit Testing and provide a much more manageable code base with respect to maintenance and support.
This was a quick introduction to who I am and my motivations for this Blog. In the future, I will continue discussing these topics and how they relate to Server Side coding. I will look at dynamically configurable kernels that are constructed at run-time. Some posts will be introductory as I cover some basic aspect of these technologies. Others will get into gory detail regarding some current project.
I wanted to end this post with some pithy comment about how much fun it is to learn and we will learn together but NO!!!!
My Blog, My Rules.
1. There are no stupid questions, only stoopid people asking questions. (Leave that poor little question alone)
2. I desire robust discussion but attack the idea not the person.
( This obviously supersedes Rule 1 and Rule 1 is the last time a person is referred to as Stoopid or any other derogatory phrase/word)
3. Shakespearean Insults are appreciated and encouraged
For example, the idea to continue to resist migrating the code to a Modular Framework is an artless fat-kidneyed scullian. Note that the idea is the artless fat-kidneyed scullian and not the person that proposed it.
Wonder where this is going?