Servlet Containers & J2EE Frameworks

[Steve Garcia <sg...@media-publisher.com>]

I would like to build a Java software application, and architect it such that it can run in any J2EE compliant *servlet* container (not necessarily any J2EE container, I don't plan on using EJB).  This software application will be replete with components that many would consider to be standard modules for a software application, db connection pools, socket servers, thread pools, JSM messaging, JAAS implementation, Mail, scheduling component, etc.  Most of these frameworks are defined as interfaces in the J2EE specification, some will be custom implementations.

My goal is to be able to write a 3-tier software application and delpoy against any J2EE application container/servlet container.  Theoretically, I could write a complete JSP web application by compiling my code against the javax.servlet.* classes, then deploy it on any J2EE compliant servlet container.  And there are certainly a bunch - Websphere, Weblogic, Dynamo, Oracle, Jetty, Tomcat, etc.etc.

The question is how to write an application that uses several of the J2EE frameworks and have it be portable to any J2EE compliant container.  For instance, if I write some pipeline servlets for Tomcat, that obviously won't work with Dynamo Application Server pipeline.  There are some J2EE interfaces, like javax.sql.DataSource, where I could use one implementation, say from Tomcat, and if the application is deployed against Weblogic, I could configure and reference it's implementation of DataSource.  

My question is whether it's possible to deploy a 3-tier Java software application against the J2EE specification - if such a thing is possible.  What is the binding framework that allows this application to reference the J2EE component implementations for all of the organizations that produce a J2EE compliant container?  One logical choice would be the JNDI API.  If an application uses JDNI to lookup an object, it should be feasible to changing the backing implementation of the JNDI provider to return a different instance of your object.  

For instance, I could have a "Configuration" bean in this application that holds a reference to commonly used J2EE interfaces, such as javax.sql.DataSource.  This "Configuration" bean can be configured by a property file.  One of the lines for the property file can be "datasource=/my/own/datasource".  So, the instance of javax.sql.DataSource would be resolved by doing a JNDI lookup of the name "/my/own/datasource".  If I deploy the application to ATG Dynamo, I can change this to /atg/service/JTDataSource".  If the application is deployed with Tomcat, I could reference the DataSource object provided by Tomcat via JNDI.

I do not want to write my own application server.  There are tons of application servers out there.  There are different kinds too, like JBoss, Websphere, Dynamo, Turbine, Avalon, Weblogic, etc.  There are tons.  Frankly they all have their advantages and disadvantages.  At this point I don't even know where to begin when evaluating the application servers.  I am afraid that if I write the application to support Tomcat/JBoss, then it will be time-consuming to deploy it against Websphere.  Frankly I do like the Dynamo Nucleus framework, out of the frameworks that I have experience with it is the most flexible of them all. 

I would like to have a serious conversation about this, I will not care for responses such as "you shouldn't support IBM software!", or "why would you ever want to deploy against Weblogic?".  Our customers demand this of our application, it should be deployable against commercial .

Thanks, Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

Re: Servlet Containers & J2EE Frameworks

[Tim Funk <fu...@joedog.org>]

As long as you follow the Servlet and JSP spec without making any attempt to 
interpret any extra items you should be "OK".

But each container has its "quirks". Find the quirks and program around them 
using configuration options (or classes) that can be loaded via JNDI. 
Hopefully these issues will not clutter up your code and can be abtracted to 
be a configuration issue and not a programming issue.

There is no way to write a single webapp for one platform and have it deploy 
on any hardware and any "(claiming) compliant" servlet engine without finding 
issues.


-Tim

Steve Garcia wrote:
> I would like to build a Java software application, and architect it such that it can run in any J2EE compliant *servlet* container (not necessarily any J2EE container, I don't plan on using EJB).  This software application will be replete with components that many would consider to be standard modules for a software application, db connection pools, socket servers, thread pools, JSM messaging, JAAS implementation, Mail, scheduling component, etc.  Most of these frameworks are defined as interfaces in the J2EE specification, some will be custom implementations.
> 
> My goal is to be able to write a 3-tier software application and delpoy against any J2EE application container/servlet container.  Theoretically, I could write a complete JSP web application by compiling my code against the javax.servlet.* classes, then deploy it on any J2EE compliant servlet container.  And there are certainly a bunch - Websphere, Weblogic, Dynamo, Oracle, Jetty, Tomcat, etc.etc.
> 
> The question is how to write an application that uses several of the J2EE frameworks and have it be portable to any J2EE compliant container.  For instance, if I write some pipeline servlets for Tomcat, that obviously won't work with Dynamo Application Server pipeline.  There are some J2EE interfaces, like javax.sql.DataSource, where I could use one implementation, say from Tomcat, and if the application is deployed against Weblogic, I could configure and reference it's implementation of DataSource.  
> 
> My question is whether it's possible to deploy a 3-tier Java software application against the J2EE specification - if such a thing is possible.  What is the binding framework that allows this application to reference the J2EE component implementations for all of the organizations that produce a J2EE compliant container?  One logical choice would be the JNDI API.  If an application uses JDNI to lookup an object, it should be feasible to changing the backing implementation of the JNDI provider to return a different instance of your object.  
> 
> For instance, I could have a "Configuration" bean in this application that holds a reference to commonly used J2EE interfaces, such as javax.sql.DataSource.  This "Configuration" bean can be configured by a property file.  One of the lines for the property file can be "datasource=/my/own/datasource".  So, the instance of javax.sql.DataSource would be resolved by doing a JNDI lookup of the name "/my/own/datasource".  If I deploy the application to ATG Dynamo, I can change this to /atg/service/JTDataSource".  If the application is deployed with Tomcat, I could reference the DataSource object provided by Tomcat via JNDI.
> 
> I do not want to write my own application server.  There are tons of application servers out there.  There are different kinds too, like JBoss, Websphere, Dynamo, Turbine, Avalon, Weblogic, etc.  There are tons.  Frankly they all have their advantages and disadvantages.  At this point I don't even know where to begin when evaluating the application servers.  I am afraid that if I write the application to support Tomcat/JBoss, then it will be time-consuming to deploy it against Websphere.  Frankly I do like the Dynamo Nucleus framework, out of the frameworks that I have experience with it is the most flexible of them all. 
> 
> I would like to have a serious conversation about this, I will not care for responses such as "you shouldn't support IBM software!", or "why would you ever want to deploy against Weblogic?".  Our customers demand this of our application, it should be deployable against commercial .
> 
> Thanks, Steve


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org