The goal of web services is to enable communication between different software and hardware systems. These systems typically differ in both their hardware and software configurations. These differences have been overcome through the definition of standard protocols, such as those employed in building web services. Occasionally,incompatibility issues arise even when using these standard protocols, which can lead to interoperability problems. This guideline introduces you to the WS-I Basic Profile, which is a set of guidelines web services should adhere to in order to achieve optimum interoperability.
Interoperability problems were once commonplace with web services becauseof the large scope of the original SOAP and WSDLspecifications, and because of the interpretation the specifications left to developers, which led to incompatible implementations. These issues have been solved through experience and by adopting a set of best practices as specified in the WS-I Basic Profile.
Prerequisites
To follow along with the examples, you need the following software installed:
Java 2 Standard Edition version 1.4.2 or higher – All of these tools are Java-based, as are the services and clients you build in this tutorial.
Apache Axis2 version 1.0 –
Apache Geronimo or another application server
Understanding the need for web services:
For a generation now, programmers have been building software programs that talk to each other. Today, every programming language comes with software libraries that make network programming possible, easy, and predictable.Not only are there low-level tools for sending bits from one computer to another, but there are also high-level protocols like HTTP that provide a common set of rules that make it possible for two programs to converse, even though they were built independently by different people and are deployed on different machines and
systems software. Imagine what happens, for example, when you click on a link in your Web browser and load a Web page you have never seen before. Through the adoption of a few standards (HTTP, HTML, TCP/IP), your Web browser is able to call another computer system, fetch a Web page, and render it for you. This type of unrehearsed and dynamic software networking is powerful. Web services are an attempt to extend this power to developers of complicated enterprise systems.
Seeing the complexity and the challenge
Just as there are differences in the way Microsoft® Internet Explorer and Mozilla Firefox interpret some Web pages, there are differences in how two web service programs interpret the SOAP messages they exchange with one another. As you might imagine, these differences can result in serious problems that are difficult to resolve. The same is true with the specifications that define the various web services technologies, such as SOAP, WSDL, UDDI, XML Schema, and HTTP.
Despite the simplicity that inspired web services, building web services today demands know-how and patience, as this tutorial series illustrates. To build web services today, you need to be a solid programmer familiar with at least one programming language and environment. You need to be familiar with computer networking and with a family of standard technologies used in web services today,such as XML, SOAP, WSDL, or XML Schema. You also need to understand a host of practical techniques needed to use these technologies — and there are many.
Imagine that you put yourself through this substantial training exercise (you can call it a career) and attempt to connect your software to another piece of software using web services only to find that it does not work. Not only is this scenario incredibly frustrating, it is also quite common (usually when you are on a tight development schedule).
Adhering to best practices and discipline
To help catalog and remedy these interoperability issues, a group of engineers known as the Web Services Interoperability Organization (WS-I) have produced a set of recommendations for web services developers that, if followed, can help produce web services and web service consumers that work well together. This set of recommendations is known as the WS-I Basic Profile. If you are a web servicesdeveloper, you should add this acronym to your resume. Understanding web service interoperability issues and proactively designing services to avoid them has become an important responsibility for web service developers, just as designing for cross-browser compatibility has become an important responsibility for Web designers.
There is no silver bullet approach to do away with all interoperability issues.Distributed computing in a heterogeneous environment is a complex activity, and there are bound to be interoperability problems. The majority of these can be avoided, however, with discipline and an adherence to the best practices described in the WS-I Basic Profile.
Understanding the problem
The first challenge is to understand the problem of interoperability and its importance in the world of web services. Web services today are built using a complex family of related technologies and standards, which make for many sources of interoperability issues.
Testing
The WS-I organization produces a set of testing tools that can be used to evaluate the interoperability of a service.
Avoiding ambiguous specifications
Technical specs are usually very clear and unambiguous. They need to be clear so that readers understand the specifics of what they are working on. However, in spite of best efforts, the SOAP and WSDL specifications contain subtly confusing examples and language that forced developers to use their best judgment and interpret for themselves where they found the texts to be unclear. This led to several interoperability issues as software implementations differed in the message formats they generated and expected.
Solving ambiguity
SOAP is an acronym for Simple Object Access Protocol, which has been controversial since the first version of the specification, because most people agreed it was not really simple to understand or use. Aside from the ambiguity and errors, the SOAP specification is complicated and too broadly scoped to give rise to the interoperability one would hope to find in the world of web services.
Using interoperable SOAP
SOAP web services have received some criticism in recent years. Developers who have used SOAP and the related family of technologies that go along with might find it hard to disagree that it is a complicated technology and that interoperability challenges are especially frustrating. SOAP is definitely powerful; but simple, it is not. In fact, since the 1.2 version of the SOAP specification (06/2003), it is no longer officially called SOAP in response to the many complaints that the acronym is inaccurate.
Today, there are other types of web services competing with SOAP. The most notable are web services inspired by the concept of Representational State Transfer (REST). REST is an architectural style rather than a particular technology or formal standard. RESTful web services (as they are called) do not share a common message format. The format is entirely up to the service designer. So, RESTful services by design suffer from the same interoperability problems as SOAP services.