An Overview of Web Service Interoperability

SAP

9/24/2004

Copyright
Copyright 2004 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

An Overview of Web Service Interoperability

SAP

9/24/2004

Abstract
The goal of integrating independent IT systems with Web services was almost cut short by a lack of interoperable implementations, even though they were based on the same specifications. This paper outlines how this situation arose, what has been done to date, and continuing efforts. Marc Goodner and Claus Von Riegen 24 September 2004

Contents
Introduction The Core Web Services Stack What Went Wrong Fostering Interoperability Continuing Interoperability Efforts Summary

Introduction
Web services are both an evolution and a revolution. An evolution, because they are based on a loosely-coupled, service-oriented architecture, a technology paradigm that has been applied numerous times already in order to describe and integrate IT systems. A revolution, because they are completely based on the Internet, which is ubiquitous, and a number of XML standards, which have broad industry support. The most widely used web service standards we discuss in this paper are: SOAP (originally Simple Object Access Protocol; now it doesnt stand for anything as it does not require the use of an object) WSDL (Web Services Description Language) UDDI (Universal Description, Discovery and Integration)

Since Web service technology is applicable to any programming language, any platform, and any hardware device, it is the ideal candidate for addressing the interoperability challenge, especially in heterogeneous IT system landscapes. The idea of a service-oriented architecture is not new with Web services. Actually, it has been discussed in the IT industry for decades. Multiple approaches for remote service invocation have been proposed to date, including, but not limited to, DCE RPC, CORBA IIOP, Java RMI, and Microsoft DCOM. The differences with Web services are:

An Overview of Web Service Interoperability

SAP

9/24/2004

Independence of programming language, platform, and hardware device (Java RMI is, for example, only applicable to the Java language) Broad industry support from almost any software vendor (Microsoft DCOM, for example, is "only" applicable to the Microsoft platform)

The last point especially illustrates the business value that Web services deliver. An application written in Java and offered as a Web service can be accessed by a Web service client that is implemented in C++. Also, there is no need to reengineer existing applications as long as their functionality can be "wrapped" as Web services. This approach can effectively be used to leverage existing IT investments. Web Services are key to SAP NetWeaver's interoperability with other application platforms such as IBM's WebSphere and Microsoft's .NET. The Web service infrastructure provided by SAP Web Application Server (Web AS) directly supports Web services in that every application function that is to be accessed remotely individually can be described, published, and accessed by means of Web service standards. In particular, SAP Web AS: Allows existing SAP interfaces, such as RFC, Idoc, and BAPI to be accessible as Web services in that they are described in WSDL and can be invoked via SOAP. Comprises a UDDI registry.

For all of their promise, however, until recently Web services were plagued by a lack of interoperable software even though most implementations were developed from the same specifications. As this problem came into focus, it gained much attention and work has been done, and continues to be done, to promote interoperable implementations of Web service standards. To understand what is being done today about these problems and where we are going, we have to first look at how we got here.

The Core Web Services Stack

The World Wide Web Consortium defines a Web service as: "A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards." SAP agrees with this definition, save for the lack of one other feature: discovery. These are the three key characteristics we identify for Web services: Message-based interface

An Overview of Web Service Interoperability

SAP

9/24/2004

Machine processable description of the interface A mechanism to discover the service

The integration of IT systems enabled by this service-oriented architecture (see diagram below) is enabled by a variety of Web service standards: XML Schema (XSD) and WSDL are formal languages for the description of Web services, SOAP is used to invoke Web services, and UDDI is used to publish or to find a Web service description by means of a registry.

These capabilities came into existence over several years at the beginning of the century. The first was a common message format in the form of SOAP. SOAP 1.1 was published as a W3C Note on November 8 2000. What SOAP provided was a format for an envelope that could encapsulate application messages, encoding rules for data types and conventions for representing remote procedure calls. The descriptive aspect of Web services came in the form of another W3C Note, WSDL 1.1 published on March 15 2001. WSDL established a convention for defining application messages and operations abstractly and provided concrete bindings of these to SOAP, HTTP, and MIME. Finally, the last core piece of the Web services stack, discovery, was filled in July of 2002 with the publication of UDDI Version 2.

