It is easy to look at the rapid emergence of the Internet and conclude that Internet computing standards such as the eXtensible Markup Language (XML) are like hurricanes taking out everything in their paths. But the reality for network-device manufacturers is destined to be much different.
For unlike their PC cousins, such devices are highly heterogeneous, using a variety of embedded processors and real-time operating systems. They are an amalgam of proprietary hardware and software components that render standardized approaches to management extremely complex, to say the least.
Because of this complexity, the industry has historically tended to fall into two management domains. In the first category are applications using SNMP and Management Information Base II (MIB II) agent code as a standards-based mechanism for managing groups of heterogeneous devices such as a machine-to-machine interface. In the second are embedded applications that use command-line interfaces or even proprietary management applications as a means of accessing and controlling all of the proprietary manageable objects in an embedded device (such as a man-to-machine interface).
Fortunately, the next chapter of device management is already being written. Nearly every device manufacturer has either delivered or is moving toward delivering Web browser-based management of its products. The Web browser is an ideal human-to-machine interface offering ubiquity, ease-of-use and support for graphical-user-interface-based display, messaging, scripting, application logic and distributed objects in a single unified client.
The moral of the story from the last chapter of device management is that this same architecture must also scale as a machine-to-machine interface. But how? Web-enabling a device typically means embedding a tiny Web server into the device and providing a host-data interface between the device's C-based manageable objects and their corresponding "presentation" objects. This leverages the same underlying architecture since both a man-to-machine and machine-to-machine interface requires that such objects be readable by both machines and humans. Moreover, scaling such an architecture to one-to-many and many-to-many combinations requires a way of acquiring, integrating and exchanging data within and between heterogeneous devices and users in an information-rich fashion. In other words, such a model must maintain the structure of the data in addition to the data itself throughout the entire device management life cycle. This is the challenging domain for which XML was born.
While many people falsely assume that XML is the next generation of HTML, or a superset of HTML, XML is best understood by what it isn't. Whereas HTML is a specific markup language for presenting data in a platform-independent fashion, XML is not a markup language at all, though it is defined as such. Rather, XML provides a platform-independent framework for creating specific markup languages for specific types of applications.
As such, the heart of XML-enabled embedded and Net-centric computing applications has two components. First, there is the specific grammar, or schema, of elements to be used by the XML-enabled application. This grammar is defined in something known as a document-type definition, or DTD, which acts as a kind of "da-ta dictionary" for the application. Second are the specific processing functions that apply operational logic against specific elements of an XML-enabled application.
Also important in leveraging XML as both a man-to-machine and machine-to-machine interface is the fact that while XML is text-based and thus readable by humans and machines, the ultimate value of any particular XML implementation is dependent upon the number of peers-human users and/or machines-that support its data dictionary. Enterprise-sizing this concept requires the broad-scale adoption of the same data dictionary for the specific problem domain at hand.
Somewhat peripheral, but related, is the fact that in Internet computing environments the same set of manageable elements resident in a device may be used for vastly different purposes, depending on the specific XML-enabled application interfacing with them. For example, the same device may rely on one data dictionary when interfacing with a system-management application and yet another when interfacing with a subscriber-management application. Fortunately, XML provides a mechanism called Namespaces for wrapping manageable objects with grammatical definitions from multiple data dictionaries.
It is important to note that, while the Common Information Model (CIM) provides a common interchange format between management/manageable systems, it doesn't provide a guide for specific implementations. This is good news. Since CIM remains implementation-neutral, it avoids many of the political issues that poison standardization efforts. Consistent with this pragmatism is the fact that CIM avoids the either/or mind-set that hinders most next-generation technologies since it provides facilities for mapping with other management models such as SNMP MIBs.
Meanwhile, the XML message for device vendors is clear: XML offers great promise as both a man-to-machine and machine-to-machine interface. It is, however, only as good as the schema or schemas that ride on top of it. And while a standards-based schema, such as CIM, offers great promise as an enterprise-management standard, there are no free rides. Actually implementing an XML-enabled application requires giving XML something to do, which translates to an engineering effort in your programming language of choice. In this age of Internet computing, that means Java for platform-independent processing.
Although it is easy to conclude that a dictionary, parser, HTTP server and host-data interface are all that are needed to deliver products into the age of XML awareness, developers should heed this message from John E. Simpson, author of Just XML: Whereas HTML is like a spreadsheet, XML is more akin to a relational database. So, XML requires developers to think beyond systems management to areas such as policy-based control, plug-and-play integration, technical-support automation and, more importantly, a whole new set of problems and solutions that haven't even been contemplated. Similarly, product architects and product managers must make sure they have a strategy for reusing SNMP objects with a minimum of re-engineering.