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

Re: XML versus SOAP/WSDL Performance

Jon and Glenn,

I agree.  XML has much to offer in improving the way data is collected
and asynchronous notifocations are expressed.  Addressing
the need to standardize XML-based configuration, data collection,
and asynchronous messaging recognizes that these are closely related
functions whose standards should be designed together if the full  power
of the approach is to be realized.

I was a little late in subscribing to this list, so I'm sure I missed some interesting
discussion. (I'll catch up through the archive.)  But if it hasn't been mentioned already,
the hierarchical representation of both configuration and dynamic data within
EMS and NMS is better mated to the hierarchical representation of the data
within the network element than the flattened SMI model.  Management paths
that do not do this flattening will be simpler, more robust, and more powerful.
This holds for the dynamic polled and asynchronous-message acquired data
as well as for configuration data.

Using two different protocols for management adds other complications as well,
such as the need to administer security (daemons, keys, firewall protocols, . . . )
twice (when once is bad enough!)

Our system, by the way, also employs XML-expressed transactions for
computational services.  The need goes beyond just access to state.
While I don't suggest that we broaden the charter, we ought to be aware
of the need to accommodate transactions that are not related to configuration or
to acquisition of dynamic state.

On  the name-mapping issue:
I believe that we will do good if we accommodate
name-mapping from SNMP mibs in some useful way.  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.


Larry Menten





Jon Saperia wrote:
Glenn,

I have mostly been watching this discussion. I wanted to empahsize how 
important your comments are from the perspective of building a management 
application. The name space problem is a critical problem. If there is to 
be a new standard way to configure systems based on XML, fine. To omit 
from the basic design of that standard, issues to deal with all the things 
we expect from SNMP like asynchronous messaging and data collection, would 
be a big mistake. 

/jon
On Monday 23 September 2002 11:40 am, Glenn Waters wrote:
  
-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com]
Sent: Friday, September 20, 2002 17:34
To: Remco van de Meent
Cc: xmlconf@ops.ietf.org
Subject: Re: XML versus SOAP/WSDL Performance
      
[...]

    
I was one of the people who brought up SNMP and monitoring at the
xmlconf bof...

I think the most important point here is that we have a standard
mechanism to convert SNMP data naming to XML, so an application
can correlate XML and SNMP data.  The ability to use XML for
monitoring is much less important. I would expect that applications
would use XML monitoring for a small amount of data, and continue
to use SNMP monitoring for large, or frequently polled, monitoring
tasks.

Andy
      
Andy, I think that we mostly agree although I think that the ability to
monitor using XML is very important. I believe that XML should be
available to configure, retrieve status, and retrieve statistics. The
reason that I believe this so strongly is that configuration is tied to
status/statistics and that more than one protocol to tie the two areas
together is problematic.

It is problematic since there are almost always fundamental problems
mapping between two naming models. The amount of code and complexity
that is required to map between naming models is non-trivial.

By example, let's say that a routing table entry is configured. One of
the first things that an application may want to do after configuring
the entry is to check the status of the routing table entry. This means
retrieving the status and potentially some statistics. I can't imagine
that a management application would want to configure the entry one way
then switch to another protocol and naming model to get the statistics.
That would just be broken.

Cheers, /gww