Building Dependency Webs in J2EE

J2EE applications are fundamentally complex. A typical system may contain
thousands of EJBs, Java classes, JSP pages, and servlets, which are linked into
an intricate web of numerous dependencies. Managing this complexity is the key
to building stable and flexible J2EE applications. To deal with complexity, it
is important to focus on the structure of the dependencies between all
components in the system. Excessive, unnecessary dependencies lead to chaotic,
unmanageable, and costly systems. On the other hand, stable software is always
well-structured and does not contain extraneous dependencies.

Cutting-edge science supports the importance of dependency-centric thinking.
The emerging Complexity Science studies common patterns and themes in
biological, economic, social, and physical systems. These systems are made of
parts organized into a network, or a Dependency Web. The interactions between
the parts of this network give rise to the greater whole -- the system itself.

From this perspective, any software can be thought of as a network of
components and interactions. Complexity Science says that the structure of the
overall Dependency Web is one of the determining factors in the stability and
longevity of the entire system. This article will illustrate how to apply the
concepts of Dependency Web Theory to your J2EE applications.

Dependency Webs

The structure of a J2EE application is the Dependency Web of components and
the relationships between them. The rule is: if component A knows about
component B, it depends on it. Put differently, if the code of component A
refers to component B, then component A depends on component B.

For example, in Pet Store, customer.jsp contains the following
code:

<c:out value="${customer.account.contactInfo.givenName}"/>

This implies that customer.jsp depends on
CustomerEJB, AccountEJB, and
ContactInfo.

Similarly, the following code in CustomerEJB.java makes
CustomerEJB dependent on AccountEJB:

public abstract void setAccount(AccountLocal account);

You can map dependents and dependencies for every EJB, JSP page,
or servlet. Put it all together to create the Dependency Web for your J2EE
application.

An Example of a Java Dependency Web

Figure 1 -- example of an UML Dependency Web in Java

To analyze a Dependency Web effectively, you need to make sure to identify
all nodes and dependencies correctly.

First, let's look at a simple example. Instead of considering all nodes of a
J2EE Dependency Web, let's consider the basic ones that come from the Java
language. In Java, the nodes are Classes, Interfaces, and Packages. Classes and
Interfaces are linked by means of standard UML relationships: Uses, Contains,
Extends, and Implements.

Figure 1 shows an example of a piece of Java code translated into its
corresponding Dependency Web. The class JFrame extends
Frame and implements SwingConstants, so it depends on
the Frame class and the SwingConstants interface.
Also, the keyEvent method of JFrame takes a
KeyEvent class as an argument, which makes JFrame
dependent on KeyEvent. The method getGlassPanel of
JFrame returns Component, which implies that
JFrame depends on the Component class. Finally, since
JFrame contains the variable rootPane of type
JRootPane, the JFrame class depends on the
JRootPane class.

An Example of a J2EE Dependency Web

Let's take a look at an example of a J2EE Dependency Web from Pet Store. We
will consider the dependencies in the neighborhood of the
CatalogDAO interface.

We will only focus on the dependencies that are specific to the Pet Store
application; that is, we will ignore the core Java and J2EE classes and
interfaces. We will also ignore the dependencies on inner classes and
exceptions.

Figure 2 -- CatalogDAO dependencies

Figure 3 -- CatalogDAO dependents

Figure 2 shows how the method signatures in the CatalogDAO
interface give rise to the four Uses dependencies. Based on this code,
CatalogDAO uses the Category, Page,
Product, and Item classes.

In Figure 3, you see extracts from four different files that show the
dependents of the CatalogDAO interface. First, we see that
CatalogDAOFactory returns CatalogDAO in the
getDAO method. GenericCatalogDAO depends on the
CatalogDAO interface because it implements it.
CatalogHelper and CatalogEJB both depend on
CatalogDAO because they contain an instance of this interface.

In any Dependency Web, if component A depends on component B, we say that A
and B are one degree away from each other. So all immediate dependents and
dependencies of the CatalogDAO interface are considered to be one
degree away from it. However, the complete Dependency Web of
CatalogDAO may be very large, since it includes all objects that
are in some way linked to this interface.

We will now show how you can build the second degree Dependency Web for
CatalogDAO. For this, we simply need to consider the dependents
and dependencies of the objects that are one degree away from this
interface.

For classes Category, Page, Product,
Item, GenericCatalogDAO, and
CatalogDAOFactory, the dependencies are identified in exactly the
same way that we described above. We want to focus instead on additional
dependencies that are induced by CatalogHelper and
CatalogEJB.

The CatalogHelper is used in several JSP pages. For example,
the product.jsp contains a use bean tag that refers to
CatalogHelper bean (see Figure 4), so product.jsp
depends on the CatalogHelper.

Figure 4 -- product.jsp uses CatalogHelper

Figure 5: ejb-jar.xml uses CatalogEJB

Figure 5 illustrates yet another kind of J2EE dependency. The XML deployment
descriptor ejb-jar.xml for the CatalogEJB refers to
the bean and, thus, depends on it.

If we put together all of the described dependencies, we get the following
Dependency Web:

Figure 6 -- a second-degree Dependency Web for CatalogDAO

Legend:

Note that arrows always point from the independent object to dependent,
creating the direction of the flow of change.

Let's look at the interdependencies between the classes that surround
CatalogDAO to make sure that we understand what we are seeing.
GenericCatalogDAO and CloudscapeCatalogDAO both
implement the CatalogDAO interface. This implies that they should
depend on Item, Page, Category, and
Product, and this is exactly what we see in Figure 6.

Thinking in Terms of Dependency Webs

In this article, we have shown how you can construct a simple J2EE Dependency
Web. Dependency Webs are representations of the intricate networks of
dependencies within your software. Thinking about dependencies helps to
simplify complex J2EE applications.

Dependency Webs are important because they offer compact visual
representations of local and global structures in our systems. While we are
buried knee-deep in code, we often forget to think about the big picture. The
visuals of the Dependency Web are always informative and revealing. By looking
at and analyzing Dependency Webs, we often uncover the unexpected or
unnecessary dependencies.

Notes

For a broad introduction to Complexity Science see Complexity, by M. Mitchell Waldrop (ISBN 0671872346).