Where Are Web Services Heading?

We may be years away from the next type of quantum leap in distributed computing ”the type of quantum leap that brought us XML and SOAP. However, in the meantime, there is plenty of work to be done in driving the two key areas of Web services: interoperability, as defined by emerging specifications and the WS-I Basic Profile, and adoption, as a function of the support provided by the major players as well as the interoperability vendors .

New Specifications on the Horizon

Because of the rapid growth in the number of Web services specifications, by the time this book is on the shelf of your favorite bookseller, there could easily be a dozen new draft Web services specifications, and some of the currently proposed specifications might be approved by their respective standards body. In this section, I ll discuss some of the specifications that were either just proposed when this book went to print or that are desperately needed to fill in the gaps in the overall Web services architecture. I assume that these specifications will all be prefixed by WS , but as things move forward, this may not always be the case.

The diagram in Figure 9-1 details how I believe the specifications that I describe in this chapter will fit into the overall Web services architecture.

Figure 9-1: Proposed future Web services architecture

Now let s take a look at what these new standards might be and why we need them.

WS-Federation

A key component in Web services interoperability is the ability of a client to authenticate with one domain or authentication service and use those credentials on another trusted domain or platform. We should be able to present a security token issued by a given security token service (STS) for authentication to any service that has a trust relationship back to the STS that issued the token, regardless of whether or not our application is in the same trust space as the Web service. And, if we can ensure trust across security boundaries, we should also be able to provide a so-called single sign-in experience by allowing the sharing of user -specific information ”with the user s consent .

In an attempt to solve these authentication challenges, IBM, VeriSign, RSA Security, BEA Systems, and Microsoft have joined forces to propose the WS- Federation specification, the first draft of which was released as this book went to print. Just to be clear, the establishment of trust between security services and across the boundaries of administered security environments, or trust domains, is known as federation . WS-Federation leverages WS-Security, WS- Trust, and WS-Policy to enable this federation and to provide a single sign-in experience with all applications and services in the federation. In particular, WS-Federation provides for the following functionalities:

• Sharing of security tokens that represent user identities across trust domain boundaries

• Sharing of user information, or attributes, for a given identity to provide a single sign-in experience

• Managing pseudonyms to enable a user to access various federated resources using a unique alias at each

Clearly, the main goal of WS-Federation is to drive Web services interoperability by enabling security credentials obtained from a preferred authentication service to be used when accessing resources at any other federated resource to which the user has access. To enable a better single sign-in experience, WS-Federation also provides a mechanism for the sharing of some necessary amount of user information across the trust boundary to federated services. In addition, to maintain the autonomy of the user, WS-Federation describes methods for specifying different aliases at federated services, which breaks the logical link between services that would exist if all knew a user by a single identity.

WS-Federation extends the concept of a security token service (STS) by defining the following additional types of security services that play a role in the WS-Federation model:

• Identity provider A special type of STS that is able to authenticate users, or principals, and issue security tokens that the principal can use later to prove its identity. WS-Federation for the most part assumes that most security services will serve as both identity provider and STS.

• Attribute service Maintains metadata, or attributes, about principals within a trust domain and enables a limited exchange of this information between federated services, within the defined privacy constraints. For example, an attribute service might be accessed to determine a principal s city and state in order to better personalize a request made across a trust boundary, where the service being requested would not otherwise have access to this information.

• Pseudonym service Provides the mapping of a principal s account within a trust domain to a single sign-in identity that exists across domains.

A final piece of federation that is described by WS-Federation is the idea of a federated sign-out. When a user accesses federated resources, the various services may cache security tokens related to that user. When a sign-out message is issued, these security tokens must be removed from caches across all federated services. Published simultaneously with WS-Federation, two additional specifications, named WS-Federation: Active Requestor Profile and WS-Federation: Passive Requestor Profile, define how different types of Web browsers and Web applications leverage WS-Federation. For more information on these federation specifications, as well as a white paper that describes the overall vision of Web services federation, see the WS-Security Specification Index Page on MSDN at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/wssecurspecindex.asp .

WS-MetadataExchange

With its imminent release predicted in WS-Federation, WS-MetadataExchange will describe a mechanism for sharing policy, WSDL, schema, and other Web services “related metadata between federated services. Both WS-ReliableMessaging and WS-Federation will use this specification.

Kerberos Support

