Some Upgrade Architectures

I assume that Figure 14.1 encompasses the main points of your legacy system: some form of non-WBEM protocol is used between management workstations and the device being managed. A protocol conversion is then carried out (which may be as simple as removing transport protocol headers) before the messages are passed to the on-device management software. This software has some model of the device (possibly implicit in a long C++ case statement, perhaps an SNMP MIB) which it uses to respond to the operator's command. Figure 14.1 could, of course, with a little relabelling, be a picture of WBEM/CIM or, indeed, almost any other management system.

Figure 14.1: A Legacy Management System

The question then is, "What do you want to do with this system?" I consider here the following scenarios. Although these cannot cover all possibilities, I have chosen them so that their components are widely applicable .

• Scenario 1. The on-device code is ancient, poorly documented and the person who wrote it has left the company. It cannot be touched without a major investment in reverse engineering, rework and retest. Customers are demanding service-level management and the on-device code makes it difficult to manage the new generation of cards which your hardware development team is currently designing. I am sure that this scenario is unfamiliar to you ”assume that I have included it for other readers.

• Scenario 2. The off-device management system is SNMP-aware and is being used to capture and display SNMP traps (i.e., alarms). Configuration management is currently done through a command-line interface that may be enhanced but not replaced because it would break many tools which have been developed over the years for automated management. While retaining these two interfaces, there is also industry pressure to provide an additional, WBEM-based interface. The intention is that the legacy system will be capped and, over time, evolved to WBEM/CIM.

• Scenario 3. The code which actually interfaces to the hardware of the device is supplied by the hardware manufacturer and source code is not made available. Although it is intended to move to a full WBEM/CIM-based management system, alarms from these devices will still be raised as SNMP traps.

Scenario 1: Untouchable Existing System

This situation appears to be very common, certainly in the telecommunications industry. My approach here is to encapsulate and freeze the existing system and gradually evolve it, subsystem by subsystem, to the new world, starting with the more complex subsystems.

I have illustrated the first step in this in Figure 14.2: a WBEM server has been introduced on the device and a CIM model founded on the DMTF's core and common models has been designed, covering not only existing management functions but also the new service management and any other device management which the legacy system doesn't cover. In effect, we are going to use the legacy management system as a large and opaque CIM provider for handling the low-level device management, with a small protocol conversion provider put in front of it to support the legacy protocol or API.

Figure 14.2: Encapsulation of a Legacy System

Unless the existing on-device management system is completely ad hoc, it is likely to have some mechanism for addressing components uniquely (the equivalent of CIM's object path or SNMP's OID). If this mechanism is present, then we can make use of the mapping string concept to simplify the interface between the new provider and the old management system. Note that, although the normal use of mapping strings is to map CIM properties to international standards, this is not necessary ”you can use them to map CIM properties to your own object identifiers.

An operator command then arrives at the WBEM server, couched purely in terms of the CIM model, providing the management compatibility with your competitors that your customers are demanding. For elements supported by the legacy system, the WBEM server passes the command to the appropriate provider which accesses the mapping strings. If the original interface was symmetric and clean, the presence of the mapping strings allows the provider to be coded in a reasonably generic manner. If the original interface was not clean, then even with the mapping strings, you may have to write some nasty code. In either case, the provider can translate the command into a form suitable for the legacy system.

This encapsulation means that the legacy system can initially remain unmodified; it need have no knowledge of the presence of the WBEM server or the service-level commands. Similarly, the WBEM server has no special knowledge either ”it simply sees a provider with a standard interface. This technique has drawbacks, primarily the amount of memory required to hold both management systems and the degradation of performance caused by low-level commands having to pass through two management systems.

There is also a psychological disadvantage : once the system is working in this manner there is less incentive to complete the migration and thereby simplify the software structure. Even if this type of migration project is started with the best intentions of returning to complete the transition, once the system is working it is often difficult to justify spending R&D money on software development that does not deliver customer-visible features.

