[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML versus SOAP/WSDL Performance
At 06:23 PM 9/23/2002 -0400, Jon Saperia wrote:
>On Monday 23 September 2002 05:07 pm, Larry Menten wrote:
>> Jon and Glenn,
I don't know if we are all imagining the same technology
when we say "XML monitoring". It would be less then clever
(okay, pointless) to emulate SNMP protocol operations with
a TCP based protocol encoded with XML. This is a short-term
transitional strategy at best. By moving away from the limited
data structures of SMIv2 and the primitive GetNext protocol
operation, XML monitoring starts to look interesting.
I also don't think it's that hard to map SNMP naming to XML.
The most commonly used tables, like in the IF-MIB, are quite
easy to map. This is also a transitional strategy. Over
time, I suspect OID naming will go away because hierarchical,
human-readable naming is much more intuitive.
Andy
>>
>> 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/>
--
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/>