8

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?

Improve this question
5
  • 5
    For cross-language integration using WSDL I strongly recommend a contract-first approach, design your WSDL (+ XSD), generate server-side Java code and client-side .net code. It's a bit more work, but your chances are better that it works. Commented Oct 7, 2011 at 11:22
  • +1 to @home for hitting it square on the nose. As it is, WS does not natively support Java Collections or Maps. Though some vendors like Oracle have proprietary extensions that you can use to achieve this it's better to implement your cross-platform web service with a top down design. Commented Oct 7, 2011 at 11:33
  • 2
    Thanks @Perception. Another (in my opinion) advantage is that you have an explicit contract defined in a language independent format, which somehow forces you to keep the interface small and tight. Commented Oct 7, 2011 at 11:38
  • 1
    I do not understand why it is a problem for the .NET clients to see arrays instead of Lists. If they pass in arrays the Java server will receive them as Lists. Do you need to replace an existing service for which the clients are already written? Commented Oct 11, 2011 at 14:07
  • I think it might help if you said which library you're using to generate the XML and how the generated XML looks. Anyway, I would try to declare the list with an alias or with an implicit array if it was XStream. Commented Oct 23, 2011 at 9:48

4 Answers 4

Reset to default
2

Use json or xml to send data between your services.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

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

Improve this answer

Comments

0

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

Improve this answer

3 Comments

The problem isn't to do with single array. If it was expecting a single array there'd be no problem. However in this case .Net sees a jagged array (Value[][])) instead of what I'd expect to see an array of RowInfo.
Is that really a problem? Are you having trouble defining the jagged array in .NET?
@Paul for the later problem, I side with the OP, that Is a problem. I'm actually surprised the OP isn't seeing an Array of RowInfo. Something looks fishy in there. @ Alan you should post the WSDL, have you tried using an array instead just to see if the generated WSDL is picked correctly by .net as an array of RowInfo?
0

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.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.