Weak Points in Web Services Architecture

Although hundreds of Web services applications have been written (a good list can be found at www.xmethods.com), the Web services architecture can still be considered to be "in its infancy." The reason is that, although UDDI, WSDL, and SOAP do work as advertised, numerous improvements need to be made to UDDI registry service and related Web services protocols to "harden" them for use in business critical production environments.

In my new role as president of Bloor Research North America, I recently published a report (Web Services Gotchas) that identifies eight "shortcomings" of Web services architecture that may impede the progress of Web services in enterprise-class computing environments (see Figure 4-1).

Figure 4-1. Web Services Shortcomings/Gotchas According to Bloor Research.

Source: Bloor Research North America, May, 2002. Used by Permission.

In short, at Bloor Research North America we believe that there are certain Web services shortcomings that must be overcome to foster the adoption of the architecture in message-rich, transaction-heavy, enterprise-class computing environments.

A closer look at the "gotchas" reveals the following shortcomings:

• Security/privacy Specifically ensuring that content can be authenticated and validated, can restrict authorization rights to prevent unauthorized viewers from using restricted content, and that ways can be found to ensure data integrity.

• Routing/messaging, Reliability/quality-of-service/transaction handling Protocols must be developed to track messages through multiple intermediaries. Standards must be established to ensure messaging reliability (this is especially important in financial transaction processing scenarios where the underlying Web services architecture must be capable of "rolling-back" transactions to their original state should a failure of some sort occur). Until these protocols are developed (or become more mature), Bloor Research will continue to identify these areas as shortcomings.

• Transaction-handling in particular All preceding distributed computing architectures provided ways to monitor and track transactions, roll-back transactions, and manage/tune application and systems environments to ensure optimal performance. Many of these architectures made use of transaction monitors to accomplish this task. The W3C has not, and is not in the process, of creating a standard transaction monitor. Thus, this task will roll to vendors or open-source software providers. And at present, the lack of a robust Web services standard for transaction tracking/roll-back/monitoring is, in the opinion of Bloor Research North America (NA), a Web services shortcoming.

• Manageability The lack of an overall plan for managing Web services environments (from a system, network, and application level) makes Bloor Research NA consider Web services manageability an architectural shortcoming. (Note that many vendors are stepping forward with robust, Web services-capable frameworks and products to assist in Web services management in the short term as well as for the long term.)

• Interoperability The formation of the WS-I goes a long way toward addressing Bloor Research NA's concern about how interoperability will be achieved across multiple disparate platforms and differing application program language environments. Still, the newness of the WS-I, plus its initial political positioning (leaving Sun off the invite list until the last minute), makes Bloor Research a little suspicious of the group's motivations. Hence, interoperability is identified as a shortcoming.

• Performance/tuning There is a distinct lack of performance tuning information and/or tools for optimizing Web services computing environments. Although the W3C does internal quality assurance (and has even published some of its test suites/tuning utilities), it is Bloor Research NA's opinion that not enough is being done here to assure that Web services applications can be optimized to compete from a performance perspective with tightly coupled distributed computing architectures. Hence, we see performance/tuning as an exposure to the general acceptance of Web services architecture by enterprise clients and thus consider performance/tuning to be a shortcoming.

In Bloor Research NA's opinion, the bottom line is that for Web services to be accepted at the enterprise level issues such as reliability, quality-of-service, transaction handling, security, manageability, and more must be addressed in a cohesive fashion. And the good news is that, through the efforts of the W3C, the vendor community, open-source software providers, and consortia, all of these shortcomings are being addressed.

Having Stated This…

Our latest research shoes that by mixing and matching Web services standards-based product with "enhancers" (other open-source or vendor-produced products that fill in the gaps in Web services architecture), reliable, secure Web services environments can be built. And, by using messaging appliances, performance tuning software, and other hardware and software products, performance-related issues can be overcome (or at least mitigated).

As a result of discussions with early-adopter Web services users and vendors, Bloor Research NA believes the following:

Even though Bloor Research NA has identified several Web services shortcomings that must be addresses by formal standards activity over time, it is our opinion that these shortcomings are not showstoppers, and we advise that enterprises not wait to experiment with and build Web services solutions. Between the advances being made within the W3C standards committees, and the advances and extensions being built by the open-source and vendor communities, very functional (even mission-critical) Web services environments can be built and deployed today.

We do observe that, at this juncture, Web services architecture is best deployed in-house (on a corporate intranet) or on a protected virtual private network (with known secure business partners) because HTTP-based Web services can leave open holes for external hacking/invasion to take place. We also believe that at this juncture, Web services routing/message handling (and transaction handling) is not well-suited for handling heavy transactional environments unless third-party products (like appliances that off-load message handling and perform security tasks) are used to augment simple Web services routing and messaging.

Still, by taking these issues into consideration (and by using workarounds to overcome these issues) there appears to be no need to wait several years until the standards mature before experimenting with Web services architecture. Web services architecture can be used successfully today in enterprise-class, production computing environments (provided it is properly augmented with the right mix of vendor-supplied hardware and software extensions to make it secure and reliable and capable of handling a lot of message traffic).

Source: Bloor Research North America (Web Services Gotchas). Used by Permission.