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:

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:

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:

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

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.

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.

The following links provide additional information about Web Service interoperability:

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.

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.

Table 18-1 Interoperability of Various Types of Data Types

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 Using 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, you must 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, you must 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 you must create the serialization class manually.

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 Using 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, you must 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, you must 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 you must create the serialization class manually.

For the results of WebLogic Web Services' participation in the SOAPBuilders Interoperability Lab Round 3 tests, see http://65.193.192.35:7001/index.html. The tests were run with version 7.0.0.1 of WebLogic Server.