A Java Web Service call from .Net that uses a List <T>

Question

I am developing a Java web service that will be used by .NET clients. The service provides a method that takes an object as an argument, this object has a field of type List, the class Row also has a field of type List.

Now, when the Java client uses this service, it correctly sees the types as List, however, when the .Net client uses this service, I get a call expecting an array of arrays of type Value (for example, Value [] []) instead of a list.

Version compatibility is installed on .Net 3.5 / METRO 1.3.

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

Cut web service versions:

Services:

@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 to create a query object, it sees the FeeDataRequest string field as Value [] [] instead of List.

The service link in .Net is configured so that the type of the collection is System.Collections.Generic.List.

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

Answer 1

Use json or xml to send data between your services.

Answer 2

Can you host a WSDL web service.

By default, when creating a WSDL, the List object is converted to an array. It is from WSDL.NET that it is trying to create object types.

Also, if your RowInfo class has only a set of Value objects, it is not easy to use a collection of Value objects in a DataRequest, rather than collecting RowInfo objects

Answer 3

All you need to do is use arrays while waiting for a list. you don't need to worry about anything else

Answer 4

I would recommend first doing this WSDL and creating clients and interfaces there. Then do a mapping to the objects you need to deal with in implementing the service.

Your circuit will look 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> 

This is followed by RowInfo, using the same pattern as for the strings. These are minOccurs = "0" and maxOccurs = "unbounded". This will force the client generator to create the list.

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

The latter type has a 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, this is just paraphrasing, you still need to specify namespaces, etc.

One of the problems with new web service developers (including me) is that we believe that just coding a web service and creating code to accomplish this task is a good idea. Unfortunately, after playing with this, I think that if you have someone who knows how to write WSDL and XML schemas, you better interact and use the value of web services.

In particular, part of the XML schema. I am from school that a hybrid approach (the first WSDL code, but the first contract scheme) is probably the best approach because you do not need to do the repetition of yourself executing the binding code. However, the skills necessary to understand it are becoming more complicated.