Ten key points of Web service interoperability development

Web|web Service |web Service

Ten key points of Web service interoperability development


Over time, many vendors have been publishing their Web services implementations at an alarming rate. This includes the major version of the product, the secondary version, and many development service packs. As the new version becomes more and more standard, interoperability between different vendors is becoming more and more high.

Nevertheless, the recommendations and strategies for using these Web services together are still required. Some practices allow you to ensure that you use and expose Web services in an interoperable way. Based on the experience, I've sorted out a list of "Top ten" points about Web service interoperability. Some of the points are based on the findings of test results that are run on Microsoft and others that are useful when developing projects. The tips here can be applied to IBM, BEA, and multiple open source stacks. I hope they are useful to you. These points are described in turn below:



Content of this page
10. Beware of empty arrays
9. Use package and type name options when generating client agents
8. Test whether the generated Java bean is empty
7. Java can recognize empty date and time values, but. NET cannot
6. Always use CompareTo () when comparing date/time
5. Using the "tracking tool" for research
4. Add options for "Change host and Port"
3. Make sure to use document/literal when building Web services
2. Use unit tests to test interoperability
1. Use XSD First

10. Beware of empty arrays
Sending an empty array through a Web service can cause problems. Some toolkits recognize an empty array as a single null value, while others represent it as a set of empty array elements. My general principle is that when you send an array of objects through a Web service, always make sure that the array contains valid data.


9. Use package and type name options when generating client agents
Many java-based tools have the option to specify unique package and type names when generating client proxies (for example, BEA WebLogic uses the "Clientgen" parameter, and the IBM Rational application developer uses the wizard).

When you create a proxy for a Web service that shares the same data type, it is important to control the package and type names, such as when you call two Web services with the same order type.

8. Test whether the generated Java bean is empty
When you use a tool or IDE to generate Java beans from an XSD file, always ensure that you know how to perform a test action to see if the object is empty. You may think that the following code can complete such a test:

if (MyObject = null)

In some cases, however, you are testing whether the object exists, rather than whether the object's value exists. My advice is to always check the Isnil () method (or similar method) on the generated bean. If it exists, it is guaranteed to have a truth value.


7. Java can recognize empty date and time values, but. NET cannot
In Java, java.util.Date and Java.util.Calendar are categorized as reference types. In the. NET Framework 1.1, System.DateTime is treated as a value type.

What's going to happen? The reference type can be empty, and the value type cannot. If you want to send a null date value across a Web service, the value is always sent as a complex type and the value of the complex type is set to NULL. This will help prevent null date values from being misinterpreted (and thus throwing exceptions).

6. Always use CompareTo () when comparing date/time
If you send a date and time between. NET and Java through a Web service, you always use the appropriate CompareTo () method in Java to compare dates. For example, use:

if (Mydate.compareto (yourdate) = = 0)

And do not use:

if (mydate = = yourdate)

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

5. Using the "tracking tool" for research
The tracking tool is an ideal choice for studying the response between a SOAP request and a Web service. It helps validate data types and message constructs, and also reports soap errors that you might miss in your browser.

There are many types of tracking tools available-some run on the client, some run on the server, some even run between the client and the server (such as proxies). These types of trace tools are difficult to set up, but are generally useful because you can see the messages passed between the systems. Some agent-tracking tools can even allow you to edit and reply to messages-which is 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 for the Web service location. This can make it easier to change the location of future Web services or redirect output to the tracking tool. I find this particularly useful for failover between Web services.

3. Make sure to use document/literal when building Web services
Some toolkits provide an option to make choices for Web services from the following:

rpc/encoding

rpc/literal

document/literal


These options control the style and encoding mechanism for Web service contracts. To help ensure consistency with the WS-I Basic profile, always make sure that document/literal is the default encoding mechanism for all your Web services. Rpc/literal is only used under special circumstances. Never use rpc/encoding.

2. Use unit tests to test interoperability
Unit tests (use. NET NUnit or Java JUnit) is the best way to examine the interoperability of multiple data types through Web services.

If the data type changes (or if you change the version of the Web Service Toolkit!) ), you need to run the test again. This allows you to be sure that the Web service you are designing has complete interoperability.


1. Use XSD First
When designing interoperability, always start by defining data first. After you decide which data to send, first create the data type in the XSD, and then use the tool to generate the class from the XSD file. Performing operations in this order helps ensure online interoperability of data types. To do this, you need to familiarize yourself with the tools that xsd--understand how to model data in XSD and can be used to model data. XSD files can be in Visual Studio. NET to create and edit directly. With XSD, the data type is generated on each platform using the appropriate tools. In. NET, you can use Xsd.exe (part of the framework) or Xsdobjectgen (available for free downloads from MSDN). For Java, this depends on the toolkit you are using. For IBM, use the Java Bean for XML Schema Wizard, and for Bea, drag the XSD file to the Schemas folder in WebLogic Workshop. If it is a different kit, search for the Schema2java tool. When you are done, expose the generated data types in the Web service--This step assumes that you need to ensure that these types are correctly serialized into XSD and XML. When you can guarantee the online display of your data, interoperability is already near you!