SOLUCIÓN AL MAL ENTENDIMIENTO DE CONCEPTOS SOA

Buen día luego de un tiempo regreso a escribir un poco sobre un tema que considero importante y que hace unos días, conversando con algunos compañeros, he notado que persiste la problemática y/o desconocimiento de muchos conceptos que derivan de SOA.

Uno de ellos y el cual me enfocaré en esta oportunidad es sobre el problema que se tiene con los conceptos de: SERVICIO, WEBSERVICE, REST, APLICACIÓN. Mucho colegas ingenieros ya sean Consultores, Arquitectos, etc, utilizan estas definiciones muy por usar, aparentemente sin conocer la realidad de cada uno y a que está enfocado, y lo que hacen es por ejemplo para hablar de un SERVICIO, mencionan WEBSERVICE, o para hacer referencia a un WEBSERVICE de un tipo específico lo llaman como APLICACIÓN y eso está realmente mal. 

El objetivo de este artículo es justamente dar a conocer las diferencias entre estas definiciones, para que los que aún tienen problemas con dichos conceptos, sepan aplicarlos correctamente al explicar y/o graficar sus arquitecturas a futuro.

A continuación detallaré con mis propias palabras, el concepto utilizado a nivel de TELCOS y en realidad el estándar que debería ser utilizado en cualquier rubro respectivamente:

APLICACIÓN:
Una Aplicación se hace referencia al software que interactúa con el usuario por medio una interface gráfica (el Front-end), está puede estar construida en cualquier lenguaje de programación como JAVA o .NET (últimamente: Angular JS + Bootstrap). En una Arquitectura SOA las Aplicaciones son las encargadas de interactuar por medio de la ejecución de sus componentes HTML (Links, Botones, etc), con un 'inventario de servicios' expuestos por detrás.

SERVICIO:
Un Servicio debe ser considerado como un 'activo de la empresa' y puede ser considerado como Servicio  a nivel de tecnología por ejemplo: un WebService, un EJB, un MDB, etc. El objetivo es que cumplan el objetivo para los que fueron construidos y así mismo sigan sobre todo los principios SOA. Finalmente, es importante saber que un Servicio en base a su tipo (muy independientemente del lenguaje en que se desarrolle: JAVA, BPEL) pueden ser de tipo:

• Presentación: Servicios que dan la cara a la aplicación (No tienen lógica de negocio), redireccionan.
• Negocio:  Servicios que orquestan a nivel de sus flujos, la lógica de negocio definida para el proceso.
• Utilitario: Servicios que su objetivo es la reutilización, para el acceso a BackEnd y/o funcionalidades por ejemplo: BD, Plataformas Legacy, Envío de correos, Generación de logs, etc (No tienen lógica de negocio), aquí entran a tallar como parte de este tipo los conceptos de servicios de: ''Conectividad' y 'Datos'. 

WEBSERVICE:

Un Webservice es un tipo de Servicio, pero que cumple los protocolos como: SOAP & REST. Si hablamos del primer protocolo estos pueden manejar: SOAP 1.1 o SOAP 1.2 y manejar su comunicación tipo: Síncrono, Asíncrono y Oneway (XML en realidad). Así mismo, el segundo protocolo puede manejar una comunicación basada en XML & JSON (Formatos distintos) y si cumple en su manejo con las operaciones estándar: GET, POST, DELETE, etc, se le conoce como RESTfull.

De esta manera se ha tratado de explicar de la manera más amigable los diferentes conceptos SOA que usualmente generan controversia en su entendimiento.

MODELO DE DATOS: 'CANÓNICO'

Este modelo consiste en definir atributos estándares y sus respectivas características, diseñados a nivel de entidades. Esto con la finalidad de la reutilización de esta información a nivel de los contratos de servicio, evitando de esta manera cualquier tipo de duplicidad en los datos.

