Top 10 points of Web Service interoperability Development

10. Beware of empty Arrays

Sending an empty array through the Web service may cause problems. Some toolkit recognizes an empty array as a single null value, while others represent it as a group of empty array elements. My general principle is to always ensure that the array contains valid data when sending an object array through the web service.

9. Use the package and type name options when generating the client proxy

Many Java-based tools have the option to specify unique packages and type names when generating client proxies (for example, BEA WebLogic uses the clientgen parameter and IBM Rational application developer uses the wizard ).

When creating a proxy for a Web service that shares the same data type, it is very important to control the package and type name. For example, when calling two web services with the same order type.

8. test whether the generated Java Bean is empty.

When using a tool or IDE to generate a Java Bean from an XSD file, always make sure that you know how to perform the test operation to check whether the object is empty. You may think that the following code can complete such a test:

if (myObject == null)

However, in some cases, you test whether an object exists, rather than whether the object value exists. I recommend that you always check the isnil () method (or similar method) on the generated bean ). If it exists, the true value can be obtained.

7. Java can recognize empty date and time values, but. Net cannot

In Java, java. util. Date and Java. util. calendar are classified as reference types. In. NET Framework 1.1, system. datetime is treated as a value type.

What will happen? The reference type can be null, but the value type cannot. If you want to send a blank date value across Web Services, always send the value of complex types and set the value of complex types to null. This will help avoid misinterpreting null date values (thus causing exceptions ).

6. Always use compareto () for date/time comparison ()

If you use the Web service to send dates and times between. NET and Java, always use the appropriate compareto () method in Java to compare dates. For example:

if (myDate.compareTo(yourDate) == 0)

Instead of using:

if (myDate == yourDate)

This will help to ensure the accuracy of date comparison between platforms, especially when trying to compare millisecond values.

5. Use the tracking tool for research

The tracking tool is an ideal choice for researching responses between SOAP requests and Web services. It can help verify the data type and message structure, and report soap errors that you may miss in your browser.

There are many types of available tracing tools-some run on clients, some run on servers, and some even run between clients and servers (such as proxies ). These types of tracing tools are difficult to set up, but they are useful in general because you can see messages transmitted between systems. Some agent tracing tools even allow you to edit and reply to messages-this is very useful for debugging.

4. Add options for "change host and port"

When designing a web service client, consider adding a helper method to change the host and port values of the web service location. This will facilitate the change of the web service location or redirect the output to the tracking tool in the future. I found this is particularly useful for failover between Web Services.

3. Make sure to use document/literal when generating Web Services

Some toolkit provides an option for you to choose from the following content for Web Services:

•	RPC/Encoding
•	RPC/literal
•	Document/literal

These options are Web service contract control styles and encoding mechanisms. To help ensure consistency with the WS-I basic profile, always ensure that document/literal is the default encoding mechanism for all your web services. RPC/literal is only used in special cases. Never use rpc/encoding.

2. Use unit tests to test interoperability

Unit testing (using nunit of. Net or JUnit of Java) is the best way to check the interoperability of multiple data types through Web Services.

If the data type is changed (or if the version of the web service toolkit is changed !), Run the test again. This ensures that the web services you designed have complete interoperability.

1. Use XSD

Data is always defined at the beginning when interoperability is designed. After determining the data to be sent, first create a data type in XSD, and then use the tool to generate a class from the XSD file. Operations are performed in this order to ensure online interoperability of data types. To do this, you need to be familiar with XSD-learning how to model data and tools that can be used to model data in XSD. The XSD file can be directly created and edited in Visual Studio. NET. With XSD, use appropriate tools on each platform to generate data types. In .net, you can use xsd.exe (part of the Framework) or xsdobjectgen (available for free download from msdn ). For Java, this depends on the Toolkit you are using. For IBM, use Java Bean for XML Schema wizard; for Bea, drag the XSD file to the schemas folder in WebLogic Workshop. If it is another toolkit, search for the schema2java tool. After completion, publish the generated data types in the Web service-the premise of this step is that you need to ensure that these types can be correctly serialized into XSD and XML. When you can ensure that the data is displayed online, interoperability is close to you!