I've prided myself on being able to accurately identify those technologies with significant future potential. I jumped on the Java(TM) bandwagon early on since I could envision the possibilities. It was the same with Apache and Java(TM) Servlets. I've also been able to identify the likely losers, things like the Distributed Computing Environment (DCE) which was too big and too complex for widespread deployment. Perhaps I should have given the J2EE(TM) documentation more than a cursory glance!
When I had some downtime recently, I dived into a book on Enterprise Java Beans. This was a skill missing from my repertoire but one which seemed to be increasingly in demand. This book provided some insight into how the J2EE(TM) platform provides some practical advantages. While there are still some portability issues to be worked out (Version 1.0 vs Version 1.1,) this is definitely a case of the whole being greater than the sum of its parts.
I applied my knowledge to a real-world project recently and had to gain experience with IBM's WebSphere and BEA's WebLogic , both J2EE(TM) servers. While there is a fairly steep learning curve on both of these products, and they operate quite differently, I was amazed at the portability of the EJB jars between these platforms. I was actually able to develop locally using WebSphere and deploy on a WebLogic server with relative ease. Not only that, I was using a LAN-connected Oracle RDBMS for development while production was using Informix.
Granted, portability was one of the main attractions of Java in the first place. Extensions such as JDBC also stressed portability, permitting relatively easy reconfiguration of the code to use different drivers and connection strings. The difference with J2EE(TM) is that you can bundle your beans into a single jar file with appropriate external references which use abstract classes such as DataSource. It then becomes the job of the deployer to map these references to the appropriate resources according to the particular environment.
Another huge advantage is that the deployment information is included in the jar file as an XML file. It is thus human- readable and can also contain comments. The individual responsible for deployment need only read the file in order to determine the type and meaning of the external references; absolutely no knowledge of the implementation details is required. The mapping is local to the deployment server and the mechanisms used to perform this step are completely transparent to the developer.
This separation of responsibility extends to the inclusion of JSP in the J2EE(TM) specification. The idea is that the web designer can generate all the HTML code associated with the served pages and merely insert the dynamic content in the appropriate places. Cascading Style Sheets (CSS) can be used to ensure a consistent look across a set of pages or even an entire site. Web designers can use their favorite content editors and don't have to provide the HTML to the servlet writers.
There's a bit of a cross-over here. I felt that anything which could be done with JSP could also be readily achieved using servlets. Interestingly enough, JSPs are often compiled down to servlets by the server! The way I've approached similar situations in the past is to request HTML from the web designer which includes tags for where they want the dynamic content to be inserted and read their code into a servlet which performs the insertion and passes the completed page back to the requester. With JSP, the web designer creates the HTML and uses special tags to "pull" content into the page from EJBs and return the completed page. Six of one, half-dozen of the other.
In the J2EE world, EJBs are packaged into jars. JSPs and servlets are packaged into web archives files (wars.) Finally, on or both types can constitue an application and be deployed as an enterprise archive (ear.) The ear file can also contain client components (Java applications) which can utilize the resources of the J2EE server. The following diagram shows the heirarchical layout of an example ear file.
So J2EE(TM) is a lot more than a glorified web server. Interestingly enough, the web server portion of IBM's WebSphere is based on Apache. In addition to providing a name service and a container for JSPs, EJBs and servlets, the server leverages additional facilities provided by vendors. A perfect example would be the use of database connection pools. Rather than the modules having to worry themselves with explicitly using a connection pool class, the deployer can simply perform the mapping from DataSource to the appropriate class.
Additional features provided by some vendors include clustering and load balancing. This makes it an even more compelling platform. With so many capabilities in a single architecture plus location independence and scalability, it makes the previous incarnations pale in comparison. The only major obstacle to wide-spread deployment I can foresee is the somewhat steep initial cost. Even so, the many advantages outweigh this drawback if the goal is to deploy and support mission-critical web applications.
The verdict? It's definitely not hype, but it might not be right
for every environment. It's like so many other technologies on
the market. If you really need the powerful capabilities which
a J2EE(TM) server can provide then it's a fine choice. If
your demands are less stringent then you can likely survive
with an Apache/JServ platform with a suitable back-end RDBMS.
I believe we'll be seeing many more J2EE(TM) servers on the 'net
in the near future and it wouldn't surprise me if IBM is able
to unseat BEA as the leader in this market.
DISCLOSURE: I am not an employee of IBM and the opinions presented here are mine alone.
March 23rd, 2002
Copyright © 2002 by Phil Selby