Advantages / disadvantages of Glassfish v3 Prelude vs Springsource dm server for web applications?

Question

Both of these application servers are at least partially based on OSGI. One (Glassfish) is obviously Java EE and the other is not. Now I'm at the stage of choosing a platform for a new project, and the natural choice is Glassfish v3 Prelude. This raises the question, perhaps we should use S2AP instead.

The question then becomes: does the springsource dm server provide any good reason to use it over Glassfish? And vice versa.

Answer 1

Java EE application servers have distributed transaction managers. If this is important at all, you might want to see if SpringSource dm contains such.

You can execute XA TX with Spring-Framework, you just stay on your own to find the right XA manager and integrate it.

The XA TX course has fallen into disrepute. Most people try to avoid them like the plague. For example, Amazon.com does not use them.

We are currently using Spring-Framework and Tomcat in combos. We do all our integration. Many people have made this choice of mid-tier stack. We are tied to the Spring-Frame API - just like the Java EE people are tied to Java EE / EJB. Don't let Spring rhetoric fool you. However, it remains open source, accessible to the user community.

Once you start Java EE, you are tied to a specific Java EE provider, as it is difficult to move between implementations. EJB3 is supposed to facilitate this, but it will bet that it will still be the primary obligation to switch Java EE application servers.

Frankly, Spring -Framework provides more useful APIs than the Java EE / EJB standard, and it is being implemented at a faster pace.

Answer 2

This is an old branch, but I thought it would be helpful if people came across this (like me) to share recent GlassFish OSGi improvements, mainly in the area of ​​OSGi Enterprise RFC: http://wiki.glassfish.java. net / Wiki.jsp? page = OsgiDashboard

Of course, there is also a @ Resource-based injection of OSGi Declarative Services, which has been there since v3 in December 2009.

Answer 3

I think the SpringSource acquisition from Covalent Technologies puts them in a better position to help anyone using the Spring / Tomcat stack. The Tomcat optimizations that come with the Spring dm server can cost the same or more than the OSGi features.

Answer 4

Using OSGi in Glassfish is misleading. Glassfish uses OSGi for the server; OSGi is not available for applications deployed to Glassfish.

With the Spring dm server, applications can be written to use OSGi.

Is OSGi important to you? The only real OSGi application server is Paremus Infiniflow. All other application servers are now talking about OSGi, but this is an internal implementation detail; This is not for deployed applications.

Answer 5

I have not used the SpringSource dm server, but I believe that it is better to wait a while before trying it in production. The reason is that it is rather new technology. In addition, the way the licensing scheme works with SpingSource (GPL) doesn’t help much, as it actually means that you will rely only on SpringSource for now and for the future. If you need server support, then your only option is to use SpringSource.

Answer 6

SpringSource dm Server supports modular applications - you can split your application into OSGi packages and share any infrastructure services that you want to provide between applications. This saves you from monolithic structures like WARs defined by Java EE. Typically, this means that during development, you get a very fast edit / save / redeploy cycle. OSGi then allows you the version modules and the packages it exports, as well as dynamically update the modules without rebooting the entire server.

SpringSource dm Server was created from scratch as OSGi packages. Thus, you can configure which dm server subsystems are loaded if you do not want a standard set.