Last time, we talked about our first hybrid (Java EE + OSGi) application where we discussed not only about development of hybrid applications including kind of maven plugins to use, deployment steps, etc., but also about the lifecycle of OSGi bundle and Java EE artifacts. Now, it's time for our second hybrid application which demonstrates an EJB as an OSGi service.

Set up
1. Download the latest nightly build of GlassFish v3, install and start glassfish:

java -jar glassfishv3/glassfish/modules/glassfish.jar

2. Start embedded JavaDB by running

glassfishv3/glassfish/bin/asadmin start-database

3. Download "OSGi web container" bundle from here and install it by copying it:

cp osgi-web-container-3.0-SNAPSHOT.jar glassfishv3/glassfish/domains/domain1/autodeploy-bundles/

Sample Application
You can download the complete sample from here. Unzip it. Let's look at the UML diagrams below. The first one is a package diagram showing dependencies, the second one shows the components of the system and the third one shows that they are all deployed in the same node.

As you can see, we have three modules and the source code organization reflects that as well. Let's briefly go over the modules:
1. common
This is just an OSGi bundle. It exports sahoo.hybridapp.example2 package which contains a single interface called UserAuthService.

2. service
This is a web application bundle, i.e., a hybrid application containing both OSGi and Java EE artifact. It imports sahoo.hybridapp.example2 package. It has following components:
2a. UserAuthServiceEJB This is a Singleton EJB designated to be initialized at startup. It is annotated like this:

@Singleton
@Startup
public class UserAuthServiceEJB implements UserAuthService

Please refer to EJB 3.1 spec for more information on these annotations.
UserAuthServiceEJB has a static variable called

static volatile UserAuthService selfRef;

which is initialized by an ejb reference in the postConstruct() method of the EJB:

    
    @PostConstruct
    public void postConstruct() {
        selfRef = sessionContext.getBusinessObject(UserAuthService.class);
        System.out.println("UserAuthServiceEJB.postConstruct: " + selfRef);
    }

2b. Activator - This is an OSGi bundle activator which looks up a data source in JNDI, ceates a table there and then registers the EJB reference (selfRef) in OSGi service registry under the service interface sahoo.hybridapp.example2.UserAuthService. For simplicity, we have not used any service properties here.

3. client
This is just an OSGi bundle. It imports sahoo.hybridapp.example2 package. It has an activator which waits for UserAuthService to be available and then invokes it. Look carefully at the activator code and see how it uses ServiceTracker to be notified of service availability. When it sees the service, it invokes it. All this is accomplished in these few lines:

    private class UserAuthServiceTracker extends ServiceTracker {
        UserAuthServiceTracker() {
            super(bctx, UserAuthService.class.getName(), null);
        }

        @Override
        public Object addingService(ServiceReference reference)
        {
            UserAuthService service = (UserAuthService)context.getService(reference);
            service.register("f..", "b..");
            return service;
        }
        
    }

Build and Test
1. If you don't want to build, then the final artifacts are in target dir, else simply run

mvn clean install

in hybridapp2 directory.

2. To deploy, simply copy the artifacts like this (please note, because of a bug as described last time), while copying the .war file, give it a .jar extension as a work around.

cp common/target/hybridapp2-common.jar glassfish/domains/domain1/autodeploy-bundles/
cp client/target/hybridapp2-client.jar glassfish/domains/domain1/autodeploy-bundles/
cp service/target/hybridapp2-service.war glassfish/domains/domain1/autodeploy-bundles/hybridapp2-service.jar

Since deployment order is immaterial, you can copy them in any order.

Benefits of EJB as OSGi service
1. An OSGi service is able to take advantage of Java EE container services like declarative transaction, declarative security, resource pooling, etc.

2. Local client views of an EJB are accessible from other applications collocated in the same JVM. Please note, since Java EE can not assume a module management system is in place, it takes a safer route of isolated class space for application classes. This does not have to be the case when we are using hybrid applications. We can safely cross application boundaries and call local EJBs.

3. Better modularity of application: as shown here, the app has been broken into three independent deployment units. Once they are deployed, they can be managed (e.g., patched) separately.

4. Deployment order is a thing of past. OSGi takes care of class loading dependencies and then application can take advantage of facilities like Service Tracking to build very dynamic application. As shown in this example:

if client bundle comes up before service bundle, then it simply waits for the service to be available.

You can observe this by removing hybridapp2-service.jar from autodeploy-bundles/ and copy it back.I hope you find this example useful. Let us know what you want to hear. As always, your feedback is very welcome. Please visit The Aquarium to know the latest news about GlassFish. If you have questions about how to use this feature, please use our forum.

Thank you,
Sahoo.