Interoperability

Interoperability

The following sections provide an overview of what it means for Web Services to be interoperable and tips on creating Web Services that interoperate with each other as much as possible:
Overview of Interoperability
Avoid Using Vendor-Specific Extensions
Stay Current With the Latest Interoperability Tests
Understand the Data Models of Your Applications
Understand the Interoperability of Various Data Types
Results of SOAPBuilders Interoperability Lab Round 3 Tests
Interoperating With .NET

Overview of Interoperability

A fundamental characteristic of Web Services is that they are interoperable. This means that a client can invoke a Web Service regardless of the client's hardware or software. In particular, interoperability demands that the functionality of a Web Service application be the same across differing:
Application platforms, such as BEA WebLogic Server, IBM Websphere, or Microsoft .NET.
Programming languages, such as Java, C++, C#, or Visual Basic.
Hardware, such as mainframes, PCs, or peripheral devices.
Operating systems, such as different flavors of UNIX or Windows.
Application data models.

For example, an interoperable Web Service running on WebLogic Server on a Sun Microsystems computer running Solaris can be invoked from a Microsoft .NET Web Service client written in Visual Basic.
To ensure the maximum interoperability, WebLogic Server supports the following specifications and versions when generating your Web Service:
HTTP 1.1 for the transport protocol
XML Schema to describe your data
WSDL 1.1 to describe your Web Service
SOAP 1.1 for the message format

The following sections provide some useful interoperability tips and information when writing Web Service applications.

Avoid Using Vendor-Specific Extensions

Avoid using vendor-specific implementation extensions to specifications (such as SOAP, WSDL, and HTTP) that are used by Web Services. If your Web Service relies on this extension, a client application that invokes it might not use the extension and the invoke might fail.

Stay Current With the Latest Interoperability Tests

Public interoperability tests provide information about how different vendor implementations of Web Service specifications interoperate with each other. This information is very useful if you are creating a Web Service on WebLogic Server that has to, for example, interoperate with Web Services from other vendors, such as .NET.
Warning: BEA's participation in these interoperability tests does not imply that BEA officially certifies its Web Services implementation against the other platforms participating in the tests.
The following Web sites include public interoperability tests:
Web Service Interoperability Organization
SoapBuilder Interoperability Lab

You can also use the vendor implementations listed in these Web sites to exhaustively test your Web service for interoperability.

Understand the Data Models of Your Applications

A good use of Web Services is to provide a cross-platform technology for integrating existing applications. These applications typically have very different data models which your Web Service must reconcile.
For example, assume that you are creating a Web Service application to integrate the two accounting systems in a large company. Although the data models of each accounting system are probably similar, they most likely differ in at least some way, such as the name of a data field, the amount of information stored about each customer, and so on. It is up to the programmer of the Web Service to understand each data model, and then create an intermediate data model to reconcile the two. Typically this intermediate data model is expressed in XML using XML Schema. If you base your Web Service application on only one of the data models, the two applications probably will not interoperate very well.

Understand the Interoperability of Various Data Types

The data types of the parameters and return values of your Web Service operations have a great impact on the interoperability of your Web Service. The following table describes how interoperable the various types of data types are.

Data Type

Description
JAX-RPC built-in data types Interoperate with no additional programming.The JAX-RPC specification defines a subset of the XML Schema built-in data types that any implementation of JAX-RPC must support. Because all of these data types map directly to a SOAP-ENC data type, they are interoperable.
Built-in WebLogic Server data types Interoperate with no additional programming.WebLogic Server includes support for all the XML Schema built-in data types. Because all of these data types map directly to a SOAP-ENC data type, they are interoperable.For the full list of built-in WebLogic Server data types, see Supported Built-In Data Types.
Non-built-in data types Interoperate with additional programming or tools support.If your Web Service uses non-built-in data types, create the XML Schema that describes the XML representation of the data, the Java class that describes the Java representation, and the serialization class that converts the data between its XML and Java representation. WebLogic Server includes the servicegen and autotype Ant tasks that automatically generate these objects. Keep in mind, however, that these Ant tasks might generate an XML Schema that does not interoperate well with client applications or it might not be able to create an XML Schema at all if the Java data type is very complex. In these cases you might need to manually create the objects needed by non-built-in data types, as described in Using Non-Built-In Data Types.Additionally, ensure that client applications that invoke your Web Service include the serialization class needed to convert the data between its XML representation and the language-specific representation of the client application. WebLogic Server can generate the serialization class for Weblogic client applications with the clientgen Ant task. If, however, the client applications that invoke your Web Service are not written in Java, then create the serialization class manually.