Once the encapsulation is in place, migration takes place in several steps:

• New features added to the device are managed only by the WBEM server, the CIM model being enhanced and the providers being written as required. This caps the growth of the legacy system.

• Any service-level features currently supported by the legacy system are remodelled in CIM and providers are written, removing this level of abstraction from the legacy system. I have found that this often comes as a relief to the maintainers of the legacy system, these higher-level features typically having been added in a somewhat ad hoc manner to a perfectly good device management system. Because of the impedance mismatch between the two parts , bugs in the legacy system tend to occur either in the service-level code or in the interface between service and device management. Removing the service-level management allows the legacy system to revert to its previous, more stable state.

• If it felt useful, device management features of the legacy system are moved to the WBEM server in an orderly fashion, possibly as the hardware of a board is replaced or a software feature rewritten, necessitating new management software.

Scenario 2: Preserving Operator Interfaces

This problem is to some extent the reverse of scenario 1: you need to preserve the external interface but are allowed to change the on-device code. In some ways this is a harder problem, particularly if the schema-modifying commands supported by WBEM/CIM are new to the system and need to be supported. There are, for example, no equivalents in SNMP to CreateClass() , DeleteClass() , etc.

My recommended approach is illustrated in Figure 14.3; the legacy operator interface is treated no differently than any other operator interface: a command transliterator is required with knowledge of the legacy interface and of the conversion between the operator interface and the WBEM/CIM world. This command transliterator acts as a WBEM client to the WBEM server and as a server to the legacy management workstation application. It can be considered to have three parts; see Figure 14.4. The legacy command terminator checks the syntax of the incoming command, responds to local commands such as requests for help, and formats responses back to the legacy system. For many popular interfaces (e.g., Cisco IOS interface) there are freely available software modules for this function. The other side of Figure 14.4 is the WBEM client. Again, this software is freely available from any WBEM server source. The work involved in creating the transliterator is therefore the conversion of the commands and responses between the legacy and WBEM worlds .

Figure 14.3: Supporting a Legacy Interface

Figure 14.4: Structure of the Command Transliterator

This conversion requires syntactical knowledge of the CIM interface and semantic knowledge of the structure of the information in the CIM model. In this scenario we are helped in obtaining the semantic knowledge, because some of the SNMP objects are already modelled in the DMTF core and common models and have mapping strings already in place. The problem, however, is that mapping strings are not keys. Given a particular SNMP object reference, there is no efficient way in which the corresponding CIM class can be retrieved from the WBEM server. There are two obvious solutions to this problem:

• Allow the conversion routine to walk the entire CIM model (i.e., enquire about every class) when the program is first started. This may be time consuming but is only needed once if it uses the information to build an internal table, indexed by an SNMP object identifier.

• Provide the conversion routine, again at system initialisation, with a copy of the schema information ”possibly by writing an additional back-end to the mof compiler.

Both of these techniques will, of course, only work if the schemata are stable between software releases ”any changes made to the structure of the schemata themselves by operators (through the use of addClass() , etc.) will not be reflected in the copy held by the conversion routine. In most transition environments this is not a problem since the legacy workstation software typically cannot support operator commands for schema changes.

Another decision which you will need to make if you adopt this approach is where to run the command transliterator. It might be more appropriate to combine it with the workstation software than to place it on the managed device.

Indications arising on the device can be routed to a listener which can convert them to SNMP traps.

Scenario 3: Preserving On-Device Drivers

This is probably the simplest of the three scenarios: a provider can hide the actual configuration interface for the hardware devices from the WBEM server.

The traps emanating from the hardware can be caught by a indication provider that creates an instance of a class derived from CIM_SNMPTrapIndication ”see Figure 8.3 on page 155.

Once this has passed through the WBEM server, it can be directed to listeners specified in instances of the CIM_SNMPTrapTarget class ”see Figure 6.6 on page 104.

This mapping of SNMP trap fields to CIM properties was foreseen by the DMTF and is defined cleanly in the various classes.