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.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am currently working on a company that is considering considering using JBoss Fuse 6.3. At the moment we are working with proof of concepts and some facts are happening: when we use the fully Open Source technologies (Camel or CXF) integrated to jetty / tomcat we can run without problems.
By integrating this into the JBoss Fuse platform we are experiencing serious packaging and deployment difficulties. I wonder if anyone is using this product until in production and what were the experiences / difficulties faced in this journey?
I actually work with many OSGi containers, and Karaf/JBoss Fuse never gave me any deployment issue.
However, when you deploy into such containers your bundles must conform to OSGI specs regarding package imports and exports. Some tuning may be required for .wars.
Some tips:
Use an up-to-date version of maven-bundle-plugin (3.x)
Use the official JBoss Fuse BOM when compiling your bundles
Don't embed jars inside your bundles unless you have no other options
Use wrap command to turn non-OSGi jars into OSGi compatible, works most of the times
When you work with databases and ORMs, use javax.sql.DataSource and JPA, will save you a lot of classloading issues
jdbc and jndi are your friends
Publish your interfaces as OSGi services
Use Blueprint as component model (works basically like Spring)
Inject a service/bean from other bundles as an OSGi service
Read "OSGi in Action" book
Log to your own files instead of fuse.log (configure Log4j to do this inside etc/org.ops4j.pax.logging.cfg file)
When you develop use 0.0.0-SNAPSHOT. It's fundamental. If you redeploy a bundle with the same version the OSGi runtime will probably reuse the previously loaded classes/resources and will not work as expected. You will not see new methods, updated code, and so on... With -SNAPSHOT version you force OSGi runtime to really reload the code.
Launch with ./fuse debug so you can connect with your IDE and debug the code live. You can even debug into Camel / Blueprint / CXF / Felix / whatever library you want.
Difficulties
Learning curve is quite steep, as there are a lot of frameworks and technologies involved. A lot of examples and documentations you find online (even here on SO) are outdated.
Jboss fuse is a quite mature product and is heavily used for integration. For soap implementations you can use cxf endpoint in camel and for rest implementations you can go for cxfrs server/client or the latest rest dsl. Fuse supports most of the EIP patterns for integration and works efficiently using osgi modularity. It's been a wonderful product so far.
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' 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
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.