Services, services everywhere!
Wednesday, February 27th, 2008I’ve spent a few hours over the last few days reworking parts of my Eclipse Organizer example that I intend to contribute to the Eclipse Examples Project. Mostly, I’ve been working on introducing OSGi Services into the mix. Frankly, I’m totally in love with services. Yes—if I could—I’d marry them.
The Eclipse Organizer is modeled after applications like Evolution or Microsoft Outlook. FWIW, it’s intended to serve as an example of how one might go about building an application using Eclipse technology; it’s not intended to be a “real” product.
I’ve reworked the guts of the mail support to be almost entirely based on OSGi services using declarative services. I’ve got services that provide connectivity to a POP3 mail server, services that provide credential management (i.e. take care of obtaining and storing userids and passwords), services that provide repositories that hold mail, services that manage a Derby database instance, and services that let me play with all of the above through the OSGi console. It’s all very cool.
One of the things that I’ve been trying to do is to make all these services interchangeable. Everything is very loosely coupled and a service providing a bit of functionality can be very easily taken out and replaced with an alternative. I’ve also been trying to make the services as focused as possible: that is, I’ve been trying to build services do one job and defer other bits of functionality to other services. For example, the service that holds local copies of mail is separate from the service that gets mail from the server.
In the process of building this, I reminded myself of an experience I had a few years back as a services consultant. My job was to review the work done by another consulting company. The application was running on a J2EE application server and was almost completely composed of Enterprise JavaBeans. In fact, they had well over 5,000 different bean types defined. All of them session beans, most of them stateful. In their wisdom, this consulting organization had decided to make every object in their system a enterprise bean because they had some “great tools for building beans” and using them “made it easier”. The funny/sad part was that they had pretty quickly run into some limitations of the current version of the specification and made a few local “optimizations” to work around the limitations (which had a rather dramatic impact on things like data integrity and server stability).
Oh the horror.
I was reminded of this because OSGi services seem similar conceptually to stateless session beans, but far lighter-weight, more dynamic, and generally more useful.
