What is the WS-I?
Since its inception on February 4th, 2002, the WS-I (Web Services Interoperability) organization has become the de facto profiling (more on what this is in a second) organization in the web services space. WS-I was created to address interoperability issues among platforms that implemented the early web services specifications.
What kind of interop problems existed?
Before the formation of WS-I, web services specifications were in their infancy, and were being produced by a wide range of bodies, from companies publishing them in a royalty free manner to standards bodies such as OASIS and the W3C. The goal of these specifications were to promote a manner of invoking remote functions on a variety of platforms in a uniform way without needing to know, and customize for, the implementation specifics of a particular platform. An admirable goal, and one that proved difficult to achieve at first.
The designers of these web services specifications seem to have been grounded in the age old software design pattern of abstraction. Abstraction is intended to separate the layers of concern, and create loosely coupled components that would remain unaffected in the event that another component were to be changed. This seems good in theory, and often is in practice, but can sometimes cause more problems than it solves. Adding to the situation was the fact that the specifications were designed by participants from various vendors that ultimately had the requirements of their individual customers in mind. The ven diagram of customer sets didn’t always overlap, and therefore niether did their requirements. The push-me pull-me model of specification design combined with the desire to achieve consensus resulted in many optional features that could be implemented but weren’t required by the specification.
The loosely coupled nature of the specifications, and the many optional features therein, resulted in a nightmare for the vendors as they actually tried to implement them. Perhaps more importantly, when vendors tried to get their software to work with the software of other vendors, they quickly realized that there were many issues arising from the various ways they had interpreted the specifications or the disjoint set of optional features implemented. Grumblings could be heard throughout the industry. Companies who had invested a significant amount of money in this space to achieve interoperability were not realizing their return on investment. WS-I was founded by a group of companies, including SAP, to give a forum where these issues could be addressed and ultimately resolved. Along with the advent of WS-I, the concept of a profile was born.
What exactly is a profile?
Profiles are specifications, primarily produced by WS-I, as a way of providing guidance to developers who are implementing the technology stacks comprised of other specifications. They illustrate how the various components defined by these specifications should compose to work together. Profiles also change some of the MAYs (the optional elements) into MUSTs to tighten up the specifications based on real world experiences. The results were a more pragmatic design, as opposed to the more theoretical design of the various underlying specifications. The first profile, the Basic Profile 1.0, defined how to use the most basic web services specfications (i.e. XML Schema, WSDL 1.1, SOAP 1.1, and UDDI 2.0) together, allowing developers to produce workable solutions that would be more interoperable out of the box.
Profiles aren’t enough, what next?
The WS-I Basic Profile by itself wasn’t enough to solve the problem. After all, the profile is yet another specification that was designed by a committee of individuals that all had their own interests to represent. In order to ensure that the resulting output of this group would actually result in more interoperability and not less, two groups were started within WS-I: the testing group, which provides a test suite designed to test the assertions in the profile, and the sample application team, to create a simple ‘real world’ application based on the profile. The Sample Application was designed and implemented during the profile development phase so that the member companies could determine if there were going to be any real world problems with the profile. It is a very simple design based on a simple SCM (Supply Chain Management) scenario; simple enough to implement quickly, but complicated enough to find potential real world problems.
SAP, as a leading applications provider, was very interested in ensuring that the web services plumbing would actually support real world applications. SAP has therefore committed to chairing the Sample Applications group and is also an active particpant. The first version of the sample application targeted the basic profile, and some of the design decisions were made specifically to illustrate certain pitfalls of that profile. Lately the organization has been focusing on the BSP (Basic Security Profile), and several architectural changes needed to be made to reflect this. The design of the Sample Application will be more thoroughly discussed in the next installment of this blog series.
What do end users get out of the WS-I Sample Application
The first and foremost answer is peace of mind. The WS-I Sample Application is intended to show that the composition of the various web services specifications that have been produced will actually work. If your vendor has participated in the Sample Applications working group and produced an implementation of the WS-I Sample Application for the platform that your applications need to run on, you can be sure that that platform will have less interoperability problems than one that doesn’t. This ultimately will save both time and money when trying to connect your applications with applications on other platforms.
The Sample Application is also one of the most tangible deliverables that WS-I has, which is really great for hands on developers. It was designed to ensure that the profile was developed correctly, but can be equally interesting for developers that are given a mandate by their managers to be WS-I conformant. The first thing most developers will do is go to the WS-I web site to find out exactly what that means. Ultimately they will see a list of vendors there that claim WS-I conformance, and they can breathe a sigh of relief if their vendor made the list. The next step will be to take a look at the code for the Sample Application to see exactly what they need to do in order to make their application WS-I compliant. Most developers like reading code, but some might also prefer a more guided approach to creating WS-I conformant applications for their platforms, which is the ultimate reason that we’ve created this series.
Now that you have a little bit of the background, and a better idea why SAP is interested in the WS-I Sample Application, I hope that you’ll stay tuned for the next installment of the series, where I will delve deeper into the design details of the WS-I Sample Application.