[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML versus SOAP/WSDL Performance
On Monday 23 September 2002 07:06 pm, Andy Bierman wrote:
> 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 had not intended to limit XML to an emulation of SNMP. What I did mean
is that we need a single management infrastructure, and if the consensus
is to use XML technologies (e.g, XML, XML-RPC) that is OK. The single
infrastructure should support all the reasonable management activities
such as configuration of one or more systems at a time, asynchronous
messaging between consenting systems, and data collection. I do think that
there are things that we have learned with SNMP (good and bad),
particularly in it's area of greatest application, fault management and
collection of performance/utilization data, and asynchronous messaging
that we should reuse. One example from a management application
perspective is the option for non-connection based communication.
Maintaining many many TCP based connections at a time is hard . People
who build large routers know this well. This is not to suggest that a TCP
based approach is not also valuable, just that one size does not fit all.
>
> 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
The initial mapping may be easy in the XML, but implementing the
associations in the database of the management system, keeping it flexible
and doing the translations is not as easy and there is a computational
cost. And yes, even with big hulky multi-processor systems this matters.
> time, I suspect OID naming will go away because hierarchical,
> human-readable naming is much more intuitive.
>
I think there are merits to both. Once again, the network management area
has to declare a path - an architecture and not do piecemeal solutions. If
that path is to banish OIDs do it, say so and move on. My argument has
been for years, consider the alternatives, choose something and make it
work well.
/jon
> 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/>
--
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/>