<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>ZapThink &#187; Linksys</title>
	<atom:link href="http://www.zapthink.com/tag/linksys/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.zapthink.com</link>
	<description>Sharpening Your Vision of the Future of IT</description>
	<lastBuildDate>Fri, 10 Feb 2012 18:12:55 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>XML Proxies: Why Current Network Protocol-based Firewalls and Routers Can&#8217;t Handle XML</title>
		<link>http://www.zapthink.com/2002/07/29/xml-proxies-why-current-network-protocol-based-firewalls-and-routers-cant-handle-xml/</link>
		<comments>http://www.zapthink.com/2002/07/29/xml-proxies-why-current-network-protocol-based-firewalls-and-routers-cant-handle-xml/#comments</comments>
		<pubDate>Mon, 29 Jul 2002 00:07:00 +0000</pubDate>
		<dc:creator>Ronald Schmelzer</dc:creator>
				<category><![CDATA[ZapFlash]]></category>
		<category><![CDATA[3Com]]></category>
		<category><![CDATA[Cisco]]></category>
		<category><![CDATA[Intel]]></category>
		<category><![CDATA[Linksys]]></category>
		<category><![CDATA[Nortel]]></category>
		<category><![CDATA[XML Infrastructure]]></category>

		<guid isPermaLink="false">http://test.zapthink.com/?p=ZapFlash-07292002</guid>
		<description><![CDATA[Look in the network closet in any good-sized company today and you&#8217;ll find a wide assortment of network gear: firewalls, switches, gateways, routers, hubs, bridges, the list goes on and on. Each of these devices essentially either directs or secures the packets that form the automobiles on the streets and ...]]></description>
			<content:encoded><![CDATA[<p>Look in the network closet in any good-sized company today and you&#8217;ll find a wide assortment of network gear: firewalls, switches, gateways, routers, hubs, bridges, the list goes on and on. Each of these devices essentially either directs or secures the packets that form the automobiles on the streets and freeways of today&#8217;s networks. All data networks &#8212; including the mother of all data networks, the Internet &#8212; are built from these packet-directing and packet-securing devices. All this equipment works pretty well, as long as they don&#8217;t care what is actually <i>inside</i> the packets. And there&#8217;s the rub. The amount of traffic going over the network that is XML formatted &#8212; in particular, Web Services messages &#8212; is set to explode, and all that equipment in the closet is completely unprepared to direct or secure that XML traffic.
<p> To understand why XML traffic is different from other network traffic, it is important to look under the covers of just what network traffic is, and how network devices work. The key to understanding network traffic is the <i>Open System Interconnection</i>, or OSI model for networking. The OSI model describes network traffic as a stack of layers, each one more abstract than the layer below. The diagram below illustrates the seven basic levels of the OSI model &#8212; physical, link, network, transport, session, presentation, and application:
<p> <center><img src="http://www.zapthink.com/reports/osimodel.jpg" alt=""></center>
<p> All the network gear mentioned above works at the five lower levels of the OSI stack. Vendors such as Cisco, Nortel, 3Com, Linksys, Intel, and dozens of others have produced hardware network appliances that direct and secure packets, and streamline and improve the efficiency of handling network traffic. All of this network gear &#8212; gateways, routers, firewalls, etc. &#8212; have melded together into a broad category called &#8220;network intermediaries&#8221; in that they facilitate communications between systems, but aren&#8217;t the end systems themselves. However, for all these network intermediaries do, they are still stuck in the lower five levels of the OSI stack &#8212; because they don&#8217;t deal with content.
<p> <b>Making the Case for the XML Proxy</b>
<p> The first six levels of the stack basically handle the nuts and bolts of network communication, while Web traffic (HTTP), email (SMTP), and other Internet protocols are part of the uppermost, application layer. As far as a firewall or router or gateway is concerned, this Internet traffic consists of nothing but applications talking to applications. Where, then, do the emerging XML and Web Services protocols such as SOAP, WSDL, and UDDI operate? These protocols don&#8217;t really fit in the OSI stack at all, because they are content-oriented, rather than network protocol-oriented specifications. So, while the OSI model is a mechanism that provides an understanding of traditional networking products, new <i>XML-aware</i> networking products must transcend the limited OSI model and focus not on the message packet or envelope, but rather the content of the message itself.
<p> This distinction between XML-aware, content-oriented products and network protocol-oriented devices is clearest when looking at firewalls. Most current firewalls work by blocking access to all network traffic, except ones that run on certain TCP ports such as Web traffic (HTTP port 80 and HTTPS port 443) and email traffic (SMTP port 25). However, most XML and Web Services traffic runs over the standard HTTP and HTTPS ports. Unfortunately, today&#8217;s TCP/IP-based firewalls can only permit or deny all traffic through these ports. The big problem with this all-or-nothing proposition is that XML/Web Services traffic might be undesirable at the content-level, unlike standard HTTP traffic, because Web Service traffic could theoretically execute any instruction on any computer on a company&#8217;s internal network.
<p> Therefore, firewalls must become aware not only of the network ports and IP addresses, but also of the content itself that is traveling across the network. Unfortunately, current firewall, router, proxy, and switch solutions are simply not up to the task. Instead of being simply network and IP-aware, these solutions need to be content-aware. More specifically, they need to be XML-aware. These devices must be able to inspect and understand XML traffic as it flows across the network and perform some sort of activity on the traffic, following the policies set for the purpose.
<p> ZapThink prefers the term <i>XML Proxy</i> to describe the evolving role of XML-aware network intermediaries. XML Proxies consist of either software or hardware applications that monitor network traffic for XML content and perform some kind of activity on that traffic. We distinguish XML Proxies from other types of network intermediaries in that they are XML-aware, while others may be TCP/IP aware or HTTP aware. However, other than the fact that XML Proxies facilitate XML communications and are capable of processing XML documents, the role that XML Proxies fill varies depending on the activity they perform on the XML content.
<p> XML Proxies currently on the market offer a wide-ranging set of functionality for handling corporate-wide XML security, management, routing, transformation, and performance enhancement. Enterprises will implement XML Proxies as a transparent layer over current network traffic (both inside and across the firewall), monitoring and acting on XML data by following established rules.
<p> <b>The ZapThink Take</b>
<p> Today there are many vendors who have recognized the need for XML-aware network intermediaries, and are developing a range of products to meet this need. Being a nascent market, however, the terminology is all over the map: network appliance, software XML firewall, XML application firewall, XML switch, Web Services gateway, the list seems endless. ZapThink considered this terminology tangle and came up with a recommendation. While the term &#8220;XML-aware Intermediaries&#8221; is a broadly inclusive and generally accurate assessment of the current products and services on the market, ZapThink believes that &#8220;XML Proxy&#8221; is a more marketable name, and hence one that can more adequately distinguish the current class of products and solutions on the market today and in the years to come.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.zapthink.com/2002/07/29/xml-proxies-why-current-network-protocol-based-firewalls-and-routers-cant-handle-xml/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>XML Proxies</title>
		<link>http://www.zapthink.com/2002/07/27/xml-proxies/</link>
		<comments>http://www.zapthink.com/2002/07/27/xml-proxies/#comments</comments>
		<pubDate>Sat, 27 Jul 2002 00:07:00 +0000</pubDate>
		<dc:creator>Ronald Schmelzer</dc:creator>
				<category><![CDATA[ZapBundle]]></category>
		<category><![CDATA[3Com]]></category>
		<category><![CDATA[Actional]]></category>
		<category><![CDATA[AmberPoint]]></category>
		<category><![CDATA[Check Point Software Technologies]]></category>
		<category><![CDATA[Cisco]]></category>
		<category><![CDATA[Contivo]]></category>
		<category><![CDATA[DataPower]]></category>
		<category><![CDATA[Flamenco Networks]]></category>
		<category><![CDATA[Forum Systems]]></category>
		<category><![CDATA[Intel]]></category>
		<category><![CDATA[KaVaDo]]></category>
		<category><![CDATA[Linksys]]></category>
		<category><![CDATA[Nortel]]></category>
		<category><![CDATA[Primordial]]></category>
		<category><![CDATA[Reactivity]]></category>
		<category><![CDATA[Sanctum]]></category>
		<category><![CDATA[Sarvega]]></category>
		<category><![CDATA[Stratum8]]></category>
		<category><![CDATA[Vordel]]></category>
		<category><![CDATA[Westbridge Technology]]></category>
		<category><![CDATA[XML Global]]></category>
		<category><![CDATA[XML Infrastructure]]></category>

		<guid isPermaLink="false">http://test.zapthink.com/?p=ZTB-0106</guid>
		<description><![CDATA[As the use and proliferation of XML and Web Services spreads throughout the corporate IT environment, so too will the demands on optimizing the performance of the XML data and applying enterprise-wide XML policies. Increasingly organizations are seeking to find solutions that can transparently monitor XML traffic on the network and apply business rules or corporate IT policies such as security, routing, performance, management, transformation, or end-point connection provisioning. Enterprises will implement <i>XML Proxies</i>, which can be either hardware Network Appliances,software Proxies, or software Firewalls, as a transparent layer over current LAN and WAN traffic, monitoring and acting on XML data as dictated by pre-configured rules.]]></description>
			<content:encoded><![CDATA[<p>As the use and proliferation of XML and Web Services spreads throughout the corporate IT environment, so too will the demands on optimizing the performance of the XML data and applying enterprise-wide XML policies. Increasingly organizations are seeking to find solutions that can transparently monitor XML traffic on the network and apply business rules or corporate IT policies such as security, routing, performance, management, transformation, or end-point connection provisioning. Enterprises will implement <i>XML Proxies</i>, which can be either hardware Network Appliances,software Proxies, or software Firewalls, as a transparent layer over current LAN and WAN traffic, monitoring and acting on XML data as dictated by pre-configured rules.<a href='?file_id=XMLProxies-072002-ZTB-0106.zip' class='download'>Download File</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.zapthink.com/2002/07/27/xml-proxies/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>XML Proxies</title>
		<link>http://www.zapthink.com/2002/07/26/xml-proxies-2/</link>
		<comments>http://www.zapthink.com/2002/07/26/xml-proxies-2/#comments</comments>
		<pubDate>Fri, 26 Jul 2002 00:07:00 +0000</pubDate>
		<dc:creator>Ronald Schmelzer</dc:creator>
				<category><![CDATA[Report]]></category>
		<category><![CDATA[3Com]]></category>
		<category><![CDATA[Actional]]></category>
		<category><![CDATA[AmberPoint]]></category>
		<category><![CDATA[Check Point Software Technologies]]></category>
		<category><![CDATA[Cisco]]></category>
		<category><![CDATA[Contivo]]></category>
		<category><![CDATA[DataPower]]></category>
		<category><![CDATA[Flamenco Networks]]></category>
		<category><![CDATA[Forum Systems]]></category>
		<category><![CDATA[Intel]]></category>
		<category><![CDATA[KaVaDo]]></category>
		<category><![CDATA[Linksys]]></category>
		<category><![CDATA[Nortel]]></category>
		<category><![CDATA[Primordial]]></category>
		<category><![CDATA[Reactivity]]></category>
		<category><![CDATA[Sanctum]]></category>
		<category><![CDATA[Sarvega]]></category>
		<category><![CDATA[Security & Identity Management]]></category>
		<category><![CDATA[Stratum8]]></category>
		<category><![CDATA[Vordel]]></category>
		<category><![CDATA[Westbridge Technology]]></category>
		<category><![CDATA[XML Global]]></category>
		<category><![CDATA[XML Infrastructure]]></category>

		<guid isPermaLink="false">http://test.zapthink.com/?p=ZTR-DI101</guid>
		<description><![CDATA[As the use and proliferation of XML and Web Services spreads throughout the corporate IT environment, so too will the demands on optimizing the performance of the XML data and applying enterprise-wide XML policies. Increasingly organizations are seeking to find solutions that can transparently monitor XML traffic on the network and apply business rules or corporate IT policies such as security, routing, performance, management, transformation, or end-point connection provisioning. Enterprises will implement <i>XML Proxies</i>, which can be either hardware Network Appliances,software Proxies, or software Firewalls, as a transparent layer over current LAN and WAN traffic, monitoring and acting on XML data as dictated by pre-configured rules.]]></description>
			<content:encoded><![CDATA[<p><b>Key Findings:</b><br /> 
<ul>
<li> XML Proxies are hardware or software solutions that actively listen for XML traffic on the network and either pass it along unmodified or perform some action on the XML content. XML Proxies can operate transparently as an XML &#8220;gateway&#8221; or as auxiliary applications on the network.
<li> ZapThink estimates that XML represents less than 2% of all traffic on the enterprise network in 2002; however, this percentage is expected to increase to almost 25% of all LAN network traffic by 2006.
<li> Current firewall and proxy solutions are inadequate to handle XML traffic. Instead of being simply network protocol-aware, XML Proxies are XML-aware.
<li> XML Proxies are capable of examining traffic at the content level, and can optionally handle other message types such as HTML or EDI.
<li> XML Proxies will converge on a single set of functionality for handling corporate-wide XML security, management, routing, transformation, and performance enhancement.
<li> As XML Proxy solutions become increasingly visible in the corporate IT environment, &#8220;established&#8221; Network Appliance vendors will enter the market.
<li> XML Proxies can also allow users to implement XML and Web Services solutions without having to constantly modify those applications to comply with various corporate XML policies.
<li> The increasing need to gain more value out of the XML documents and traffic on the network will drive adoption of XML Proxy solutions. </ul>
<p> <b>Table of Contents:</b><br /> 
<ul>
<li> I. Report Scope
<li> II. The Role of the XML Proxy
<ul>
<li> 2.1 The Evolution of Networking Devices and Applications
<li> 2.2 Why Current Network Protocol-based Solutions Are Not Adequate to handle XML Traffic
<li> 2.3 XML Proxies
<li> 2.4 Use and Context of XML Proxies </ul>
<li> III. XML Proxy Functionality
<ul>
<li> 3.1 Security
<li> 3.2 Performance: Compression and Caching
<li> 3.3 Monitoring and Management
<li> 3.4 Routing
<li> 3.5 Transformation </ul>
<li> IV. XML Proxy Solutions
<ul>
<li> 4.1 Hardware XML Network Appliances
<li> 4.2 Software XML Proxies
<li> 4.3 &#8220;Cross-over&#8221; Software and Hardware Solutions </ul>
<li> V Drivers for XML Proxy Adoption
<ul>
<li> 5.1 Managing increased volume of XML traffic on the network
<li> 5.2 Enforcing corporate XML policies and normalizing XML implementations
<li> 5.3 Simplifying external XML integration
<li> 5.4 Providing Value-Added Services for XML </ul>
<li> VI. Barriers to Adoption of XML Proxies
<ul>
<li> 6.1 XML and Web Services Standards and Markets in Flux
<li> 6.2 Increased Competition through Product &#8220;Scope Creep&#8221;
<li> 6.3 The Rack &#8220;Stack&#8221;
<li> 6.4 Processing Overhead </ul>
<li> VII. Future Trends
<ul>
<li> 7.1 Convergence on a set of functionality: the one-stop box
<li> 7.2 Rapid growth of XML traffic on the network
<li> 7.3 Entrance of the &#8220;Established&#8221; Network Appliance Vendors
<li> 7.4 Further clarification of the role of SOAP Intermediaries </ul>
<li> VIII. Conclusions
<ul>
<li> 8.1 Key Notes
<li> 8.2 Decision Points
<li> 8.3 Figures
<li> 8.4 Tables </ul>
<li> IX. Profiled Vendors
<ul>
<li> 9.1 XML-aware Network Appliances
<li> 9.2 Software XML Firewalls and Proxies </ul>
<li> A. Related Research
<ul>
<li> Reports
<li> Briefing Notes </ul>
<li> B. Copyright, Trademark Notice, and Statement of Opinion
<li> About ZapThink, LLC </ul>
<p><a href='?file_id=XMLProxies-072002-ZTR-DI101-1.pdf' class='download'>Download File</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.zapthink.com/2002/07/26/xml-proxies-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

