The Device Independent Authoring Language (DIAL) addresses the important area of device-independent Web page authoring. The intention of DIAL is to facilitate Web page access to as diverse an audience as possible -- as the standard states, "any time, any place, anyhow." DIAL tries to accommodate the evolution of Web access devices, higher-speed and more diverse delivery networks, and the growing audience for Web content. One of the primary DIAL goals is to provide a functional (that is, worthwhile) user experience. Although the emerging DIAL standard mostly addresses the needs of human users, a broad range of applications exists that use machines to access Web data. As you'll see, there are some pressing reasons for machines to have functional user experiences.
One example of this need is the evolving field of information technology (IT) management. Traditionally, this area has been an open and highly competitive market for solutions that consist of devices, software, and management technology. In many ways, IT has become a victim of its own success, as enterprises demand increased services in return for reduced investment and staffing levels. IT services live or die by the availability of service- and infrastructure-related data. This data has become the lifeblood of many organizations. It's the means by which IT staff deploy and manipulate infrastructure elements (hardware and software) and services (the services consumed by users).
For example, management data might exist as static/dynamic Hypertext Markup Language (HTML) or (more recently) as Web service-accessible data. The problem is, this data has no unifying standard for its representation or its manipulation. So, if you want to change the configuration of one of the devices in Figure 1 (such as inserting a static route in an IP router table), then you must employ a proprietary scheme to browse the appropriate table and make the required insertion. Likewise, if you want to get the number of hours of operational uptime of the projector in Figure 1, you must send a SOAP message to the element manager.
Putting Web servers on network devices is a complex effort that adds to the cost of developing the devices. It can also make their operational use more complicated because management software must interact with the Web server. There are also issues related to timing -- if you change some data in your browser, how long does it take before that change is propagated to the device operation? The more code you squeeze into devices, the more complex these issues become.
Although progress is being made in the area of Web Services Distributed Management (WSDM) (on the right side of Figure 1), literally millions of deployed devices continue to evolve as proprietary entities. Vendor lockin is the order of the day in these situations.
Figure 1 illustrates a typical generic scheme where IT management is facilitated with HTML-based entities on the left and SOAP-based entities on the right. The computer in the center represents a management system. This could be any management console application, such as an autonomic computing management application. Although it's illustrated in Figure 1 as just a Web/SOAP browser, the management application is in fact an arbitrarily complex software suite. For the purposes of this article, the interesting part of the manager is the element responsible for communicating with managed entities, such as those in Figure 1.
Figure 1. IT management schemes
The goal in this article is to change Figure 1 into Figure 2.
Figure 2. Adapted IT management schemes
The transition from Figure 1 to Figure 2 is slight, but the benefits are significant. These benefits derive from one aspect: open standard compliance. Having access to management data in a standard format yields the following advantages (among others):
- Vendor lockin is less likely to occur.
- The same tools can manage multiple vendor entities.
- Representation of management data can be standardized.
- Managed entities can be simplified.
One of the key attributes of the data produced by the adapter in Figure 2 is to specify more information about the data it sends and receives. This information can be encoded in Extensible Markup Language (XML) as part of a simple vocabulary.
A simple DIAL vocabulary for IT management using XML
DIAL specifies that compliant entities provide well-formed XML data in accordance with the required rules and the schema. It's a big task to try to derive an XML representation of managed data -- there's a lot of it out there. But the following few sections are a step in that general direction.
Several industry-wide efforts aim to define information models for managed networks, such as the Common Information Model (CIM), the Shared Information and Data Model (SID), and so on. The problem with these models is their complexity and a lack of vendor uptake. Other formats and protocols, such as Simple Network Management Protocol (SNMP), have filled the vacuum to become de facto management standards. A further complexity is that the management data-access mechanism supported by some of the most highly deployed vendors is nothing more than a command-line interface (CLI). The CLI can be hidden under graphical user interface (GUI) server applications, but this is still a primitive way of managing devices. It's also nonstandard and vendor-specific.
A proposal for simple IT management data
This article proposes a simple way to describe managed data in a standard, open data format: XML. Conformance to the DIAL standard will then result in the additional benefits of openness and accessibility by a wide range of access mechanisms, device types, and applications. Some vendors already use XML technologies in their management software, so the ideas here aren't completely revolutionary.
Listing 1 illustrates one possible format for an XML representation of a common legacy device: an Internet Protocol (IP) router. The first half of Listing 1 illustrates a simple XML description for a router. The second half describes the semantics for entries in the routing table for that device. A complete XML model would require many thousands of definitions similar to those in Listing 1.
Listing 1. XML definitions of legacy IT managed entities
<entity router="deviceType" purpose="forwarding"> <model>"Best router in the house"</model> <vendor>"Acme router manufacturer"</vendor> <address>"Somewhere or other"</address> <company-name>"Cisco"</company-name> </entity> <forwarding table="IP forwarding table" purpose="forwarding"> <destination>"a.b.c.d"</destination> <preference>Integer value</preference> <gateway>"e.f.g.h"</gateway> </forwarding> |
Many legacy devices store the Listing 1 data in a proprietary format. Access to the data is made using a range of technologies including SNMP and CLI.
Later, this article examines a way to automate this data migration. For the moment, assume that you have the data in XML/DIAL format. What about software to manipulate this data? The DIAL standard allows for the inclusion of Extensible Hypertext Markup Language 2 (XHTML2) object modules. The next section looks at these modules.
A simple DIAL vocabulary for IT management using the XHTML2 object module
The object module in Listing 2 describes the location of a route table for an IP router. The src field indicates the location of the data to process -- in this case, a route table. The srctype field indicates the data type. The standby field provides a message for the user while the overall XHTML2 object module is processed. What processes the object module? This task can be performed by the adapter in Figure 2 in conjunction with the legacy device. The adapter acts as a kind of data gateway, translating between the proprietary formats of the legacy devices and the XML format of the management system.
Listing 2. An XHTML2 object to provide alignment of management data and handler code
<object
src="http://www.myorganization.com/router1/routetable"
srctype="text/clear">
<standby>Loading route table data for router 1...</standby>
Route table data.
</object>
|
Processing this object module requires access to the semantic data described in Listing 1.
Assume for the moment that the management data format for all legacy telecom devices was suddenly available in something like the formats just described. What are the benefits? Probably the biggest single benefit is the ability for a compliant management application to manipulate devices from any vendor.
The next section looks at a simple scheme for transforming legacy data into XML. Surprisingly, this isn't hard to do.
Transform legacy data into the DIAL dialect
Listing 3 illustrates an excerpt of data describing an IP router, such as one of those in Figure 1. The data in Listing 3 can be comma-separated or use one of the many popular formats; here, the data appear in a linear format to make them easier to read.
Listing 3. Legacy device data
Device: Router1 Contact: Frank En Stein Email: frank@largeserviceprovider.com Phone: 1800 512 9999 System name: LER A IP-capable: Yes MPLS-capable: Yes Last Discovery: 1 January 2006 Location: Transylvania |
Listing 3 describes the attributes of an IP router. As you can see, one of the attributes describes IP capability. This indicates that the device implements IP (more precisely, it implements the TCP/IP protocol suite). Another item in Listing 3 is Multiprotocol Label Switching (MPLS) capability. MPLS is a standard technology that uses IP to provide greater control over the way traffic is forwarded by the router. In other words, MPLS is a technology attribute of a router device.
The provenance of the legacy data
The origin of the data in Listing 3 might be any of the following:
- CLI data dumped to a file
- SNMP queries reformatted as ASCII text
- A management system database dump to file
- Some other proprietary mechanism
The important point is that the data is acquired as a result of some interaction with a managed device. The data in question are acquired in a non-XML format and translated either for storage or display. You have the data; now, how do you get it into XML format?
A Java program for transforming the legacy data into XML
For a simple Java™ program that transforms your legacy data into XML, see Download in this article. To run this code, you must install a copy of the Java Development Kit (JDK) available for download from Sun Microsystems (see Resources). Basically, the legacy data is listed in a text file; you can run the program against that file with the command in Listing 4.
Listing 4. Commands to transform legacy data into XML
Change to the code directory set CLASSPATH=.;%CLASSPATH% java TransformationApp LegacyNMSData1.txt |
Listing 5 illustrates the transformed version.
Listing 5. Post-transformation XML version of the device data
<?xml version="1.0" encoding="UTF-8"?><nodedata> <device>Router1</device> <contact>Frank En Stein</contact> <email>frank@largeserviceprovider.com</email> <telephone>1800 512 9999</telephone> <sysnname>LER A</sysnname> <IP-capable>Yes</IP-capable> <MPLS-capable>Yes</MPLS-capable> <Last Discovery>1 January 2006</Last Discovery> <Location>Transylvania</Location> </nodedata> |
Now your legacy data is in XML format. What does this give you? Quite a lot! You can now use the huge range of XML tools to further process this data, as discussed in the next section. The key point is that the data is no longer in proprietary format.
Render the DIAL data in the delivery context
Remember the adapter in Figure 1? The Java transformation code mentioned in the previous section would most likely form an important part of such an adapter, because the adapter serves as a kind of bridge between the legacy data and the DIAL data formats. Part of the requirement set for the adapter to ensure that the transformed data is DIAL-compliant. Figure 3 sketches some parts of a possible adapter.
Figure 3. An adapter for transforming legacy data into DIAL-compliant format
Given that you now have the legacy data in XML format, you can transform it in further ways. One such transformation is from XML into HTML. You can also store the XML data directly in an XML database if required.
Management system interactions: the user experience (machine-to-machine dialog)
The legacy data has been transformed from proprietary form into a DIAL-compliant format. Up to now, you've considered infrastructural issues outside the IT management problem domain. What can you do with this new data? Whatever you like! Now that the data is in DIAL-compliant XML form, you can leverage it using the management system software. Typically, this can include features such as:
- Configuration backup and restore
- Software distribution
- Antivirus software updates
- License checking
These features involve both reading from and writing to network devices. For this reason, the adapter dataflow in Figure 3 is bidirectional, just as you require in a real IT management situation.
DIAL provides what might become a standard data platform for IT management. Given that DIAL is based on XML, this automatically opens compliant data to the wide range of available software tools. You can easily define simple vocabularies for legacy data, and create Java tools to transform from legacy to DIAL-compliant format. Doing so will help open a marketplace for much-needed IT management tools that has heretofore been closed.
DIAL allows the inclusion of XHTML2 object modules. These are flexible data definitions that provide detailed instructions about how to process the associated data. Thus managed devices can provide hints on how to use specific data.
Migrating management data into DIAL format is much easier with appropriate transformation software. This is a relatively straightforward (if laborious) process. Once the data is in the required format, the IT management tools can use it as usual. The main difference is that the IT management infrastructure is now open and standards-compliant.
| Description | Name | Size | Download method |
|---|---|---|---|
| Sample transformation code for this article | x-dial-transform.zip | 6KB | HTTP |
Information about download methods
Learn
- DIAL at the W3C Web site: Find out more about DIAL.
- XML programming in Java technology series (Doug Tidwell, developerWorks, January- July 2004): Learn how to manipulate XML with Java.
- Hit the ground running with AIDE, Part 1: Building a touchpoint (Stephen B. Morris, developerWorks, April 2006): Learn how to get up and running quickly with the IBM Autonomic Integrated Development Environment (AIDE) toolkit.
- WSDM for J2EE provides next-generation management (Leigh Williamson, Mark Weitzel, Dan Jemiolo; developerWorks, March 2006): Learn how to build a Web Services Distributed Management (WSDM)-compliant manageability endpoint for Java application servers with the IBM Autonomic Integrated Development Environment (AIDE) component, the IBM Manageability Endpoint Builder, and the JSR 077 API.
- OASIS Web Services Distributed Management: Find more on details on Web Services Distributed Management(WSDM) at this Web site.
- Network Management, MIBs & MPLS (Stephen Morris, Prentice Hall, 2003): Learn about IT and network management in this book by the author.
- IBM XML 1.1 certification: Find out how you can become an IBM Certified Developer in XML 1.1 and related technologies.
- XML: See developerWorks XML Zone for a wide range of technical articles and tips, tutorials, standards, and IBM Redbooks.
- developerWorks technical events and webcasts: Stay current with technology in these sessions.
Get products and technologies
- IBM trial software: Build your next development project with software available for download directly from developerWorks.
-
Java Development Kit (JDK): Get a program to transform legacy data into XML; download the JDK from Sun Microsystems.
Discuss
- XML zone discussion forums: Participate in any of several XML-centered forums.
Stephen Morris is the CTO of Omey Communications in Ireland. For the past 20 years, Stephen has worked for some of the world's largest networking companies on a wide range of software projects, including J2EE/J2SE-based network management systems, billing applications, porting and developing SNMP entities, network device technologies, and GSM mobile networking applications. He is the author of Network Management, MIBs and MPLS: Principles, Design and Implementation (Prentice Hall PTR, 2003) as well as several articles on network management and other topics for InformIT and OnJava.com. You can reach Stephen at stephenbjm@yahoo.com.