El objetivo es que el modelo canónico proporcione los formatos de intercambio de datos del negocio, de manera que todos los componentes (servicios, aplicaciones, etc), sólo necesiten saber (como máximo) su propio formato de datos y el formato de datos predeterminado (el que comparte dentro del bus de servicio), ya que el modelo canónico de mensajes tambien representa el formato estándar utilizado para intercambiar información de negocios en un bus de servicio.

Dicho modelo está enfocado en la aplicación dos patrones:

- SCHEMA CENTRALIZATION.
- CANONICAL SCHEMA.

Dando solución a los PROBLEMAS siguientes:

¿Cómo pueden los contratos de servicio ser diseñados para evitar la definición de datos redundantes?.

Esto se refiere específicamente al contenido de los esquemas redundantes (muy comúnmente) y/o mal diseñados que en si son difíciles de gobernar.

¿Cómo pueden los servicios diseñarse para evitar la transformación del modelo de datos?.

Esto se refiere e impacta directamente a servicios con esquemas diferentes, con datos similares (Redundantes) y que requieren de transformación, con esto aumenta el esfuerzo de desarrollo, la complejidad del diseño y la sobrecarga de rendimiento en tiempo de ejecución, ya que el objetivo es llegar a la Interoperabilidad  intrínseca (de manera natural). 

La SOLUCIÓN sería:

Crear y seleccionar esquemas existentes físicamente separados del contrato de servicio (.WSDL), ya que justamente la representación más común que se utiliza para el modelo canónico mensaje es un conjunto de esquemas XML. Esto tiene la ventaja de hacer el tipo y definiciones de mensajes (esquemas) con el fin de reutilizarlos y compartirlos entre varios contratos.

Un modelo de datos canónico es conjunto definido de tipos, elementos, atributos y relaciones que representan las entidades de negocios, estas están justamente basadas en los requerimientos del negocio para el proyecto SOA. Los modelos de datos (esquemas) deben estar estandarizados (Modelo Canónico) a nivel de entidades, almacenado y versionado por medio de alguna herramienta que permita centralizar todo el Modelo Canónico (MDL) de entidades, para que ante algún requerimiento de información por parte de un servicio dentro del contrato se importe la referencia a la entidad y se reutilice el dato requerido. Esto evitará cualquier tipo de redundancia de información, problema de transformación a nivel de Xsd, etc.

¿Cómo diseñar un MDL?

Dependiendo de cuan grande sea la empresa puede que ya tenga algunos modelos de referencia (para las Telecomunicaciones existe SID-TM Forum, etc.).  La idea es tener un modelo base inicial para poder trabajar y que se ajusta a las necesidades, al cual se puede complementando con más entidades en base al levantamiento de información que se realice. Aquí están algunas ideas sobre cómo lograr un buen modelo conceptual MDL (muy similar a cualquier otro modelo de datos):

- Validar si se seguirá algun modelo base del modelo canónico (como SID).
- Enumerar todas las entidades principales que requiere su empresa (cliente, pedido, etc.).
- Relacionar las entidades.
- Especificar los atributos de las entidades.

TeleManagement Forum (TMF) han definido un conjunto de cuatro marcos conocidos colectivamente como Frameworx. Los marcos clave proporcionan un valor empresarial que son el 'Marco de la Información' (SID) y el 'Marco de Procesos' (eTOM). Ambos pueden ofrecer una mayor agilidad en los negocios. Dichos modelos SID representan el ejemplo más importante de los esfuerzos puestos en desarrollar formas eficientes de compartir información entre sistemas de telecomunicaciones. Incluso, el SID debe convertirse en el lenguaje que SOA proporcione como vocabulario, gramática y sintaxis base que utilicen los servicios para proporcionar o recibir información. Así mismo, se debe de asegurarse de que todo el tráfico de mensajes a través de la ESB esté alineado SID, así el esfuerzo necesario para integrar los servicios se reducirá drásticamente así como también se reducirá los costos de mantenimiento respetivamente.

