member login

WebServices dot org

Todays Featured Content:

Layer 7 Technologies Announces Support for Solaris(TM) 10 on SPARC

Leading XML Security and Networking Vendor Adds Support for SPARC Platforms to Family of Products to Help Secure, Simply and Scale XML and SOA Deployments

Fast and Flexible Security Solutions for Cross-Domain Web Services Integrations

This paper presents general, benefit, and architectural information about the SecureSpan™ family of products.

A Practical Guide to Policy Authoring for SOA Governance

This Webcast, presented by Layer 7 CTO and WS-Policy co-editor, Dr. Toufic Boubez, will cover how to declaratively *define SOA Policy for SOA Governance applications.* Consistent, standards based policy definition is the first step in implementing an SOA Governance framework.

ZapForum Podcast: Understanding Identity & SOA

Learn what identity is and how it fits into SOA, understand the relationships between identity and governance and between identity and policy. Grasp the nature of federated identity, and the standards that support it

Featured Content provided by Layer 7 Technologies

The Coming XML Invasion: There Will be Many Needles in Our Haystacks

20th Apr 06:

XML penetration in our organizations is about to accelerate dramatically – and not under our direct control.

Many of us have been working with XML for quite a while now, and usage continues to grow as we build out our Web services and SOAs. Analysts have been predicting that XML messages may constitute as much as 50 percent of our network traffic within two years. The challenge is, then, one of being able to separate out the XML wheat from the chaff when it comes to protecting your Web services and SOA.

Two trends will drive this challenge – the deployment of Office 2007 and the burgeoning adoption of Ajax and similar technologies. Office 2007 uses XML file formats for all of the popular productivity products, admittedly in Zipped containers, but then for bandwidth reasons we are already seeing of custom XML zipped to reduce document and message sizes. So we will see lots of XML scattered around our internal networks.

Ajax and other dynamic Web interfaces use XML for back-end communication. As browser users in your organization interact with Google Maps and other emerging interfaces, this moves XML and Web services traffic across your corporate boundaries in both directions.

What does this mean for the issues we are already grappling with in XML, such as processing and transaction throughput on application platforms, security of content and services, and understanding and control of Web services deployments in general? With Office 2007 and Ajax, the scale of the problem is going to have a huge impact. Traffic generated in many of these emerging applications is not just the limited transfers between applications – it is orders of magnitude higher, as it is being generated by that “great unwashed” multitude of users.

Enterprises often believe they can control their XML traffic by ensuring that Web services are only accessible internally. However, it’s difficult to effectively separate Web services access from other HTTP traffic without an XML security gateway.

These enterprises now have a big problem. How do you know whether in that mass of XML moving across your Internet connection is not some piece of proprietary or private data? Looking for XML content that should be controlled and protecting it is going to be much like looking for the proverbial needle in the haystack for traditional network security devices.

The requirement to offload XML filtering, security, privacy and transformation into an -XML-aware network appliance has never been higher. By early 2007 the XML deluge will be starting to hit. Now is the time to get these issues under control.


Trackback URL for this post: http://www.webservices.org/trackback/id/74001

Comments

Why should we control XML traffic?

Sorry, but maybe I didn't understand your concern. I think we do not have to bother at all with the growing XML traffic. If your only concern is whether networks can handle the extra amount of traffic, I would say it is not a big problem. I mean bandwidth is going so fast, the costs for network traffic are falling quickly, so there is no real need to do some kind of XML filtering.

Will infrastructure keep up?

A sort of Moore's Law -- as it relates to network bandwidth -- may outpace the demands of increasing XML traffic. The other side of the issue is we need to increase the capacity of hardware and servers as well. But it's a question of organizations forking out the money for the necessary upgrades -- for hardware as well as higher-capacity networks. An analogy would be the continual need to overhaul servers and workstations for every new release of Windows -- it can take years, and doesn't happen in one swoop. The infrastructure will eventually catch up, but in their current state, may just not be ready to handle orders of magnitude increases in XML traffic.

xml and network traffic

yes, huge file of XML will affect network traffic. It should hav compressed file are some other mechanisms like browser in-built for xml files. we hav to find some other idea to reduce its size