viernes, 15 de enero de 2016

SEGMENTACIÓN EN DISEÑO DE .WSDL


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





miércoles, 6 de enero de 2016

ANÁLISIS SOA: [TOP-DOWN / BOTTOM-UP]


En muchas empresas NO se les da la importancia debida al trabajo del Rol: 'Analista SOA', es más en muchas empresas este Rol ni exíste. Este es un error grave, ya que la tarea que realiza dicho Rol es en si la base de toda Arquitectura SOA, debido a que el resultado de dicho análisis ('modelado y arquitectura orientada a servicios') que estos profesionales hagan, definirá los 'Servicios Candidatos' que posteriormente se verán reflejados como base en el Inventario de Servicios (con relación a los ‘servicios compuestos’).

Cuales son las consecuencias de un incorrecto Análisis SOA: que los servicios base en el inventarios de servicios NO sean altamente reutilizables (en muchos casos NI existen), que exista rebundancia constante a nivel de codificación en los procesos, que se creen servicios compuestos por crear, problemas con la gobernanza y el posterior mantenimiento de cada servicios, etc. Y lo peor es que el impacto es incremental a media que el inventario de servicios va creaciendo.

Actualmente, existen algunos enfoques SOA (ejemplo: SOMA y MSOEM) que definen un conjunto de técnicas para identificación de 'Servicios Candidatos'. Dichas metodologías SOA, tienen muchas cosas en común, ya que existen entre los resaltantes dos caminos posibles: TOP-DOWN y BOTTOM-UP.

- Técnica BOTTOM-UP:  
La cual se enfoca en realizar un análisis, para la obtención de los servicios candidatos, partiendo de  las aplicaciones y/o sistemas legacy (antíguas) ya existentes en los cuales los procesos de negocio no están definidos.

- Técnica TOP-DOWN:
La cual se enfoca en realizar un análisis, para la obtención de los servicios candidatos, partiendo de los procesos de negocio (si no se tienen estos, deben ser obtenidas del Feedback de los 'Analistas Funcionales' y modelando los BPMN respectivos). Descomponiendo dichos áreas funcionales, en proceso de negocio en  hasta llegar a procesos, subprocesos y tareas. Es importante recalcar que esta técnica descompone los elementos del nivel más bajo de la granularidad.

Así mismo, se debe tener en claro que todo el proceso de negocio tarde o temprano tenderá a ser un TOP-DOWN (es recomendable), de lo contrario no se llegara a una Arquitectura SOA ideal, donde IT esté alineado al negocio.

Por otro lado, se debe tener claro que este enfoque de análisis debe ser iterativo, ya que no se debe de querer hacer desde el inicio TODA la descomposición del total de los procesos existentes en la empresa. Es recomendable hacerlo por partes, en base a los procesos principales a medida que los requerimientos vayan saliendo. Esto debido a que los servicios serán altamente modificables y apuntan a la reutilización, por lo que se debe analizar por partes los procesos de negocio de la empresa, para definir y formalizar los primeros Servicios Candidatos base del Inventario de Servicios. 

Finalmente, para su posterior investigación los enfoques más resaltantes actualmente son:

- SOMA (IBM).
- MSOAM (Thomas Erl).

Particularmente, prefiero la segunda, pero se pueden complementar.