Exploring the EAR

 

 

 

When a developer hands their application to the WebSphere administrator for deployment, the enterprise application is delivered to the administrator as an EAR file. 

What is an ear file? 

Well, in simplest terms, it’s a zip file renamed with a .ear extension.

If you double-click on any ear file and choose to open it up with WinZip, the file will open up, and you can inspect the contents of the ear file.

A lot of things go inside of an ear file, after all, an ear does represent an entire enterprise application.  Subsequently, and ear will contain EJBs, Servlets, JavaBeans and even a bunch of XML files.  It only makes sense that we would compress all of these items into a single file and deliver that single, convenient zipped up file to our administrator.

“An ear is just a zip file with a .ear extension”

Of course, the Java world being what it is, simply calling  a “zip file” a “zip file” would be far too straight forward.  Instead, we have to give it a cute little name, such as ear.  Someone figured that ear could stand for Enterprise Application aRchive, and everyone would get a kick out of the cute little name.

Now an ear file itself isn’t too interesting.  What is interesting is all of the things zipped up inside the ear file.

Opening up an ear file with WinZip or any other decompression utility will reveal a variety of war files, jar files, and couple of xml and xmi files as well.

An ear file will contain at least one web module or one EJB module.  Once that minimum requirement is met, any additional EJB or web modules can be added.

The xml file, named application.xml, is the deployment descriptor for the ear.  If you were to open up the deployment descriptor and take a look at it, you’d see that all it really does is say “hey, I’m an enterprise application, and I contain a bunch of web modules and EJB modules, and this is what their names are.”

“Each ear file contains a deployment descriptor named application.xml”

There’s also an xmi file in the root of the ear which contains information about “IBM extensions” to the J2EE spec. 

What is an IBM Extension?

Any vendor, so long as they have implemented the J2EE spec properly, are allowed to go beyond the spec an add features they think users of their application server might find helpful.  Extensions represent a competition point – if a vendor has a bunch of extensions that make their server easier to use, people should flock to that vendor.

Nevertheless, the IBM extension file for the ear really isn’t that interesting.  We’ll see some interesting extensions when we crack open the EJB and web modules.  The interesting part of an ear file is the war files and jar files the ear file contains. At the ear level, the only extension an assembler can specify is the reload interval in seconds.

“Extensions are additions to the standard J2EE deployment descriptors.  They enable the use of enterprise extensions, older systems, or behavior not defined by the specification” –Application Assembly Tool

 

 

What is a WAR file?

Did I mention the Java world’s propensity for taking regular zip files and giving them cute and cuddly names?

WAR is an acronym standing for Web Application aRchive. 

All of your dynamic web content, which includes all Java Server Pages, all compiled Servlets, supporting Java classes, and a couple of other files including a deployment descriptor and an extension file for the web module, gets zipped up into a single file before deployment.  When you change the extension of your zip file to .war, you have a J2EE web module that is ready for deployment.

All of your dynamic web components are packaged up in a WAR file.

WAR, what is it good for?

So, if Bruce Springstien ever asks you “war, what is it good for?” you can simply reply “it’s great for packaging all of your web based components into a single, simple, easy to manage zip file.”

Like the ear file, a war file will contain a deployment descriptor, although the deployment descriptor in the web module is named web.xml.  If you crack open a war file, you’ll also notice the compulsory extension and binding files named ibm-web-ext.xmi amd ibm-web-bnd.xmi respectively.

Whereas the deployment descriptor for the ear file points to the various web and EJB modules it contains, the deployment descriptor for the web module points to the various Servlets that are to be deployed and managed by the web container. 

The web.xml file of course can get more complex than simply pointing to the Servlets that it contains.  The deployment descriptor for the web module includes such things as how Servlets are to be secured, and how long a session will last before it times out, but the most important part of the web.xml file is the listing and mappings for the various Servlets it contains.

The deployment descriptor for the web module is read by the application server when the application starts, and the web.xml file describes to the web container how to manage the various web based resources contained within the war file.

 

What type of extensions exist for a web module?

 

An IBM web module goes beyond the specification by allowing an administrator to enable such things as:

Ffile system reloading,

Fenablement of directory browsing

Fserving Servlets by class name

You can even use the IBM extension file to enable a file serving Servlet that allows your application server to serve up html, pdf, zip or any other type of non-java based file from the application server.

Why would you enable the file serving Servlet?

For the most part, static content should be delivered through you web server. Web servers are very efficient at serving up images, html files, zip files, pdf files etc. 

Your application server should be used to serve up dynamic content through JSPs, Servlets and other Java components that require a good deal of logic.

Now, having said that, there are times when you might be interested in serving up static content through your web module, the most common reason being security. 

“Static content should be handled by the web server”

The mechanism that secures Servlets and EJBs does not extend itself to the web server.  As a result, if you want to secure content that resides on your web server and make that content part of a single authorization environment that integrates with the WebSphere Application Server, you have to ask IBM to sell you another product such as Tivoli Access Manager (TAM) or WebSeal. IBM is very good at selling you new products.

An alternative to buying these other products that create a single authorization environment between your web server and your application server is to move your static content into your web module. You can then secure your web module and subsequently the static content inside..  Static content then becomes the domain of the security service of the WebSphere Application Server.

What is the implication of including static content in a war file?

The benefit to doing packaging static content in a war is having your static and dynamic content secured by a common security mechanism that doesn’t involve any third party products. 

The drawback to packaging static content in the war is that you are now burdening your application server with the task of acting like a web server.  This may introduce significant performance and scalability issues down the road. 

Your web server is incredibly efficient at serving up static content.  As much as possible, we should let the web server do what it does best, and keep static content away from your application server.