Por otro lado, una contra que se debería tener en consideración es que ante algún cambio en el 'tipo/tamaño' del dato perteneciente a la entidad, se debe de considerar que esto impactará en las ‘N’ aplicaciones que reutilizan dicha entidad (por medio de sus Xsd), y en las otras ‘N’ aplicaciones consumidoras que también reutilizan en sus comunicaciones.

¿Cómo implementar un MDL?

Para implementar un MDL como ya se ha mencionado se debe de diseñar, modelar y relacionar las entidades de negocio, para esto uno se puede apoyar en herramientas empresariales como Enterprise Architect (Sparx), que permitira diseñar desde un Diagrama de Clases 'UML', poder modelar las entidades y a si mismo y generar en base al diagrama de clases, esquemas .XSD y clases .JAVA.

El Modelo Canónico de las entidades completo puede ser diseñado exportado y reutilizado en los para cada servicio dentro de sus contratos respectivamente:

Tal como se mencionó durante el desarrollo de un Servicio Web la idea es reutilizar el Modelo Canónico estandar dentro del Contrato tal como se puede apreciar en la imagen:

Finalmente, una de las cosas más importantes que se debe también hacer, es educar a la empresa en el uso del MDL, y las ventajas a largo plazo de la misma. La gente a menudo no se enfocan a largo plazo y prefieren optar un enfoque más pragmático para resolver los problemas que se enfrentan sin tener en cuenta el impacto de la misma en el futuro.

Para los intersados se pueden descargar los archivos utilizados desde aquí:

Modelado:
http://www.mediafire.com/download/zkfz3x3xazkrci6/XSD_Model_Generator.zip

Wsdl/Xsd:
http://www.mediafire.com/download/n2lbxbnxnk40i24/ModeloCanonico_Dummy.zip

SOA vs MICROSERVICIOS

En esta oportunidad complementaré la idea de este muy bueno artículo hecho por: Andrés Hevia

http://pensandoensoa.com/2015/10/25/a-vueltas-con-los-microservicios-y-soa/, dando mi punto de vista sobre este tema tan controversial del cual se habla este último tiempo.

En si NO se debe de confundir lo que es SOAP con WS-*, ya que SOAP (Simple Object Access Protocol), es un protocolo de comunicación estándar para mensajería apoyado por la W3C como un modelo distribuido. Por otro lado, WS-* es un protocolo definido por OASIS orientado al desarrollo y la adopción de estándares. Dichos estándares son comúnmente implementados por los Vendors (ORACLE, IBM) en sus herramientas, así como en apis OpenSource.

Ahora, en si una de las diferencias que comúnmente se menciona es que SOA en su implementación debe ser desarrollada con Web Service específicamente y por otro lado, MicroServicios debe ser implementado con servicios RestFul basado en arquitectura REST. En mi opinión está mal ya que se en un proyecto SOA las implementaciones deben ser orientadas a servicios (NO Web Service), esto quiere decir que dichos servicios pueden también ser considerados de tipo RestFul, NO hay problema con ello.

Por otro lado, la gran diferencia entre ambos es que una de las características de SOA es que es recomiendable como patrón, el usar un ESB para la comunicación, seguridad, transformaciones, eliminaciones de conexiones punto a punto, etc, entre los servicios de manera desacoplada, en sí que sea la columna vertebral de las soluciones SOA. Por otro lado, MicroServicios NO manejan la visión del manejo del ESB, ellos de apoyan en lo que se denomina API Gateway que proporciona un punto de acceso central para administrar, enrutar, supervisar y asegurar el acceso a servicios expuestos públicamente.

Finalmente, desde mi punto de vista veo que un API Gateway no es un sustituto de un ESB, sino más bien una mejora para la implementación de una Arquitectura Orientada a Servicios (SOA).

APLICACIÓN 'WS-ADDRESSING' ...

