Since IBM began shipping the 4.0 version of WebSphere Advanced Edition, the server and documentation imply that you must package up all of your objects and stick them in either an Enterprise Archive (EAR) or Web Archive (WAR). IBM's WebSphere Studio Development Tools are built around the WAR and the EAR. When you create a project in any of the WSxx or WDSC tools, two major components are created: a directory path for your source objects, and a directory that will contain your EAR file.
Using this approach, a WAR file is created for Web-based objects, including your JSPs, HTML pages, images, etc. At deployment time those objects are gathered up and bundled into the WAR file. Any Java objects such as your model objects, EJBs, etc. are bundled up and stuck in the EAR as is your WAR file. The bottom line when all is done is that you end up with an EAR file containing a WAR file, JAR files (possibly), and discrete classes. Included in the EAR and the WAR are the subdirectories that were created as you developed your application.
You are then supposed to publish your EAR file to a directory on your target machine then via the WebSphere console install the application bundled in the EAR.
WebSphere then unpacks the EAR file, creating all of the subdirectories that you created on your PC. When it encounters the WAR file it also unpacks it, creating all of its subdirectories.
Doesn't it kind of look like the EAR and the WAR are nothing but suitcases that you stuff your application objects in to send to the server where they are unpacked? That is exactly what happens. Major hardware and software companies such as IBM, Sun Microsystems, Hewlett-Packard operate the J2EE consortium. Their bias is that of a software company selling application software. For a vendor to ship a single EAR file that a user installs and the server unpacks eliminates a lot of installation support issues and hassles.
Unfortunately, for the commercial developer this introduces management issues that make the in-house development and deployment of Java applications a nightmare. I don't know about you, but my users want us to make small cosmetic changes that may affect a single JSP. How many times do you change one word in the JSP?
Lets first look at exactly what EAR, WAR, and JAR files are. They are nothing more than ZIP files using the file format and compression schemes dictated by PKzip. You can unpack an EAR file using WINZIP32 or any other PKzip utility. A WAR file contains a file called web.xml that allows you to control the behavior of specific resources within the application server. This includes creating object alias's, instructing the server to load the object on server startup and other features. It is NOT required to run your applications. The EAR file contains two XML files: the Deployment Descriptor File and the Application Descriptor file. Those get involved with EJB development.
My apologies to IBM's WebSphere server developers, but the WebSphere Application Server is nothing but a bunch of Java classes and APIs (mandated by the Servlet, JSP, and EJB specification) that sit inside an OS/400 JOB (NT or Unix Process) and run in the JOB in a JVM that is loaded into the Job at startup.
While IBM encourages you to stick your objects in your EAR and let WebSphere unpack them in to an IBM controlled directory, the reality is your programs run in WebSphere's JVM. You may modify the WebSphere classpath for your server and put objects anywhere on the machine.
To create an application you must deploy an EAR or a WAR, but this can contain a single dummy class. You may then manually control the classpath and put objects anywhere you wish.
My developers have come up with a strategy of putting application-specific objects in an EAR file and deploying the EAR, but carefully separating "shared" objects (those objects used in many applications) and placing them in a directory tree that we called "Shared".
We also use our change control system to manage individual objects after we first deploy our EAR so that a developer may check out change and check in a single Java object.
I'm limited on space in this tip, but I will write more on this issue in future tips.
-------------------------
About the author: Bob Cancilla is managing director of IGNITe/400, an electronic iSeries 400 Internet users group. He is also author of the book Getting Down to e-business with AS/400 and IBM eServer iSeries: Built for e-business.
=======================
MORE INFORMATION
=======================
- Eliminate WebSphere team deployment headache
IBM made some significant enhancements to the Administrative Console with the introduction of V4.01 Advanced Edition. Unfortunately, the product's origins on the NT platform present challenges to multiuser machines like the iSeries that were not anticipated or handled well by the cross-platform development team, says e-business expert Bob Cancilla.
- Introduction to QShell: Administer Java applications
IBM has provided more than one way to do most of the administrative tasks you need for Java applications. Some of them can just help manage files; others do much more.
- WebSphere/Web development discussion forum:
Post your WebSphere and Web development questions here. You'll get advice from our site experts who monitor the forum, as well as ideas and suggestions from other users.
- Best Web Links on Web Development
