Using to create information support for management applications

Paul Madsen is the principal Structured Information Analyst for Newbridge Networks Corporation, a maker of telecommunications network hardware and network management software. In the past he has been responsible for the design and maintenance of the DTD for Newbridge technical documentation products and the creation of Web-based Online help products. His current focus is the investigation of structured data technologies as they apply to the delivery of dynamic information support and multimedia training to users of Newbridge products. Other work includes using XML as an alternative syntax for network management protocols.

Paul holds a PhD in theoretical particle physics from Carleton University in Ottawa, Canada.

Abstract

Introduction

Web-based Management

Embedded Web server model

Dynamic Information Support

Simple Scenario

 
Static Version
    
 
The following figure represents the WBM application screen from which the user sets the parameter values.
      
      
 
If the user is uncertain of the allowed parameter ranges and clicks on "Help", the   following window might appear:
    
    
 
In this example, to use this information, the user must:
       
 
for "Param A", verify that the value is in the acceptable range
   
 
for "Param B", verify that the value conforms to the stated relationship
   
 
for "Param C", determine which information is relevant to them

    
 
Most importantly, even though the values entered by the user for "Param B"   and "Param C" explicitly violate the recommended values (as declared in the implicit rules  in the documentation), the online help information delivered back to the user makes no   mention of this. The information support isstatic 
, in that there is no   dependence on real-time values. Consequently, the onus remains on the user to make   what they can of the help provided.
    

DIS
Dynamic Information Support
 
Dynamic Version
    
 
Consider the same scenario as above, but with a difference. The
   (
) application now has access to the real-time parameter values, both from   previously configured and current GUI screen parameters. Additionally, the implicit rules   previously declared in the documentation have now been made explicit and are available for   use by the DIS application.
    
 
Now, given the same GUI values as before, the information presented to the user might be:
    
    
 
With Dynamic Information Support, what is presented to the user is specific rather than   general, tailored to the user's actions, current system "state", and even expertise level.   The onus of analysis, the filtering out of information not relevant to the current situation,   is removed from the user and placed on the DIS system itself.
    

Proof of Concept - Dynamic Node Knowledge

Dynamic Node Knowledge Architecture

State Capture

 
 

 
Template
 
Result

    
 
 
HTML
 

<p><b>Packets dropped</b>: <EMWEB c='packets_dropped();'></p>

 
<p><b>Packets dropped</b>: 89</p>

    
 
 
XML
 

<packetsdropped><EMWEB c='packets_dropped();'></packetsdropped>

 
<packetsdropped>89</packetsdropped>

State Analysis

 API, Application Programming Interface 
 DOM, Document Object Model 
 Java applet 
 SAX 
client-side
 
Analysis Location
    
 
The DNK architecture consists of a triangle, with the switch, the client, and a   separate Web server (which we will see later is required for the storage and serving  of the HTML information objects intended for display) as the vertices. Although the possibility   of performing the analysis of the state directly on the  switch was ruled out because this scenario would require more extensive switch   resources, there remains a choice to be made, whether this analysis is   performed on the client or the separate Web server.
      
 
On a user request for "help", the XML state could be sent from the embedded server  on the switch to the client, where a
(downloaded from the separate Web   server) would perform the analysis. After the analysis was complete, the applet   would request the appropriate information objects from the separate Web server.   Although requiring an applet to be downloaded to the client, the time of which will   depend on the complexity and resultant size of the applet, this scenario distributes  the processing burden over all clients, theoretically providing for faster procesing if  the number of concurrent users requesting help becomes significant.
      
 
Alternatively, on a user request for "help", the XML state could be sent from the embedded   server on the switch to the separate Web server for analysis. This analysis could  be performed with either a CGI script or perhaps a Java servlet. Once the   analysis was performed, the appropriate information objects would be "pushed"   to the waiting user. A variation is that the user requests help of the separate  server, which in turn requests that the embedded server on the switch create and send it   the XML state for analysis. Once the state is analysed, the initial user request for help is  responded to by the transmittal of appropriate information objects. The obvious advantage of these systems is that they require   no possibly lengthy download to the client of a Java applet. However, placing the  processing burden on the server, whose system resources must be shared between the existing   installed base of managed switchs introduces the possibility of clogging and slow   processing.
    
 
Fundamentally, the choice of the
model for the prototype is based on a   preference for it's comparative simplicity to the server-side alternative, more so than the  arguments of processing speed and possible server overload. Realistically, given a Java applet's relative lack of speed compared to a C program   running as a CGI script, and the currently small probability of a "log-jam" of users  requesting help, these arguments favouring the client-side model versus the server-side model   are perhaps somewhat tenuous. However, our aim in this proof-of-concept is to learn lessons which we will  in the future be able to apply to larger scale systems, where server limitations may be   relevant.
    
 
A Java applet for DNK can use any of the available  parsers for its XML intelligence, we need only code for how the data, once extracted from the   XML, is to be analysed. Additionally, the
and

