Software Plasticity with Aspect-Oriented Programming

• By Stephen B. Morris
• Sep 16, 2005

Like this article? We recommend
Aspect-Oriented Software Development

Just about all objects in nature are flexible—it's part of survival! Excessive rigidity and hardness tend to contribute to breakability: Concrete is strong in compression but pulls apart. The present generation of software tends to be brittle and difficult to change. Because this lack of plasticity is at odds with the need to safely maintain and extend complex software products, we need to improve the plasticity of software.

Aspect-oriented programming (AOP) provides a convenient mechanism for dipping into Java code, taking a look around, and applying a focused fix or upgrade. AOP can help in multiple situations:

• A problem is located but insufficient logging detail is available in the deployed code.
• You need to be able to rapidly deploy modifications to operational software.

In this article, we'll review the area of in-field debugging and repair of code that has been operationally deployed. Along the way, we'll also see some concepts from the emerging discipline of software architecture and the highly dynamic IBM initiative of on-demand computing. The latter is a potentially revolutionary change to the way in which software will be deployed.

Software Developers and the Value Chain

Software development metrics are changing; it's no longer enough to know Java or C++, SQL, and some UML. Increasingly, developers have to be able to formulate solutions in completion or component form. Moving up the value chain is not a matter of choice for developers. What to do? One of the best investments a developer can make is gaining a solid knowledge of design patterns. Another beneficial area for study is architectural patterns. Software architecture patterns—just like design patterns—are a powerful tool for creating solid software solutions. One such pattern is used for creating software in layers; this allows for demarcation of special-purpose APIs such as Sun's Java Dynamic Management Kit (Java DMK). The layering pattern facilitates swapping out and replacing this API. You may have been using the layering pattern for years, but many programmers are unaware of the need for some associated architectural quality attributes: scalability, security, and modifiability.

Network-Management Domain Notes

Consider the following excerpt from a generated Java DMK file, called RFC1213_MIBOidTable.java:

//Metadata definitions for managed objects of interest
new SnmpOidRecord("ifInOctets", "1.3.6.1.2.1.2.2.1.10", "C"),
new SnmpOidRecord("ifLastChange", "1.3.6.1.2.1.2.2.1.9", "T"),
new SnmpOidRecord("ifOperStatus", "1.3.6.1.2.1.2.2.1.8", "I"),
new SnmpOidRecord("ifAdminStatus", "1.3.6.1.2.1.2.2.1.7", "I")

Don't worry about the details; we'll focus on the general overview. Basically this file contains a generated Java class that can be used to gain access to network-management data. For example, the entity ifInOctets indicates the number of bytes that have been received at a selected network interface.

Figure 1 illustrates a layered management application that employs Java DMK (in the bottom layer) to access the network data. Typically, the application in Figure 1 is a large, complex beast that has grown over the course of many years. As new devices and technologies such as MPLS are added to the network, the management system software is modified to bring those devices and technologies into the fold. It's not uncommon for the management application to include several programming languages and many millions of lines of code. The network at the bottom of Figure 1 may be that of a service provider or a large enterprise; in any case, it contains lots of devices. The network data access classes in Figure 1 are used to read data from and write data to the network.

Figure 1 A layered network-management application.

Architectural Layering Patterns

Layering has been used for decades in the area of networking, as evidenced by the OSI seven-layer model. This model has enabled networks to mature and develop over the years as new technologies develop. The three boxes in Figure 1 represent architectural layers. The Network Data Access Classes layer is the one we'll look at most closely. Its purpose is to present a generic technology-independent interface into the network for the Management Application layer.

Once a network exceeds a certain size, it becomes necessary to deploy automated network-management software, such as that in Figure 1. But this software ain't cheap! Often, the cost is on the order of $10,000 per managed node—if your network has 100 routers, the price is $100,000+.

The application uses Java DMK to dip into the network elements and retrieve real-time data. This data can then be used to update a GUI or for inclusion in a report.