Todos sabemos que la importancia que tiene en el ciclo de vida SOA la interface .WSDL, esto debido a que es el 'Description Language' de los Web Service y porque es el punto de acceso expuesto para la comunicación entre todos los servicio de tipo Web Service.
Debido a ello, es importante que durante la etapa de diseño uno se dé el tiempo debido en diseñar un correcto archivo .WSDL, de preferencia ya sea por medio de una herramienta o si se tiene práctica a mano, pero definir un buen diseño, considerando el posterior Topdown que se realizará.
En esta oportunidad mostraré como crear un .WSDL basado en un diseño segmentado "no común", pero altamente recomendado en los escenarios en que se requiere definir un .WSDL con gran cantidad de capacidades (operaciones) dentro de este.
Los modelos clásicos para diseñar un .WSDL (v1.1) son los siguientes:
_ Un solo archivo .WSDL que contenga todo en su interior: (types (complexType, simplexTypes), message, portType, binding, service).
_ Un archivo .WSDL que contenga en su interior: (message, portType, binding, service) y un archivo .XSD que contenga en su interior: (types (complexType, simplexTypes) ). El .WSDL import ó include el .XSD.
_ Un archivo .WSDL que contenga en su interior: (message, portType, binding, service), un archivo .XSD que contenga en su interior el modelo de datos propio de todas las operaciones: (types (complexType) ), un archivo .XSD que contenga datos 'genéricos' entre todas las operaciones. (types (complexType, simplexTypes) ). El .WSDL import ó include el .XSD propio y este import el .XSD genérico.
Estos modelos de diseño de .WSDL son los conocidos y según el orden van mejorando el diseño propiamente. Así mismo, existe un modelo aún mejor pero que no es tan aplicado, este modelo de diseño se basa en segmentar la interface .WSDL de las operaciones en sí, haciendo que cada operación maneje su propio .WSDL y que exista un .WSDL principal. En otras palabras el diseño sería de esta manera:
_ Un archivo .WSDL (principal) que contenga en su interior: (portType, binding, service), varios archivos .WSDL (según el número de operaciones existente) que contenga en su interior: (message y types (complexType) propios de la operación), un archivo .XSD que contenga datos 'genéricos' entre todas las operaciones. (types (complexType, simplexTypes) ). El .WSDL principal import todos los .WSDLs según el número de operaciones existentes y cada uno de estos .WSDL secundarios import el .XSD genérico.
La ventaja de este modelo de diseño de .WSDL, es que está enfocado en las operaciones y hará al momento del Topdown respectivo que las clases .java (por ejemplo), se autogeneren en directorios independientes por cada operación respectivamente. Esto hará que no exista riesgo en el problema clásico de la duplicidad de clases usadas por cada operación al momento del Topdown:
La relación entre archivos es a nivel de NameSpace, debido a ello es bueno que se defina un correcto estándar en lo relacionado a los nombres, ya que en base a esta definición, se creará el orden de los directorios luego del Topdown respectivamente. Así mismo, todo lo demás es un juego de imports entre los archivos definidos:
- Archivo .WSDL (principal):
- Archivo .WSDL secundario por operación (Operación#1):
- Archivo .WSDL secundario por operación (Operación#2):
- Archivo .XSD genérica:
Para los interesados en utilizar este tipo de modelo de diseño de .WSDL, pueden descargarlo desde aquí: http://www.mediafire.com/download/8nl9nuv6tmnpqr9/DisenioSegmentado_Wsdl.zip
No hay comentarios:
Publicar un comentario