inititatives   enable the Java DNK applet to be created independently of the specific parser used.   We are currently investigating the available parsers to determine their suitability for   DNK, a major consideration being minimal size given the necessity of downloading. Since we  control the environment in which the XML is created and therefore can trust in its validity,   a validating parser is probably not required.
    

 
Logic definition
    
 
There are two broad alternatives for the method by which the queries to be performed on the  state are expressed, "hard-coded" or "rulesheets".
    
 
The simplest alternative, at least with respect to initial development, is to encode the   queries of the XML instance directly in the code of the DIS tool (the Java applet).   For instance, consider the following pseudocode:    
 

  function startElement (String name)
  {
    String GI;
    GI = "packets_dropped";
    if (name.equals(GI))
    {
        if (name.content.greaterthan(80))
        {
            packetsDroppedWindow.show();
        }    
    }
}


      
 
Each time the startElement is called as the XML is parsed, it queries the element to   determine if it is a <packetsdropped>. If so, and if the value of the content of the   element is greater than "80", a warning window is displayed. For all other elements, or if   the value is less than "80", no warning window appears. In theory, each XML element in   the source XML could have its own test, and appropriate action (perhaps   calling other methods, performing mathematical manipulations etc.,). The cost for this simplicity   is that the DIS tool becomes "hard-coded" with respect to a given set of data structures (as expressed   in the XML instance it queries and the query logic and resultant actions). If the data structures change,   or the query logic and actions, then the DIS tool code must be modified and recompiled. Depending on the  deployment architecture we'll discuss later, this maintenance issue may be significant factor.   Additionally, the DIS code cannot be easily repurposed for application to providing DIS for another switch   (with different data structures and appropriate query logic).
    
 
The alternative to hard-coding the logic in the code is to store it externally.  The power of stylesheets in SGML and XML applications is that they separate the data   from the formatting to be applied to them. The advantages of separating data from the   processing to be applied to it remain even if the processing to be applied is more   than simply formatting for display.
    
 
A "rulessheet" for an XML instance, rather than specifying a "style" to be applied to a   given element, specifies "rules" for the processing of the data contained within that element.   The processing can be dependent on the value of the data or other  criteria, these dependencies forming part of the rule. We will provide a more concrete   example of this concept after discussing rules-based expert systems in the following section.
    

Expert Systems
 JESS 
 


    
 
To diagnose a switch problem, an expert human user (a network   support operator for instance) might analyse the state of the switch by applying a set of heuristic rules built up   through experience (theirs and others). A rule would consist of a pattern to search for   within the data that encapsulates the state  and an action to perform if that pattern were found. The concept of rules containing patterns and actions is essentially   the core idea of rules-based expert systems. In such expert-systems, rules are used to represent heuristics,   or "rules of thumb," which specify a set of actions to be performed for a given situation. A rule is composed   of anif 
portion and athen 
portion. The if portion of a rule is a series of patterns which   specify the facts (or data) which cause the rule to be applicable. The then portion of a rule is the set of   actions to be executed when the rule is applicable. An expert system tool basically matches facts against   patterns and determines which rules are applicable.
    
 
There are several current options for embedding rule engines in Java-based systems, one being
  (Java Expert System Shell), a port of the CLIPS system to Java. JESS uses the CLIPS syntax for the   specification offacts 
