In researching OSGi and OSGi containers, I stumbled across this SO question mentioning GlassFish as an OSGi container, and I have to say I'm quite baffled.
How is this possible?!?!
My understanding was that OGS - a Java-compliant app server - has 2 containers:
Web Container: where you deploy WAR files for web apps and services
App Container: where you deploy EJBs for business logic
Where do OSGi bundles fit into this paradigm?!? Does OGS allow you to deploy an OSGi bundle to the app container and treat it like an EJB or something? And if I'm mistaken about how OGS works please correct me! Thanks in advance!
Hmm, a rather total misunderstanding of what OSGi is ...
OSGi is a framework that allows you to organize your code so that you can built it from reusable components that can then collaborate through the service layer (no more Class.forName or XML!).
OSGi frameworks can run standalone, they run inside an application, the can run in a WAR file, and they can run inside an application server. And you can even run OSGi inside OSGi inside OSGi since it does not rely on statics anywhere.
The OSGi Alliance specifies a format for the modules (bundles) so that modules can specify their dependencies. The Alliance also specifies an API to install and manage modules. And last, it specifies a large number of interfaces that are useful when you develop applications.
Websphere, Glassfish, JBoss, Jonas, all support deploying OSGi bundles.
OSGi is a module system that allows to add/remove/upgrade different bundles, handles dependencies, provides runtime information on the status, etc.
When it comes to GlassFish (which has an Apache Felix OSGi container in it), the different features of the application server (eg HTTP server, JMS server, etc.) are implemented as bundles. There is console and web based interface for the OSGi container where you can start, install, remove services (see the PDF below)
As far as Java EE applications go, they can interact with the OSGI container too. For example, an EJB can be exported as an OSGi service and also the EJB can consume an OSGi service itself.
For more info, see http://glassfish.java.net/public/GF-OSGi-Features.pdf
Glassfish internally uses OSGi to provide the features you mentioned. Besides that you can deploy your own OSGi bundles on it. See https://wikis.oracle.com/display/GlassFish/OSGi
There is no real connection between OSGi and Java EE though. You can not yet use JavaEE in OSGi bundles on Glassfish. For this case there are first initiatives like Weld on OSGi: http://www.slideshare.net/TrevorReznik/weldosgi-injecting-easiness-in-osgi
They are not really production ready though.
Related
I'm running into some issues in deploying my Java EE application, and could use some advice.
I have 3 components to deploy:
Integration layer (Data): POJOs and CDI Beans - JAR file
Application layer (BL): EJBs, CDI Beans and POJOs - JAR file
Presentation layer: Servlets and such - WAR file
Optimally, I would like to be able to deploy both the integration and application layer JARs in the same Java EE server, but as separate JARs (since I might want to change the hardware configuration later on and separate them into two different servers on two separate machines).
The problem, is that I'm unable to get the CDI injection from the integration layer JAR to the application layer JAR to work. The server says (and probably rightfully so) that it's impossible to resolve the injections.
So far I came up with these possible solutions:
Package the two JARs into a single EAR file (maybe throw in the WAR as well ...), and deploy that
Use JNDI between the different layers (possibly create a CDI producer to do a generic injection based on JNDI names or something like that)
In the integration layer, make the objects being injected into the application layer (the DAOs) EJBs instead of CDI beans
I don't like either of these solutions (especially the last), since they restrict my future deployment options. The second solution does not restrict me, but it might become tedious at some point (when I accumulate a lot of code).
Finally, my question is:
Is there an option I didn't find yet, that would allow me to deploy the two JARs on the same server with the CDI injections working ? Possibly something that would still work if at some point I separate the JARs into different servers ?
Yes, there are other options as well.
Use a java EE container that supports OSGi as well, and use OSGi interface for your deployment dependencies. At least Websphere, Glassfish, JBoss (with jbosgi installed), Jonas support deploying OSGi bundles. This means your modules should be converted into OSGi bundles.
Use a container-specific extension that allows modules to communicate between each other. JBoss as jboss-deployment-structure.xml that you can use to have a dependency to another deployment.
Use a server-provided shared classpath for your dependencies. Wouldn't really recommend this.
My vote would go for OSGi.
None of them will work by themselves however if you deploy packages to different servers. A remote technology like remote EJBs, remote JNDI lookups, Spring remoting, HTTP-based api, CORBA or similar is needed between different servers. In Java EE, EJB is the de-facto standard for this, but Spring remoting is not bad either.
Update: you added that you use TomEE servers. Indeed TomEE won't support the first two options I mentioned. I would use EJB in that case - the fact that you're using EJBs can be abstracted away from the business layer using an EJB delegate, and you could use EJB (stateless session bean) only for the interface part, leaving your DAOs as POJOs.
not sure what your goal is but deploying a war is fine, can even be done manually with these commands:
mkdir -p webapps/myapp/WEB-INF/lib
cp myjar*.jar webapps/myapp/WEB-INF/lib/
If your goal is to be able to split them you can use TomEE skinny war feature.
Create a war with a WEB-INF/jars.txt file.
In this jars.txt put one line by dependency/jar. It can be the path to the jar or maven coordinates.
Once setup it will allow you to change jars one by one then simply restart the server. This is great when several teams work on the same binary.
There are some alternative with TomEE but this one has the advantage to be easy to change to a portable one (war).
We are currently developing a web application for college and we would like some advice from a more experienced developer.
We have a backend using Hibernate to operate on a MySQL database. Another project is the web UI that uses the API delivered by the backend (registering user, fetching data associated with certain profiles etc.). We use the JSF framework (RichFaces) for the UI. Everything is built using Maven.
The technology we can't decide on is for the communication between UI and logic modules. The first option is to use ApacheCXF to provide SOAP webservices that UI can be a client of. The second option is to use EJBs to invoke backend methods from the UI module.
What approach is more widely-used? As far as we read on the Web, using EJB is faster than SOAP webservices. On the other hand, we don't have any experience with EJBs using Tomcat (we would prefer using Tomcat since it seems to be a cheaper option, however we don't know what we would have to do in order to use EJBs with Tomcat). Additionally, working with webservices since the beginning will allow us to add support for different platforms (for example, Android).
Another aspect which we are discussing is about how should the application be deployed. The alternatives we have considered right now are:
Deploy it as a single WAR project (which would solve the problem we have about communicating the UI with the backend of our application).
Deploy two WAR projects in the same server using webservices for communication between the projects. (We have a prototype using this approach deployed on a Tomcat server)
Deploy a WAR project and EJB project.
Deploy an EAR project which would contain the references to the WAR and EJB projects. (We have a prototype using this approach deployed on a Glassfish server)
The project right now is starting, so we will only be handling a couple hundreds of users right now. However, if the project succeeds we would need to deal with a couple million of users.
Any advice would be appreciated. Thanks.
Edit: So any advice about how the project should be deployed? Is it necessary to use EAR? Is there any advantage if we deploy the project as an EAR module?
Edit 2: We found the advice we needed on this thread: Deploying java applications (Tomcat/Glassfish)
First things first. I would avoid using Web Services if there's no need for it. If you feel that you might need to call this system from external programs and platforms, then go for it. Even then, I would only use the web service interface for external integration, and still have an internal EJB implementation.
EJBs are awesome for enterprise applications. I would highly recommend that you look into that. They provide support for EJB Pooling, Transactions, Aspect oriented programming, Security, Stateful sessions, Java Messaging, JNDI etc. And you can inject them directly inside a Managed Bean (JSF). You said that you will eventually handle millions of users, so I assume that you will want your application to run as fast as possible, I don't think SOAP web services will be a good fit. Remember that SOAP web services encode messages as text, so if your application will be sending binary files etc, then you'll suffer significant performance issues.
As far as deployment goes I would go with an EAR, or a WAR for the JSF and and EAR backend. you can use Injection to pull the classes you need, even remotely, from multiple web applications and other EAR apps.
I'm not sure why you say Tomcat is Cheaper. Glassfish open source edition is a fully functioning JavaEE6 Server and its free. JBoss is also JavaEE compliant and is free. both of them are used in lots of production environments. I find glassfish to be much more user friendly, and would recommend it to EJB noobs :)
I also started with Tomcat, but now I don't use it at all. why use the servlet container only, when you can have the whole shabang? hope this helps.
we use ApacheCXF at work and its has SOAP and Restful. Reliable and relatively easy to setup. I am not sure why you want to use glassfish maybe it's preference but you can implement your projects in eclipse too. It's really that is up to you and your team and the requirements and skill sets your team may have to build and support, that a side CXF webservice+apache + eclipse with maybe two war files would be a good path.
I wouldn't use web services in this case. You can use managed beans as controllers.
Put the logic into EJBs, views into rich faces and control the flow using managed beans.
If you use maven you can generate a project with the structure of EAR (war for web module and jar for ejbs). I don't remember the name of an archetype but you can find it easily.
Working on a project that runs an embedded Jetty web server withing its infrastructure. We are looking at addings a new web application that would benefit greatly from allowing views to be plugged in using OSGi. Vaadin is our web framework of choice.
There is a great tutorial on creating an OSGi pluggable Vaadin application in GlassFish where the web container and OSGi container are bridged. That is, the web container is not running in the OSGi container. Here is the tutorial: https://vaadin.com/wiki/-/wiki/Main/Creating%20a%20Modular%20Vaadin%20Application%20with%20OSGi
My question is. Would it be possible to bridge an embedded Jetty web container and OSGi container in the same way as described in this tutorial.
Running jetty in an OSGi container is simply not an option for us as we have to work with existing deployment.
You should be able to embed any 4.2 compliant framework via the org.osgi.framework.launch.FrameworkFactory class. There's a few good examples if you google, two good ones are on the Felix site, and Neil Barlett's blog.
Configuring it will be far more work - you'll need to export all the Jetty and servlet packages via a system property org.osgi.framework.system.packages.extra and use something like Felix fileinstall or a console and pax-url to un/deploy bundles.
While your Vaadin app will be dynamic - nothing from Jetty or the embedding application will be (i.e. domain entities, services etc).
Could you embed a different container? Eclipse Virgo and JBoss AS are both OSGi and J2EE containers.
http://www.eclipse.org/virgo/
http://www.jboss.org/as7
If I were to deploy an application on Tomcat vs. Websphere, what are things that I need to consider?
Do I have to develop my Java code differently if developing in one app server vs another?
Edit:
I will be funneling people from a website into a web app that does credit card processing and e-signatures (cc processing and e-sigs are through separate services). That is its sole job
You cannot use EJBs on Tomcat (unless you add OpenEJB). If your WebSphere deployment uses EJBs, you'll have to remove them to deploy on Tomcat.
If you use any Java EE features beyond servlet/JSP engine and JNDI naming service you'll have to eliminate them from your app.
Tomcat accepts WAR packages. If you package your app into an EAR on WebSphere, you'll have to change it to WAR for Tomcat.
Both use JNDI for data sources. There might be some nagging differences in naming conventions, but if you stick to the standard they should be portable.
If you use any WebSphere specific code in your app, you'll have to remove it to deploy on Tomcat.
If your app is servlets, JSPs, and JDBC you can deploy on either one without any problems.
You can think as Tomcat as a subset of Websphere, so theoretically everything that works on Tomcat will work in Websphere.
But...Deploying in Websphere, in my humble opinion, is a terrible pain, while deploying in Tomcat just works. (And if fails, just delete temporary folders)
Without knowing the technologies you are using, that's all I can say.
Depends, what are you trying to deploy?
Tomcat isn't a full EE server--are you trying to deploy an EE app?
If you're just deploying a web app, it's more important to consider which version of the servlet spec/etc. each server implements.
I have been looking for a solution to create a modular web application, which is modular in the sense that user can provide its own plugin in form of a simple jar which will then provide its own data to my web application and my webapp will be responsible for displaying it.
Now the catch is i want my web app to be as generic as possible without relying on the j2ee web container to support anything . i.e. i cant rely on my web container to provide osgi support and deploy web application as an osgi bundle itself ( which truly makes things very simple for eg. glassfish and WAS).
I am planning to use equinox and only solution i see currently is the servlet bridge they provide on their official site, but to me it is really a pain to delegate everything to a servlet which will in turn interpret the request and find an apropriate bundle Class and then again communicate back somehow only the data to the web application.
To me it would be wonderful if my web app was also a bundle.
Is there anything close to this ideal solution which i can try for? Or any other communication method between the two relams of osgi and web appliction (container)?
The OSGi spec details the WAB (Web Archive Bundle) format.
And Pax Web offers great support for WAB/WAR webapps (PAX Web runs fine on Equinox, Felix, etc)
Using pax web you get the BundleContext via the ServletContext, eg:
BundleContext bundleContext = (BundleContext) getServletContext().getAttribute("osgi-bundlecontext");
For the user driven pluggability you mention, I'd suggested you provide some service interfaces for the plugin bundles to implement and in your webapp use a ServiceTracker to listen for their registration (unless you're using Declarative Services). You also easily be able to install bundles from an upload servlet.
I'm guessing users uploading plugins would have to be logged in and authorized, so security issues will have been met at this point.
EDIT: replying to comment here as not enough space in comment field
Apologies, think I misinterpreted you question - you have an existing webapp container(s) and you want to deploy a WAR with OSGi functionality? If that's the case then either use the ServletBridge as others have mentioned or embed an OSGi framework into your WAR (this is relatively easy, see this for example).
You could even make this optional by attempting to get the BundleContext from the ServletContext and if this returns null then launch your own embedded framework. That way it'll run in a native OSGi container (e.g. Glassfish) or in a Java EE app server.
Otherwise, PaxWeb is an implementation of the HttpService and WebApp OSGi specs, but with lots of extensions to make life easier - but you deploy this to an OSGi container.
You might want to look into Apache Sling. It is a web framework that has an embedded OSGi container. The OSGi container is called Apache Felix and is pretty good.
ServletBridge is for embedding an OSGI contianer within a web container. The other option is to embed a web container (as a bundle) in an OSGI container. The following article has some details on how to achieve this.
http://java.dzone.com/articles/osgi-and-embedded-jetty
You may want to try ChonCMS - http://www.choncms.com
Its architecture is based exactly on what you are asking, it comes with few plugins to enable base CMS functionality, it is modular platform with minor web app container using felix and plugins can be added/removed at run time as well.
Disadvantage might be that it has lack of documentation, but you may ask, it is open source, I'm sure they will be happy to answer questions, and even better you can contribute - it is still in incubation phase.