CODEWITHSUNDEEP
jbossosgiseam
Danilo
Danilo

Reputation: 31

Move a seam application to OSGI

i' ve some web applications developed using Seam Framework 2.3 + jBoss AS 7 + Hybernate.

Since i' ve been studying OSGI for a while, i was wondering if is possible to move my applications to the osgi world for modularizing everything; i' ve read a lot of blogs and these interesting discussions as well (how-to-modularize-an-enterprise-application-with-osgi-and-ee6 and how-to-modularize-a-jsf-facelets-spring-application-with-osgi) but honestly i still don't really know where i should start from, since i' ve never used OSGI before.

According to you

  1. Is it possible (and useful) do such things?
  2. According to your experience, what would be a good starting point?

Thanks for help

Upvotes: 1

Views: 429

Answers (1)

earcam
earcam

Reputation: 6682

Approach

Possibly start with a toy application as a spike, a WAB (OSGi WAR) and single service bundle.

Definitely take an iterative approach. As far as I know JBoss supports the mixing of OSGi services and Java EE stuff, via JBoss modules/msc, this will allow you to try OSGi and migrate gradually.

I think you'll find some things are incredibly easy and others very hard, so pick easy battles while you're getting familiar. In the end you may stick with a hybrid approach.

Build

What's your build tool? Mostly like Maven or Ant, in which case have a look at maven-bundle-plugin or bnd respectively. You'll need to ensure the OSGi metadata is present in each of your bundles (Bundle-SymbolicName, Import-Package, Export-Package, etc). If you're using Maven see this answer.

It can be tricky to divide a monolithic app into modules, but as a general rule when you migrate a reasonable sized module you should have separate bundles for API and implementation (which is good design anyway but has implications for the runtime too).

Interop

You can acquire OSGi services, access bundles etc using the low level framework APIs from an injected BundleContext, which will give you a low-level programmatic hook into OSGi. It should be as simple as:

@Resource
BundleContext context;

Unless your Java EE code is packaged as JBoss modules I don't think it will be easy for you to call the other way (e.g. OSGi service looking up Java EE service) without resorting to something like JNDI.

You should be able to install the webconsole and see what Java EE bits are registered in OSGi, and similarly check JNDI to see what's available OSGi for Java EE.

Migrating Services

While OSGi is a lot of fun, using the raw framework API results in quite a bit of boilerplate code and it's unlikely you'll need the power or want the coupling. You can use a number of dependency injection frameworks on top of OSGi; blueprint (Spring-like), Peaberry (Guice) and Declarative Services for example.

I'm biased but Declarative Services has a strong affinity to the OSGi µservice model and the implementations are lightweight.

CDI

I don't know much about Seam/CDI, but Pax CDI might help (though JBoss might already have covered this).

Web

Are you planning to have a highly modular UI with hot deploy of the various components? If not then probably best just to package the UI as a WAB. A WAB is a skinny WAR (i.e. it imports rather than embeds most dependencies). Even if you're after a highly modular, dynamic frontend, I would definitely do this for the first pass.

JPA

A word of warning - JPA implementations typically don't play well in OSGi environments, you may want to look at Apache Aries or Eclipse Gemini. Another option might be to leave the JPA stuff in Java EE space and access Java EE DAOs/Repositories as OSGi services. Again though you may experience some classloading issues.

Possibly useful examples https://docs.jboss.org/author/display/JBOSGI/Provided+Examples

Upvotes: 2

Related Questions