hardware on multiple machines from multiple vendors .... Listing 1. HTTP request with the SOAP message where SOAP Action value is a quoted URI. Listing 2.
WS-I Basic Profile: A Practitioner’s View K M Senthil Kumar Akash Saurav Das Dr. Srinivas Padmanabhuni Software Engineering and Technology Labs, Infosys Technologies Ltd., Bangalore, India. {senthil_km,akash_das, srinivas_p}@infosys.com
Abstract Interoperability refers to the ability of software and hardware on multiple machines from multiple vendors to communicate with each other without significant changes on either side. Web services streamline enterprise application integration by making it easier to tie applications running on heterogeneous platforms together helping them communicate correctly, effectively and at reduced cost. The difficulty of integration is a function of the level of interoperability between the applications being integrated. Even though there are established standards for web services messaging (SOAP), description (WSDL) and discovery and registry (UDDI), custom implementations of these protocols by individual vendors has led to various interoperability issues. Web Services Interoperability Organization (WS-I) recently released Basic Profile 1.0, addressing the interoperability issues with core web services standards. In this paper, we look at some of the key web services interoperability issues pointed out by practitioners and critically examine how Basic Profile 1.0 addresses them. Further we also examine some limitations of the profile. We conclude by evaluating a popular web services implementation against the profile and present our observations.
1. Introduction Web services have been making waves in the IT and business community alike for the past couple of years. A range of applications have been developed and deployed as web services. The key factor which initially promoted the widespread application of web services is the interoperability it promised to deliver. Interoperability implies that any client should be able to access or invoke a service over standard network transport protocols like HTTP, SMTP, etc. in a
Proceedings of the IEEE International Conference on Web Services (ICWS’04) 0-7695-2167-3/04 $ 20.00 IEEE
platform and language independent manner. For example, a web service could have been implemented using JAVA on a UNIX machine while the client consuming that service could be on .NET technology. But this turns out to be more difficult than stated. Interoperability is not guaranteed by merely adopting the same set of standards universally. A lot of interoperability issues have risen when it comes to invoking web services across heterogeneous applications running on different platforms due to the customized implementations of the standards by the vendors [1], [7], [8]. Thus interoperability has remained an unfulfilled promise leading to slower adoption of web services by the enterprises. In theory one of the key facilitators to interoperability is open standards. Compliance with these standards should guarantee that any vendor’s product will work with any other vendor’s. During the course of the last two years, universally accepted set of standards have been developed for messaging (SOAP), description (WSDL), and discovery and publishing (UDDI) of web services. But these standards specifications are not precise about how the standards should be implemented. Hence each vendor exercises freedom in implementation of the standards. Some of the vendors implement only part of the standard specification of the protocols in their products. Applications thus developed using these incomplete products clearly pose interoperability problems. The Web Services Interoperability Organization (WS-I) was thus formed as an open industry effort to promote web services interoperability across platforms, applications and programming languages. It brings together a diverse community of web services vendors to provide best practices, tools, and sample applications that enable the development of interoperable web services. After considerable amount of research work in identifying the various interoperability issues present in the standard protocols used for describing, publishing and consuming web services, WS-I has come up with the Basic Profile 1.0
(BP) [2]. The profile contains a list of web services standards (including version) together with the implementation and interoperability guidelines for each, recommending how the specifications should be used to develop interoperable web services. The profile per se does not prescribe any web service standard. In this paper, we examine some of the key interoperability issues that are encountered in SOAP 1.1 and WSDL 1.1 implementations by practitioners. We also explore the conventional means, if any, by which these issues were tackled. Further we also analyze how BP addresses these issues. We then critically examine the limitations of BP and see how the recommendations of BP maximize interoperability across applications. The paper is structured as follows: Section 2 talks about BP in a nutshell. Section 3 deals with typical interoperability issues related to SOAP 1.1. Section 4 talks about the WSDL 1.1 interoperability issues. Section 5 lists the limitations of BP. Section 6 describes our experience in evaluating a popular web services platform against BP. Section 7 provides a summary of the conclusions.
2. WS-I Basic Profile 1.0 BP is a set of recommendations and guidelines covering the core web service standards including SOAP 1.1[3], WSDL 1.1[4], UDDI 2.0, XML 1.0, XML Schema: Part 1 and 2 [5], [6], along with related internet and network protocols. Some of the key recommendations and restrictions imposed by the profile for the transport protocol are: allowing HTTP 1.1 as the only transport protocol, mandating the use of HTTP POST method, and mandating the use of HTTP binding for SOAP. BP also provides recommendations about how to use the standards together, with the goal of promoting interoperability. BP will significantly simplify the task of implementing interoperable web services solutions within and across enterprise boundaries, by allowing companies to focus resources on delivering new products and services to the customers, instead of dealing with the basic plumbing. BP is part of the first set of deliverables from WS-I. The deliverables from WS-I also include use cases and usage scenarios to capture the business and technical requirements for the use of web services, sample applications confirming to the given set of profiles and testing tools to determine whether or not a web service instance or its artifacts (messages, WSDL and UDDI components) conform to BP guidelines.
Proceedings of the IEEE International Conference on Web Services (ICWS’04) 0-7695-2167-3/04 $ 20.00 IEEE
We shall explore the detailed prescriptions from BP for SOAP 1.1 and WSDL 1.1 implementations in the following sections. Let’s now go through some of the key interoperability issues related to SOAP 1.1 and see how BP addresses the same.
3. Interoperability issues related to SOAP 1.1 SOAP Version 1.1 is a protocol intended for exchanging XML based structured information in a decentralized, distributed environment. SOAP provides a vendor independent mechanism for exchanging messages. It is fundamentally a stateless, one-way message exchange paradigm, but applications can create more complex interaction patterns (e.g., request/response, request/multiple responses etc.) by combining such one-way exchanges with features provided by the underlying protocol and/or application specific information. SOAP is transport agnostic. SOAP is silent on the semantics of any application– specific data it conveys and on issues such as the routing of SOAP messages, reliable data transfer, firewall traversal, etc. However, SOAP provides the framework by which application-specific information can be conveyed in an extensible manner. For data interoperability SOAP 1.1 leverages XML Schema datatype definitions with the 1999 namespace URI (http://www.w3.org/1999/XMLSchema). SOAP 1.1 specification allows SOAP messages to be sent over HTTP, SMTP or any other transport protocol. But, the most widely used transport protocol till now has been HTTP. Let’s start with the typical interoperability issue related to SOAP over HTTP.
3.1. SOAPAction HTTP Header When a SOAP message is sent over HTTP, the HTTP request header is added along with the SOAP message. This header contains the details about the HTTP request used to transport the SOAP message. The SOAP specification adds the mandatory SOAPAction header to this HTTP request header. SOAP specification allows three legal kinds of value to this header: x Null x An empty quoted string x An arbitrary URI. Such loose definition in the specification allows flexibility in the functionality and implementation. Hence, different vendor’s products can choose to implement this particular specification by customizing the SOAPAction header to contain any one of the
above mentioned values and still adhere to the SOAP 1.1 standard. Listings 1 and 2 show snippets of sample HTTP requests with SOAP messages with different values for the SOAPAction header. An application server hosting the web service, which runs a vendor’s implementation of the SOAP engine, may or may not respond back in the expected manner to a valid SOAP request if the value of the SOAPAction header is not the one it is expecting, even though the value is a legal one as per the SOAP spec. Practitioners have found out that a valid SOAP request message to a sample web service may result in different responses, ranging from a fully valid correct response to a SOAP fault response, depending on the value of the SOAPAction header [7]. The heterogeneous applications implementing different values for the SOAPAction header in a SOAP HTTP request clearly pose an interoperability issue on both provider and requester side when they start communicating with each other. These applications need to come to a common understanding about how they represent the value of the header. POST /axis/services/HelloWorld HTTP/1.0 Content-Type : text/xml; Charset=utf-8 …… SOAPAction:”http://soaphelloworld.org/” …. …..
Listing 1. HTTP request with the SOAP message where SOAP Action value is a quoted URI POST /axis/services/HelloWorld HTTP/1.0 Content-Type : text/xml; Charset=utf-8 …… SOAPAction:““ …. …..
Listing 2. HTTP request with SOAP message where SOAP Action value is null How BP addresses it: In BP it is recommended that the SOAPAction HTTP header value has to be always quoted. This implies that the value is either an arbitrary URI in quotes or an empty quoted string, which thereby eliminates the possibility of a null value.
Proceedings of the IEEE International Conference on Web Services (ICWS’04) 0-7695-2167-3/04 $ 20.00 IEEE
However, possibility of having an empty quoted string retains the interoperability issue. Thus BP provides only a limited way of addressing this by reducing the options of SOAPAction header from three to two.
3.2. XML Schema In case of RPC style invocation, SOAP requests are XML documents containing the description of the namespace, the method that the request is targeting and the data or parameters needed for the method. In the document style invocation, SOAP messages have the namespace definitions, but instead of the name of the method and parameters they contain the entire request XML document as the payload in the body. Irrespective of the style, XML Schema definition is an integral part of the SOAP message. The entire SOAP message gets validated against the XML Schema used. XML Schema gives the definitions of all the elements and datatypes used in a SOAP message. The major interoperability issue related to XML Schema is with reference to the usage of different versions of XML Schema in the SOAP messages. The two versions available are the 1999 and the 2001 XML Schema URIs. Listings 3 and 4 show code samples of SOAP messages using the 2001 and 1999 versions of XML Schema URI respectively. SOAP engines initially used the 1999 XML Schema URI during the construction of the SOAP messages. When these SOAP messages are processed by SOAP engines which use the latest XML Schema version (2001), the results are unpredictable [7]. When different versions of XML Schema are used in the applications that integrate with each other, there is a very high possibility of the SOAP messages not being understood in the right context resulting in an interoperability issue. The need was to determine the universal XML Schema used by all vendors implementing SOAP 1.1 standard specifications.