As I described briefly in Chapter 5, Kerberos is a fairly complex protocol used to generate session credentials based on a shared secret. The WS-Security specification describes a general framework for transporting binary tokens in the message header, and Kerberos tickets are essentially binary security tokens. However, Kerberos is a complex authentication scheme that involves third-party services issuing trusted credentials. Therefore, we need a standard method that describes how to implement Kerberos within the WS-Security framework, which includes the following:

• How to use Kerberos to establish a secure Web services interaction

• How to request and issue Kerberos tickets from a Web service

• How to attach these binary tokens to a SOAP message

• How to use a Kerberos ticket to sign and encrypt a SOAP message

Authorization

While WS-Security describes how to embed security credentials in the message header, there is no specification that describes authorization. Ideally, there is need of a Web services specification that describes how a Web service defines authorizations and what credentials can be accepted for various levels of access. The joint IBM and Microsoft white paper Federation of Identities in a Web Services World refers to a pending specification named WS-Authorization. This specification will likely integrate with both WS-Security and WS-Policy to define how a Web service accepts credentials to allow access to its resources.

Privacy

While not strictly related to interoperability, issues having to do with online privacy have become a major concern for many developers and privacy advocacy groups in recent years. It s likely that this concern will result in a protocol, tied into the WS-Policy framework, which will enable a Web service to advertise its privacy policy. The joint IBM and Microsoft federation white paper also refers to a pending specification named WS-Privacy. With such a standard, an end user Internet application will be able to divine the privacy policy of all the Web services with which it exchanges data, which would enable the application to give a user accurate privacy information based on an aggregation of the privacy policies of those related Web services.

Data Description

While a great deal of attention has been paid to creating standards for Web services messaging, security, description, transport, and other mechanical aspects of Web services, there has been a conspicuous absence of any protocols that define a standard method for accessing the data using a Web service. Up to this point, the working assumption has been that since we have Web Services Description Language (WSDL), we have the freedom to expose data in a Web service however we want. While this is true, a standard data exchange format would both reduce the dependence on WSDL and remove the necessity for intermediate Web services to take the potentially expensive steps of converting message data to intermediate structures to fit an internal schema or the WSDL definition of a Web service further down the road.

This kind of Web services data specification would provide uniform data description and manipulation, a kind of OLE DB data format for Web services. It would likely detail how to describe data in a proprietary schema using a virtual XML representation mapped to an XSD schema. In my opinion, this specification would need to describe a standard language for data manipulation, which of course includes operations such as create, read, update, and delete data modification language (DML) operations. Perhaps XQuery and XPath functionality could be leveraged so that we wouldn t need to start from scratch.

A similar specification, known as XML for Analysis (or XMLA for short), has already been developed that defines XML data structures for transporting analytics generated data within Web services, and I anticipate a similar standard to address tabular representations and other widely used XML data structures.

Synchronization

When we have a standard for describing data access using Web services, it s not much of a stretch to envision a protocol that describes how to synchronize data among multiple Web services. Synchronizing Web services could prove highly beneficial in a number of scenarios. A standard method for synchronizing Web services data would enable Web services to act as virtual clusters: if for any reason a Web service could not fulfill a data request, the request could be made to a second Web service. This type of Web services failover requires that both Web services have identical copies of the data and that any changes made to the data in one Web service would get synchronized with all of the other participating Web services.

With synchronization and data access standards, such Web services could easily be built on separate, heterogeneous platforms. While creating such a topology is possible today using proprietary methods and WSDL to publish data access and schema information, standardizing synchronization and data access would greatly simplify this effort and remove the need to consume a WSDL file at design time.

Microsoft Support for Web Services

As a major proponent and one of the loudest voices extolling the virtues of Web services, Microsoft is perhaps the key player to watch when trying to divine the direction in which Web services are headed. The rhetoric and hype at Microsoft around Web services have quieted considerably since the early .NET and Hailstorm days; however, Microsoft has continued to doggedly pursue its big bet on the future of distributed computing and software as a service. Just because Microsoft wisely backed away from the idea of securely hosting everyone s private data doesn t mean that it isn t still working to shape the future of Web services.

Microsoft will continue to be a bellwether in this sector. It has already helped the cause along by aiding in the foundation of the WS-I, driving dozens of Web services specifications, continuing to build the .NET Framework, and delivering new products (such as WSE) that enable .NET Web services to implement emerging specifications. What Microsoft desperately wants, at least in terms of technology, Microsoft tends to get. If you don t think that this is the case, consider the Xbox video game system and those come-from -behind wins with Internet Explorer and the enterprise server offerings, such as SQL Server and Windows Server.

Web Services Enhancements Going Forward

