Software development enthusiast and CTO in a German SME Kristian has posted 2 posts at DZone. You can read more from them at their website. View Full User Profile

Switching to Java EE - Seamlessly?

07.30.2008
| 5905 views |
  • submit to reddit

Quite some of my (spare?) time the last couple of weeks I spent pondering a smart way of getting an existing Spring/webapp environment consisting of several modules migrated to make more use of the Java EE 5 features, namely provided by the glassfish application server which has been in productive use in our environment for quite a while now. But while migrating webapps from tomcat to glassfish has proven to be pretty straightforward in our case (asides a few minor caveats it was just as difficult as deploying the .war file using asadmin and seeing the application start up on the new system… ;) ), the idea to make our “backend” application (so far Spring-Remoting packed into a web application context) a well-behaving EJB3 module turned out to be a little more complex than just that. But doable, to say now, after all…

General considerations

Overally, even though wanting to use “more” of Java EE 5 than just the web tier, we didn’t want to give up on Spring, mainly because it’s a decent, unobtrusive technology allowing for getting applications structured rather quickly. On the other side however, EJB3 is a core part of Java EE 5 and, using this platform to its widest possible extend, leaving it out didn’t seem an idea that good. Adding to this, we simply wanted to make use of our tools as good as somewhat possible, including, in example, having exposed Web Services visible in the glassfish administration panel, or making use of the NetBeans tooling for accessing EJB methods in client code. This, overally, made us search for an environment like that:

  1. Deploy components to be “stock” Java EE components (.war applications, EJB modules, …) to make the application a “Java EE” app from a “high-level” point of view. This should be done in order to use all the tooling and technology support provided by the glassfish / NetBeans tooling combination.
  2. Make use of Spring internally in these components, as there are a lot of things that still do benefit from using Spring here - autowiring EJB modules, in example, while using a stateless session bean to be merely a facade exposing functionality implemented in this module, or getting web applications crafted using the Spring Web MVC or Spring WebFlow. Plus, however, we wanted to be capable of mixing Spring autowiring and EJB3 dependency injection side by side while creating EJB3 modules.

Another consideration thrown into this: We have been using maven2 for quite a while now, mainly in order to get dependency management (and, here, most notably the handling of transitive dependencies) done in a way less painful than wagonloads of binary .jars dumped to our SVN repository and/or having huge, unsorted file systems containing downloaded and unzipped libraries. From this point of view, a solution would need to be doable using the features provided by maven2 as well as the maven2 tooling in NetBeans (which, as I can’t stop pointing out, is pretty much excellent at the moment).

Basic solution


So, overally, as described, deploying / migrating .war files / web applications wasn’t that much of a problem in our case. More seriously EJB3 applications, and be that because (other than the maven webapp archetype), tooling support to generate EJB3 maven2 skeleton projects from within NetBeans is still rather rudimentary. First shot, so, was to set up an environment having all these technologies thrown in and being capable of editing, building, deploying and actually starting an EJB3 application in one of our glassfish installments. I did write down the outcome of these efforts, along with a simple prototype project which easily could be modified / extended, in the NetBeans Community Docs wiki pages; in our internal environment parts of this sample project made their way into a parent maven2 pom to be inherited by all EJB3 projects and into an empty archetype for the same purpose. From that point of view, it’s routine now. :)

Goin’ further