What Went Wrong

Having agreed-upon Web service standards is certainly a prerequisite for interoperability, but does not guarantee that two independent IT systems can actually

An Overview of Web Service Interoperability

SAP

9/24/2004

interoperate, even if they use the same set of standards. This is especially true since standards themselves sometimes provide alternative approaches for the same requirement. SOAP in particular was plagued by interoperability problems. This had as much to do with timing as anything else. That is not to say problems arose from the rush of vendors to quickly implement and adopt SOAP (though undoubtedly many did) but through the timing of the publication of the specification itself. SOAP was written and published prior to the finalization of XML Schema; it therefore has its own type system called SOAP Encoding. Developing a type system is notoriously difficult, which is why it took so long to develop XML Schema in the first place. WSDL had a slightly different problem. Quite frankly it is simply a very difficult specification to understand and implement. This owes largely to the layers of abstraction defined there; while they allow for flexibility they also are a great cause of confusion. As an example, if you were to look at a SOAP message you could probably have an idea of what is being represented there; the same cannot be said of a WSDL document. The format of WSDL is more suitable to machines than humans. UDDI did not tend to have quite as many interoperability issues as the other specifications here. Many would joke that this is owing to the lack of use of UDDI, however UDDI uses SOAP and WSDL; thus any pains in their adoption are felt even more in the adoption of a higher order spec like this one. However, this can also be attributed to the fact that there was a small consortia dedicated to the development of UDDI. As part of their work they developed the Universal Business Registry (UBR) that used UDDI in live implementations that replicated data between nodes across the Internet. It was this implementation experience with UDDI while the spec was in development that is most likely responsible for it having fewer requirements than any of the other specs in the Basic Profile. The other specifications were member submissions to the W3C that were published only as notes, not as ratified specifications. The intention was for the W3C to get input from the broader community and initiate work to standardize these specifications and in the process discover and address any inconsistencies in them. What actually happened was a rush to market of implementations that were made of these notes before the standardization work was actually done.

Fostering Interoperability
Early on, an ad-hoc group called SOAPBuilders was formed to try to solve issues around SOAP through the direct testing of implementations to common test cases. The group was open and published their test cases; however, there was still room for improvement in better defining what it would take to create interoperable Web services. For one thing, there needed to be a more formal mechanism for documenting what the issues were with not just SOAP, but WSDL and UDDI as well. Obviously one way would be to wait for the final specifications for SOAP and WSDL to be released through the W3C. Unfortunately end users of Web services needed a solution today and could not wait for the amount of time this work would require (ultimately SOAP reached final Recommendation status as version 1.2 last June while WSDL only recently reached).
An Overview of Web Service Interoperability 6

SAP

9/24/2004

These were the factors that led SAP with IBM, Microsoft, and others to found the Web Service Interoperability Organization (WS-I) in 2002. The WS-I brought together not just vendors, but customers to jointly identify and resolve the issues we faced with interoperability issues. The Basic Profile WG was formed to specifically tackle interoperability challenges with the core Web services stack identified above in documenting a profile of SOAP, WSDL, and UDDI. This was accomplished through clarification of statements in the existing specification and by restricting the use of some features, for example SOAP encoding is disallowed in any Basic Profile (BP) compliant Web service. Another aspect to the work were the Sample Applications WG, which defined and implemented a real world Supply Chain Management application that would use BP conformant Web services as well as identified and documented common usage patterns of Web services. Finally a Test Tools WG was also established that developed a monitor and analyzer that could examine Web service artifacts for conformance to the BP. The Basic Profile 1.0 was delivered in August of 2003. Did it work? The proof is in the Sample Application in which 10 different vendors, including BEA, IBM, Microsoft, Oracle, SAP, and Sun demonstrated an application in which web services for common roles were published in UDDI and could be dynamically configured for use in running the same SCM application. The Test Tools validated these services for compliance to the Basic Profile. This could not have been done without the Basic Profile. When this initiative started the story among the implementers in the room was very different. Through the expertise of the experts working on the Basic Profile and the work done by implementers that informed and validated their decisions the WS-I was a great success in this effort. Today the interoperability story between competing Web service software vendors is not only improved, but is actually quite good owing to the work of the WS-I.