Why might you serve Servlets by class name?

Older applications invoked a Servlet by using the entire package and class name of the Servlet in the URL.  Enabling the ability to serve a Servlet by class name allows clients to call a Servlet by using an address such as:

 http://localhost/webmodule/com.myapp.servlet.MyServlet 

 

You might enable the feature to server Servlets by class name in order to support older Servlet applications.  However, serving Servlets by class name bypasses the application servers security service, opening a security hole that could easily be penetrated by a clever hacker.

Migrate your older applications as soon as possible, and get out of the habit of serving Servlets by class name.

Should you precompile your JSPs?

Precompiling your JSPs is a good idea.  Doing so will alert you to any compile errors that exist within you JSP files early and you can fix those problems before you slam head first into a runtime exception.

Don’t get fooled into thinking that this will make your files run faster on the application server though.  Despite procompiling JSPs, the application server will still turn any updated JSPs into a Servlet the first time the JSP is encountered, then compile the Servlet it creates, and load the Servlet into memory.  Precompiling does not always sidestep this.

Precompling JSPs won’t necessarily make your applications any more responsive at runtime. It will alert you to any compile errors in your JSPs, which is indeed a valuable feature.

What is a jar file?

A jar is, once again, just a zip file with the extension changed to .jar. It just sounds so cute to say that we “package our JavaBeans in little jars.”

When inside an ear file, a jar file can be one of three types:

Fejb jar file, containing all the resources needed by an ejb module

Fa java jar file, simply containing Java code needed to support web modules and ejb modules

Fa client jar file, containing code require to support a J2EE compliant stand alone java application

The ear file differentiates between ejb jar file, client jar files and java jar files by looking in its own deployment descriptor named application.xml.

What is so special about an ejb-jar file?

A jar file is an ejb-jar file if it contains EJBs.  Okay, maybe that’s too simple a definition.

An ejb-jar file will contain a special file named ejb-jar.xml. As you might guess, this is the deployment descriptor for the ejb module. 

Whereas the deployment descriptor for a web module points to the various Servlets the web module contains, you won’t be surprised to discover that the deployment descriptor for the ejb module essentially points to the various EJBs that are contained within the jar file. 

The deployment descriptor also specifies whether an ejb is a message bean, entity bean or a session bean. Again, this is the information the application server need to know in order to properly manage the EJBs you have created at runtime.

The ejb-jar.xml file describes hot to manage the EJBs you wish to deploy at deployment. I guess that’s why they call it a ‘deployment descriptor.’

And not unlike a war file or the ear file as a whole, the ejb jar file also contains an extension file.  For EJBs, IBM extensions include the ability to support for ejb inheritance, and also relationship mappings for container managed persistence (CMP) beans.

A WebSphere EJB jar file might also contain a schema map, a field attributes file and a ddl file which will create database tables to support your CMPs if you don’t already have the underlying database created.  A WebSphere ejb module is a very clever thing.

The schema map and ddl files are provided just in case you want to create database tables based upon the container managed persistent beans you’re using, although they are not necessary for the day to day execution of your EJBs.

What is a client jar file?

A client jar file simply contains the Java code required to run a stand alone Java application.  A client jar file also contains a deployment descriptor which generally contains nothing more than a link to the Java class that kicks off the standalone application.

What is a utility JAR file?

Regular Java Jar files may also be included in the root of the ear file.  Java jar files placed in the ear simply contain Java code that might be shared between web modules and ejb modules.

Utility JAR files are incredibly important because they make it possible for ejb, web and client modules to share the same set and version of Java classes.  Common components used by EJB and web modules are usually packaged together in a regular Java JAR file that resides in the root of the ear file, alongside all of the client, web and ejb archives.

Why would an ear file have more than one web module?

An ear file can contain any number of web and ejb modules.  This begs the question, “should I deploy all of my web content in a common war file, or should I separate my web content into separate war files?”

Well, application partitioning is an inexact science, but there are some rules we can follow.

Take for instance a scenario where your enterprise application provides web access for both your human resources (hr) and accounting departments.  Should this web application be separated into an accounting.war and hr.war file, or should everything be packaged together into a single hraccounting.war file? 

When it comes to application packaging, there are no ‘right answers.’  There are only ‘wrong answers.’ The best we can do is try not to get the wrong answer.

Here are a few important points to consider when developing and subsequently deploying an application.

The Session Problem

Sessions, a mechanism for storing transient information about the client interacting with your website, are not shared across war files.  If session information needs to be shared amongst hr and accounting modules, splitting your Servlets and JSPs across multiple war files is going be a problem.

 

The Common ServletContext

Servlets and JSPs can share information between each other by using a special scope named the ServletContext.  If you are placing information in this ServletContext, such as the IP address of the accounting database, you  probably don’t want you’re hr application to be able to access it. 

The ServletContext is not shared between war files. If you do not want one set of Servlets to see another set of Servlets ServletContext, you’re going to have to separate the two applications into separate war files.

Forwarding to a JSPs

A common design pattern is to have a Servlet handle a request, and have it forward to a JSP for display.  However, Servlets can only forward to JSPs packaged inside of a common war.  You can use a special method called ‘redirect’ to send a user to a JSP in a different web module, but the redirection becomes a brand new request, and information about the initial request and response is lost.

Managabitly

Manageability of your applications must always be a prime concern.  The cost of any application is not how much money is require to develop it, or the hardware required to run it, but is instead the cost of managing that application over the long-term.

If the two applications you are packaging are large, separating them into two separate war files would make them much easier to manage.  Modularity helps facilitate maintainability