'WS-Addressing' es una especificación WS, que permite incluir en un mensaje SOAP información sobre el servicio emisor en  lo relacionado a los destinatarios, a quién se le requiere responder, a quién se debe informar en caso de error, etc, por medio de los mecanismos propios SOAP.

Ahora hablando ya no tan técnicamente, lo que facilita esta especificación es hacer que desde un 1er 'servicio X', al consumir un 2do 'servicio Y', este 'servicio Y' (independientemente de su tipo: Oneway, Sincrono ó Asincrono) permita redireccionar una copia de la 'respuesta' procesada de dicho 'servicio Y' hacia un 3er 'servicio Z' (se podría enviar más de 1 copia). El efecto 'Callback' se cumplirá por medio de esta solución.

El dummy preparado acontinuación muestra la aplicación de esta funcionalidad a nivel de servicios, desarrollado con JAX-WS (Metro) en JDeveloper v11.1.1.7 y desplegado en: Weblogic 12c. Asi mismo, las características de los componentes son las siguientes:

1- DummyAddressingWS: Servicio SOAP en el que se ha aplicado las funcionalidad de 'WS-Addressing' en sus operaciones a nivel de WSDL y código. Las respuesta posibles de las operaciones, serán replicadas a otro servicio definidos internamente de manera directa. Así mismo, internamente el .jar (proxy client), del servicio: 'DummyAddressingCallbackWS', justamente para la realización del efecto de replicación.

2- DummyAddressingCallbackWS: Servicio SOAP que expondrá operaciones que serán consumidas por el servicio: 'DummyAddressingWS_Proxy' (Callback). 

3- DummyAddressingWS_Proxy: Proyecto de tipo Test, el cual contendrá internamente el .jar (proxy client), del servicio: 'DummyAddressingWS', para el procesamiento requerido. Es importante comentar que el consumo por JAX-WS (Metro), será un poco diferente, ya que se requiere especificar una configuración a nivel de código necesaria a causa de la aplicación del 'Addressing'.

Para los interesados, las fuentes propias del dummy mostrado pueden ser descargadas aquí:
http://www.mediafire.com/download/wnd8d8zb3s3cpuv/Dummy_Addressing-Callback.zip


Saludos.

SOA: SERVICIOS & TECNOLOGÍA

En esta oportunidad brindaré mi opinión personal sobre este muy buen post titulado:
'RESTful APIs are also SOA'
http://www.soa4u.co.uk/2013/09/restful-is-also-soa.html?showComment=1440170531922#c6039681206622596310


ESPAÑOL:
Totalmente de acuerdo con el post, al hablar de SOA como tal NO hay diferencia al hablar tanto de las APIS REST como los WebService (SOAP), no debemos considerarlos como cosas completamente diferentes (tecnológicamente hablando), ya que en si viendolo desde el punto de vista de arquitectura SOA, ambos son considerados como servicios (servicios REST y servicios WS), tal como 'Thomas Erl' lo menciona en sus libros. En si un servicio es una lógica a la cual se le ha aplicado el paradigma de la “Orientación a Servicios” y durante la Fase Análisis son llamados: 'Servicios Candidatos' son considerados 'Activos de la Empresa' (Estos servicios propiamente pueden ser de cualquier tecnología incluídas: REST y WS, eso si con estándares definidos).

Por otro lado, a nivel de WS, sobre los WSDL estoy muy de acuerdo ya que brinda un orden a nivel de interface para client/provider (Top-down), algo que REST no maneja hasta el momento (WADL no estandarizado formalmente a nivel de compañias y vendors) y es liminado a definir una buena especificación en documentación.

INGLES:
Totally agree with the post, to talk about SOA as such there is no difference in speaking both as the WebService REST APIs (SOAP), we should not regard them as completely different things (technologically speaking), and that if seeing it from the point SOA view, both are considered as services (REST and WS service) as 'Thomas Erl' mentions in his books. Whether a service is a logic which has been applied to the paradigm of "Service Orientation" and during Phase Analysis are called 'Candidate Services' are considered 'Assets Company' (These services themselves may be of including any technology: REST and WS, that if defined standards).

