Re: XML versus SOAP/WSDL Performance

[Jon Saperia <saperia@jdscons.com>]

On Monday 23 September 2002 05:07 pm, Larry Menten wrote:
> 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.
>

>
I think there are several approaches one could take here:
	1. Provide a mechanism to associate SNMP OIDs with XML-based 
configuration data.  Like you, I have seen this approach. This preserves 
the SNMP infrastructure but has the disadvantages of then requiring two 
infrastructures, SNMP and the XML-based one.  It also suffers from 
problem of mapping between the two, always less efficient.
	2. Leave the problem for later. If this is done, it will probably never 
be solved.
	3. Recognize now the need for a common name space for management and use 
XML for everything.  I like a common infrastructure for everything 
approach. Some do not for legitimate reasons.  The management area needs 
to pick a strategy and go with it. If it is XML fine, just do the whole 
task not a part.

/jon
> 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

-- 
Jon Saperia                         
				
saperia@jdscons.com
Phone: 617-744-1079
Fax:   617-249-0874
http://www.jdscons.com/

--
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/>