|
|
 |
Day 1 |
Day 2 |
Day 3 |
Day 4 |
Day 5
By Nitin Bharti
April 2002
Discuss this article
Introduction
TheServerSide presents "A Look Inside EJB for Architects", a glimpse into The Middleware Company's most advanced and 'prestigious' course. This series of articles will be your window into a class full of intense discussion on some of the most essential topics pertaining to EJB and J2EE. Everyone from seasoned J2EE developers to the J2EE savvy have descended upon downtown Chicago for this architectural pilgrimmage. Coverage comes to you daily from the heart of The Windy City.
The first day of the course kicked off with an impassioned Q&A; session on the merits and drawbacks of clustering your J2EE application across multiple servers. Load balancing and failover, using remote local transparency, were established as the two primary benefits while high network traffic was seen as the main drawback. As the class settled down somewhat, the lecture progressed into J2EE Project Management, the value add of EJBs, and a fascinating comparison on when to use entity beans vs session beans and JDBC. At the end of the day, I spoke with the instructor to get an idea of what the essential value add is of the course and what particular skills students can expect to aquire by taking it.
The Instructor, J2EE Project Management, "To EJB or Not to EJB"
Partha Nageswaran, instructor for this course, holds three masters degrees, but it is his extensive experience working on large projects for companies such as LEC, BMW, and Honda, his Senior consultancy experience with IBM including his designing and developing of the core server runtime component for Websphere Enterprise, and his architecting of several web applications using J2EE technology, that truly make him an 'authority' on the subject. At the end of this course, said Partha, "you should be well-equipped to architect true middleware apps."
The first part of the day focused on the various challenges of J2EE Project Management. Some of these challenges include project staffing, assembling a development team, designing use cases, and determining which application server to use. The last of these points spawned a series of deeper questions with respect to J2EE: Is a J2EE application server even necessary for your project? Is an application server necessary at all? Perhaps you can get by with a web server using CGI scripts. At this point it seemed that the course was about "How NOT to use J2EE", but in reality, these questions are critical in determining if and how the vast array of J2EE technologies can actually be implemented for your particular project. Nevertheless, Partha's message seemed to be clear: "Don't use a sledgehammer to crack a nut."
If a company does decide to go with J2EE over .NET, another set of important decisions needs to be made that is in harmony with your company's business requirements for the project. Some of these key decisions are what type of framework to use, how the UI will be constructed (web-based or thick-client interfaces), which Model-View-Controller paradigm will be used (i.e. Command Pattern, MVC2, or JSP's using taglibs). Choices, choices, choices.
"To EJB or not to EJB" was another key area of discussion. The value of the EJB layer was made clear. By deciding to use EJB's you empower your application with a 'declarative' quality of service provided by the container: The container takes care of distributed access and distributed transactions. And of course the obvious benefit of going with EJB's is the separation of your business logic from your presentation layer.
As the class progressed, and Partha drilled deeper into the 'middle tier', several architectural choices, or design decisions presented themselves: should you go with entity beans or session beans using JDBC? The advantages and disadvantages were presented for both. The pros of entity beans are that they can be cached, and they're loosely coupled with the schema whereas session beans using JDBC calls are tightly coupled with the schema. Any change in the schema simply requires an adjustment of the appropriate XML file to update relationships between entity beans, whereas with session beans using JDBC, entire SQL statements may have to be rewritten within the code. One of the main disadvantages with entity beans is performance as expressed by the 'n+1' problem. Whenever a client calls the get() method on an entity bean, the ejbLoad() method is automatically called, which results in a direct call to the database. Another problem with entity beans is that when a large number of rows are instantiated, an entity bean is created for each row and a stub is returned: imagine instantiating a million rows. Large resultsets being returned are not a problem with session beans using JDBC because these are all taken care of through collections. There is a significant gain in performance by using session beans with JDBC.
The Students, The Course, and Things to Come
The student backgrounds for this particular class are very diverse: Developers from The Bank of America looking to enhance performance of their J2EE application and integrate it with a legacy system, former C++ programmers looking to increase their J2EE skillsets, and developers from a small IT department of a wireless firm wanting to overhaul their outdated app server with current J2EE technologies. When asked what the job prospects are for those completing the EJB for Architects course, Partha replied, "mostly design and architecture jobs, analysis and design jobs in the J2EE space."
What differentiates the EJB for Architects course from other TMC course offerings is that it is more discussion-oriented and less rigid in adhereing to the course syllabus. The "Mastering J2EE" course for example is paced with labs and exercises with limited time for open-ended discussions. Although even here there is a course outline and timeline within which certain topics have to be covered, some of the most fascinating discussions today were spawned by particular architectural issues raised by students based on real world experience.
Day 1 saw no shortage of these 'digressions' which covered various topics from clustering to a detailed look into XA, an organization that defines the XOPEN spec, which essentially dictates how a server can participate in distributed semantics.
Some upcoming topics of interest include EJB Design Patterns, JDO, Message-Driven beans, SOAP and Web Services. These will surely stir up the 'high winds' of critical debate.
On the second day of coverage, we will look at various design patterns that are discussed such as the Strategy Pattern and the Facade Pattern, the Data Transfer Object Pattern, and the Message Facade.
Student commentaries will also be provided on how these and other design patterns and technologies may potentially help them in their own projects.
PRINTER FRIENDLY VERSION
|
