General J2EE: application-defined resources for MDBs
Hi guys, I have a small question.. This is my interpretation: most application servers uses a server specific deployment descriptor (or annotation) element that maps the logical JNDI name as used by the module (EJB,WAR) to the deployment environment JNDI name. This descriptor is defined and packaged in the module, not in the application (EAR). Let's assume I have packaged and tested a set of modules which will be exposed as reusable modules from (for example) a maven repository. I pick appropriate modules to be assembled in applications. I have a hard time understanding how modules containing MDBs can be packaged in multiple applications (deployed in the same server) and still avoid "deployment environment jndi name" conflicts. Servlet context can be bound using application.xml. Deployment environment JNDI names for SLSBs can be generated depending on what application it was deployed in (JBoss works this way?). I think persitence.xml can be packaged in the application and modules can use logical names to reference "application-defined" datasources? All of these approches avoid conflicts by binding the logical name when assembling the application, not when assembling the module. But, for MDBs i have not found any similar way of "lately" bind the logical name of a queue to the deployment environment JNDI name? Cheers, -Kristoffer
- Posted by: Kristoffer Sjögren
- Posted on: July 20 2006 02:15 EDT
- Re: application-defined resources for MDBs by Kristoffer Sjögren on July 20 2006 12:17 EDT
I just want to add: .. if binding of JNDI names are done when assembling the module, then i guess the following documentation is not valid: Reading from "Development Roles" http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Overview6.html : "For example, in the application component development phase, an enterprise bean software developer delivers EJB JAR files. In the application assembly role, another developer combines these EJB JAR files into a J2EE application and saves it in an EAR file. In the application deployment role, a system administrator at the customer site uses the EAR file to install the J2EE application into a J2EE server." Because there is no way for the "application assembly role" to _freely_ pick EJB JAR files from the "enterprise bean software developer". He will be getting global conflicts if an EJB JAR is assembled inside two EARs and deployed in the same server. Do you see my point? Reusing EJB modules accross applications is not possible. Or have I misunderstood something obvious? Cheers, -Kristoffer
I guess I continue my monolog :-) Let's take an example: A large organization uses ejb's to provide an infrastructure layer (messaging, persistence) to all of its products. Products which are realized as appliction ears. They might choose a buildning tool like Maven. Maven lets each project produce at most one artifact (good practice?), which could be an ejb, war, ear, jar etc. Artifacts are uploaded to a repository to be used by other projects. How can this infrastructure layer ever be realized if the specifics are bound to the module itself? Also, applications might have diffrent requirements on the infrastructure. Why not make it possible to let the application worry about assign global resources to logical names instead? Keep the comments coming :-)
This sort of thing is the reason I have become disenchanted with JEE over the past couple of years. It's not the complexity of development that gets me, it's the nightmare of trying to deploy the thing when you have anything other than the simplest of deployment requirements. Deploying and supporting these applications in a production environment with any sort of complexity is a royal pain.
I agree, but im suprised that most big application servers does not support this. I have a hard time understanding that this is an uncommon thing? I mean, layering and reuse of common functions is how we build software, right? As you say, simple deployments such as "mick's webshop" might be peanuts. But telecommunication companys might have diffrent (read larger) requirements.