Listing 2. The generated XML Schema for the CustomerService class. - Web Services

This article introduces a couple of techniques that you can use to build interoperable Web services that take and return object collections. This is the first of a series of articles covering this subject. Future articles will cover more detailed scenarios. (This intermediate-level article was first published by IBM developerWorks, May 28, 2004, at http://www.ibm.com/developerWorks).

TABLE OF CONTENTS:

By: developerWorks

Poor Best

Rating:

/ 5

December 22, 2004

print this article

SEARCH DEV SHED

TOOLS YOU CAN USE

<schema elementFormDefault="qualified"
targetNamespace="http://pack"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://pack" xmlns:intf="http://pack"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
   <element name="getCustomers">
<complexType>
    <sequence>
      <element name="queryString"
        nillable="true"
        type="xsd:string"/>
       </sequence>
</complexType>
   </element>
   <complexType name="ArrayOfXSDAnyType">
<sequence>
    <element maxOccurs="unbounded"
        minOccurs="0"
        name="item"
        nillable="true"
        type="xsd:anyType"/>
</sequence>
   </complexType>
   <element name="getCustomersResponse">
<complexType>
    <sequence>
      <element name="getCustomersReturn"
          nillable="true"
          type="impl:ArrayOfXSDAnyType"/>
    </sequence>
</complexType>
   </element>
</schema>

As you can see, the tooling generates a complex type definition for something called ArrayOfXSDAnyType, which is, in turn, an unbounded sequence of type <xsd:anyType>. Why didn't it generate an element of type xsd:linkedList to contain your Customers? It's because there is no xsd:linkedList. There is no xsd:hashMap, no xsd:treeSet, no xsd:vector and no xsd:stack. All of those ficticious types would have some implied functioniality associated with them beyond storing an ordered list of objects. Each language, tool or environment is at liberty to provide arbitrary collection constructs that do one of the following:

- Implement variations of the implied functionality
- Omit that type of collection
- Define others not included in Java collections.

So how do you exchange collections of objects in an interoperable fashion? The answer is using an array.

The solution? Plain arrays...

While some of the collection classes might actually work in your specific environment (such as a Java to Java environment), they might not work in others. Thus, we recommend against using those classes on the service interface. The only way in which collections of objects should be transferred between Web services is as an array. The WS-I Basic Profile describes how arrays (which are still a language-specific construct) are mapped to XML and how this is described in the XML Schema, making its handling interoperable across multiple environments. Listing 3 shows what the changed CustomerService JavaBean looks like:

Next: Listing 3. The CustomerService class using a simple array. >>