(XSD) INCLUDE vs (XSD) IMPORT

Tanto en los proyectos SOA donde existe la necesidad de orientar la arquitectura a nivel de servicios, como en las exposiciones de sistemas Legacy y Virtualizaciones de Servicios por medio de OSB, en todos estos proyectos nace la necesidad de desarrollar servicios de tipo Web Service. Ahora, durante el diseño de dichos Web Service lo primero que se requiere hacer son los contratos de servicio (.wsdl), ahora nace aquí el problema ¿cómo los diseño?..., por medio de una IDE o manualmente, en mi caso yo recomendaría inicialmente apoyarse en una IDE como JDeveloper o Eclipse que manejan editores que facilitan de algún modo su creación, posteriormente cuando ya tengan práctica y como yo acostumbro hacer, por rapidez y conocimiento, es definir una plantilla base y desde ultraEdit aplicar replace a los nombres estándar de: wsdl:definitions, Namespace, xsd:element, wsdl:message, wsdl:binding, wsdl:service, wsdl:port, soap:address, wsdl:part, wsdl:operation. Así mismo, la edición del modelo de negocio dentro: wsdl:types.

Jústamente, aquí es la idea de este post, ya que es recomendable NO embeber el modelo por medio de los: wsdl:types, dentro de las interfaces: .wsdl. Aquí se genera la gran duda de muchos profesionales que es: ¿Cómo lo manejo con Include o con Import?, ¿Cual es la diferencia de ambos?, y que así nomás no se encuentra su explicación. La diferencia es la siguiente:

xsd:include: 

Se debe usar cuando se requiere manejar los datos de un .xsd con un mismo Namespace.

xsd:import:  
Se debe usar cuando se requiere manejar los datos de un .xsd con un diferente Namespace. 

Esto quiere decir que la gran diferencia entre ambos en a nivel de como uno diseñe su contrato de servicio, específicamente a como segmentará .wsdl y .xsd's con relación a sus Namespace.

Procederé a explicar mejor por medio de un dummy de un diseño que he creado para su mejor entendimiento, este consiste en un .wsdl y tres modelos .xsd:

ObtenerTecnologia.wsdl, este es el contrato de servicio el cual se ha diseñado para que NO se alterado y/o modificado posteriormente. Maneja un Namespace definido como: http://pe.com.eai.dummySOA/bean/obtenerTecnologiaWS, y segmenta su modelo de negocio de manera externa a el, por medio de un xsd.include ya que manejará el mismo Namespace: 

[xsd:include schemaLocation="./ObtenerTecnologia.xsd" /]

ObtenerTecnologia.xsd, es el modelo principal y base del contrato, este se ha diseñado para manejar un mismo contrato que dicho contrato: http://pe.com.eai.dummySOA/bean/obtenerTecnologiaWS. Así mismo, desde el se referenciará a los demás modelos .xsd que se han creado:

- Persona.xsd: la referencia con relación a este modelo, será por medio de xsd.include: [xsd:include schemaLocation="./Persona.xsd" /], ya que dicho .xsd SI manejará el mismo Namespace:  http://pe.com.eai.dummySOA/bean/obtenerTecnologiaWS

- Auditoria.xsd: la referencia con relación a este modelo, será por medio de xsd.import: [xsd:import namespace="http://pe.com.eai.dummySOA/bean/auditoria" schemaLocation="./Auditoria.xsd" /], ya que dicho .xsd NO manejará el mismo Namespace (ya que este modelo será REUTILIZABLE entre diferentes proyectos). El NameSpace que manejará será: http://pe.com.eai.dummySOA/bean/auditoria

Persona.xsd, es el modelo donde será definido los campos embebidos en los objetos: simpleType, complexType, relacionados directamente al negocio que el servicio implementado utilizará.

Auditoria.xsd, es el modelo donde será definido los campos de auditoría especificamente, embebidos en los objetos: simpleType, complexType, que serán REUTILIZADO en diferentes proyectos (modelos).  

Finalmente, con esto se completa la explicación del post. Para los interesados en el diseño explicado, pulsar aquí:
http://www.mediafire.com/download/l152h524h6l2rrb/xsd.include++VS++xsd.import.zip

CAMPOS DINÁMICOS EN 'WSDL / XSD'

Durante los desarrollos de servicios tipo Web Service, los que estamos en el ambiente de desarrollos relacionados a EAI / SOA principalmente, sabemos que para el manejo de los Web Service propiamente, como buena práctica, es estándar el diseñar los contratos de servicios (WSDL) para poder en base a ellos, realizar los Top-down respectivos y en base a estos generar las clases necesarias para poder realizar los implementaciones de los servicios propiamente.