andrules 
. Facts are lists of information about the current state of the "system". The rules encode the logic of the   system, in operation the JESS interpreter constantly queries the facts to see if any of the rules are true,   and if so activates the appropriateaction 
.
    
 
Facts are placed onto the list than JESS maintains with the "assert" function; the following assertion   declares that the IP variable is equal to 123.45.67.89.
    
 
(assert (IP 123.45.67.89)) 

    
 
A rule in the JESS syntax consists of a list of patterns and a list of actions. The patterns are matched  against the facts list. When facts are found that match all the patterns of a rule, the rule becomes activated  and will have its actions activated. The "defrule" construct is used to define a rule. Here is an example   of a simple rule called "test-IP-value" which determines if the IP variable has a valid syntax.    
 JESS 
 

    (defrule IP::Validate-IP 
              ( IP ?value ) 
          => 
            ( bind ?string  ( strcat ?value ) ) 
              ( if ( regexp "[0-9].[0-9].[0-9].[0-9]" ?string ) 
                    then ( printout t "IP  address " ?string " is valid". crlf ) 
                       else ( printout t "IP address " ?string " is invalid." crlf ) 
              ) 
    ) 


    
 
If
is to be used to provide the intelligence of the DIS tool, then the state data must be extracted from the XML and converted to the facts syntax that   JESS expects. This conversion will need to be performed on the client. The following demonstrates a simple mapping between   XML and a JESS fact assertion:
    
 
<packets_dropped>89</packets_dropped> -------> (assert (packets_dropped 89)) 

    
 
An alternative to serving XML and subsequently converting it to an the JESS   syntax for analysis would be to serve that syntax directly (or perhaps both XML and JESS syntax).  The previously mentioned independence of the embedder server mechanism from the details of the   "markup" would allow the direct creation of the state data in the optimal syntax for analysis,   this file to be served to the client. If the analysis of the state were the only purpose to which  the data were to be applied, this solution would be viable. However, the data, once in the optimal   format for analysis, would be of no use for other purposes. This is of course not a new phenemona,   PDF is an excellent format for specifying exact formatting, it is however not much use if you   want to do anything other than display the data.
     
 
It is the requirement that the information coming from the switch be multipurposed that forces us to convert from   XML to the JESS syntax for facts, this syntax not appropriate for other purposes beyond that of JESS analysis.   The other half of the JESS equation are the rules which JESS will apply to the state facts. Since these   rules serve a single purpose, there is no need to serve them in a more general syntax for conversion on   the client, they can be served along with the DNK applet in the appropriate JESS format.
    
 
In the present architecture, the user does not have the ability to "edit" the rules  to make them appropriate to the specifics of their networks, the analysis will be based   on a Newbridge "default" ruleset. This default ruleset will model the Newbridge version  of how their network switchs should work, this  may or may not be appropriate to a given   customer. User-editable rules implies both a mechanism for the creation of these rules   (ideally a GUI to insulate the user from the complexity of the rule syntax), a system for   storing them on the client, and a mechanism for merging these local rules with those   downloaded from the Newbridge server.
    

Information Object Library

Location

Granularity and Authoring

Syntax

Display

 
Information Levels
Example

    
 
 
I
 
IP address: 123.45.67.89

    
 
 
II
 
The IP address "123.45.67.89" is valid.

    
 
 
III
 
An IP address has two parts: the identifier of a particular network on the Internet and an identifier of the
particular device (which can be a server or a workstation) within that network. On the Internet itself - that
is, between the routers that move packets from one point to another along the route - only the network part
of the address is looked at.

    

Applications

Procedural Guidance

Statistical analysis

Related Information Support

XML as a management protocol syntax