Java in the management sphere, Part 1

A historical look at Java's emerging role in the changing system and network management

Understanding the Java platform and its relation to the problem space of system and network management applications on the Internet is a little like trying to understand the nature of the Web itself. There are no edges, no linear models, no apparently singular, limited set of protocols and APIs that you can neatly stack up, reference, and understand. Movement through the jungle of management technologies is an intricate and complex journey, fraught with peril for the uninitiated. But you cannot underestimate the importance of network resource management, not with Internet usage (now approaching 200 million users worldwide) growing almost as fast as such underlying technology drivers as runaway ecommerce and embedded systems growth. The challenge and the opportunity in this problem space represent fertile ground for the ambitious Java developer as well as the budding Javapreneur.

To understand the relationship of the Java platform to the management space, a bit of history is in order. We will spend most of our time in this, the first installment of our series, laying contextual groundwork -- defining the management space, acknowledging its history and legacy, and setting the stage for Java's entrance into it.

Management and the Internet

Though the Internet started as a research project funded by the US Department of Defense (DOD) in 1972, it was effectively born in its more modern incarnation in 1983, when TCP/IP replaced ARPANET at the DOD.

Given the proliferation of technologies based on Internet-related standards (TCP/IP, HTTP, HTML, CGI, and of course, Java, to name a few), it stands to reason that management software will be involved somewhere in the cycle of any given device's life. From design to manufacturing, distribution to tracking, connection and configuration to repair and recycling, management software of some kind will be employed.

What is management?

What, strictly speaking, is meant by the phrase management software? While some applications might have obvious management functionality, such as the ability to react to a fault on an arbitrary network node, other applications might not. Based on traditional approaches, and, consequently, the capabilities expressed by existing or legacy infrastructures, we can define the high-level functional areas for system and network management:

  • Configuration management: Inventory, configuration, and provisioning
  • Fault management: Reactive and proactive network fault management
  • Performance management: Number of packets dropped, timeouts, collisions, CRC errors
  • Security management: Not traditionally covered by SNMP
  • Accounting management: Cost management and charge-back assessment
  • Asset management: Equipment, facility, and administration personnel statistics
  • Planning management: Trend analysis to help justify a network upgrade or bandwidth increase

Management applications built since the adoption of TCP/IP have tended to add value to a network in one or more of these areas. Noticeably absent from this functional list is the general area of storage management. And while storage management does deserve mention, for the purposes of this discussion, I'll avoid much detail in that particular space. Arguably, storage management is a proper subset of the management space; in order to solve the problems inherent in a storage area network, you must provide and utilize much of a generic management infrastructure. But, until I cover Jiro in a future installment, storage will be treated separately.

The management jungle

The evolution of management frameworks mirrors that of the growth of heterogeneous networks within large organizations. In the 1980s, before Microsoft became the monopoly player on the desktop, most enterprise IT organizations were still focusing on mainframe solutions. The Unix workgroup servers were making headway, and the Unix era was starting to take hold. But the PC was also making inroads. And since PCs often fell below the price threshold for IT approval, they stealthily made their way into organizations despite the lack of IT support; the first line manager of a small group would often have approval authority for the purchase of a low-cost item like a PC. And as soon as one person in the group had one, everyone wanted one. Naturally, it made sense to network these systems together. And soon, as important corporate data started filling those many PC disk drives, support for and management of these desktop PCs started to become important to large corporate players. The days when Unix workgroup servers and desktops had a monopoly on the resources of corporate IT departments were over.

Sun Microsystems was one of the pioneers in software management; the SunNet Manager (SNM), which was first shipped by Sun in the late 1980s, was one of the first entries in the space. SNM provided a cost-effective product that could expand to meet the needs of businesses in the early 1990s, when the networking of smaller systems started to become strategic to commercial health. In November 1997, Sun announced that no further development work would be funded for SNM, though it seems that the company intends for the product to remain a cash cow for the corporation.

Novell, a pioneer in networking itself, was also one of the early entrants in the management space. But its focus on a more proprietary network protocol (SPX/IPX) instead of TCP/IP proved to be an evolutionary dead end.

Today, a number of players exist in the management space, most of whom have provided point-to-point solutions within proprietary frameworks. Computer Associates, IBM (Tivoli), Hewlett-Packard (Open View), and BMC represent the bulk of the big business players when it comes to enterprise-scale management framework packages. Other providers include Platinum, Cisco, Microsoft, and, of course, Sun Microsystems with its Enterprise Manager products. SNM is a framework as well, but is no longer a viable player given the success of others in the market.

The point-to-point approach gets pretty chaotic in a heterogeneous environment. Consider the network in Figure 1. Each node in the network, each network appliance, whether it be an end-user system, a server, a printer, or a network enabler, such as a hub or a router, requires some form of management during its service cycle. Each appliance, coming from a different vendor, has its own interface. As such, players in the management space must provide a solution for each possible connection within the network -- and, just as a network's value increases exponentially with the number of nodes, so do the management possibilities.

