Estoy desarrollando un servicio web Java que consumirán los clientes de .Net. El servicio expone un método que acepta un objeto como argumento, este objeto tiene un campo de tipo Lista, la clase Fila también tiene un campo de tipo Lista.Llamando a Java Web Service desde .Net que usa la lista <T>
Ahora cuando el cliente Java consume este servicio, ve correctamente los tipos como List, sin embargo, cuando un cliente .Net consume el servicio, termino con la llamada esperando una matriz de tipo Value (por ejemplo, Value [] []) en lugar de ListLa compatibilidad de la versión se ha establecido en ".Net 3.5/METRO 1.3".
¿Alguien sabe cómo puedo conseguir que esto funcione de la misma manera con los clientes de .Net y Java que aceptan Lista en lugar de Valor [] []?
talados versiones del servicio web son:
Servicio:
@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;
}
Valor:
public class Value {
public String name;
public String value;
}
En mi cliente de .Net cuando intento crear el objeto de solicitud, ve el campo de filas de FeeDataRequest como Valor [] [] en lugar de Lista.
La referencia de servicio en .Net se ha configurado para que el tipo de colección sea System.Collections.Generic.List.
¿Alguna idea sobre cómo hacer .Net ve esto correctamente?
Para la integración entre idiomas utilizando WSDL, recomiendo encarecidamente un enfoque de contrato, diseñe su WSDL (+ XSD), genere código Java del lado del servidor y código .net del lado del cliente. Es un poco más trabajo, pero tus posibilidades son mejores de que funcione. – home
+1 a @home para golpearlo en la nariz. Tal como está, WS no admite de forma nativa Java Collections o Maps. Aunque algunos proveedores como Oracle tienen extensiones propietarias que puede usar para lograr esto, es mejor implementar su servicio web multiplataforma con un diseño de arriba hacia abajo. – Perception
Gracias @Perception. Otra ventaja (en mi opinión) es que tiene un contrato _explicit_ definido en un formato independiente del idioma, que de alguna manera lo obliga a mantener la interfaz pequeña y ajustada. – home