AON 3.0, a messaging intermediary, released by Cisco

Discussions

News: AON 3.0, a messaging intermediary, released by Cisco

  1. Cisco has announced the release of Application-Oriented Networking 3.0 (AON), a product for some of their routers that provides messaging services at the network level. The benefits to this are that messages can be transparently routed quickly, with translation into various protocols. In this, it's almost like an ESB router at the network router level, instead of having an actual ESB on the network. (That said, it doesn't replace an ESB - just extend some of an ESB's functions to the router level.) An explanation of AON in action might go something like this: a REST request is sent from an external entity to an IP managed by an AON-compatible router. AON can translate that REST message into JMS, and send it to a queue, for example, or apply security, or perhaps decode the message if it's secure already; all of these things happen in the router, transparently, so that if routing or message payloads need to change, it can happen without affecting routing tables. It's actually an intriguing idea, made harder by being vague on Cisco's site: they describe a lot of things it can be used for, without actually describing what it is in simple terms. To wit, from AON's default product page:
    Cisco Application-Oriented Networking (AON) capabilities combine the reliability, availability, and scalability of the network with the flexibility and functionality of the software world. It provides centralized control and management to a global application IT infrastructure at a fraction of the cost and effort of using traditional technologies. As your organization accelerates its move into service-oriented architectures, AON provides both a bridge to your legacy application infrastructures and a platform for moving into full Web services deployments and integrated third-party solutions. Use Cisco AON technology to:
    • Complement existing core application and messaging infrastructure
    • Create a more flexible, less brittle application infrastructure
    • Eliminate or complement server-based infrastructures
    • Complement traditional application network infrastructures
    One of the Cisco employees working on the product described it like this:
    AON (Application Oriented Networking) is an overlay network designed for application infrastructure. It offers shared application services such as Messaging, Logging, Transformation, Security, Protocol bridging, Event Monitoring, SLA Compliance. It is an application platform that provides distributed, flexible and real-time policy control. It also has all the benefits of a network device such as hardware acceleration, pervasive location, built-in clustering for high-availability and scalability and centralized manageability.
    Still a high buzzword factor, but somewhere buried in all the BS there's a functional and useful idea. The "new features" list from Cisco actually provides a clearer view of what AON does:
    • WSDL and WS-Policy import and PEP generator: Ability to import WSDL and WS-Policy documents from a file-system, or from a given HTTP URL (only clear text, not HTTPS) into the ADS
    • Create SOAP Message bladelet for callout requests: A new bladelet which is similar to the existing Create Message bladelet, except that it is completely geared towards allowing the user to configure outgoing SOAP calls.
    • SAML 2.0 support: AON will now accept both SAML 1.0 as well as SAML 2.0 tokens in its Identify, Verify Identity, and Authorize bladelets.
    • SOAP request classification and prioritization: Message type definitions now allow classification to be based on SOAP headers and body tokens like WSS username token, WSS X.509 certificate token, and WSS SAML token.
    • Context- and content-based routing enhancements: Enhancements to content-based routing based on sender identification in HTTP or SOAP headers, HTTP header elements (HEAD, and so on), HTTP and SOAP header information (values), SOAP header, HTTP header, source IP/port number, and context-based routing based on day, date, time.
    • SSL support added to BEA JMS Adapter: Processing of WebLogic JMS messages over SSL is now possible.
    • HTTP pipelining support: Support now provided for pipelining of incoming HTTP requests on persistent connections, where responses need to be sent in the same order in which the requests were received per HTTP 1.1 spec (RFC-2616).
    • Data streaming support: Today, embedded adapters conform to a programming model and a set of APIs defined in the adapter SDK in order to interact correctly with the AON system. The data streaming model enhances the existing interaction to support streaming of data in discrete chunk sizes.
    • Syslog extended to NOTICE and DEBUG: Support added for redirecting AON logs to syslog for DEBUG and NOTICE level messages.
    • Multi-port support on appliances: Enhancements made to enable the use of the third network interface on AON appliances.
    • Message order preservation: A new combination of Unreliable/Ordered delivery semantics was added to allow messages to be delivered at the outbound in the same sequence as they were received at the inbound.
    • SNMP MIB metrics: A comprehensive set of SNMP MIB metrics were added for AON 3.0.
    • Notification bladelet: A new bladelet that allows the user to send a custom notification by e-mail or SNMP trap.
    • Microsoft SQL Server support for Log bladelet: Ability to select Microsoft SQL Server database while creating a Message Log policy in AMC has been added.
    • System-tunable parameters: A new policy that allows the administrator to modify system-tunable parameters such as number of threads and so on has been added.
  2. Seems like a direct rival for IBM Datapower products. Its interesting to see more companies to activate in this segment.
  3. This is an interesting development and a logical closer integration of middleware into the network. Looks like an impressive set of new features. Moving wire-level messaging protocols into the network hardware should give us increased performance, manageability and, importantly, predictability. I understand however that much of the functionality is still software with AON - I think its a Linux blade that IOS communicates with to host the services. For routing to JMS for example this is the only way to go however for well defined wire-level protocols such as AMQP or FIX surely it could be hosted in IOS itself or in custom hardware? Another related product is from Tervela, http://www.tervela.com. They are implementing their routing logic in pure hardware - i.e. ingress to egress processing in the messaging switch is in hardware. What makes this attractive is not only the high volume and low latency but its predictability. Message routing in software is susceptible to long tails in the distribution of latency meaning you'll always get a small percentage of messages that take way longer than the average to route. This is bad for latency sensitive applications often seen in finance. I spent some time with Tervela last year and was very impressed. Colin http://hermesjms.com
  4. Has anyone use AON or DataPower[ Go to top ]

    Has anyone used AON or DataPower in real production?
  5. Has anyone used AON or DataPower in real production?
    A major US bank (contact me directly if you want the contact name there) has talked publicly about their use of DataPower. From several presentations that I've seen, they're quite happy with it, and use it far beyond the ways that IBM envisioned its use, including as part of their grid efforts. The differentiator for DataPower was always in the hardware .. it was a custom built processor for doing XSLT etc., and not just another x86 "appliance" running some open source stack. DataPower was a startup here in Boston; they got bought by IBM around two years ago. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  6. I see this product as a direct competitor to DataPower. Not sure if Cisco AON has a "hardened" version of an XSLT engine as in DataPower, their documentation is not clear on this. But the availability of SDK is a good strategy on their part and their console looks pretty good, when compared to DataPower. Would love to hear more from "real" users who used this in a production environment. Cheers, http://mkosaraju.wordpress.com