Figure 1. Point-to-point management

SNMP: The real management standard

Naturally, standards exist in the management space. Simple Network Management Protocol (SNMP) is probably the best known. The Internet Engineering Task Force (IETF), a large open international community of Internet operators, network designers, vendors, and researchers proposed the protocol as an interim measure, which quickly and quite surprisingly became a standard.

The odd story of SNMP's ascendency began in the second half of the 1980s, when the task force concluded that the rapidly growing Internet could no longer be managed on an ad hoc basis and decided to use OSI's Common Management Information Protocol (CMIP). OSI, the Open Systems Interconnect Reference Model, had been proposed in 1974 by ISO (the International Organization for Standardization) in order to address problems in networking that arise when proprietary approaches prevail. To fit CMIP into the TCP/IP-based Internet, a number of small changes were needed; the modified protocol was called CMOT (Common Management Over TCP/IP). But the development of OSI management took quite some time. Because the IETF didn't want to just sit and wait for results, it decided to further develop the already existing Simple Gateway Monitoring Protocol (SGMP), which was defined in 1987 by a request for comment (RFC) to the IETF to manage the ever-expanding router network on the Internet, and use this modified protocol -- which would become SNMP -- as a short-term solution.

It would probably to useful to understand that the IETF established a working group to develop the SGMP RFC. RFCs are, in effect, the written specifications for a given Internet standard. As a working group begins to work on a standard, it is given a number and status as a draft, indicating that it is still a work in progress. When a standard has been agreed upon by all parties involved, it is given recommended status and becomes the official specification for that standard. SGMP was quite short-lived, given that it dealt only with router management. But it did provide a basis for a broader management protocol, and thus SNMP traces its roots to SGMP. As a short-term solution, SNMP seemed to do the trick. The task force intended to eventually replace SNMP with a structural solution based on OSI's CMIP.

But ... surprise! Standards can become established in many ways, market adoption among them. SNMP was the right solution at the right time. Within a few years, it showed that it was able to manage the majority of devices linked to the Internet; as a result, today's producers of data-communication devices incorporate SNMP by default. The protocol has become the most important standard for network management. The unforeseen success of SNMP was complete in 1992, when the IETF dropped its original plan of replacing SNMP with CMOT. It now seems unlikely that OSI will ever be used for network management.

SNMP uses the User Datagram Protocol (UDP) as the transport mechanism for SNMP messages, as diagrammed in Figure 2. In the TCP/IP suite, the User Datagram Protocol lets an application program send a datagram to other application programs on a remote machine. Basically, UDP is an unreliable transport service; delivery and duplicate detection are not guaranteed. UDP uses IP to transport a message between the machines. It is connectionless, and does not use acknowledgements, establish flow control, or control the order of arrival. UDP messages can thus get lost. But network overhead is also lower with UDP than it is with TCP. Thus, the least intrusive choice for a management protocol would be to use UDP as the transport mechanism. There are clear implications to the management application programmer: SNMP messages can also be lost.

Clearly, the designers of SNMP could have elected to utilize TCP rather than UDP if data loss were a serious enough problem for management applications. But, generally speaking, management issues are not that time critical. If an agent raises an alarm and does not hear back from a known manager in an arbitrary amount of time, it can simply raise another alarm. By the same token, if a manager polls an agent and does not hear back, another effort to poll the agent can easily be made without significant impact on either the manager or the agent, depending upon the nature of the relationship and the resources involved. For most management issues, UDP does the job and has the least impact on the network overall.

Figure 2. SNMP uses User Datagram Protocol (UDP) as the transport mechanism for SNMP messages

SNMP has quite a few advantages:

  • You can use it to manage every system linked to the Internet
  • Its implementation costs are minimal
  • By defining new managed objects, you can expand its management capabilities easily

In addition, SNMP is robust. Despite the occasional lost datagram, management applications utilizing SNMP have proven to be effective in solving early network growth problems in the modern enterprise. Even in the event of partial network failure, managers can continue working -- it's just a small matter of programming, right?

And yet, even with a standard like SNMP, the basic problems of managing a heterogeneous network environment remain. Granted, every vendor on the network can agree to communicate via TCP/IP and agree to use SNMP when it comes to exposed management interfaces. But fundamentally, without common agreement on exposed managed-object properties, gnarly point-to-point solutions will naturally evolve, just as they have over the past decade.

Next month, I will discuss JMAPI and how it could have offered a homogeneous view of the network -- that is, a 100% Pure Java view. But, alas, there are legacy considerations, which, if ignored, will prove the undoing of any well-intentioned design. Java can theoretically improve this situation, but there is a lot of resistance due to significant investments in current solutions. In Part 3 of this article, I will discuss how Jiro might also help.

CORBA, the OMG, and the DMTF

Other standards and touch points to consider in the management space include:

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform