hands-460872_640

El pasado jueves 16 salí al aire con mi primer webinar sobre gobierno y patrones de diseño en SOA. Un webinar organizado por CAC-TI de Perú con el que vengo colaborando desde hace un tiempo y tengo que decir que la participación que tuvo me sorprendió muy gratamente (más de 140 inscritos y 70 asistentes a la sesión) que por supuesto se debe al poder de convocatoria que tiene el CAC-TI.
Sobre el contenido del webinar, intento ser muy respetuoso con el tiempo disponible que tiene la gente, y lo primero que asumo es que tengo una responsabilidad por hacer que este tiempo sea provechoso y útil para las asistentes al webinar. Así que espero de verdad que haya valido la pena el contenido del webinar.

Y sobre el continente tengo que decir que debido a mi poca experiencia con la herramienta tuve un pequeño problema con la grabación del video y no he podido publicarlo (os pido disculpas por ello). Aunque sí podeis descargar las slides aquí.

Dentro de unos pocos días, realizaré otro webinar sobre análisis en SOA, y espero que todo salga mejor (cruzaré los dedos).

Dicho esto, algunos de los asistentes me plantearon algunas preguntas muy oportunas e interesantes. He contestado por mail a cada uno de los autores de estas preguntas pero creo que es también intersante si las recojo todas aquí, en el blog.

Por supuesto, considerad este blog como vuestra casa para plantear nuevas preguntas, dar feedback sobre las existentes y en general plantear todos los debates que se os ocurran sobre la arquitectura SOA y la arquitectura TI en general.

Sin más entremos en las preguntas.

Pregunta 1

Una duda el análisis no inicia con la descomposición del proceso de negocio en si. Identificar el tipo de logica que manejan y con el los modelos de servicio propiamente.

Respuesta:
Si es posible, creo que sería deseable empezar con los procesos de negocio de la empresa. Es decir, en cualquier empresa que venda algo tendrá el proceso de “contratación”. Si se quiere automatizar este proceso hay que analizarlo de manera detallada porque seguramente implicará a varias áreas o departamentos de la empresa. Si queremos vender un bien físico tenderemos el control de inventario, el marketing, el pago, la facturación, el envío, servicio post-venta, etc. etc. Sería conveniente empezar desde este nivel e ir descendiendo para “descubrir” los servicios que se corresponden con cada tarea, cada entidad de negocio, etc.
En este descubrimiento, es posible que haya que crear servicios nuevos pero también es muy posible (y más deseable), que ya existan. En este último caso, como analistas, deberemos acudir a la herramienta de registro para buscar estos servicios mediante los criterios de la funcionalidad requerida, tipo de parámetros, etc. etc.
Sin embargo, hay muchos casos en los que no es posible hacer este análisis “cross” a través de toda la empresa analizando el proceso de negocio. En muchas ocasiones, tendremos un proyecto más “local”, es decir, que se ocupa sólo de una de las partes de la cadena, por ejemplo del control del inventario. En este caso, el análisis lo veo más como el análisis orientado a objetos que decía en el webinar, buscando los sustantivos (las entidades de negocio), los verbos (las operaciones o capacidades de los servicios), etc. etc.

Pregunta 2

La nomenclatura que mencionas en lo relacionado al NameSpace normalmente la mayoria lo hace en base a la ruta del paquete .. ejemplo: pe.com.tdp.aaa.bbb.

Respuesta:
Todos los servicios web tipo SOAP pertenecen a un espacio de nombres. Como comentas, se puede indicar en base a la ruta del paquete, o más correctamente dicho, según una URL.
De todas formas, ya sabes que no hay que pensar primero en el paquete “java” u otro lenguaje. Hay que seguir el principio de “contract first”, por lo que lo más apropiado sería decir que el paquete tiene el nombre del espacio de nombres y no al revés 😉

Pregunta 3

Cual es tu opinión con relación a los contratos WADL para REST, se que no son estándar aún, pero ayudan a evitar el acomplamiento entre el servicio consumidor y la implementación. implementación

REST tendria que utilizarse WADL?

Respuesta:
Tengo la sensación de que el WADL no se usa mucho actualmente, y quizás nunca triunfará. Una prueba de esto que estoy diciendo es que las herramientas de API Gateway de los principales proveedores como IBM, CA o Axway, utilizan el formato no estándar Swagger para definir los contratos. No es un estándar oficial pero se está convirtiendo en el verdadero estándar de facto.
La otra forma de especificar los contratos de los servicios REST es simplemente indicando unos cuantos mensajes de entrada/salida. Algo así como “contrato como ejemplo”.

Pregunta 4

Esos servicio CHURRO que mencionas muchos servicios mal diseñados definen los parametros metiendo XML y Tramas separados por | , en 1 parámetro String.

Respuesta:
Exacto. Algunos más elaborados, meten un XML completo en el campo String, por lo que hay que parsearlo después y evidentemente no está declarado en el WSDL del servicio.

Pregunta 5

