The primary reason that Web services have gathered so much attention from the vendors of software products and professional software developers is the promise of interoperability across platforms and programming languages. But, before you jump into the fray, you might be wise to stop and consider how true this promise of interoperability is.
In this hour, we will cover the issues surrounding interoperability. We will begin by stating the goals of Web services, and then move on to the limitations that have been discovered in the real world. Following that, we will discuss the industry’s efforts to work through these issues.
In this hour you will learn about
Interoperability goals
Interoperability limitations
How interoperability is attained
The Web Services Interoperability (WS-I) Proposal
If you take interoperability out of Web services, you have yet another single-vendor solution for making remote procedure calls. At the core of Web services is the dream of universal interoperability.
At present, Web services transactions will be successfully exchanged only if the following are true:
They use the same version of the same transport. The most common communication now in use is TCP/IP running Hypertext Transfer Protocol (HTTP 1.1).
They are created with the same version of XML schema.
They both use the same version of the WSDL specification.
They interpreted the ambiguous areas of the WSDL specification in the same way.
They are using the same version of SOAP.
They interpreted the ambiguous areas of the SOAP specification in the same way.
No additional headers were used in the SOAP message without prior agreement.
No additional features like WS-Signature, WS-Transaction, and so on were used.
The preceding list seems intimidating, and it should. In reality, there are many opportunities for failure mentioned on this list.
To suggest that there are limitations to the interoperability of Web services sometimes causes gasps in the first row of pews. Many exclaim that because the entire premise of Web services is interoperability, there shouldn’t be any interoperability problems. Here in the real world, however, there are limitations that you must be aware of before you ruin your technical reputation by recommending that your organization head down an immature path.
Some readers will scoff at the idea that the basic Web services specifications can have interpretation problems. In the ideal world, all specification would be written by people with great foresight and unlimited time to get everything exactly right. The user community is far too impatient to wait too long for the standards bodies to act. If a standard is slow in coming, software vendors will implement their own solutions, thereby making it harder later to get them to adopt the new standard.
All standards bodies operate on a feedback loop in which interested parties make comments on what has been proposed. The feedback loop provides the perfecting mechanism whereby the oversights and omissions that appear in an initial version of a specification are worked out. In the mean time, misunderstandings are a problem whenever a clause is vague enough for two different interpretations to exist.
In SOAP 1.1, consider the case in which a message is received where the namespace name of the Envelope is not http://schemas.xmlsoap.org/soap/envelope/. The SOAP 1.1 specification states that this message might be discarded. If one vendor discards, but another chooses to generate a fault instead, a difference in behavior occurs. Later in this hour, you will see how the WS-I proposal handles this type of situation.
The perfecting process requires that standards bodies respond to the feedback that they get from the user community. The customary way to respond to feedback is to issue a modified version of the standard complete with a new version number; HTTP 1.0 was superceded by HTTP 1.1.
At present, five core standards form the foundation of Web services:
XML
XML schema
SOAP
WSDL
UDDI
If there were two versions of each of these in common use, there would be 32 (two raised to the fifth power) different combinations of these standards that a product could be programmed to. If you add in all the proposed standards, and the underlying standards like HTTP and UTF-16, the number of combinations becomes very large.
In the good old days, you purchased a computer, operating system, and much of the layered software from one vendor. If you had a problem, you called 1-800-MyFavoriteVendor and they handled it (sometimes). This model began to break down when the personal computer came on the scene because the computer, operating system, and each application were purchased from different vendors.
With the advent of Web services, this model is completely destroyed. In the PC world, a transaction was normally handled by one application. In the new Web services world, a single transaction might invoke 5, 10, or who knows how many different Web services. In addition, each of them might have been built with a different tool, and they might be running a different SOAP processor. This is the hurdle for a lot of companies that want to use open-source software, but are afraid of the lack of support. If you are using a vendor’s implementation, you can call them.
Who are you going to call when something goes wrong? Your customers know who to call: YOU! What vendor is going to accept responsibility for a problem if it is only one of a dozen different programming staffs that have contributed code to this transaction’s processors?
Look for the third-party support model now in its infancy to become the standard way of tackling these kinds of problems. They will accept the problem and work it because you pay them to, either on a retainer or on a per-case basis.
In addition, look for a new generation of tools to emerge that are able to analyze long transactions throughout their life cycles in order to isolate the Web service that is misbehaving.
In the ideal world, customers would wait to ask for new features until clear, well-tested standards existed for all the technology needed to support it. In the real world, customers ask for the moon and want delivery tomorrow. They pressure us to make modifications to our systems that push them beyond the approved standards and into areas where either no standard exists yet or where only immature standards exist.
The following is a only a partial list of the proposed standards that were in some workgroup at the time of this writing:
BPELWS—. Business Process Execution Language for Web Services provides an XML-based programming language for defining business processes.
SAML—. The Security Assertion Markup Language allows clients to identify themselves to Web services.
WS-Coordination—. Defines an XML grammar to coordinate complicated Web services requests.
WS-Security—. Provides a framework for Web services security solutions.
WS-Transaction—. Defines an XML way of creating both atomic transactions that can be rolled back as well as long transactions that cannot.
XML-Encryption—. Allows a confidential message or part of a message to be sent.
XML-Signature—. Provides a way for clients and Web services to verify their identity.
It is safe to say that the suite of standards that define Web services will grow without an end in the foreseeable future. This creates several opportunities and problems:
You will be able to use a standard instead of a homegrown approach to provide the functionality mentioned previously. On the flip side, you can get out of synch with the providers and consumers that you interact with if they don’t upgrade to the same standard at the same time you do.
The number of possible combinations of standards that will be in use at the same time will grow exponentially. Because nothing happens in an instant, there will be a transition period with each standard in which the old standard version of proprietary approach is replaced by the new one.
Some overlap exists between these standards. You might implement one standard to handle an issue, but the consumers of your service might choose another.
Those developers who have created public sites that don’t know in advance who the consumers of their services will be are going to have a never-ending task of deciding which of the standards to support, and when to support them.
It would be great if this section could describe the silver-bullet solution to the challenges previously described. As you have probably suspected, there is no silver bullet, nor is there likely to be one in the future.
Note
Human nature tells us that as soon as we solve one interoperability problem, the user community will demand even more ambitious systems from us, which will lead us into another set of interoperability challenges. This could discourage us, or we could see it as an almost endless demand for analysts, programmers, and managers who are up to the challenge.
Keep in mind, however, that although the challenges never cease, the Web services that we design, program, implement, and deploy will be improving steadily and moving closer to the strategic center of your organization.
The solution, or rather solutions, to the problem of interoperability all require a strategy instead of a technique.
We all try to stay off the “bleeding” edge of technology but we are all enticed to enter it from time to time. Sometimes our customers pressure us to become involved before the time is really right, but many times we treat new technology similar to birthday presents—we get so excited that we open the present before the guests arrive.
Your first job is to understand both the technology and what stage it is at in the collective mind of the computing business. Reading about the progress of a standard or technology will give you a sense of when “critical mass” has been reached.
Testing for interoperability is not something that you want to tackle on your own. The amount of resources required to perform a thorough test of one vendor’s product that implements one suite of standards would be forbidding. A thorough test would have to create a Web service. Then it would have to create clients using every other popular product. Finally, it would have to test every client against the server.
A faster and less-expensive approach is to become acquainted with the testing already going on in the industry. One of the most promising of these efforts is called SOAPBuilders.org (www.SOAPBuilders.org). This organization states that
The purpose of SOAPBuilders is so the techie types from the various SOAP implementations can ensure interop isn’t just a buzzword. Part of that involves having a low barrier to entry.
From this informal mission statement flows a series of tests. These tests are organized into rounds—with later rounds providing a more rigorous set of tests than the earlier ones. In addition to the tests, each round provides some general guidelines to vendors who are planning on testing their applications. These guidelines are refinements to the specifications that instruct the participants such as “SOAPAction should be present, and quoted.” or “Method namespace should be a well-formed, legal URI.” As you can see, they don’t raise the bar too high.
The first three rounds tested to see if the various vendor products could perform the following:
Round One—. Echoed the most common different data types back when sent to them.
Round Two—. Echoed some more data types (Hex binary, Base64, and so on) back when sent to them.
Round Three—. A more thorough test that involved generating a WSDL and using the generated WSDL to communicate with Web sites, and so on.
Periodically, SOAPBuilders hosts what they call face-to-face events, normally in conjunction with a Web services conference. During these events, different vendors demonstrate their compliance with the test suite that has been developed for them. By keeping up with the proceedings from these conferences, you can learn about the different vendors and what sort of effort they are willing to expend to make their products interoperable. If your requirements are less ambitious than the tests that have been run, you will be able to have confidence that your efforts will not be wasted.
On October 24, 2002, Sun Microsystems announced that it was planning to join the Web services Interoperability Organization (WS-I, www.ws-i.org), the consortium of companies that is working to make Web services interoperate. IBM and Microsoft, Oracle, BEA, HP, and Intel had already joined along with a huge number of other companies such as Ariba, Iona, and VeriSign.
The addition of Sun to this group is critical because of the following that Sun has among the Java development community. Because of Web services’ position on the leading edge of technology, many of the early technical converts are Java heavyweights in companies around the world. Now that Sun has joined, these technical leaders will feel comfortable bringing their development efforts in line with decisions made by the consortium and its budding proposed standard WS-I.
As specifications go, WS-I is a newborn. Because of the central role that interoperability will play in the future of Web services, however, it is hard to imagine a standard that is more critical to its long-term success.
The stated goal of WS-I is
To accelerate the adoption of Web services by assisting in the selection and interpretation of Web services specifications, and in the development of common best practices for their usage in the development, deployment, and integration of business applications.
The WS-I organization is producing three primary sets of deliverables: profiles, testing tools, and sample applications.
A profile is a named set of versioned specifications. Included in the profile is a set of guidelines that provide interpretations of these specifications. In addition, the profile includes a set of recommendations on how to use these specifications.
As you recall, earlier in this hour, we discussed the difficulty caused by the multiplicity of specification versions that are available at any one time. The profile narrows this list to exactly one version of each specification. If either the versions or the number of specifications changes, the profile would be given a new name and would therefore be a different profile.
The effect of constraining a profile in this way is far reaching. If a Web service provider claims that it is compliant with profile X, a potential consumer of that service can have a high degree of confidence that it will succeed in communicating with the other service.
The addition of the guidelines will tighten up the specifications so that the number of potential conflicts because of incompatibilities can approach zero over time. The vision is to provide a logo that states what profile a particular service is compliant with. This would provide one name for a potential customer to look for, instead of n different specification names and version numbers.
At this writing, the only profile that has been published is the Basic Profile Version 1.0. This profile names the following standards:
HTTP/1.1
RFC2965:HTTP State Management Mechanism (cookies)
SOAP 1.1
UDDI Version 2.0 XML Schema
UDDI Version 2.03 Data Structure Reference
UDDI Version 2.03 Replication Specification
UDDI Version 2.03 Replication XML Schema 2001
UDDI Version 2.03 XML Custody Schema
UDDI Version 2.01 Operator Specification
UDDI Version 2.04 API
WSDL 1.1
XML 1.0 (Second Edition)
XML Schema Part 1: Structures
XML Schema Part 2: Datatypes
In addition, dozens of pages of guidelines serve to tighten up these specifications to the point at which misunderstandings are unlikely to occur if both parties in a transaction comply with them.
In order to determine conformance to a certain profile, WS-I will also provide a set of testing tools that can be used to observe the messages being exchanged by different services and their consumers. Monitors would capture messages and hand them to analyzers that determine the conformance, or lack thereof, to a particular profile.
Sample applications allow vendors to gain a better understanding of the specifications and guidelines as they pertain to the system that they are trying to create. If a picture is worth a thousand words, a piece of code that is known to be correct is worth ten thousand. If there is a question on how to use a certain message feature, the programmer can look at the sample application to find an example to mimic.
In addition, the sample applications will provide a test bed to prove that the profile is correctly written. If the sample application isn’t capable of conforming, the profile will need to be modified.
Another area in which the profiles are wonderful is in the area of new standards. We stated earlier that when new standards are proposed, the timing of when to incorporate them into your Web services can be tricky. As a result, everyone tends to wait on everyone else just like cars at a four-way stop. The publication of a profile that includes a new specification might serve as the “coming-out party” for a new standard. Once the WS-I agrees that a profile is needed that includes the new specification, it will signal that everyone agrees that it has value and that it is ready for prime time.
In this hour, we covered the problems associated with writing Web services that interoperate well. We first looked at some of the issues that keep our services from communicating. Next, we looked at some basic strategies for handling this problem. Finally, we looked at the WS-I and its attempts to remove the risk from committing to an implementation.
The Workshop is designed to help you review what you’ve learned, and begin learning how to put your knowledge into practice.
1. | List the reasons that interoperability problems can occur. |
2. | Go to SOAPBuilders.org and examine the details of the upcoming round of testing. If a face-to-face event is held in your area, attend it. |
3. | Go to the WS-I Web site (www.ws-i.org) and read the Basic Profile 1.0. Pay particular attention to the guidelines. |