Chapter 9: Future of Web Services, Specifications, and WSE

This final chapter discusses future directions of Web services, the Web Services Interoperability Organization (WS-I), and any newly proposed specifications. It also describes the other kinds of services we can expect from Microsoft in the near future and shows how they might be of interest to developers. In addition, the chapter discusses how the unification of Microsoft s Web services vision around well-accepted, advanced Web services specifications provides the foundation for future Microsoft service offerings.

Where Are We Now?

I believe that when Web services truly arrive , I will no longer be writing articles and books describing and promoting Web services specifications, tools, or technologies. They will be so ingrained in our everyday work that we won t think of them as special, separate, or especially innovative. Even now, most people have become accustomed to Web sites working as expected, unaware of the complex underpinnings that enable their computers to interact with Web servers around the globe. A time is coming when deploying a complex Web services “based application will be as simple as creating an HTML Web page. At that point, support for all of these networking and Web services standards will be deeply ingrained in our development environments, Web server applications, and operating systems so that we can take these things for granted, in the same way a Web developer can take TCP/IP, HTTP, and HTML for granted today. For now, however, we breathlessly await the blessing (or the curse!) of each iteration of specifications as it arrives.

Even as I write this book, Web services specifications are proliferating and Web Services Enhancements (WSE) is undergoing significant functionality changes between versions 1.0 and 2.0. While it s always difficult to predict exactly what will happen with these technologies (especially with Microsoft Web services technologies!) we can make educated guesses and get opinions from experts in the Web services industry.

Before I get to the discussions of where the industry and Microsoft are heading, I ll briefly summarize the current status of Web services in the industry, Web services specifications, and Microsoft s support for Web services. The following sections address the current state of the union of Web services.

Targeting Interoperability

As of this writing, the hype generated by Microsoft and others regarding the potential brave new world of Web services is slowing down. The buzz in the industry has shifted away from delivering end user services and software as a Web service and toward enabling the development of enterprise-quality applications that interoperate using Web services. Major platform developers as well as third-party solution providers are pushing hard to demonstrate the cross-platform interoperability benefits of Web services, particularly for the .NET/Java 2 Platform Enterprise Edition (J2EE) chasm . As an example, adoption of the WS-Security and related specifications has enabled the creation of interoperable Web services between an IBM WebSphere application hosted on the J2EE platform and a Microsoft .NET application enabled with Microsoft Web Services Enhancements.

At the 2002 Web Services One Conference in Boston, Microsoft and IBM showed off a Web services application implemented against the WS-Security, Direct Internet Message Encapsulation (DIME), and WS-Attachment specifications that demonstrated Web services interoperability between .NET and Java. The demonstration consisted of a three- tier distributed application, in which all communication between the tiers was via SOAP messages. In the demonstration, any of the three tiers could be either a Microsoft .NET application hosted by ASP.NET enabled with WSE (at that time called the WSDK) or a Java application hosted by IBM WebSphere on an Apache Web server and enabled with the IBM Web Services Toolkit (WSTK).

