member login

WebServices dot org

Todays Featured Content:

StrikeIron Jump-Starts 2008 with Multiple Industry Honors

CMP’s Intelligent Enterprise Web site announced its 2008 Editors’ Choice Award winners with StrikeIron included among its 36 “Companies to Watch” in the enterprise application category. StrikeIron was also included in Robin Bloor’s list of “10 IT Companies to Watch in 2008.”

StrikeIron Expands Web Services Marketplace with New Financial and Business Data Services from Gale

In-depth financial and corporate information on hundreds of thousands of U.S. and international companies: Two new Financial and Business data services from Gale, part of Cengage Learning, have been added to StrikeIron's expanding Web Services Marketplace: Gale Business Information Web Service 1.0.0 and Gale Business Intelligence Web Service 1.0.0.

StrikeIron Delivers Data Web Services via IBM QEDWiki

StrikeIron Inc., a provider of Data as a Service (DaaS), today announced that it has aligned with IBM to deliver premium web services via IBM's enterprise mashup maker QEDWiki. Content available includes business intelligence services such as multiple D&B services, Address Verification, Email Verification, Currency Rates and many more.

StrikeIron Super Data Pack

Start working with Web services and live data instantly! The Super Data Pack brings together dozens of Web services into one easy-to-use “Super” Web service. With the Super Data Pack, developers and end-users can leverage multiple data sources for use within a diverse set of rich applications at no cost or with no commitment.

Featured Content provided by StrikeIron, Inc.

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.