A recent IBM developerWorks article by J. Jeffrey Hanson, Build an SOA framework with Apache Geronimo and POJOs, describes a POJO-based development process with the Apache Geronimo server.

The article describes GBeans, the Geronimo version of Java management beans, or MBeans:

GBeans are managed components in Geronimo that share many similarities and relationships with JMX MBeans, such as exposing attributes and operations according to a class named GBeanInfo, which is strikingly similar to the JMX equivalent MBeanInfo class...

GBeans maintain states and association dependencies, and they handle life cycle events. A GBean can register as an interested party in the status of other GBeans. After the GBean of interest is started, the interested GBean will receive a reference to the GBean of interest through dependency injection.

The article then shows how Geronimo supports GBeans:

A Geronimo kernel is a framework of GBeans. Using this framework, you can model and build most any sophisticated system as a set of GBean containers and GBean components to manage state, relationships, and event handling... Creating a Geronimo kernel programmatically is a simple process using the KernelFactory classes.

The concluding section of the article describes how to expose POJO's as GBeans and present services via those POJO's in an SOA application:

... Register POJOs as GBeans whereby interested clients can query and invoke them without the need for additional interfaces or APIs. The framework resides in the business tier of a multi-tiered enterprise application environment. A service-locator class is responsible for interacting with the kernel to find and, if needed, register POJOs to be used as services. The service-locator class then returns the POJOs to a business-delegate component where it invokes them.

As the article illustrates, SOA is often a fanciful buzzword for simply exposing a Java object or interface on the network, allowing that object to service invocations from remote clients. Turning such POJOs into managed beans adds the benefit of being able to dynamically stop and start POJO instances based on service requirements. This technique is reminiscent of Jini, which has recently become an Apache project as well. One difference, though, is that Jini does not define a management interface for Jini services; and, instead of discovering objects capable of servicing remote calls via an app server kernel, Jini relies on a network-based service discovery protocol.

What do you think of Geronimo's POJO-based approach to service-oriented applications?