Most software is rigid in nature, making it difficult to reconfigure and modify without costly upgrades. Can software be made more plastic or malleable? Stephen Morris demonstrates how aspect-oriented programming provides an important tool in the race to achieve plastic software. If IBM's on-demand computing spreads across the industry, this requirement will become the rule rather than the exception. Will you be ready?

Like this article? We recommend

Like this article? We recommend

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:

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.

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.