October 2002
Introduction
The Middleware Company is pleased to present a new article series, 'A Look Inside J2EE Patterns', which gives you daily coverage of our newest, advanced course offering. Take a look inside the class, sample some of the patterns, and meet some of the interesting people taking the course. Delve into the intense, technical labs that use the most well known J2EE patterns and some really neat open source tools. Come on in, grab a seat and immerse yourself in a full week of J2EE design patterns. Coverage comes to you daily from the heart of New York City, in downtown Manhattan.
Some of the topics covered on the first day of class were the Pattern Modeling Language (PML), J2EE Architecture Design Concerns, Java Data Objects (JDO), and a unit on the Data Access Object (DAO) Pattern.
The Instructor and Students
Owen Taylor, our instructor for the course, is originally from Canada, and has lived and worked in New York for the past 18 years. His knowledge of server side technologies and architecture is extensive, which is complimented by his keen sense of style and wit. A Senior Enterprise Architect at The Middleware Company, he specializes in B2B, EJB and J2EE training and consulting with special emphasis on webMethods B2B server and BEA's WebLogic Server. Owen has advised several companies on building new e-commerce applications and transitioning their product lines and internal applications to EJB/J2EE. Amongst some of the clients Owen has delivered e-commerce and J2EE architecture consulting, mentoring or training to are Chase Manhattan, Bear Stearns, XOR, Exxon-Mobil, Motorola, and US West. Many of his engagements involved developing application prototypes on-site.
The class consisted of a diverse range of students, everyone from tech leads looking to gain validation of patterns they've already implemented in their systems, to senior software architects looking to fix their company's 'antipatterns' and aquire skills to train their staff, to Project managers who have been using everything BUT EJB in their system, simply using TopLink for persistance. One tech lead came to evaluate and deliberate on patterns and gain a better understanding of how and when to use certain patterns. A young lady in attendance, was a developer for a small startup looking to design a J2EE application from the ground up and run it on Weblogic, which was the app server we would be using in our labs.
Pattern Modeling Language
The first day kicked off with a unit on the Pattern Modeling Language (PML), a high-level modeling tool, syntactically similar to UML, which can be effectively used to conceptualize a group of related J2EE patterns. PML itself is based on the Component Pattern Language created by Markus Voelter, and was developed by Owen and Floyd (Director of TheServerSide) in an attempt to create a way of rapidly and effectively communicating patterns and strategies among developers and non-developers, specifically, non-technical managers who may not be familiar with design patterns.
"PML is a higher level modelling language used to enable the rapid communication of patterns," explained Owen.
The first lab allowed students to try their hand at PML, relating certain 'Principles' with 'Patterns'. One such example related the principle of 'Code Reuse' to the practice of 'Designing Interfaces'. Using arrows, it was shown that using Java and J2EE components depended on 'Using an OO strategy' which ultimately required 'Designing Interfaces'.
The class was taking a liking to PML as they were shown more examples. Given the plethora of patterns in J2EE and the fair number of them that would be studied in the course, PML seemed useful for when you wanted to step back every now and then, and understand how the big picture looked. After all, many patterns are subtle variations of other patterns or practices, so it is useful to know how they conceptually relate to one another.
J2EE Architectural Design Concerns
Owen began the lead into the patterns sections by first running through a quick overview of J2EE Architecture. He described the four tiers of the J2EE architecture (Client, Web, Business, EIS) which was followed by a description of J2EE Components (Servlets, JSPs, EJBs, etc.), J2EE Standard Services (JMS, JDBC, JNDI, etc.), and the various J2EE Platform roles (application assembler, application deployer, tool provider, etc).
"The purpose of J2EE is to build enterprise applications to service many clients", explained Owen. "It's for the good of the many."
The differences between a J2EE system vs a Single-User System were described in context of Objects vs Components. Whereas objects are the essential building blocks of Single-User systems, components are more prevalent in distributed systems. Components are more useful in large-scale, distributed systems because they gain valuable services such as container managed transactions and persistence.
Owen then described 'The Open Closed' principle which states that applications should be designed so that they can be extended without modification to the existing code. J2EE applications should encapsulate variation, and favor composition over inheritance. Components are advantageous because they exist in all tiers of a J2EE system, they have a broad scale and scope, and most importantly, have patterns ingrained in them and their infrastructure. So by working with components, we are setting the stage for J2EE patterns.
JDO
As a precursor, the class was taken through a fascinating section on JDO which included a hands on lab. Owen admitted that the 'coolness' factor was behind the decision to include a section on JDO in the course. Still a controversial technology, it was nevertheless an effective way for the class to get their feet wet with some coding. And what better way to do it than with some cutting edge technology?
JDO is a well-defined standard, although it is still an emerging technology. It's ease of use, support for complex relationships, and it's transactional abilities are some of it's advantages. JDO requires less code than entity beans, since there is no need for home and remote interfaces. What JDO does require is metadata and post-author-processing. JDOs can be developed using plain old java objects, independent from a container. Using byte-code instrumentation, the compiled byte code of your Java objects is 'enhanced' using a JDO vendor-supplied tool.
In the JDO hands-on lab, we were provided with a plain Java class and a metadata.jdo file that described our java object to the JDO implementation. The metadata.jdo file is an xml file used by the JDO engine to perform mapping to relational databases and other persistent stores. As we were using the Libelis JDO implementation, it needed a vendor-specific way of identifying the primary key attritube of our Java class. We therefore had to create a separate, serializable class for this attribute. We first constructed the required table using a database generation tool of our JDO implementation that examines the metadata.jdo file.
We compiled our Java class and then, using Ant, we ran the byte code enhancer which used the metadata.jdo and our generated class to create a new class which implements the javax.jdo.PersistanceCapable interface. To look at this newly generated class, we decompiled it using the jad utility and noticed it's implementation of the PersistenceCapable interface and how all of the get and set methods now performed state management operations. We also noticed the addition of methods such as jdoIsDirty(), jdoIsNew(), jdoGetObjectId(), etc, which are used to manage the persistent object's state and fields within the object. There were also some newly added fields such as jdoFlags, jdoFieldTypes, jdoFieldNames, etc., that were not part of the implementation of the original class file we created.
Patterns, Roadmap, and The DAO Pattern
So what is a J2EE pattern? Well, we know that they are derived from experience with the J2EE platform. The patterns that would be studied in this course would be the ones that were 'tried, tested and true'. Specifically, the emphasis in this course would be to eliminate inter-tier dependencies, decoupling the tiers as it were, allowing for refactoring and reusability.
The roadmap for the course is to start with persistance-layer patterns and then move into the business tier, and eventually into the client and web-tiers.
The Data Access Object (DAO) pattern solves the problem of tight coupling between business components and the data source. When data access code resides in your business components, it is difficult to migrate to a different data source because these business components will also have to be changed. The DAO pattern makes the data source transparent to business components by factoring out data access code out of your business components. This creates more flexible J2EE applications. By abstracting data source access from business components, developers can easily accomodate changes in database or an API, since only code in the DAO has to be changed.
A fairly lengthy and intense lab followed the lecture on the DAO pattern, in which a DAO was used to encapsulate data access by moving persistence code out of a stateful session bean and into a stateless DAO.
What's in Store Tomorrow
In tomorrow's class, we will look at at CMP 2.0 and conduct a lab in which Middlegen and XDoclet will be used to automate the generation of our CMP entity beans. We will also look at Primary Key Generation Strategies such as the UUID and Sequence Blocks, the Read-Mostly Pattern, and we will also study the use of Data Transfer Objects (DTOs).