More recently, at the 2003 Burton Group Catalyst Conference, Microsoft and IBM demonstrated interoperable Web services that enabled business- related interactions between Microsoft .NET and IBM WebSphere 5 applications. By implementing WS-Federation, WS-Trust, and WS-ReliableMessaging specifications, these applications leveraged federated identity for secure and reliable Web services communication. The demonstration was a major milestone in using federated identity to enable companies to establish business partnerships that allow their partners to access internal resources without incurring the cost of provisioning the rights of users from the partner company. I will discuss WS-Federation more shortly. (Based on information published at http://www.infoworld.com/article/03/07/08/HNnewwebspec_1.html .)

The work of the WS-I group is becoming a beacon in the push toward interoperability, which was the reason for its creation. In addition to carving out a subset of the existing specifications to enable better interoperability, called the Basic Profile 1.0, which I discussed in Chapter 1, the WS-I is also developing a suite of test tools that support version 1.0 of the Basic Profile, which includes the following:

• Web Service Communication Monitor This tool intercepts SOAP messages to and from a Web service using a man-in-the-middle approach and stores them in an XML log file for later analysis.

• Web Service Profile Analyzer This tool actually does the work of message validation and conformance checking by analyzing the message log produced by the monitor tool and checking the logged messages for compliance with Basic Profile 1.0.

The other major area where Web services are making an impact (and maybe even a profit) is that of third-party vendors that develop specialized code to retrofit new platforms and applications to old legacy applications and incompatible systems. In the past, these adapters needed to be specially developed for each pair of platforms or applications being integrated. However, today companies such as Iona and webMethods are selling products that enable simplified integration with existing Java and CORBA-based services to expose them as Web services. Another Web services solution vendor, Vignette, offers adapters for its Business Integration Studio product, which enables various back-end applications to communicate with its application server product using Web services.

Specifications Abound

It seems that a side effect of this push toward interoperability has been a shift from planning to deliver the next killer Web service to developing the next killer Web service specification. With groups of affiliated companies gathering behind what they think of as the crucial Web services specifications, there is currently a great deal of flux in the area of Web services specifications, and new specifications are continuously emerging. Whereas without widely adopted specifications, the interoperability promises of Web services will never materialize, having too many competing specifications puts us back in nearly the same situation. As the drive to standardize Web services has commenced, you can once again see the familiar competitive lines being drawn, with Oracle and Sun proposing a specification that overlaps one backed by IBM and Microsoft. Overlap has been a great concern among Web services developers, and no one wants to get caught on the wrong side of the adoption curve.

Well-thought-out and widely adopted standards will be crucial to developing interoperable Internet technologies. However, if companies wait for all of the necessary standards to be put in place before developing new Web services, the impact of Web services could be delayed for years . Even Microsoft Web services guru Don Box, an author of the first SOAP specification, mused in his keynote speech at the 2003 Web Services One Conference in Santa Clara, California, that perhaps the industry has become so fixated with writing specifications that the focus has been taken off of the deployment of XML-based solutions, which he called a terrible, terrible thing (as reported by http://www.infoworld.com/article/03/03/05/HNmanyspecs_1.html
). Whether it s because of the obscuring of the path to implementation or the diverting of energies away from developing XML solutions, there clearly is a drawback to having too many standards as opposed to simply having enough.

Much of this specification churn is a natural result of a competitive environment in the enterprise computing market, but things will settle down as Web services mature and customer demands for interoperability force all players to agree on a workable set of standards. Fortunately, if it s able to live up to expectations, the WS-I could (and should) play a key role in paving the way to a coherent set of standards, if only because it provides a forum for all of the major players to have a dialogue and reach an interoperability consensus outside the competitive corporate realm.

Note

As a rule of thumb, when handicapping the Web services specification horserace, avoid betting on proposed specifications backed by only one of the major players (Microsoft, IBM, Sun Microsystems, Oracle, and BEA) unless an implementation has experienced wide adoption. Even this may not be substantial enough to place a bet, but it could prove to be an exception to this rule.

On the other hand, the proliferation of Web services specifications of a limited scope seems to indicate that most of the major players in Web services have accepted the IBM and Microsoft vision of a modular approach to Web services. As I described in Chapters 1 and 2, this modular approach provides benefits in that a service has to implement only the specifications that it needs; specifications have a smaller scope and are easier to develop quickly and standardize, and individual specifications can be more easily replaced with better versions if necessary. As evidence of the adoption of this modular approach and to use my earlier example of overlapping specifications, at publication time, a group consisting of Fujitsu, Oracle, Sun Microsystems and others had proposed a specification called WS-Reliability at around the same time that Microsoft, IBM, and others unveiled the WS-ReliableMessaging specification. Since both specifications occupy the same space in the overall Web services specification space, it will be up to the industry leaders and vendors supporting each specification to make the best case for adoption to the appropriate standards bodies and to the development community at large, since wide adoption weighs heavy in standards adoption decisions. At the same time, working against one of these two specifications is less risky since the functionality of one can be relatively easily swapped out for the final specification that defines reliable messaging.

Licensing Concerns

Another interesting angle with respect to the proliferation of specifications is the resurgent concern over the licensing model for the forthcoming Web services specifications as they vie to obtain the blessing of becoming standardized by an Internet standards body. Fear of licensing practices among Internet developers is not unwarranted, considering the licensing fiasco that arose around some of the most popular image formats, the Graphics Interchange Format (GIF) in particular. In the early days of the Internet, GIF was widely heralded as a wonderful compression scheme for online images, and it was an Internet standard to boot. While GIF was originally released as a free and open specification, many developers who built tools and software that displayed and manipulated GIF images weren t aware that a patent on the Lempel-Ziv-Welch (LZW) compression scheme, which is at the core of reading and writing GIF files, was held by Unisys. Only after its wide adoption and standardization did the patent s owner begin to assert its rights to license its invention and attempt to collect royalties. As a result of this fiasco, members of the development community committed to the ideas of open-source and royalty-free software banded together to develop the Portable Network Graphics (PNG) image format, which, like GIF, is a lossless compression scheme but which is made available royalty-free .

While an interesting sidebar, the past problems with widespread adoption of the GIF standard combined with the strength and fervor of the open-source community are producing feelings ranging from wariness to open hostility at the notion of any Internet standards that don t come with a royalty-free licensing model.

In 2002, an attempt by the World Wide Web Consortium (W3C) to allow the publishing of standards based on a generally accepted, reasonable, and nondiscriminatory (RAND) licensing model was essentially shouted down by open-source advocates. This in effect would prevent the W3C from adopting any standards based on held patents if the patent holder retains rights to seek royalties from the standard, no matter how reasonable. The pursuit of a RAND licensing model would ideologically alienate a large portion of the developer community, which in turn would hamper the critical adoption race for these specifications.

Fortunately, both Microsoft and IBM seem committed to delivering a set of advanced Web services standards that are royalty-free, and this commitment is key to wining the adoption battle. Of course, this commitment toward keeping the advanced Web services specifications discussed in this book royalty-free would not prevent Microsoft from proposing separate specifications to extend the functionalities of Web services for the Windows platform, and any such specifications, I would imagine, might require licenses.