Geek Answers Handbook

A way to keep the minimum dependency on the server application?

What is the best (easiest, easiest) way to build a Java application, although it relies as little as possible on the actual application server used in the deployment?

For example, let's say I want to deploy Geronimo to Apache, and later I want to use GlassFish, how difficult will the transition be? What is the best way to abstract the use of each application server?

Sorry my ignorance, I'm relatively new to Java development. I want to start a new project, but I'm not sure whether to use separate APIs for the functionality I need or to develop on top of the selected server application from the very beginning.

Thanks for your help,

Ivan

+4
source share
4 answers

Without going into too much detail, even if you can write bare-bone Java EE code, the configuration around it is not very simple. Each application server has its own set of configuration files and naming conventions (for example, the format for specifying the AS location is different in IBM WAS and JBOSS). Although this is not very important for application development, once you get to the deployment phase, they will become important. As for libraries and your code, if you adhere to EJB standards, you will be able to run your application on most application servers (I know WAS and JBoss - the code I wrote should not have changed for these servers, the configuration, although, well, this there was another beast!).

+3
source

Follow the Java EE specifications as much as possible, while follow the server specifications as little as possible.

If we try to figure out what is common among Java EE application servers (JBoss, WAS ...), the answer is the Java EE specification, which server providers must follow. If you have 2 solutions to the Java EE problem, you can check which solution meets the Java EE specification better than the server specification.

+2
source

From my experience with Jboss and Sun AS, you should just forget about AS independence.

In sql, for example, you can do quite a lot without using vendor-specific functions. Well, this is not the case as in Java EE. For Jboss and SAS, even hello world applications will require different configurations. And more applications are growing, more vendor-specific features that you should use.

In particular, if you look at the official Sun Java EE tutorial, you will find that from the very beginning it uses SAS configuration files (sun-web.xml, sun-ejb-jar.xml, etc.).

But all of the above applies only if you use the full set of Java EE features (for example, EJB, JMS, mbeans). I found that if you only have servlets / jsps packaged in one military archive, such an application can still be very portable.

+1
source

If you have the resources, consider developing and testing multiple application servers, not just your initial target. This will allow you - from the very beginning - to pinpoint what you need to configure and code accordingly.

Personally, I would consider Glassfish 3.0.1 in such a situation as a reference implementation, so everything should work there without much effort.

0
source

More articles:


All Articles