[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML versus SOAP/WSDL Performance

David,

If the model of data in the network element and the model in the EMS/NMS
are close or identical, then the design of the EMS/NMS is simpler. The complexity of
mapping from the natural data model to a flattened structure and then from the flattened
structure back to the natural data model is avoided. Consider attempting to acquire the
configuration state of an OSPF router. The application must construct separate sets of
indices for each of the tables that contains configuration data. And if this is to be done
based solely on the content of the MIB, the program must deduce the correct mapping
from the EMS/NMS internal model to the MIB model using TEXTUAL-CONVENTION
elements. If the vendor has implemented only an enterprise-specific MIB, then the OIDs
the objects that would otherwise appear in the standard tree are now different. And the
mapping is not provided in the enterprise-specific MIB in any machine-interpretable
form. At best, it might be expressed in the comments.

The SNMP MIB is like a relational database in which you cannot rely
upon having a " join" operation. ; )

Managing SNMP devices in the context of enterprise-specific MIBs is like attempting to
write queries against relational databases where the schema is not known in advance,
there is no join operation, and the data dictionary is missing. : )

A request for data when a subtree of the "natural model" is desired
is far more concise than the equivalent attempt to access such a subtree
through SNMP. An xpath expression and one or two attributes are sufficient
to name a subtree of that data and the number of levels of that subtree that are
desired. The relationships between the elements returned by
the request are retained. Furthermore, it is easier to design the management application
to deal with network elements that have enterprise-specific extensions. I contend that
a standard schema that permits the addition of enterprise-specific extensions (marked
with namespaces) is easier to manage than attempting to manage a device that supports both
standard MIB and an extension MIB. For one thing, the relationship between the objects in the
extensions and the objects in the standard MIB is retained. In an SNMP MIB, the relationship
is not expressed at all. If you don't know in advance about the location of the extensions
you will never discover them. And without creating the mapping , by hand, between the
enterprise-specific and the standard MIB, you cannot use the extensions.

This is all a consequence of the rigid OID naming scheme of SNMP.
("Powerful-GET-NEXT" not withstanding. : )

If the extensions are included with the standard elements within the same tree, then
the manager always knows where to find objects related to, say, OSPF.
The manager has the option of handling extensions that it "understands" and
skipping those that it does not. Furthermore, the configuration or dynamic state
that is not understood can still be stored in the EMS/NMS database with it's proper
relationship to the rest of the tree.

I would also contend that an XML-Schema is a more powerful and, (soon) universal/standard
way to express the schema of management information than are TEXTUAL-CONVENTIONs.
It provides more compelete validation and accommodates the addition and separate expression
of validation rules for elements from other "namespaces." (Read "extensions.")

In addition, the desire that a subtree of data be acquired as an atomic operation is more
easily expressed in an XML transaction than in SNMP. Generally, the need for such
operations must be designed into the managed system for each sort of
such "query" that is to be supported. In a system designed for XML-based
management, such requests can be performed easily for any subtree of the model
without the custom code or data buffering mechanisms required by SNMP.

If a query of some sort was required, then it was designed in advance into the
SNMPv1/V2 MIB. The query was implicit/hidden. In constrast, XML provides
more natural and explicit ways to express queries against both the configuration
and dynamic state of a system.

I hope that addresses 1), 2), and 3) to your satisfaction.

In the example that I mentioned, the symbolic names were both represented in the
class names and in values of class member variables so that the mapping between the
derived object and the MIB is available to the management code.

As for the model expresswed within the EMS/NMS,
I believe that, for many features, there is often common model that spans
products across many vendors. Vendors may add additional features, but the fundamental
model remains the same. I believe that where they exist, such models should
be expressed in the NMS/EMS. I believe the SNMP MIB presents an obstacle to
accomplishing this. I believe that a hierarchical expression of management transactions,
such as XML, facilitates this.

Regards,

/larry menten

David T. Perkins wrote:

HI,

In your message, you make statements that say that using XML is
good, but provide no reasons. Would it be possible for you to
describe why you believe that:
1) using XML improves the way that data is collected
2) hierarchical representation is better mated to data in the
network element than SMI's relational model (that you call
a flattened model)
3) Management paths that do not do this flattening will be simpler,
more robust, and more powerful.

Also, would you provide more description about the following:
"In fact, I have had experience with management systems in
which (symbolic) SNMP object names have been adopted within
the internal object trees that represent the managed systems.
I expect this is not uncommon and would like to hear from others who have seen this done."
Do you mean that the identifiers that you use for variables in your
C program, or the class names and attribute names in your OO programs
are using the descriptors from SNMP MIB definitions? Do you mean that
the management applications are using the management models from
the MIB modules directly instead of carefully creating the management
models that work well for the functions of the application?

Some of believe that the management model found in the MIB modules
should in many cases be quite different from that found in management
applications and it would be a step backwards to have MIB modules
reflect the management model in management apps. Instead, they should
reflect the management model in the managed device, with just enough
abstraction so that the model will easily to most devices developed
by different vendors.

What is your reaction to the above?

Regards,
/david t. perkins




--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>