Calling Java Web Service from .Net that uses List<T>

I'm developing a开发者_运维百科 Java web service that will be consumed by .Net clients. The service exposes a method that accepts an object as an argument, this object has a field of type List, the Row class also has a field of type List.

Now when as Java client consumes this service it correctly sees the types as List however when a .Net client consumes the service I end up with the call expecting an array of arrays of type Value (e.g. Value[][]) instead of List.

The version compatibility has been set to ".Net 3.5/METRO 1.3".

Does anyone know how I can get this to work the same with .Net and Java clients in that they accept List instead of Value[][]?

Cut down versions of the web service are:

Service:

    @WebService(serviceName = "Test")
    public class Test {

    @WebMethod(operationName = "DataRequest")
    public DataResponse DataRequest(DataRequest req) {
        return new DataResponse();
    } 

}

DataRequest:

public class DataRequest {
    public DataType datType;
    public String source;
    public List<RowInfo> rows;
    public String loginId;
}

RowInfo:

public class RowInfo {
   public List<Value> valueList;
}

Value:

public class Value {    
    public String name;
    public String value;
}

On my .Net client when I try and build the request object it sees the rows field of FeeDataRequest as Value[][] instead of List.

The service reference in .Net has been configured so that the collection type is System.Collections.Generic.List.

Any idea on how to make .Net sees this correctly?

---

Use json or xml to send data between your services.

---

Can you post the WSDL of the web service.

By default when the WSDL is generated the List object is converted to array. It is from the WSDL that .NET tries to build the object types.

Also if your RowInfo class has just a collection of Value objects is it not easy to use collection of Value objects in the DataRequest rather than collection of RowInfo objects

---

All you need to d is to use arrays whereever its expecting List . you dont have to worry about anything else

---

I'd recommend just doing it WSDL first and create the clients and interfaces from there. Then do the mapping to the objects you need to deal with on the service implementation.

Your schema would be something like

<complexType name="DataRequest">
    <all>
        <element name="datType" type="DataType" />
        <element name="source" type="string" />
        <element name="rows">
            <complexType>
                <sequence>
                    <element name="row" type="RowInfo" minOccurs="0" maxOccurs="unbounded" />
                </sequence>
            </complexType>
        </element>
        <element name="loginId" type="string" />
    </all>
</complexType>

Followed by the RowInfo using the same pattern we had for rows. That is minOccurs="0" and maxOccurs="unbounded". This will make the client generator create a list.

<complexType name="RowInfo">
   <sequence>
       <element name="valueList" type="Value" minOccurs="0" maxOccurs="unbounded" />
   </sequence>
<complexType>

The last type you have is Value.

<complexType name="Value">
    <all>
         <element name="name" type="string" />
         <element name="value" type="string" />
    </all>
</complexType>

Finally you need a containing element.

<element name="dataRequest" type="DataRequest" />

Of course the above is just paraphrasing, you still need to put in the name spaces and such.

One of the problems with new Web Services developers (myself included) is we think that just coding the web service and having code generation do the job for is is a good idea. Unfortunately, after playing around with it, I think that if you have someone who knows how to write WSDL and XML schema, you'd have better interop and reap the value of web services.

Specifically the XML schema part. I am of the school that the hybrid approach (code first WSDL, but contract first schema) is likely the best approach because you don't need to deal with repeating yourself doing the binding code. However, the skills necessary to understand it gets harder.