Chapter 1: Web Services Specifications and Interoperability

This chapter begins with a discussion of the importance of interoperability in the enterprise and why widely adopted specifications are crucial to the future of SOAP-based Web services. It describes Microsoft s proposed vision for Web service interoperability and how Microsoft proposes to extend SOAP-based messaging for the enterprise. This chapter also introduces the Web Services Interoperability Organization (WS-I, http://www.ws-i.org/ ), a consortium tasked with providing guidance, in the form of interoperability recommendations and tools, to application developers. Finally, this chapter provides a brief overview of the foundational technologies on which these advanced Web services specifications are based.

The Promise of Web Services

To understand the promise of Web services, I need to be clear as to what I m referring to. A good (albeit basic) description of Web services is that they use standard Internet communication protocols to provide a discoverable standards-based architecture to integrate applications in a decentralized environment. In this age of distributed computing, people expect applications to be able to readily share information with each other, but achieving this level of interoperability has traditionally involved writing lots of customized code to handle and translate incoming data streams of various formats on varying platforms. Unlike simple application integration, which relies on writing custom code or implementing third-party solutions to enable dissimilar applications to communicate, interoperability promotes communication by enabling applications to communicate using agreed-upon communication protocols.

Today an XML-based Web service exposes public methods by using Internet protocols that are published specifications that have been widely adopted by the industry. This means that instead of effecting an implementation requiring communication via platform-specific binary protocols, developers can use well-known Internet messaging standards to create applications that can interact with other applications. The net result is that Web services can be constructed using a variety of technologies on whatever platform the architects are most comfortable working with. Instead of wasting time writing customized integration code, you can spend more time developing the features that your customers demand.

To that end, Web services are essentially Web-based applications that can be described, published, located, and remotely accessed using standard Internet protocols, wherein access to the service is provided by XML messages that conform to SOAP.

Note

SOAP is an XML-based messaging format that is a key component of interoperable Web services, and I do discuss it at some length in this chapter. However, since I do not intend this book to be a resource on SOAP and XML, you might also want to check out Building XML Web Services for the Microsoft .NET Platform by Scott Short (Microsoft Press, 2002).

Since a Web service is discoverable and accessed via standard protocols, other applications or Web services can use it without the requirement that these clients possess detailed knowledge about the service s underlying implementation.

Web Services Interoperability

The bottom line of being based on widely distributed and adopted specifications, which are platform-neutral, is that Web services are ultimately designed to improve interoperability between applications. While you can develop Web services based on proprietary message formats for use within an organization, cross-organization interoperability is the pinnacle of a distributed computing environment in which applications developed in various programming languages and on differing platforms are able to communicate in order to exchange information and get work done. Until now, achieving interoperability has required creating specialized software components to bridge the gap between incompatible systems, a process that required a high degree of expertise with both systems and that therefore usually involved the hiring of expert consultants . Now, with the ability to write toward interoperable interfaces, Web services hold the promise of providing interoperability at a much lower cost.

For example, for a client to be able to access a Web service, only a limited amount of information about the service, namely, the service address and the XML schemas of the request and response message for the exposed Web methods, needs to be disclosed. The client doesn t know whether the request is serviced by a COM-based service running on a Microsoft Windows server or by a Java-based application running on a Sun Solaris server. Furthermore, bindings have been defined for SOAP over Hypertext Transfer Protocol (HTTP) and over Simple Mail Transport Protocol (SMTP), and applications can be accessed through firewalls on port 80 and using e-mail, which means that you won t have to open new ports on the firewall to enable SOAP messaging.

Note

The thought of allowing access to Web services across the firewall on port 80 may make some administrators nervous. However, new technologies are being developed to more effectively scan port 80 to allow access only to valid messages.

Because a Web service uses SOAP messaging, a client application that consumes a Web service can run on any device with Internet connectivity and the ability to serialize and parse XML. This means that other non-PC devices, such as mobile phones, PDAs, Tablet PCs, and even Web-enabled appliances, can consume SOAP messages and transform the encapsulated information as needed for a particular device. For example, consider a certain Web service that provides up- to-date inventory information. A SOAP request message to the inventory service would be the same whether it was sent by a client application running on a PC, on a PDA, or on a mobile phone.

The Role of Standardization

One of the main factors in the success of Web services will be the willingness for and the ability of all of the industry s fiercest competitors to work together toward a standard set of distributed protocols based on SOAP. When the supporters of today s disparate computing platforms are all able to develop Web services that uphold these standards, we will all be free from the archaic clutch of platform-partisan development. True interoperability can be achieved only when the Web services community develops, adopts, and implements meaningful specifications based on business needs rather than on an individual group s political or corporate goals.

To develop specifications that address real-world needs and that support the broadest base of developers, businesses, and consumers, the daunting task of generating meaningful standards has been taken on by Microsoft and IBM and other industry partner. Specifications, like SOAP, became de facto industry standards long before they were ratified through the standards process, which makes the task of these bodies much easier by working with specifications that have been already proven in industry. When it comes to Web services, these are some of the key standards bodies and interoperability organizations:

• World Wide Web Consortium (W3C) Since the early days of World Wide Web standards such as Hypertext Markup Language (HTML) and cascading style sheets (CSS), the W3C has handled many of the core foundational Internet specifications. Today they also handle many of the core XML and Web services specifications, including XML, XPath, XSLT, SOAP, WSDL, XML Encryption, and XML Signature. Although this organization moves rather slowly, it has a great deal of buy-in from the developer and business communities. You can learn more about the W3C at http://www.w3c.org .

• Organization for the Advancement of Structured Information Standards (OASIS) A newer standards body that aims to support business-oriented Internet and Web services standards, this group seems a bit more nimble than the W3C but is also not as well known. The goal of this group is to fulfill business needs with common specifications that help businesses agree upon common languages and mechanisms. OASIS has been tasked with driving adoption for, among others, the following specifications: WS-Security, UDDI, SAML, and ebXML, and they have already released WS-Security 1.0. You can learn more about OASIS at http://www.oasis-open.org .

• Internet Engineering Task Force (IETF) A venerable but relatively slow-moving standards group, the IETF focuses mostly on transport protocols. It has handled such standards as SMTP, URI, and most recently, WS-Attachments and Direct Internet Message Encapsulation (DIME). To learn more about the IETF, see http://www.ietf.org .

• Web Services Interoperability Organization (WS-I) WS-I is a consortium made up of industry leaders that have banded together to improve the interoperability and thereby the adoption of Web services. The WS-I is focused on the big picture of Web services, and to that end it deals with defining and testing a subset of existing specifications that will guarantee interoperability among the disparate Web service platforms. The WS-I is also developing sample applications and testing tools to enable developers to develop more interoperable Web services.

Although everyone seems excited about creating and deploying Web services, as mentioned earlier, interoperability is one of the major driving forces behind these technologies. However, going forward interoperability can be maintained only with a broad adoption of meaningful Web service specifications. For example, even though a number of XML-based protocols existed initially for making remote procedure calls to services, only since the broad adoption of SOAP have many commercial and interoperable Web service deployments been undertaken.

SOAP by itself is not a detailed enough specification to describe many of the business and technical requirements needed by commercially viable Web services, such as secure messaging and trust as well as complex message addressing and transactions. Fortunately, SOAP is extensible such that developers can implement these characteristics; but when this extensibility is leveraged in a proprietary manner, interoperability will suffer. So instead, the industry has wisely turned to extending SOAP using openly published specifications. However, in the race to implement Web services, competing specifications are being proposed independently by many industry leaders and being handled by the various standards bodies. This kind of activity is to be expected in an emerging field, and this number will decrease to a manageable number as certain well- drafted and efficacious specifications receive the backing of a majority of players, as happened with SOAP.

Advanced Web Services Architecture and the Microsoft Vision

To continue the evolution of Web service standards in a consistent and systematic fashion and to promote a more systematic development of XML Web service specifications, industry leaders, including IBM, Microsoft, BEA Systems, Tibco, SAP, and others, are taking a more modular approach to the development of future specifications. The four main goals of these emerging Web service standards are as follows :

• Built on widely accepted standards Advanced Web services specifications must be built on existing, ubiquitous standards such as SOAP, WSDL, XML, and XSD.

• Modular Adopting a set of specifications in which each standard has a limited scope allows for faster adoption and simpler implementation. Also, as new needs arise, new modular elements can be added to the mix. With such an approach, Web services can be developed more efficiently through the implementation of only those functionalities that they need to get the job done.

• General-purpose These specifications should be applicable in and useful for a wide array of service sectors.

• Federated With service interoperability as the key goal, these specifications must allow Web services that operate cross-platform and cross-domain, without a centralized administration or support structure.

For example, if a Web service needs to communicate in a secure manner but does not require additional message-routing functionalities, the service need only implement the security functionalities that it requires without being burdened by the rest. This modularity also reduced the overall complexity of specifications, which makes them easier to read and more readily understandable than the wide-reaching specifications of the past.

In this coming world of Web service standards, XML Web service standards will be architected using more detailed and descriptive Web services standards with smaller scope that build upon foundational Web service standards that are in place today. Figure 1-1 shows how this architecture will unfold.

Figure 1-1: Web service standards architecture

As you can see, all of these proposed Web services specifications are built on SOAP and XML, which, in turn , leverage the underlying Internet transport protocols HTTP, TCP/IP, SMTP, and the like. Standards, like WSDL, that expose information about a Web service s interfaces and access requirements can be extended to support these advanced Web services specifications. Missing from this architecture are any specifications that proposed a standard format for how binary data is transported in SOAP messages and how this data can be synchronized and cached in a Web service, as these standards have not yet been defined. However, since providing and processing data are principal reasons for writing a Web service, such specifications will make up the top level of this architecture. I discuss these and other possible future directions in Web services standards in Chapter 9.

In fact, we have already achieved some major milestones in interoperability with advanced Web services functionalities. Thanks to support in version 1.0 of Microsoft Web Services Enhancements (WSE), as early as August 2002, IBM and Microsoft were able to demonstrate a functionally interoperable XML-based Web service for secure transport of binary attachments between a Java-based application hosted on IBM WebSphere and a Microsoft .NET application. In an even more convincing demonstration that occurred at the 2003 Burton Group Conference just as this book went to press, Microsoft and IBM demonstrated federated identity and secure, reliable Web service communication between .NET and WebSphere endpoints. In this demonstration, trust relationships were established between mock companies, and messages were sent in a secure, reliable manner between .NET applications running on Windows Server 2003 and WebSphere-based applications running on Linux. The demonstration showed modularity of the advanced specifications described in this book and showed that they can be used to create messaging scenarios that are secure, reliable, or both secure and reliable. For more information on this demonstration, see http:
//www.informationweek.com/story/showArticle.jhtml?articleID=14800273 .

In the rest of this chapter, I ll discuss the foundational technologies that represent the building blocks of this advanced Web services architecture. For a more complete discussion of this advanced Web services architecture, read the white paper Secure, Reliable, Transacted Web Services: Architecture and Composition published jointly by Microsoft and IBM and available at MSDN online ( http://msdn.microsoft.com/library/en-us/dnwebsrv/html/wsoverview.asp ). In following chapters, we ll take an in-depth look at the major Web services specifications and examine Microsoft s implementation strategy for them.

Making Web Services Interoperability a Reality: More on Microsoft s Vision

Web services allow disparate systems to interoperate , solving part of the integration problem and enabling the creation of service-oriented architectures. But the mere exchange of application-level messages is not always enough: applications often require platform-level solutions to the generic issues of security, reliability, routing, and transactions. While the value of using Web services has often led organizations to create unique, proprietary answers to these problems, for true interoperability it s essential that broadly accepted industry solutions exist.

Microsoft and industry partners are designing a set of specifications to provide standard protocols for secure, reliable, and transacted Web service communication. This collection of specifications is called the advanced Web services protocols (WS-*). These specifications are based on widely used Internet standards previously engineered by Microsoft and partners , standards such as XML schemas, SOAP, and WSDL. These composable and federated specifications are applicable to a broad range of uses, from large business-to-business (B2B) applications to interactions among small devices.

To accelerate broad adoption, gain feedback, and prove interoperability, Microsoft and its partners continue to publish early drafts of the specifications, refining them through public workshops. Microsoft intends to submit completed specifications to a standards-setting organization for ratification and is committed to licensing necessary technology on a royalty-free basis.

Microsoft s strategy for Web services connectivity, today and moving into the future, is called Microsoft .NET. Those who want to begin realizing the benefits of service-oriented architecture can take advantage of supported code offered by Web Services Enhancements for Microsoft .NET, which provides an early implementation of the advanced Web services specifications. Over time, deep Web service support will be found at the platform level.