Web services won’t be truly ready for enterprise prime time until the industry provides tools, standards and approaches for managing traffic and ensuring predictable end-to-end performance. Unfortunately, the industry hasn’t begun to explore the possibility of binding SOAP to something other than HTTP – preferably, to middleware protocols, such as Java Message Service or MQSeries, that support guaranteed, reliable message delivery.
To most users, the Web is a “world wide wait.” The typical browsing session has more long, awkward pauses than a Swedish art film. Even power users with broadband connections are frustrated by HTML pages that take too long to display and files that take forever to download.
The new generation of Web services, grounded in XML and Simple Object Access Protocol (SOAP), isn’t fundamentally faster or more reliable. The reason for this sad state of affairs is that XML and SOAP are just new freight in old boxcars, and the rails they’re riding are the Web’s HTTP. What’s lacking from HTTP is a standardized means for ensuring guaranteed, timely delivery of content – be it HTML, XML, streaming video or anything else – from server to client. Instead, HTTP offers what’s euphemistically known as best-effort delivery, which means that each intermediate router will attempt to forward packets to the optimal next hop, but that the end-to-end path taken by any individual packet is beyond any node’s control.
Web services won’t be truly ready for enterprise prime time until the industry provides tools, standards and approaches for managing traffic and ensuring predictable end-to-end performance. Unfortunately, the industry hasn’t begun to explore the possibility of binding SOAP to something other than HTTP – preferably, to middleware protocols, such as Java Message Service or MQSeries, that support guaranteed, reliable message delivery.
Nevertheless, Web services work well enough for many real-world applications. Web services implementers have come up with many creative approaches for speeding and scaling delivery of HTML and XML/SOAP traffic over HTTP, without messing with the underlying transport protocol. The most promising techniques for end-to-end Web services traffic management are content caching and choreography. Unfortunately, the industry hasn’t converged on the standards needed for interoperability among diverse vendors’ traffic management approaches. Until vendors agree on such standards, an effective approach for global management of Web services traffic will remain out of reach.
For example, caching infrastructures have become critical to the delivery of HTML, FTP downloads and other static contents, and increasingly are being used with dynamic database-driven contents. The good news is that there are Web caching standards. The bad news is that there are too many of them. Caching vendors implement a confusing array of proprietary and open specifications.
The situation isn’t much better in the content choreography arena. In Web services environments, choreography refers to the structured, rule-driven workflow of information and tasks across network connections between two or more application components. In a SOAP-based environment, choreography refers to the functions performed by integration broker servers, and, to a lesser extent, by the new wave of specialized application data router appliances.
However, unlike IP routers, application data routers typically aren’t set up to participate in a global routing mesh that computes optimal routing paths. Instead, application data routers primarily serve as co-processors that accelerate local routing and transformation of XML/SOAP messages. There is no equivalent to Open Shortest Path First protocol or Border Gateway Protocol for XML/SOAP application data routers.
Over the next several years, traditional IP network routers might evolve to incorporate SOAP content routing and caching functions. Recently, the industry has taken a tentative step in the right direction by developing the WS-Routing specification, which provides a syntax for defining the end-to-end routing path of a SOAP message. But WS-Routing defines static routing paths, not the dynamic paths necessary for adaptive, real-time Web services traffic management.
Increasingly, Web services middleware approaches are being deployed in mission-critical corporate network applications. But Web services still have to prove themselves where performance and scalability are concerned. They could become a sprawling, unworkable, unscalable mess if the industry doesn’t proactively address open issues surrounding end-to-end traffic management.