That, however, is far from having things completely done. In order to achieve our goal while doing a “seamless” migration and throwing away / rewriting as little code as somewhat possible, our application structure needed to be transformed in some way. Initially our project structure looked more or less like this (which is just an “abstraction” of our actual architecture and the projects involved):

  • core-api-jar contains all the domain classes and interfaces used throughout the system (i.e., so far, for Spring remoting).
  • core-impl-jar, not that much of a surprise, contains implementations of said interfaces to be used either directly or via some sort of remoting.
  • backend-services-war, a Spring web application context, exposes the services implemented in core-impl-jar (so far using different web services protocols along with the Spring HTTP invoker.
  • frontend-war, also a Spring web application, contains “client” logic doing (hopefully) meaningful things using the services exposed by the backend via remoting.

So in the next step of migration, the idea was to replace backend-services-war (web application) with backend-services-jar (EJB module), ideally without breaking everything else. Playing around with things a little, overally we used to follow this approach which, in the end, did get us started rather quickly:

  • At first, of course, we needed to ensure that frontend-war, the client application(s), are capable of easily using the EJB instead of the Spring webapp remoting backend. Fortunately, thanks to the Spring support for accessing remote EJBs, this turned out to be rather easy. However we still wanted to do with the interfaces in core-api-jar, ideally without messing with this package.
  • In order to deal with the EJB3 requirements, we created @Remote interfaces for each of the required components. Doing so, finally we ended up with empty interfaces, simply extending those defined in core-api-jar.
  • Likewise, each of these @Remote interfaces got implemented as a @Stateless session bean, again mainly extending the “legacy” implementation in core-impl-jar. Thus, the amount of new code to be written was limited to some “plumbing” and wiring required to get the EJB working and inject dependencies and information formerly declared in the backend’s main applicationContext.xml - things did get somewhat easier here thanks to using EJB3 DI for resources (Java Mail, JDBC, …) provided by the container anyway, as well as for dependent resources implemented in other EJBs in the same module.

So at the moment, in our testbed system parts of the functionality required by frontend-war are still in the “old” backend-services-war, while others already are exposed by backend-services-ejb, and overally, it works rather good.

Left to do

… of course is to do right this for all the services implemented in the backend, as well as attaching all the “frontend” / client applications to the new structure. Next big step, then, is to rebuild some of the services which so far make use of a pretty arcane Request/Response scheme where a message oriented setup possibly would do better potentially using message-driven beans, and to rebuild backend and possibly mid-tier to have more loosely coupled services. And then… recrafting the “outer-world” connections using JCA, maybe throwing in the Java Business Integration features wherever possible. Still, most of the work is to be done, but at least we know how to get there, which is a rather good feeling after all… ;)

From http://dm.zimmer428.net

Published at DZone with permission of its author, Kristian Rink.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Slava Imeshev replied on Wed, 2008/07/30 - 11:37pm

This sounds like a lot of "fun". What was the reason for migration?

I am asking because I moved just between major changes of the J2EE standard tree times, and that was quite an effort. Moving between different platforms may be a serious challenge. Is it really worth it?

 

Regards,

Slava Imeshev

Cacheonix: Clustered Java Cache 

 

 

John Hancock replied on Thu, 2008/07/31 - 12:23am

You're going to make Rod cry with posts like this.

Kristian Rink replied on Thu, 2008/07/31 - 12:59am in response to: Slava Imeshev

It actually is a lot of fun. ;) Well, so far our environment does mainly consist of a "legacy" proprietary backend system providing core functionality, to which we kind of "attached" missing parts using tomcat based Java applications. As this environment is getting more and more difficult to even keep running / get debugged (not even talking about doing meaningful extensions), we were searching for a good platform to bear both the features implemented in our backend system and in the Java / tomcat addons. We finally ended up with Java EE, because...

... thanks to Java it is rather good at being platform-independent. I like quite a few things about .NET but, so far heavily using Linux, flirting with Solaris, .NET wouldn't eventually have been a good choice,

... it does already provide a good set of the kind of features we need just ready for us to be used, and, another important thing,

 ... it is pretty much vendor-independent, given there are just wagonloads of (surely differing, but generally Java EE compliant) implementations around.

Overally, to cut things short: Yes, this migration is a serious challenge, and it is likely to keep us busy at least for the next three years. Looking at the demands of our customers we so far have to meet using our pretty much heterogenous environment, I think that however our choices are limited. But this is actually why I am in many respects searching and evaluating ways of getting this migration done as "floating" and seamless as somewhat possible. Let's get it done and hope for the best. ;)

 Best regards,

Kristian

Kristian Rink replied on Thu, 2008/07/31 - 1:03am in response to: John Hancock

> You're going to make Rod cry with posts like this.

 Aah, no offense, I love Spring and I think the Interface 21 / SpringSource people have done a great job in this framework. From our point of view however I have come to a point beyond general tooling discussions at which I just want to have technologies come along with each other seamlessly. I don't want to miss Spring in my tool chain, but comparing developing and debugging and enterprise application using, say, EJBs and the Java EE web tier in a well-integrated tooling environment (in our case NetBeans and Glassfish), I see this brings some advantages I don't want to lose as well. Maybe it's time for a "best-of-breed" decision again. ;)

Cheers,

Kristian

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.