En esta oportunidad mostraré una forma de cómo, al momento de diseñar la interface WSDL, los parámetros que se manejan tanto en el Request / Response, se puede manejar dinámicamente. En si cuando hablamos de dinamismo quiero decir que por ejemplo al momento de crear los parámetros tanto para el Request / Response, normalmente estos son diseñados basados en types: (xsd:string, xsd:int, etc) de la siguiente forma:

Ahora al ser diseñado de esta manera la cantidad de campos enviados serán siempre de un tamaño fijo y ante cualquier campo adicional que se desee agregar, se necesitará alterar la Interface WSDL (esto impactará en la generación de otro Top-down, tanto para el server como para el cliente proxy).

Una solución para evitar este problema es el diseño dinámico en los 'xsd:Type'. Esta idea también es diseñada dentro de un 'xsd:complexType' y 'xsd:element', pero la idea no es tener comúnmente una cantidad de campos fija, sino tener un objeto o lista de campos definidos como: ‘Campo/Valor’ de la siguiente manera:

De esta manera los Top-down brindará fácilmente enviar la cantidad deseada tanto en el Request como Response deseado y dentro de la implementación, dependiendo del lenguaje deseado por ejemplo en JAVA simplemente se deberá antes que nada iterar un FOR combinándolo con un IF para comparar y obtener los campos deseados independientemente de la cantidad de campos que se desee. Vale la pena indicar que de este modo, una vez implementado previamente el Web Service, ya no será necesario realizar algún tipo de cambio tanto en el server como en el cliente proxy respectivamente.

Espero que la información les haya servido

VALIDACIONES Y CONTROL DE ERRORES EN WEB SERVICE

En esta oportunidad hablaremos un poco sobre estos temas comunes que durante los desarrollos de este tipo de servicios afromtaremos. 

En lo relacionado al CONTROL DE ERRORES en Web Service, tenemos 2 formas de manejarla:

1. MEDIANTE 'SOAP FAULTS': Esta opción agrega en el WSDL un 3er message para el control de excepciones, esto 
permitirá que antes algún posible error de cualquier tipo en el servicio, esta excepción sea y mostrada toda la traza del 
error en el fault de respuesta.

2. MEDIANTE 'RESPONSE PERSONALIZADO': Este manejo cubre el uso de un 'complexType' que soportará un idTransaccion y mensajeRespuesta, el cual serán siempre personalizados y seteados los mensajes ya sean exitoso o con error.


Por otro lado, a las VALIDACIONES de formato, existen varias formas:

1. MEDIANTE INTERFACE XSD:  Esta opción requiere que todas las restricciones sean ingresadas a nivel de .xsd por medio de 'simpleType', esto permitirá que si algún atributo del REQUEST no cumpla con la restricción automáticamente sea rechazado y no ingrese al flujo de servicio. Este manejo no permite identificar qué campo ha sido mal enviado. 

2. MEDIANTE VALIDACIONES EN CÓDIGO: Esta opción requiere que los atributos del REQUEST sean validados uno por uno mediante sentencias IF / ELSE. Y permite saber identificar qué campo es el que ha sido mal enviado por la aplicación consumidora.

RECOMENDACIONES:

Debido a mi experiencia puedo mencionar las siguientes recomendaciones:

CONTROL DE ERRORES:  Recomendaría la opcion#2, ya que brinda un mejor control tanto para la identificación de las transacciones, variedad de mensajes exitosos y erróneos que se pueden personalizar.

Esto ayuda sobre todo a las aplicaciones consumidoras para la identificación respectiva. Esta es una ventaja que la opcion#1, no se puede manejar ya que simplemente aquí ante un error revienta y muestra la traza completa del error.

VALIDACIONES:  Recomendaría un híbrido entre las 2 opciones, esto se manejaría definiendo un .xsd con las restricciones del servicio 'simpleType', este archivo sería utilizado para validar dichas restricciones a nivel de código pero directamente igualando REQUEST contra .xsd, si cumple con las restricciones se acceder al flujo del servicio y sino se responde el mensaje personalizado.

Si se tiene un desconocimiento de cómo aplicar esto por ejemplo en JAVA podemos apoyarnos en las librerías: JDOM, XMLBEANs y JAXB, para realizar las transformaciones y validaciones respectivas.