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
Is it possible (and useful) do such things?
According to your experience, what would be a good starting point?
Thanks for help
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
Related
OSGi R5 Enterprise release contains the Subsystem specification.
Does OSGi subsystems contain all capabilities of Eclipse feature?
Does tooling exist for it?
Purpose of this mapping would be a re-use of existing eclipse features in e.g. felix or bnd/bndtools based infrastructures.
Yes... kind of. A subsystem is powerful but also more complex than an Eclipse Feature.
A feature is just a set of bundles. You can install multiple features into a single OSGi Framework, and the bundles from each feature can interact with each other, e.g. by importing packages or binding services. This makes them hard to test and to reason about, because a feature that works on its own might not work when installed alongside some other feature.
A subsystem is also a set of bundles, but it additionally includes a degree of isolation. You can control whether the packages, services and other capabilities from one subsystem are visible to the members of any other subsystem. Thus they are more predictable.
Unfortunately constructing a subsystem is a much more complex task, and there is no specific tooling for this that I know of. We haven't done anything in bnd/Bndtools to help with this. But hey it's open source... contributions welcome ;-)
Subsystems and features are really two orthogonal things. An Eclipse feature is a set of bundles that can be installed into an OSGi runtime. Actually, there's little difference between a bundle that has a lot of Require-Bundle elements and a feature, as far as requiring that they be installed.
An OSGi subsystem on the other hand was a proposed way of allowing OSGi runtimes to be nested. However, they were replaced with a more general wiring construct in the final version of the OSGi spec; but in any case, they do a completely different thing.
i have some requirements on my project that modularity appears to be needed, so i'm researching some approaches on the best way to do it.
Based on this, i found OSGI and sounds like a great deal, after some search and some tutorials i have some doubts.
In a high level i'm thinking in separate my modules by business segments, for instance, financial, invoices, registers, and so on.
1) I believe i can create bundles to separate these modules, i also saw that i can use osgi container to deploy those bundles. Is is possible to distribute this application on jboss, websphere and weblogic?
2) Is there any known disadvantage to make my application full dependent to OSGI? I mean, i only wanted to use OSGI to separate my modules and make deploy and version distribution easier?
Thanks
As relates to WebSphere Application Server, the answer to your question #1 is positive. WAS has extended support for applications based on OSGi and has the notion of Web Application Bundle (WAB) and EJB bundle. You should take a look at the official documentation - OSGi applications.
You might also want to take a closer look at Apache Aries, the project that enables the use of OSGi for building applications in Java EE environment.
is there a reference or book, maybe a tutorial that can get me started with ejb using the technologies that I have mentioned above?
thank you
You can take a look at the JBoss Tools if you're interested in developing Java EE applications in Eclipse.
If you already know EJB (and if you don't there is quite good Enterprise JavaBeans 3.1 book) you know you can develop your EJB's as plain POJO's just with annotations. No need for fancy plugins here.
You would, however, need a plugin to easily deploy your application to the server. In this case, take a look at these JBoss Tools and this topic.
Is it possible to run Jboss 4.2.3 as a bundle inside OSGI container? What would be the challenges associated with it?
For those who cares, I am looking at running dcm4chee inside OSGI.
While not impossible it would be incredibly hard, a simpler alternative would be to embed OSGi inside JBoss, see:
http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html
and
Programmatically Start OSGi (Equinox)?
and
http://njbartlett.name/2011/03/07/embedding-osgi.html
http://www.dcm4che.org/jira/browse/DCM-308 Looks like they're adding support to make the Jars valid bundles - couldn't you just work out the dependencies and deploy these to an OSGi framework? OSGi has support for JMX and JNDI.
Unless there are huge dependencies on JBoss' internals, I'd suggest the second option, but beware of Class.forName usage and other non-osgi-friendly code.
I logged the bug specifically for the dcm4che (note 1 e) toolkits, not the dcm4chee war. I would suggest logging a new issue for the dcm4chee assembly. However, making the dcm4che toolkit components osgi bundles would likely be a required step in the direction of getting dcm4chee to run in an osgi container.
If client of the system is on the web there are no advantages JBossAS+Seam over Tomcat+Seam?
Your questions suggests you're confused about what is what.
Seam is a framework for building web applications in Java.
JBoss AS is a Java EE application server.
Tomcat is a Java servlet container.
You can run Seam on either JBoss or Tomcat.
Since JBoss is a full EE app. server, you get certain features like Enterprise Java Beans out of the box with JBoss.
With Tomcat, you don't, but this isn't usually a big concern since, for example, Spring framework can replace Java EE if you need that functionality.
It does matter what you use, since the majority of your system will be probably coded in the back end (server side Java).
If you want the minimum amount of hassle when using Seam, I'd suggest using JBoss since that company made Seam.