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.

Related Reading Java Enterprise Best Practices By The O'Reilly Java Authors

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

J2EE has a richer Dependency Web than J2SE. In addition to classes, interfaces, and packages, J2EE has Enterprise Java Beans, JSP pages, servlets, HTML pages, XML configuration files, and .jars.

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).
• We have used Pet Store 1.3.1 for this article.
• Factories always depend on the objects that they instantiate, since they "know" about them.
• A complete Dependency Web includes all transitive dependencies; that is, A -> B, B -> C implies A -> C.

Alex Iskold is a founder of Information Laboratory, a New York based company that created Small Worlds, a Software Analysis and Visualization tool.

Daniel Kogan is a founder of Information Laboratory, a New York based company that created Small Worlds, a Software Analysis and Visualization tool.

Return to ONJava.com.

Copyright © 2009 O'Reilly Media, Inc.