Cual es tu opinón relacionado al manejar un Registro de Servicios en excel, cuando una empresa recien está implementando SOA en la organización, y posteiormente a un futuro mediano migrar a un Registry Repositorio de algun vendor ó opensource. Ya que en si lo importante es el orden del inventario.

Respuesta:
Lo que digo es precisamente que es mejor tener un inventario en una hoja Excel en una carpeta compartida que no tener nada… y quien dice un Excel dice cualquier herramienta gratuita, por ejemplo, un site hecho con wordpress que tiene buscador, etiquetas, etc. Una excelente opción para tener un inventario potente sin gastar un céntimo.

Pregunta 6

Esto de hacer los servicios con diferentes lenguajes a veces hay problemas con los servicios y aplicaciones .NET ya que al consumir servicios que tienen .xsd embebidos, estos no los reconocen eso por un lado y por otro lado, dependiendo la version de su ,NET soportan una version diferente de SOAP (1.1 ó 1.2).

Respuesta:
Es cierto lo que dices, nosotros también nos hemos encontrado con problemas de este tipo.
Lo primero que hay que establecer es un estándar de interoperabilidad como es el Basic Profile 1.0 o 1.1. De este modo, no importa el lenguaje con el que estén hechos los servicios.

Pregunta 7

Con relación al standar del .WSDL el SOAPUI cuenta con una herramienta llamada: WS-I compliance, que valida el estándar usado y genera un reporte de cumplimiento de dicho estandar. Con el wsdls basados en SOAP 1.1 funciona bien, pero con el SOAP 1.2 encuentra un warning.

Respuesta:
me parece recordar que SOAP 1.2 no está soportado por el WS-I Basic Profile 1.0

Pregunta 8

Cual es tu opinión en un entorno SOA, que algunos servicios desarrollados no sean solo de tipo WebService ó Rest, sino que entre los artefactos que se manejan se usen EJB (Enterprise Java Bean) y MDB (Message-Driven Bean). Se que no es 100% estándar pero muchas empresas lo usan.

Respuesta:
Mi opinión es que la gente abusa de los EJBs. En la mayoría de los casos realmente no hace falta hacerlos. Sólo he encontrado una justificación en estos años para usar un EJB: el manejo de la transaccionalidad distribuida. Pero ahora mismo, incluso el uso de este tipo de transaccionalidad está muy cuestionado (lo he tratado en el blog).

Pregunta 9

El tema de servicios de tipos SCA cual es tu opiníón sobre esos, serían mejor usarlos en un ambiente SOA aplicado a los servicios de composición

Respuesta:
se supone que los servicios SCA son un estándar y son los “ladrillos” con los que se construyen los servicios compuestos… esta era mi impresión hace unos años (puedes ver una entrada al respecto en el blog). Como me ha ocurrido con muchas cosas de las implementaciones de SOA, con el paso de los años me he desengañado de muchos de estos “estándares” y tecnologías.
Ahora mismo prefiero algo mucho más estándar, de verdad, para construir los servicios y el software en general. Por ejemplo, en el Java estaríamos hablado de los objetos POJOs y el framework Spring.

Pregunta 10

En un entorno SOA, como es el manejo de las BD, ya que sé que el modelo de BD relacional, genera problemas… Debido a ellos se maneja mucho lo que son Store Procedures.

Respuesta:

A mi no me gustan nada los procedimientos almacenados, opinio que no es un lenguaje de propósito general e incluso la propia Oracle no los contempla en su arquitectura de referencia. Hoy en día hay muchas soluciones de cacheo y bases de datos en memoria que nos podrían ayudar en esto.
En definitiva, vería un stored procedure como última opción cuando haya que “mover” muchos datos, pero en ningún caso para implementar lógica de negocio.

Pregunta 11

Cual es tu opinión para el manejo de versionamiento .. el uso de un Gestor de Contenidos … y versionar lo que son … solo fuentes (.ZIP), más no ejecutables (.EAR, .WAR ).

Respuesta:

Supongo que estás hablado de un gestor de código fuente ¿no? lo que se conoce como un SCN. No hay que confundir el versionado de los servicios con el versionado del código fuente.
Respondiendo a tu pregunta, lo que he visto mucho es tener un repositorio de código fuente y otro de binarios (separados). Los binarios se crean continuamente a partir del código fuente de una versión en concreto mediante un mecanismo de integración continua.

Pregunta 12

Cual es tu opinión sobre le manejo de validaciones a nivel de .XSD en los .WSDL, aplicarlos de esa manera o mejor manejarlos a nivel de código dentro de la aplicación. Más que todo por el LOG generado para identificar donde es el error respectivamente.

Respuesta:

Creo que lo ideal sería validar a nivel de XSD y de WSDL, es decir, ponerlo en el contrato. Cuantas más validaciones se hagan ahí mejor porque le desarrollador no se tiene que preocupar de esto. Además, hoy en día existen aceleradores, incluso “hardware” como algunos appliances especializados, que se encargan de hacer estas validaciones en runtime.
Si no se tiene un producto de este tipo, quizás sea conveniente de todos modos desactivar las validaciones en el entorno productivo debido al impacto en el performance, pero depende del caso.

Anuncios