Although ,a href="http://www.ibm.com/">IBM, Microsoft, Sun, and a raft of other W3C participants have signed on to major specifications required for this environment to flourish (including SOAP and XML), there's still a lot of work to be done in order to make Web services a viable Internet platform for cross-application communications.
Many CIOs I've talked with are hesitant to begin developing systems that rely heavily on Web services due to legitimate reliability and security concerns. Now that the standards are moving ahead quickly, CIOs can at least start developing internal systems where these issues are more easily managed, while waiting for public standards to be released. Once standards are released, it will be easier to build systems that interoperate outside the firewall.
IBM and Microsoft are drafting and submitting most of the new W3C proposals around Web services, and so far, five new draftsââ,¬"WS-Inspection, WS-Referral, WS-Routing, WS-Security, and WS-Licensingââ,¬"have been submitted and are under review. Let's take a look at the existing holes in the Web services fabric and how these draft specifications are designed to solve them.
Finding services directly
The existing Universal Description, Discovery, and Integration (UDDI) standard documents the methodology for discovering and consuming Web services when the location of the Web service is unknown. UDDI works like a Yellow Pages directory, allowing an application to find and contact a server hosting a given Web service. But in many cases, the locations of the Web services are known, and it's inefficient to use UDDI to look up the address first. Having a central repository for service discovery is useful for publishers wanting to expose their services but may not be the most efficient way for consumers to connect.
WS-Inspection, on the other hand, relies on a completely distributed model for providing service-related information. Service descriptions are stored at the delivery point, and requests to retrieve the information are directed to the sites offering the services. WS-Inspection is an XML format that helps a calling application query a known site for available services that it exposes. It defines a set of rules for how sites should expose their inspection-related information to callers issuing a query. WS-Inspection documents also provide methods for aggregating references to preexisting service description documents, regardless of the original format in which they were authored. The service information returned by a query uses existing standards, such as Web Service Description Language (WSDL), which allows the calling system to work with the returned Web service information without modification.
Building reliable systems
Initial implementations of the SOAP protocol are simple, one-way calls between two systems. The WS-Referral and WS-Routing specifications provide core technology that will help systems architects build more robust systems. These two specifications work together to define the concept of a SOAP router, which systems architects and developers can use to develop Web services like load balancing, mirroring, caching, and client authentication. For example, a Web service may hand off portions of its processing to third-party services, and the results can be returned to the original users of that service without them ever knowing.
The WS-Referral specification defines how SOAP routers will build a message path between multiple service points, and WS-Routing defines the way to describe the path of a message. WS-Routing also adds the capability to define a reverse message path, thus enabling two-way message exchange patterns like request/response, peer-to-peer conversations, and the return of message acknowledgements and faults. This adds to the overall reliability of a system built on the SOAP platform.
Building secure systems
Existing SOAP-based systems pass their payload as XML text strings. Although this allows any two systems to communicate regardless of their underlying architecture, it presents some serious security concerns. Existing standards allow encryption of the information while it's in the pipe (using SSL over HTTP) or encryption of the pipe itself (using Internet Protocol Security, or IPSec). But these are all-or-nothing scenarios. Unless both sides of a conversation agree on the formats for securing the message itself, then it's impossible to enforce more granular security methods.
The WS-Security and WS-License specifications work together to enhance the granular security of SOAP-based systems. WS-Security defines the ability to exchange credentials, verify the integrity of a message, and to enforce confidentiality of a message, and can be used individually or in any combination. Using WS-Security, messages are associated with licenses (including, but not limited to, X.509 certificates or Kerberos tickets). WS-License describes the process for encoding credentials for use with WS-Security. WS-Security includes instructions for ensuring message integrity (using WS-License) and also confidentiality, by leveraging encryption to encode all or part of a message while providing the means for receiving systems to decode the information.
TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to fire walls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
©2001 TechRepublic, Inc.