At the completion of this book, WSE is approaching its 2.0 release. In addition to the initial support for WS-Security and DIME attachments, support now exists for other large chunks of the Web services standards framework with the addition of WS-Trust, WS-Policy, WS-SecurityPolicy, and WS-SecureConversation in WSE 2.0. For early adopters, there was some churn, with the optimistic support for WS-Routing being replaced almost entirely by support for WS-Addressing.

As of this writing, Keith Ballinger, lead program manager for WSE, has advised me that besides more tools, documentation, and sample code, WSE 3.0 is expected to support the new standard WS-ReliableMessaging. WS-ReliableMessaging brings message queuing capabilities to Web services, which as I mentioned earlier overlaps with the WS-Reliability specification. WS-Reliability has, at this writing, already been submitted to the OASIS standards group by Oracle, Sun Microsystems, and Fujitsu, while Microsoft and partners have published but have not yet submitted the WS-ReliableMessaging specification for standardization. Microsoft and partners claim that WS-ReliableMessaging has been structured to work better than WS-Reliability with other specifications, such as WS-Security, but time will tell.

As to the future of DIME and WS-Attachments, as I prepare to hand in this manuscript for publication, the draft DIME specification has not been resubmitted to the Internet Engineering Task Force (IETF). With continued advancements in the SOAP with Attachments specification that I discussed in Chapter 3 coupled with this pullback from pushing DIME as an encapsulation standard, I have to wonder whether the third version of WSE will continue to support DIME and WS-Attachments and whether IBM and Microsoft will keep pushing these specifications.

Indigo

With the unveiling of its technology code-named Indigo at the Microsoft Product Developers Conference 2003 in Los Angeles, it became clear that WSE is meant to be an interim solution for building secure and reliable Web services, much like the SOAP Toolkit before the advent of .NET. Microsoft introduced its first support for SOAP in the SOAP Toolkit, followed shortly by support for both SOAP and WSDL in the first release of the .NET Framework and Visual Studio .NET. At this point, it seems likely that WSE will play a similar role as the SOAP toolkit in migrating developers into the future of secure, reliable, and transacted Web services. Indigo, which Microsoft describes on their site as a new breed of communications infrastructure built around the Web services architecture is designed to provide secure, reliable, and transacted messaging along with interoperability. Since Indigo will be delivered in the next version of the .NET Framework, code-named Whidbey and introduced at the Microsoft Product Developers Conference (PDC) 2003, it will provide the infrastructure for the security, messaging and the other advanced Web services functionalities that are now only available through WSE. For more information on Indigo, see the Indigo site at http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx .

Microsoft TrustBridge

In a press release back in June 2002, Microsoft announced plans for a new offering that will extend Microsoft Windows Server 2003 to more easily implement Web services “based federated trust scenarios. With a code name of TrustBridge, this offering leverages the Web services support in Windows Server 2003 and the .NET Framework along with Web services security standards to enable the use of .NET Passport, Kerberos tickets, or X.509 certificates as authentication credentials between Web services hosted by Windows Server 2003. This trust scenario provides the following benefits:

• Provides XML-based trust federation between trust domains leveraging WS-Security

• Enables browser-based single-sign-on scenarios

• Supports Microsoft Active Directory, .NET Passport, and Kerberos authentication

• Includes trust management and auditing tools

• Provides full integration with existing Windows Server tools

While it sounds like the idea of TrustBridge is still alive , as this book goes to print it seems much more likely that this product will be delivered with the next release of Windows client, code-named Longhorn, much like the SOAP Toolkit before the advent of .NET.

Web Services in Windows

While much of the .NET excitement has been driven by the .NET Framework, which includes ASP.NET and Visual Studio .NET, Microsoft s core franchise is still Microsoft Windows. Since the launch of .NET, Microsoft has been slowly moving back to a Windows positioning for these new Web services technologies, as is evidenced by the subtle renaming of the .NET Framework to the Windows .NET Framework in version 1.1. It s certainly likely that Windows, whether for the personal computers, servers, or handheld devices, will be the product in which Microsoft will be showing off all of its own cutting-edge Web services “based technologies.

With Microsoft s continued focus on allowing users to do more with their data and considering the original vision of .NET My Services, I would not be surprised to see some kind of Web services “driven data exchange mechanism for end user data built into the upcoming Longhorn release of the Windows client platform for the PC. I ll also be watching to see whether the Indigo functionalities incorporated in the Whidbey version of the .NET Framework will support WS-Transactions and WS-Coordination for Web services “based distributed transactions.