Chapter II: Migrating your application ecosystem from GlassFish
What are GlassFish users supposed to think–as well as plan–for the future in light of these changes? Will you be patient or pragmatic…or both? In this chapter, we discuss migrating your application code and DB/datasource elements.
How did we choose TomEE and JBoss as options for GlassFish users?
When GlassFish 4 was released, many users were planning to migrate their applications from GlassFish 3 to get advantage of all benefits brought by the Java EE 7 specifications. But now, they have been forced to plan a migration effort towards a different application server instead, pushing the excitement about using Java EE 7 away for now.
GlassFish users are probably facing the following options:
|Meaning||Find an alternative to the GlassFish 3 web/full profile and postpone the plans to migrate to Java EE 7||Leave things alone for a while and start evaluating alternatives to GlassFish 4|
|Why?||You’ll probably want to start a relationship with another support team as soon as possible to eliminate all lock-in features and avoid a hurried and risky migration in the future. They will focus all their attention on the migration and stop thinking about Java EE 7 for a while.||If you believe your apps are not that locked-in, you’ll want to increase productivity and reduce app complexity, thus it’s ok to stay with GlassFish for a while and postpone the migration opportunity towards an application server that already supports Java EE 7.|
At this point, you might may face yet another dilemma: do you continue relying on OSS, or move to a proprietary solution?
Glassfish is an open source software and it is certainly a reason why people decided to use it. These people are probably looking for an open source alternative because they need full transparency, have a lower budget and are able to improve the product if they can to.
Some of you don’t care if the application server is open source or not. You might fear that other open source options will end up like GlassFish, with no long-term technical support for subsequent releases. The lack of transparency and budget are not a problem for them either, and they hardly would have time to look at the code to find the root cause of the problem.
We can combine the options above and identify alternatives for each combination. The following table shows potential candidates to replace your Glassfish installation based on the options above:
|Stay using Java EE 6||Also move to Java EE 7|
* Red Hat doesn’t offer technical support for WildFly yet.
It is true that there are many other alternatives out there, such as Jetty, Resin, Geronimo, JOnAS and more; however, we have decided to limit our focus to the tools mentioned above due to the following reasons:
- The vibrant developer community around these tools, namely JBoss and Tomcat
- The amount of documentation available on the web
- The sponsorship and support by market leaders
Open Source options with commercial support – TomEE and JBoss
If you want to stay using Java EE 6 for a while and keep trusting on open source software, we suggest TomEE 1.6 and JBoss AS 7 / JBoss EAP 6 as alternatives to GlassFish.
TomEE is a bundle of Apache implementations of the Java EE 6 specifications. It’s a relatively new product in the market, but it profits from Tomcat’s maturity, making it reliable and competitive. TomEE recently got Java EE web profile certified, which reduces the need for application changes when migrating from another certified product, such as GlassFish. Its official support is provided by Tomitribe, the company started by David Blevins in 2013, who engaged several TomEE committers to interact directly with customers.
Red Hat has a very similar business model. Like TomEE, they offer official support for customers using products under the JBoss brand (i.e. JBoss = JBoss EAP and WildFly, formerly JBoss AS), which has a mature and established codebase. Among the above-mentioned, JBoss also has the largest installation base, documentation and a huge community. They are very competitive–indeed, our own Great Java Application Server Debate awarded 1st place to JBoss–but it doesn’t mean they are competition killers.
As part of Red Hat, they seem to have become slower to respond and more bureaucratic over time as they grow, a syndrome that attacks most growing IT corporations. The much-smaller and more agile Tomitribe is far more efficient in terms of decision making and response time, but cannot compare with resources. At least, that was our perception when we contacted both companies to request a offer for support and training.
Proprietary options – WebLogic and WebSphere
Outside of the open source world, you find WebLogic and WebSphere as the two main proprietary players, provided respectively by Oracle and IBM. These companies have large developer bases and equally large contracts. In terms of service agility, we can apply the rule “the bigger you are, the slower you move”. It means their support works according to the agreed terms, but it might take more iterations to finally get a solution to the issues.
There is a very low probability that you are going to talk directly with a WebLogic/WebSphere committer (one of the people in charge of programming the application server), which is the opposite case with TomEE and, to some extent, JBoss. On the other hand, WebLogic and WebSphere have much more means to invest into their products for achieving higher levels of reliability, stability, optimizations, vendor support, HW/SW cost efficiency, and so on.
Oracle is tempting users with a claim that the easiest path away from GlassFish is directly to WebLogic, since it supports GlassFish’s deployment descriptors and share some of the libraries already.
However, the open source alternatives already support those deployment descriptors as well and JBoss also shares most of those libraries too. Therefore, the most logical decision when migrating from GlassFish is opting for an equivalent open source alternative. That’s why we have decided to explore only the technical details of JBoss and TomEE in the following sections.
Download the PDF