spring - paso - Servicio web con un tipo XML de carga útil genérica "Cualquiera"

web service wsdl ejemplo

Question

Desarrollé un servicio web que acepta y responde con una estructura de mensaje común. Es decir, esta estructura de mensaje está hecha para ser genérica. La forma en que lo hicimos genérico es usando el siguiente esquema XML:

<xs:complexType name="HeaderType">
<xs:complexType name="MessageType">
<xs:complexType name="PayloadType">

donde PayloadType es el siguiente:

<xs:complexType name="PayloadType">
        <xs:annotation>
            <xs:documentation>Payload container</xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:choice>

                <xs:element name="CreateExceptionSeverity" type="cmsmsg:ExceptionSeverity" minOccurs="0">
                    <xs:annotation>
                        <xs:documentation>CreateExceptionSeverity is a hello world operation that takes in a app id, id, name, and description where the web service creates a new entry in EXCEPTIONSEVERITY table.</xs:documentation>
                    </xs:annotation>
                </xs:element>
                <xs:element name="OperationSet" type="cmsmsg:OperationSet" minOccurs="0">
                    <xs:annotation>
                        <xs:documentation>Each operation set is a collection of operations that may require operational-integrity and/or sequence control.</xs:documentation>
                    </xs:annotation>
                </xs:element>
                <xs:element name="Compressed" type="xs:string" minOccurs="0">
                    <xs:annotation>
                        <xs:documentation>For compressed and/or binary, uuencoded payloads</xs:documentation>
                    </xs:annotation>
                </xs:element>
                **<xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax" namespace="##other">**
                            <xs:annotation>
                                <xs:documentation>For XML payloads, usually CIM profiles defined using an XSD in a profile-specific namespace.</xs:documentation>
                            </xs:annotation>
                </xs:any>
            </xs:choice>
            <xs:element name="Format" type="xs:string" minOccurs="0">
                <xs:annotation>
                    <xs:documentation>Hint as to format of payload, e.g. XML, RDF, SVF, BINARY, PDF, ...</xs:documentation>
                </xs:annotation>
            </xs:element>
        </xs:sequence>
    </xs:complexType>

Entonces, la línea:

<xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax" namespace="##other">

hace que esta estructura sea lo suficientemente flexible como para enviar datos cuando se invoca el servicio web y cuando el servicio web devuelve la respuesta. Este servicio web se implementa en un servidor TIBCO (utiliza Tomcat) y se invocará a través de SOAP / HTTP.

El cliente de este servicio web es una aplicación web de Java Spring. Mi pregunta es: ¿cómo puede el código de Java lidiar con este elemento Any porque requiere un tipo concreto de XML como entero, cadena o un tipo complejo? Cualquier dirección aquí será muy apreciada.

Answer 1

Por favor no hagas esto He trabajado anteriormente con este tipo de servicios web "genéricos" y son el equivalente a tener una API de Java donde cada método tiene la firma

public Object methodName(Object o);

Sí, todo es muy genérico, pero no transmite información sobre cómo usarlo (una interfaz bien diseñada transmite cómo debe usarse, de la misma manera que el mango de una tetera sugiere que la tetera debe ser levantada por el mango ) Cuando alguien desea desarrollar una aplicación que consuma su servicio, ¿cómo averigua qué enviar y qué recibirá? Si está en otro documento, básicamente has creado tu propio lenguaje de descripción del servicio web a medida, que no se integrará con ninguna herramienta (como Spring o Axis-2) y requerirá una gran cantidad de código manual adicional para ser escrito.

Además, tendrá que escribir un código adicional en su implementación de servicio para validar el contenido de las cargas útiles. Esto significa trabajo adicional para mantener y mayor posibilidad de defectos.

Utilice entradas y respuestas XML concretas para las operaciones de su servicio web y elimine las de cualquier. No solo simplificará su código y simplificará el código de sus consumidores, sino que también eliminará la pregunta que ha hecho sobre cómo consumirla desde Spring.

El hecho de que hayas tenido que venir aquí para preguntar cómo consumir un servicio web que has creado debería hacer sonar las alarmas en tu cabeza. Al crear cualquier tipo de interfaz, si es difícil de usar, entonces será extremadamente difícil de usar. Para asegurar que mis servicios web sean fáciles de consumir, lo primero que hago (antes de crear el WSDL o la implementación) es crear un programa simple que invoca el servicio como parte de una prueba (por ejemplo, JUnit o Cucumber-JVM, etc.) , pasando solo los datos que se necesitan (y nada más) y solo buscando los datos de respuesta que necesita (y nada más). Luego trabajo en la implementación del servicio web hasta que la prueba haya pasado. Esto siempre resulta en servicios agradables y fáciles de usar, en lugar de grandes servicios inflados con esquemas altamente complejos, de los cuales solo se usa el 1% (estoy seguro de que ponen el otro 99% del esquema allí y no usan esto, solo para desviar a los nuevos usuarios del servicio).

En términos de los metadatos que desea incluir en el mensaje (es decir, el tipo de mensaje y la información del tipo de encabezado), considere usar encabezados SOAP según el patrón SOA de metadatos de mensajería . Le permiten incluir información adicional, sin contaminar el cuerpo de su mensaje.

Por último, si necesita aplicar algún tipo de consistencia sobre la estructura del mensaje (porque por alguna extraña razón el sobre de SOAP no es suficiente y necesita su propio sobre a medida para ponerlo en el sobre de SOAP), considere usar tipos de base abstractos , que luego extiende a la suite las necesidades particulares del método. Esto le permitirá aplicar consistencia, sin requerir que los consumidores de su servicio adivinen qué es realmente el "cualquiera".

Nota al margen. Un cliente en el que trabajé tenía una estructura de mensaje genérica como la suya. Una de las razones era que querían una manera consistente de informar el éxito o error en sus respuestas al servicio web. Entonces, en la parte superior de su sobre de respuesta personalizado había un elemento para indicar el éxito o el fracaso, y todo estaba bien ...

... excepto por los consumidores del servicio, que ahora necesitaban escribir un código adicional no solo para verificar las fallas de SOAP, sino también para verificar si se había establecido el indicador de error personalizado.

... y excepto cuando quisimos poner un equilibrador de carga en frente de nuestros servicios, porque no admitía de forma nativa nuestro elemento de error personalizado. Sin embargo, admitía fallas SOAP y códigos de estado http: /

ACTUALIZAR

Una manera más simple de expresarlo. La operación viola el principio de sustitución de Liskov .

Si una operación acepta "Cualquiera", debería esperar que cualquier elemento xml válido que pase a la operación funcione. Sin embargo, solo se permiten ciertos elementos XML. La única forma de saber qué tipos están permitidos es conocer los detalles de la operación. En otras palabras, la operación es menos flexible que lo anunciado.

La actualización anterior se modificó a partir de la respuesta excelente en https://softwareengineering.stackexchange.com/a/198100/37491