On the other hand, at the level of WS on the WSDL I agree very much as it provides a command-level interface for client / provider (Top-down), something that REST does not handle so far (WADL not formally standardized level companies and vendors) and is bound to define a good specification documents.

APLICACIÓN DE 'MTOM' EN SERVICIOS WEB.

En esta oportunidad hablaré un poco sobre un mecanismo no muy utilizado y conocido que es MTOM. Dicho MTOM (SOAP Message Transmission Optimization Mechanism), es un estándar a nivel de servicios Web, que permite la transferencia o envío de datos binarios (documentos, imágenes, mensajes de gran tamaño o con estructura compleja), de manera eficiente hacia y desde servicios Web.

MTOM requiere que el mensaje binario dentro del XML document sea codificado en 'base64', ya que dichos datos binarios serán envíados como attachment.

Para usar MTOM basta con seguir estos pasos:

1. Desde el SERVIDOR:

A. Habilitar el tipo de mensaje en el WSDL del servicio:

B. En la clase implementadora ingresa la anotación @MTOM respectiva, para que el servicio reconosca que se va a trabajar con MTOM:

C.  Al aplicar el Topdown respectivo, notaremos que la equivalencia al 'base64', será una variable de tipo 'byte[]', se deben de entender que en base al tipo de mensaje serializado que se defina como envío se deberá de parsea el 'contenType' respectivo. Ejmplo: "image/jpeg", "image/jpg", "image/gif", "application/pdf", etc. Así como las rutas absoludas de descarga de los adjuntos (imagen, pdf, etc) en el servidor ó si es en algún otro server, la solucion FTP ó SFTP respectiva.



2. Desde el CLIENTE:

A. Desde la aplicacion cliente se verá de realizar el envío del adjunto propiamente y su respectiva serialización, dicha serializacion variará dependiendo del tipo de adjunto que se requerirá envíar:

Para los interesados se comparte el siguiente dummy, que cumple todo lo explicado previamente para la aplicacion de MTOM. Implementado bajo el Ide ECLIPSE y con JAXWS. Los componentes adjuntados son:

- DummyMTOMCliente
- DummyMTOMServer


http://www.mediafire.com/download/x916kri9tiyrfyq/DummyMTOM.zip

Saludos.

'RELIABLE MESSAGING' ...

Se define como un SOA Pattern, en el cual el problema es comunicación del servicio que no puede ser Reliable Messaging garantizada al usar protocolos de mensajería o ser usado en ambientes poco fiables. En si lo que soluciona este patrón es aplicar un mecanismo para garantizar la entrega de la mensajería a un destino específico.

Para lograr este objetivo se aplica la especificación WS-ReliableMessaging (WS-RM), justamente para asegurar la entrega fiable del mensaje, así mismo dicha especificación va de la mano con otra especificación que es la WS-Addressing que ayuda en identificar servicios web y mensajes independientemente del protocolo de transporte utilizado.

Actualmente, existe muy poca información sobre estos temas, debido a ello el tutorial y dummy preparado a continuación muestra justamente la aplicación de: WS-ReliableMessaging, WS-Addressing en un servicio de tipo One-way el cual por ser propiamente ‘asíncrono’ no existe respuesta inmediata, pero mediante un callback la respuesta (que puede durar N tiempo) es respondida por medio de otra operación de manera automática:

[Tutorial]:
http://www.mediafire.com/download/4k9us8b743n9shr/Tutorial+Aplicacion+Reliable-+Messaging%2CAddressing%2C+Callback+con+JAXWS+.pdf

[Fuente]:
http://www.mediafire.com/download/ga7m2j2yno8rzny/DumyCallbackServiceWS.zip

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.