JAOO 2006 – Day 1 (Tutorials)
Aarhus, Denmark, October 1st, 2006.
Louis & Cesar
Programming with Equinox – The OSGi foundation for Eclipse
Presented by Jeff McAffer & Tom Watson, both from IBM (slides).
OSGi is a standard for dynamic management of components within a java runtime. It was born out of the need to dynamically download and run components within a java runtime, but has since evolved into a framework for mitigating the complexity of software component management. The idea is that as the software systems that we produce become more complex and larger in size, there is a greater need for component organization. In addition, there is a desire to make component composition easily configurable in a dynamic way (again, that idea of installing and using components dynamically).
OSGi provides mechanisms for:
- explicit declarative management of dependencies: rather than relying on a single static classpath configuration for the entire runtime enviroment, each component gets its own class loader. Thus, the runtime can have two components loaded that each depend on different versions of the same sub-component without conflict (“which version of xyz jar is needed?”)
- dynamic discovery and binding of components, that is, lifecycle management of components at runtime
Up until version 3.1, eclipse’s plugin development environment was a proprietary protocol for component management. Eclipse is now heavily involved in OSGi and their implementation of OSGi is Equinox. With version 3.2, eclipse’s component model and plugin development environment was completely rewritten in terms of Equinox. (This rewrite took almost 2 years!)
As you can imagine, this framework is quite complex and elaborate, so you only want to consider it for large systems in which component management is difficult. That said, the runtime is small (~800k): they had some examples of small components that were distributed to portable devices.
For us, while the dynamic component distribution and loading looks nifty, our interest lies in the ability to manage dependency complexity. On our project, whenever we’ve discussed breaking our monolithic, giant application into components, we run into two issues:
- what should the components be and how would we migrate to that structure?
- how would we manage component dependencies, versions, etc.
Neither of these issues is trivial. It looks like Equinox may be a suitable solution for us for the 2nd issue. Of course, it’s still up to the application designers to figure out how to componentize their systems. Clearly, such a component breakdown is going to required in order to productize our application. Productization aside, it is quite interesting to think of how flexible component management could help in reducing the complexity of deployment of the application as it stands now. Moreover, we really feel that breaking the application into components will significantly increase development efficiency and quality overall. To put it another way, we’re getting close to the application enhancement ceiling of the monolith.
Spring 2.0 and Persistence
Presented by Eberhard Wolff, Interface 21
For us, this was both an introduction to Spring as well as a summary of what is new in Spring 2.0.
Why use Spring?
- to seperate your infrastructrure code away from your domain code, i.e your business logic.
So what is Spring providing?
- declarative dependency injection
- AOP capabilities
- support for infrastucture frameworks (JNDI, JMS & Persistence (JDBC, Hibernate, Ejb 3.0 JPA))
The presenter stated two reasons why the service locator approach is sub-optimal:
- all users of the locator are transitively coupled to each of the services provided by the locator; and
- worse still, because of the transitive nature of the dependencies, they are not obvious and easy to forget.
We agree that using dependency injection eliminates unnecessary dependencies. Furthermore necessary dependencies are made explicit and are therefore easier to analyze (it is easy to whip off a dependency grapg based on the Spring configuration file). It also makes unit testing more straight forward.
Spring’s implementation of AOP is based on refelection and proxies. We prefer this approach over that of byte code manipulaltion (i.e. AspectJ) which can be problematic in situations where some other librarry is using byte code manipulation (e.g. Clover). That said, apparently the 2.0 release has support for AspectJ (whatever that means — we don’t know enough about either to comment on it further!).
Infrastructure Framework Support
These look very appealing. They eliminate the need to write a bunch of boiler plate infrastructure code. For example, no need to write all that repetitive JDBC boiler plate code, but more importantly it provides a unified abstraction for supporting persistence frameworks of all flavours (Hibernate, JPA, etc.). The same is true for other infrastructure things like JNDI, JMS and transactions. We agree with the presenter that there is no need to roll your own infrastrucre framework for those specific things “ever again”.
How could we make use of Spring within our Weblogic based J2EE application?
The obvious answer is to ditch the container and replace everything with POJOs and Spring. Aside from the question of it being a huge effort, are there other reasons why we couldn’t do so? (Yes: we would require buy-in from the customer, obviously.) Perhaps we can benefit from using Spring without going whole-hog: we can run Spring within the container and make use of specific features where they fit. Some obvious candidates are:
- dependency injection (replacing the ImplementationRegistrar and giving us an easier handle on dependency management)
- JMS infrastructure
and some other likely ones are:
- frameworks for Hibernate and transactions
- AOP for logging, performance metering, transactions
- does it make sense to consider Spring for the fat client? (hopefully, because we could benefit from dependency injection there too)
- what’s the memory footprint of Spring?
- by introducing yet another framework into the application architecture, are we really helping or are we hindering? We need to be aware of consistency throughout the system (or at least have a workable plan for whatever conversion may be involved).
Cesar & Louis