member login

WebServices dot org

Todays Featured Content:

SOA testing tools advance

Mindreef and iTKO are making separate moves Tuesday in the SOA testing space. Mindreef has integrated its SOAPscope Server SOA and Web services testing software with HP Quality Center, a centralized platform for managing processes and automating software testing. ITKO is announcing availability of Lisa 4 SOA Testing, a product suite for testing SOA.

Mindreef Introduces SOAPscope Workstation for Web Services Testing, Diagnostics, Governance and Support

Mindreef product family expanded to include a cost-effective professional solution for individuals and small teams creating and maintaining high-quality web services and composite applications.

Automating What You Can’t See: Testing Middleware for the Enterprise

Read about the problems of testing SOA middleware applications and the requirements for the tools, and discover one solution that has been in use for over a year, has executed hundreds of thousands of tests, and certifies the functionality of systems that execute over a billion transactions per month.

The Foundation of SOA Quality

This paper explores the many facets of SOA Quality and the primary technology elements that make up the Foundation of SOA Quality.

Featured Content provided by Mindreef

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