Wywołanie usługi Java Web Service z domeny .Net korzystającej z listy <T>

Question

Zajmuję się tworzeniem usługi WWW Java, która będzie używana przez klientów .Net. Usługa udostępnia metodę, która akceptuje obiekt jako argument, ten obiekt ma pole typu Lista, klasa Wiersz ma również pole typu Lista.

Teraz, gdy klient Java korzysta z tej usługi, poprawnie widzi typy jako List, jednak gdy klient .Net zużywa usługę, którą kończę, oczekując połączenia z tablicą typu Value (np. Value [] []) zamiast listy.

Zgodność wersji została ustawiona na ".Net 3.5/METRO 1.3".

Czy ktoś wie, w jaki sposób mogę uzyskać to samo z klientami .Net i Java w tym, że akceptują listę zamiast wartości [] []?

wycięte wersje usługi internetowej to:

Usługa:

@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; 
} 

Wartość:

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

Na moim kliencie .Net, kiedy próbuję zbudować obiekt żądania, widzi pole wierszy FeeDataRequest jako wartość [] [] zamiast listy.

Odwołanie do usługi w .Net zostało skonfigurowane w taki sposób, że typem kolekcji jest System.Collections.Generic.List.

Każdy pomysł, jak zrobić .Net widzi to poprawnie?

Answer 1

Wszystko, czego potrzebujesz, to używać tablic, gdziekolwiek się spodziewasz. nie musisz się już martwić o nic innego:

Answer 2

Czy możesz opublikować plik WSDL usługi internetowej.

Domyślnie po wygenerowaniu WSDL obiekt List jest konwertowany na tablicę. To z WSDL, .NET próbuje zbudować typy obiektów.

Także jeśli twoja klasa RowInfo ma tylko zbiór obiektów wartość jest nie łatwy w użyciu kolekcji obiektów wartość w DataRequest zamiast zbierania RowInfo obiektów

Answer 3

Korzystając json lub xml do przesyłania danych między swoimi usługami.

Answer 4

Zalecam najpierw zrobić WSDL i utworzyć klientów i interfejsy stamtąd. Następnie wykonaj mapowanie do obiektów, z którymi musisz się uporać w implementacji usługi.

schematu byłoby coś

<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> 

Obserwowani przez RowInfo przy użyciu tego samego wzoru mieliśmy na wierszach. To jest minOccurs = "0" i maxOccurs = "bez ograniczeń". Spowoduje to, że generator klienta utworzy listę.

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

Ostatnim typem jest wartość.

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

Na koniec potrzebujesz elementu zawierającego.

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

Oczywiście powyższe jest po prostu parafrazą, nadal trzeba umieścić w przestrzeni nazw i takie.

Jednym z problemów z nowymi programistami usług sieciowych (włącznie z mną) jest to, że wystarczy napisać kod usługi internetowej i wygenerować kod, aby to zrobić, to dobry pomysł. Niestety, po zabawie z nim, myślę, że jeśli masz kogoś, kto wie, jak pisać schematy WSDL i XML, lepiej mieć współdziałanie i czerpać korzyści z usług sieciowych.

W szczególności część schematu XML. Jestem w szkole, że podejście hybrydowe (pierwszy kod WSDL, ale pierwszy schemat kontraktu) jest prawdopodobnie najlepszym podejściem, ponieważ nie musisz zajmować się powtarzaniem siebie, wykonując wiążący kod. Jednak umiejętności niezbędne do zrozumienia go stają się trudniejsze.