In a nutshell, if its not in the J2EE Spec, you can't assume is part of the available architecture of a J2EE compliant app server, even if 50% of the containers provide it. So if your looking for 'job scheduling', for example, and some have it, and other don't, you basically need to build one your self to use in the containers that don't have it, and for the ones that do, build custom wrappers for each implementations.
I think your question of whether you should use JNDI to decide which implementation to invoke on a given container is just the tip of the iceburg. How you decided on the implementation to use in a given case can be as simple as a 'Factory Pattern', which may read web.xml, any other .xml or .properties config file you dream up. In web.xml you could use servlet parameters, <env-entry>, or even <context-param> But by taking this task on, you are almost doing single handed what the J2EE Spec team and the community are all the app server providers are trying to do which is ... 1) Define the common interface for the feature (like scheduling) 2) write a reference implementation (keeping to J2EE specs) for containers that don't have this feature 3) For each container that has this feature already, write a custom bridge between there API's and your generic Interface(s). The dilemma then comes when/if that feature is included in the next j2ee spec, and all vendors now support it. I'll guess your interfaces will not be an exact match and you're left with the choice of 1) throw away everything above and refactor your app to the new J2EE spec, or 2) Keep your 'proprietary' non-J2EE spec compliant version or 3) Implement a wrapper between your original API your app is coded against, and the new J2EE app, assuming there is a match. It just a hard problem to solve! I think your goals for a framework are similar to ours, which is why we started the JAFFA open source (http://jaffa.sf.net). A J2EE based solution (EJB's optional), utilizing the best of what's already been built, and adding on bits where we can't find existing solutions that fit. We took the above 'interface/factory' approach with our persistence layer, we implemented a standard interface, with the view to have different 'engines' based on different evolving technologies (JDBC, O/R Engines, JDO, Entity Beans), so that the application code and business logic could stay the same even if we change the underlying technology. All this abstraction comes at a price, with many compromises along the way. We had a CastorJDO implementation, we move to a more basic JDBC O/R implementation, and are now considering an implementation base on Jakarta OJB project for JDO compliance... The only thing you need to be certain of with frameworks is that they meet the relevant parts of the J2EE specs that you care about, beyond that pick existing frameworks that you believe meet you technical needs and that are supported by a community that have the same beliefs and vision for the architecture and you do. Choice is a great thing and with Java there a plenty of open/commercial ones to pick from. Choose wisely as you will be investing lots of time and effort learning it. In my opinion 'real' applications will always need more features that what comes in an 'out the box' container or architecture, as its the real world solutions that drive the next iterations of what should be in the J2EE specs and what new patterns and features are needs in the frameworks. It's a cycle. Paul Extance -----Original Message----- From: Robert Biernat [mailto:[EMAIL PROTECTED] Sent: Thursday, May 22, 2003 8:42 PM To: 'Tomcat Users List' Subject: RE: Servlet Containers & J2EE Frameworks I suggest you take a look at the J2EE patterns and blueprints on the SUN website. Theyre are numerous patterns and techniques that go along way in helping you architect a distributed J2EE system that is both flexible and portable. -----Original Message----- From: Steve Garcia [mailto:[EMAIL PROTECTED] Sent: Friday, 23 May 2003 1:41 PM To: Tomcat Users List Cc: [EMAIL PROTECTED] Subject: RE: Servlet Containers & J2EE Frameworks It is interesting that you are doing what I wish to achieve. I have an application that we need to rewrite and make more portable, we want to design it such that it supports multiple app servers and databases, just like your organization/company. Sorry this is a long e-mail, but I would like to hear your thoughts, and anybody elses, on this topic. Re: the database layer. We are consigned to exclusively use an O/R Mapping tool. Frankly, if we want to support numerous RDBMS, then I don't see any other way around it. I suppose we could write custom SQL for each provider and use JDBC but that sucks big time. I've looked into Jakarta OJB, and I think it will do the job. What are your thoughts on this? There is still some work for configuring the datasources/configuration files, but theoretically it should only be an issue of configuration files, not source. (at least in theory). Re: the app layer. I can see logging being a tricky subject. Oddly enough, logging is the first thing I architected and implemented for our new application. I decided on using the Commons-logging API (as opposed to some specific implementation) and have defaulted to using the Log4J implementation. This is an enterprise app, so there will only be one instance of this app per VM. Re: the numerous components/services that the application must resolve, I am thinking that there should be one general "gateway" by which the application resolves all service instances. This isn't necessarily JDNI, it really could be any implementation. How have you gone about this? For instance, suppose this application is a simple one, all it really needs is a DataSource, some SMPTEmailer and job scheduler, which both do not exist in the J2EE specification. There should be some common interface that defines the contract for these three API services, we already know the DataSource interface because it is defined in the javax.sql.DataSource class. So, we can define the SMPTEmailer and the Job Scheduler interface that the application will use. The common "gateway" that I was speaking of would be a way to resolve these three service interfaces: it could be as simple as a configuration bean that has three methods on it: javax.sql.Datasource getDatasource(); SMPTEmailer getSTMPEmailer(); JobScheduler getJobScheduler(); Every single time the application wishes to use one of these services it must resolve the instance via this configuration bean. However, what is underneath this bean is certainly 3rd party specific. I could use JDNI to resolve each of the services above in a property file. For example, the property file for this bean could look like datasource=myapp:/sql/Datasource smptEmailer=myapp:/email/SMPTEmailer jobScheduler=myapp:/background/scheduler At the time of the configuration bean creation each of the JNDI values could be resolved by a Context (no easy feat, mind you). Each of the values corresponds to a absolute URI that can be resolved by JNDI. the "myapp" namespace resolves to my own application, but it could be easily replaced with something like datasource=tomcat:/the/specific/tomcat/datasource smptEmailer=weblogic:/a/SMPTEmailer/from/Weblogic jobScheduler=atg:/atg/dynamo/service/Scheduler Obviously some of those values are incredulous but you get my point. Besides the large amount of work involved, I can see the enormous benefits offered: it would be easy to add another Java archive file to support an application server, JDNI is supported by most major makers of application servers, etc. What do you think? -----Original Message----- From: Justin Ruthenbeck [mailto:[EMAIL PROTECTED] Sent: Thursday, May 22, 2003 2:27 PM To: Tomcat Users List Subject: RE: Servlet Containers & J2EE Frameworks Sounds like you're on the right track. We're doing exactly what you're suggesting (pluggable modules for different appservers *and* databases), and I've found the appserver part pretty easy. With the exception of logging (some vendors provide their own logging that's tied into the management applications, others don't), obtaining the JNDI InitialContext (again, this process varies), and the method of getting a Connection from the DB Connection pool, it's pretty simple so long as you're not doing anything off the beaten path in your code. Write your own interfaces for those things and you'll be in good shape -- although you will find small annoyances (eg: one vendor provides Connection objects who's setAutoCommit() method is ignored, while another allows you to change it). Supporting multiple databases is, of course, an entirely different story. justin At 12:51 PM 5/22/2003, you wrote: >I agree with what you said. That is my fear/concern. The real effort is >trying to develop a framework of interfaces that all providers should >implement for this application server that I want to build to be truly >portable. As such, there would be my application server framework, >(complete with spi interfaces), and corresponding "connectors" for BEA, >Tomcat, JServ, Websphere, ATG, JBoss, etc. > >The question is whether there is a general specification to use these >various J2EE architectures? I guess that would be the J2EE specification >itself. That is, to get a connection from a datasource, a provider should >implement javax.sql.DataSource. All of the organizations/companies that >write application servers probably have their own database connection >pooling implementation, and they should (hopefully) respect the J2EE >DataSource contract! > >So is JNDI the appropriate API for gluing together all of these >frameworks, APIs, etc? > >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: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] ____________________________________ Justin Ruthenbeck Software Engineer, NextEngine Inc. justinr - AT - nextengine DOT com Confidential See http://www.nextengine.com/confidentiality.php ____________________________________ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