Continuing Interoperability Efforts

One much-requested feature that was unfortunately left out of the original Basic Profile is support for attachments in Web services, i.e. transmitting a binary package along with the SOAP message. This was especially unfortunate, as a specification had been published as a W3C Note since 2000 dealing with just this topic, SOAP Messages with Attachments. Ultimately it boiled down to the fact that addressing this topic would delay publication of the BP. It turned out to be the right decision. For technical reasons of composing the BP with future Profiles it was split into two parts; the core part is now the Basic Profile 1.1 supplemented by the Simple SOAP Binding Profile. This allows alternate bindings to be defined in the future and facilitated the relationship of the BP with the new Attachments Profile. This work on these Profiles was completed and published last month. Again, the Sample Application WG has been able to demonstrate interoperability in implementations.

An Overview of Web Service Interoperability

SAP

9/24/2004

The hot topic alluded to above in incompatible token type in WSS is of course security. Indeed the WS-I is currently addressing this space as well in the Basic Security Profile (BSP) which addresses Web Services Security (WSS) and SSL in its scope and was published as a Work Group draft in May of this year. Again, the Sample Applications WG and Test Tools WG are tracking this work, currently in various stages of specification and implementation. Looking further ahead, the WS-I is hoping to gather more input from Web service users to make the organization more inclusive of all of its members and be a tad less vendor-driven. To that end, the Requirements WG was formed last year. Already they have identified issues end users are facing with XML Schema, which has led to a Schema Planning WG. The word planning since it was felt that the scope of this work is not well understood enough to assume that we will need a Profile or what it should cover; this WG will produce those recommendations. A similar planning WG led to the formation of the BSP WG.

Summary
Today we have the core Web services stack in fairly good order. We even have to look forward to wider availability of implementations of the final SOAP 1.2 Recommendation as well as the finalization of WSDL 2.0. Work on UDDI 3.0 has been completed as well. WSS has been ratified at OASIS and the BSP will be available soon. So are we done? Not by a long stretch. There are still lots of issues out there with things like WS-Addressing (recently submitted to the W3C for standardization) that provides mechanisms for identifying Web service endpoints and specific messages. Other efforts around security like SAML (Secure Assertions Markup Language) and business process languages like BPEL (Business Process Execution Language) are continuing at OASIS. There is also WS-Policy which is needed for defining the policies of a given Web service, for example security requirements. This list gets longer and longer as SAP continues to work with partners like IBM and Microsoft to define the future of Web services. This is done in an open workshop process before these are submitted to a industry consortia like W3C or OASIS for standardization with the broader Internet community. If you are interested in this workshop process, read this recent article on it published by Microsoft. Whether the specifications are being developed in workshops or under the auspices of a consortium like W3C, there is always much more emphasis on early implementation than in the past, the intention being to have interoperable implementations soon after the specification work is complete. Interoperable Web services are key to integration in SAP application and a key component of the ESA vision. As mentioned above, all of our existing core interfaces, RFC, BAPIs, and IDocs, are available as Web services. In addition to peer-to-peer connectivity between SAP and non-SAP applications using Web services, SAP
An Overview of Web Service Interoperability 8

SAP

9/24/2004

Exchange Infrastructure (SAP XI) provides additional mechanisms on top of pure technical connectivity, for example, logical addressing, message mapping, business process modeling, and execution. SAP XI also supports other protocols by means of adapters, for example, Java Message Service (JMS), Java DataBase Connectivity (JDBC), and RosettaNet Implementation Framework (RNIF). As you can see, now standards play a key role in the future of our products. That role is providing interoperable solutions for use in the most demanding IT environments our customers have.

An Overview of Web Service Interoperability