Results of SOAPBuilders Interoperability Lab Round 3 Tests

For the results of WebLogic Web services' participation in the SOAPBuilders Interoperability Lab Round 3 tests, see http://webservice.bea.com:7001. The tests were run with version 7.0.0.1 of WebLogic Server.
For the test results, see http://webservice.bea.com/index.html#qz41; for the source code of the tests, see http://webservice.bea.com/index.html#qz40.
For more information on the SOAPBuilder Interoperability tests, see http://www.whitemesa.com.
Warning: BEA's participation in these interoperability tests does not imply that BEA officially certifies its Web Services implementation against the other platforms participating in the tests.

Interoperating With .NET

You invoke a .NET Web Service from a WebLogic Web Services client application exactly as described in Invoking Web Services from Client Applications and WebLogic Server. When you execute the clientgen Ant task to generate the Web Service-specific client JAR file, use the wsdl attribute to specify the URL of the WSDL of the deployed .NET Web Service.
To invoke a deployed WebLogic Web Service from a .NET client application, use Microsoft Visual Studio .NET to create an application, then add a Web Reference, specifying the WSDL of the deployed WebLogic Web Service, as described in the following example. In Microsoft Visual Studio, adding a Web Reference is equivalent to executing the WebLogic clientgen Ant task.
Warning: The following example describes one way to invoke a WebLogic Web Service from a .NET client application. For the most current and detailed information about using Microsoft Visual Studio .NET to invoke WebLogic (and other) Web Services, consult the Microsoft documentation.

Start and use Microsoft Visual Studio .NET to create your application as usual.
In the Solution Explorer in the right pane, right-click your application and chose Add Web Reference. The Solution Explorer Browser appears.
Enter the WSDL of the deployed WebLogic Web Service in the Solution Explorer Browser. As soon as the browser accepts the WSDL, the Add Reference button becomes active.
See WebLogic Web Services Home Page and WSDL URLs for information on getting the WSDL of a deployed WebLogic Web Service.
Click the Add Reference button. The WebLogic Web Service appears in the Solution Explorer.
In your application component that will be used to invoke the Web Service, such as a button, add Visual C# or Visual Basic code to invoke a particular operation of the Web Service. Visual Studio .NET uses statement completion to help you write this code. The following Visual C# code excerpt shows a simple example of invoking the echoString operation of the SoapInteropBaseService Web Service:
WebReference1.SoapInteropBaseService s = new SoapInteropBaseService();



string s = s.echoString("Hi there!");
In the example, WebReference1 is the name of the Web Reference you added in preceding steps.

Data Type	Description
JAX-RPC built-in data types	Interoperate with no additional programming.The JAX-RPC specification defines a subset of the XML Schema built-in data types that any implementation of JAX-RPC must support. Because all of these data types map directly to a SOAP-ENC data type, they are interoperable.
Built-in WebLogic Server data types	Interoperate with no additional programming.WebLogic Server includes support for all the XML Schema built-in data types. Because all of these data types map directly to a SOAP-ENC data type, they are interoperable.For the full list of built-in WebLogic Server data types, see Supported Built-In Data Types.
Non-built-in data types	Interoperate with additional programming or tools support.If your Web Service uses non-built-in data types, create the XML Schema that describes the XML representation of the data, the Java class that describes the Java representation, and the serialization class that converts the data between its XML and Java representation. WebLogic Server includes the servicegen and autotype Ant tasks that automatically generate these objects. Keep in mind, however, that these Ant tasks might generate an XML Schema that does not interoperate well with client applications or it might not be able to create an XML Schema at all if the Java data type is very complex. In these cases you might need to manually create the objects needed by non-built-in data types, as described in Using Non-Built-In Data Types.Additionally, ensure that client applications that invoke your Web Service include the serialization class needed to convert the data between its XML representation and the language-specific representation of the client application. WebLogic Server can generate the serialization class for Weblogic client applications with the clientgen Ant task. If, however, the client applications that invoke your Web Service are not written in Java, then create the serialization class manually.