The benefits of programming to an interface and not to an implementation are espoused in discussions of style, pattern use and sound OO design. The use of interfaces decouples components and allows for simple substitution of implementations to keep up with changing requirements (or to facilitate unit testing).

At it's core, ServiceManager simply returns an implementation class for a specific interface. It has a simple service registry which associates a specific interface with a given implementation. It also uses the concept of a locator to obtain an actual instance of a class. Different locators can instantiate different kinds of services; right now there is support for plain Java classes and EJB classes.

Back in 1998 I was reading about the dream of reusable enterprise Java bean component architecture, about how beans encapsulating generic business logic could be glued together to form a complete application.

I imagined a system that smelled much like today's SOA (Service Oriented Architecture) where services, local or remote connect to and use one another in an orchestrated way (perhaps across heterogeneous environments) to implement a solution. I built two frameworks that delivered on that vision, ServiceManager which abstracted away how a service was implemented and where it was located along with an action framework that orchestrated services using an XML description.

The ServiceManager started off exposing dynamically with the ServiceManager class returning a Service object. You would then invoke methods on a service through Service's invoke() method which used reflection to call methods on implementing classes. ServiceManager was really designed to be used from the action framework and it showed. It was powerful, though, at the time supporting calls to POJOs, EJBs, RMI, OS software/shell scripts via Runtime.exec() and eventually SOAP services using Axis. The combination of the two went on to form the basis for several projects that I delivered while working for Ericsson. One project, an XML content based Web/WAP portal offloaded XLST processing to powerhouse servers in production but used local POJOs in development. By using ServiceManager one could easily control the implementation used by simply having a different configuration file in development and production.

In late 2001 I started wanting to use ServiceManager outside of it's relationships with the action framework and expected services to be concrete implementations of specific interfaces. To that end, I made use of proxy classes to support concepts like calling EJBs without needing Business Delegates. I also later played around with clustering of service registries using UDP based discovery and TCP based communication between registries in a given environment. Finally I added support for JMX components and sat back to look at a whole whack of spaghetti code; the result of 2 years of 1-2 coding sessions spread weeks apart.

I'm now working on releasing some of the cleaned up code. None of this is really new or revolutionary now, so it's really just an exercise in code cleaning and maybe to meet some people interested in solving the same problems that I've encountered in web application development. If you find this code interesting or useful, great!