Resumen Capítulos 6 y 7

Capítulo 6

Patrones de Inventario 

Enterprise Inventory

La prestación de servicios de forma independiente a través de diferentes equipos de proyecto a través de una empresa establece un riesgo constante de la producción de servicio inconsistente e implementaciones arquitectura, poniendo en peligro las oportunidades de recomposición. Servicios para múltiples soluciones pueden ser diseñadas para la entrega dentro de una arquitectura estandarizada, el inventario de toda la empresa en la que se pueden libremente y en repetidas ocasiones recompuesto. En el impacto se debe tener Análisis inicial significativo es necesario para definir un modelo de inventario de la empresa y el resultado numerosos impactos de la organización de los requisitos de gobierno posteriores.

Domain Inventory

Establecimiento de un inventario de la empresa de servicios solo puede ser difícil de manejar para algunas empresas, y los intentos de hacerlo puede poner en peligro el éxito de la adopción de SOA como un todo. Los servicios se pueden agrupar en los inventarios manejable, el servicio de dominio específico, cada una de ellas puede ser independiente estandarizada, que se rige, y de propiedad. Normalización disparidad entre inventarios de dominio de servicio impone requisitos de transformación y reduce el beneficio general potencial de la adopción de SOA.

Service Normalization

Cuando la prestación de servicios como parte de un inventario de servicios, hay un riesgo constante de que los servicios se creará con la superposición de los límites funcionales, lo que hace difícil para que extendida reutilización. El inventario de servicio debe ser diseñado con un énfasis en la alineación de servicio de frontera. Asegurar que los límites del servicio son y permanecen bien alineadas introduce adicional por adelantado el análisis y el esfuerzo continuo de gobierno.

Logic Centralization

Si los servicios de agnóstico no son siempre reutilizados, funcionalidad redundante se pueden entregar en otros servicios, dando lugar a problemas relacionados con la desnormalización de inventario y la propiedad de servicios y la gobernabilidad. Acceso a la funcionalidad reutilizable se limita a los servicios oficiales agnóstico. Cuestiones de organización que recuerda de los proyectos de reutilización pasado puede aumentar obstáculos a la aplicación de este patrón.

Service Layers

Servicios de manera arbitraria la definición de entrega y se rige por diferentes equipos de proyecto pueden conducir el diseño de la incoherencia y la redundancia funcional involuntaria a través de un inventario de servicios. El inventario se estructura en dos o más capas de servicios lógicos, cada uno de los cuales es responsable de la abstracción lógica basada en un tipo funcional común. Los costes comunes y los impactos asociados con los estándares de diseño y por adelantado el análisis de necesidad de ser aceptado.

Canonical Protocol

Servicios de apoyo a la comunicación diferentes tecnologías de interoperabilidad compromiso, limitar la cantidad de consumidores potenciales, e introducir la necesidad de superar las medidas de protocolo indeseables. La arquitectura establece una única tecnología de las comunicaciones como medio único o principal por el cual los servicios pueden interactuar. Una arquitectura de inventario en el que los protocolos de comunicación estandarizados está sujeta a ninguna limitaciones impuestas por el tecnología de las comunicaciones.

Canonical Schema

Servicios con los modelos dispares de datos similares imponer requisitos de transformación que incrementar el esfuerzo de desarrollo, la complejidad del diseño, y la sobrecarga de rendimiento en tiempo de ejecución. Los modelos de datos para los conjuntos de datos comunes son estandarizados a través de contratos de servicio dentro de un límite de inventario. El mantenimiento de la estandarización de los esquemas de contrato pueda introducir esfuerzos en materia de gobernabilidad y los desafíos culturales.

Capítulo 7

Utility Abstraction

Cuando no comercial centrada en la lógica de procesamiento se empaqueta junto con el negocio específico de la lógica, los resultados de la aplicación redundante de funciones de utilidad común a través de los diferentes servicios. Una capa de servicios dedicada a la transformación de servicios públicos se ha establecido, la prestación de servicios reutilizables de utilidad para el uso de otros servicios en el inventario. Cuando la lógica de servicios públicos se distribuye a través de múltiples servicios que pueden aumentar el tamaño, la complejidad y las demandas de rendimiento de las composiciones.

Entity Abstraction

Agrupación tanto en el proceso independiente del proceso y la lógica específica de la empresa en el mismo servicio con el tiempo da lugar a la creación de lógica de negocio independiente y redundante a través de múltiples servicios. Una empresa independiente del nivel de servicio puede ser establecida, dedicada a los servicios que basan su contexto funcional de las entidades de negocio existentes. El núcleo, centrada en el negocio naturaleza de los servicios introducidos por este modelorequiere de modelado y atención diseño y sus requisitos de gobierno puede imponer cambios radicales en la organización.

Process Abstraction

Agrupación tarea centrada en la lógica con la lógica de trabajo independiente del gobierno dificulta el de la lógica específica de la tarea y la reutilización de la lógica agnóstica. Una empresa dedicada padre proceso de nivel de servicio se estableció para apoyar la independencia de gestión y el posicionamiento de los servicios de trabajo como posibles recursos de la empresa. Además de los modelos y las consideraciones de diseño asociadas a la creación de servicios de trabajo, haciendo abstracción de negocios matriz lógica de proceso establece una dependencia inherente a la realización de que la lógica a través de la composición de otros servicios.

Proceso MecaPlus: Descubrimiento de servicios

A continuación presentamos los entregables de Ecosistema y Portafolio de Servicios para el nuevo proceso MecaPlus.

Para este trabajo se aplicó un enfoque vertical, aplicando el patrón de descubrimiento Top-Down encaminado a Atributos. Esto es porque para expresar nuevo proceso, requerimos realizar seguimiento de los negocios, a nivel de características de los negocios, como entidades, y también capacidades de estos negocios. Los entregables también se basan en ejercicios de creación de un modelo de atribución y un árbol de decisión.

También se practicó el patrón Top-Down encaminado a Procesos de Negocio, para verificar en manejo de repuestos, cómo se realiza este proceso ya existente.

Lista de capacidades del proceso

Portafolio de Servicios

Ecosistema de Servicios

¿Qué patrón aplicamos hoy?

Downward, Top-Down, procesos, atributos, interfaces, productos de legado, etc. Estamos ahí, en una mesa grande, con colegas, escribiendo notas, devorando documentos, referencias, de empresas, departamentos, trabajos de investigación, casos de éxito,en busca de una idea, no de cualquiera, sino de la más, la más factible, la más económica, la que de  más y mejores resultados en poco tiempo, una idea para encontrar capacidades, o cosas que pueda hacer un producto, un sistema, y además que todos en el mundo puedan usar por la Web, tomarla de ahí, cuando la necesiten, ya sea, transferir dinero de Bogotá a Singapur, o una boleta para la gira de U2, o conseguir la maquinaria para ser fabricante de un coche de marca europeo.

El trabajo de Michael Bell, de SOA Modeling Patterns, no es otro trabajo académico, en la oscuridad de una universidad clásica, para estudiosos. No en vano, está en Amazon, tiendas importantes, referenciado en muchas investigaciones importantes, como un gran estudio para modelar, hacer de procesos, los productos deseados por empresas, empresarios, para satisfacer sus necesidades. Me encontré viendo referencias, en busca de complementos, sumarios de las lecturas. El trabajo de Bell es extenso, las lecturas son extensas, y aunque  so una gran guía, se necesita tiempo, y algo más, habilidades, competencias, para diseñar y construir productos de calidad, desde el arte de encontrar servicios, capacidad, lo que puede disponer un sistema para el resto del mundo.

En mi caso, no he trabajado con Unisys, o Amazon, menos con Oracle, EC2, y reconozco que no sé de Web Services más que escribir uno y arrancarlo en un servidor casero. Por eso, tal vez, puedo hacerme a la idea, o ideas generales, del propósito de cada enfoque, modelo, o patrón dado el caso. Puedo hacer las asociaciones siguientes: Enfoque vertical para ir al corazón y los detalles de los procesos para encontrar servicios. Modelo Top-Down para a partir del nivel macro, las imperaciones y los proceso de negocio, encontrar los servicios simples. Patrón Encaminado a Procesos de Negocio, para investigar y conocer íntimamente los proceso que ya existen, Patrón Encaminado a Atributos para hallar las características de los procesos en general, Front-2-Back para procesos nuevos de monitoreo y manejo de información en tiempo real, Back-2-Front para procesos de informes gerenciales y analítica visual, Patrón Bottom-Up para servicios desde sistemas de legado, etc.; y desde ahí, ser curioso, saber cómo más aplicar los patrones, aplicarlos a VehiAlpes, y a los negocios de ejemplo.

Pues, tal vez sea una idea general, fácil, con más experiencia se puede advertir más aplicaciones de los patrones, cómo aplicarlos hábilmente, etc. Pero sí hay una idea, una sensación, que vale la pena adquirir, con o sin experiencia, y es cómo aplica, a diseñar soluciones, más allá de la parte técnica, o pragmática, rgeresando alas primeras sesiones del curso de Patrones, y es la de conseguir soluciones, acercándose a la estética, la elegancia, productos, que más que servir, funcionar, trasmitan sensaciones de gusto, comfort, placer, al hacer uso de ellas. Esto lo consigue SOA, a través de su filosofía, sus principios de bajo acoplamiento, reutilización de servicios, y sus patrones de descubrimiento de servicios; de forma que el diseñar, descubrir servicios, sea más que estar en la mesa, devorando documentos, sea un momento de crear, hacerlo con inspiración, abstraerse en la forma, las cualidades. Por eso también, más que saber los enfoques, o patrones para encontrar servicios, se necesita también cierto toque, cierto desenvolvimiento para decir, esto que ocurre en el proceso, lo puedo hacer una capacidad de este servicio.

En este trabajo vale la pena también echar un ojo a la introducción del libro, el sentido de éste, más allá de la descripción formal de los patrones. También, como complemento, practicar Web Services, verlos, como ir a la excursión, o a la fábrica, y ser curioso de cómo encontrar eso que vemos funcionar en el computador. Para el caso de VehiAlpes, en mi caso, aplicaría hoy Top-Down encaminado a atributos, y algo de Bottom-Up, para nuestro enfoque de poderes

Diseño de patrones de integración

Tecnología a utilizar

La herramienta de Mule nos parecio el mejor softwate para el manejo de la mensajería, ya que es un excelente gestor de objetos escalable y distribuible que puede manejar interacciones con servicios y aplicaciones que usan distintas tecnologías de transporte y mensajes.

Además que Mule es un framework muy liviano y fácilmente de embeber en aplicaciones Java, y se puede integrar con frameworks como spring, hivemind y plexus y soporta muchos componentes de transporte y servicio como JMS, SOAP, JBI, BPEL, EJB, AS/400, HTTP, JDBC, TCP, UDP, SMTP, FILE, FTP y más. Adicionalmente una extensión beta de Mule es Mule estudio, la cual facilita aún más la implementación grafica de la aplicación con respecto a la mensajería, pero fundamentalmente Mule es una herramienta que posee un gran soporte ya que es la herramienta más utilizada de integración en el mercado, lo que permite una mejor retroalimentación de la comunidad a la hora de solucionar problemas.

Solicitud servicio grúas

Patrones SOA implantados

Comunicación Asincrónica

“Un servicio puede requerir que los consumidores se comunican con él de forma asíncrona y proporcionar una dirección de devolución de llamada para que el servicio pueda enviar mensajes de respuesta.”

Este patrón se utiliza al solicitar el servicio de grúa, a un conjuntos de aplicaciones diferentes de grúas que atienden solicitudes ya sea de manera asincrónica, ya que necesitan procesar primero  las solicitudes en Batch y luego si dar una respuesta.

Transformación del formato de la información.

“Intermediario formato de datos lógica de transformación debe ser introducido con el fin de convertir dinámicamente un formato de datos a otro.”

Para poder comunicarse con las aplicaciones de las grúas se debe hacer una transformación de la información y/o de los datos para que dependiendo de la aplicación de la grúas, esta pueda procesar la información de manera adecuada

Diseño completo de solicitud 

Patrón BPM Reclamación

Ilustración

Borrador

Motivación

Cubrir de manera formal y única le proceso de reclamos y devolución de productos o servicios.


Problema

El proceso de reclamos y devolución se aplica en las compañías para cada caso, de manera particular, sujeto a reglas, directrices e intereses por parte de la compañía que maneja este proceso. Por tanto, al realizar modelado de procesos, nos encontramos con que este proceso debe modelarse de manera particular, rehaciendo nuevamente subprocesos, tareas y elemento gráficos que pueden ser innecesarios.


Solución

Se propone para este proceso un patrón de modelado que cubre los elementos "estándar" en el proceso, bajo la perspectiva también de un proceso formal, ordenado, aplicable a cualquier entorno. En éste, entran en escena 4 actores que son: Cliente, Vendedor, Proveedor y Contratista. Y se manejan los casos de reparación y devolución del producto adquirido que desea ser reclamado por garantía.

Un ESB, muchos buses.

Basado en el libro, donde se dice que el mejor esquema de integración es aquel basado en mensajería, o al menos es el que mas problemas puede resolver, puedo decir desde mi experiencia personal que es completamente cierto.
Es cierto que cada problema es diferente y en cada situación, las necesidades de integración pueden atacarse de maneras distintas dependiento de la naturaleza del problema, con un esquema basado en mensajería se resuelven la mayoría de los retos que se plantean en una necesidad de integración.
Hoy en día las herramientas para proveer este tiopo de soluciones. Por necesidades laborales, llevo algún tiempo trabajando con la suite de herramientas de IBM y quiero compartir mi experiencia sobre ello.
IBM cuenta principalmente con 3 productos que actuan como ESB.

WebSphere ESB el cual es totalmente basado en tecnología Java y esta soportodado (dependiente) en el servidor de aplicacion WAS. Esta es quizas la mejor opción cuando se trata de integrar aplicaciones escritas en el mismo lenguaje(java) y que su esquema de su formato de mensajería este basado en estandares SOAP, WS, XML, y tecnologías relacionadas.

WebSphere Message Broker Es el mas apropiado cuando se trata de integrar aplicaciones en tecnologias heterogéneas. Tiene muchas facilidades para convertir mensajes de un formato a otro y convertir tambien protocolos heterogeneos. Es el apropiado para implementar patrones de integración complejos.

WebSphere DataPower Es el mas poderoso en cuanto a desempeño se trata. WebSphere DP es un appliance (Hardware) donde se pueden definir transformaciones de XML y tambien conversión de protocolos de comunicación. Dado su alto poder de procesamiento es el preferido cuando se requiere minimizar la latencia adicionando una capa de integración. En general es recomendable implementar patrones simples en esta tecnología.

Por fortuna, he tenido la oportunidad de trabajar con las 3 herramientas y es importante saber escoger cual usar en cada momento.
Espero sea de ayuda la información aca expuesta.

BPMN 2.0 = Holy Grail?

El libro BPMN 2.0 de Thomas Allweyer, provee de una concienzuda exploración al estándar BPMN 2.0, su semántica y aplicación en el diseño de procesos de negocio. Luego de la lectura de sus capítulos me quedo una impresión general del poder expresivo de la notación y su semántica. Así mismo, los comentarios de diseño del autor, son en mi opinión enriquecedores, particularmente en lo que respecta a los problemas a los que uno se enfrentara un diseñador durante su uso. Luego de la lectura me inquietaron algunos puntos respecto a BPMN 2.0.

En primera medida, creo que la notación ofrece un lenguaje visual altamente rico, pero a su vez complejo. En este sentido me cuestiono si al modelar un proceso típico, es empleado todo el abanico de elementos que este ofrece. Por otro lado, un mayor número de elementos de la notación puede finalmente entrar en conflicto con una de sus filosofías, el ser lingua franca para la representación de modelos de negocio. Creo que BPMN 2.0 puede ser de difícil acceso (y comprensión) para el público en general -si uno peca por ser muy detallista en sus modelos, lo cual puede ser muy probable. Lo anterior representa una debilidad en mi opinión, pues toda la responsabilidad en este sentido recae sobre el modelador, pues BPMN 2.0 aporta poco en términos de restricciones sobre el modelaje los procesos de negocio.

Ahora con respecto a los modelos ejecutables, la semántica de BPMN 2.0 y su potencial expresivo, sin duda es muy alto, pero considero que las notaciones simplificadas como los eventos de inicio y final, así como los gateways implícitos, hacen más complejo entender el detalle del comportamiento de un proceso, pensado para ejecución. En este sentido, entiendo el ánimo de BPMN 2.0 de ofrecer expresiones que son visualmente más simples (y accesibles para quienes es presentado el proceso), pero en mi opinión pueden terminar confundiendo a quien tiene interés en el detalle del proceso y su consistencia.

Patrones de Integración

Integración en Aplicaciones (Bernarnd y Laurent)

El libro ilustra y es escrito de manera clara asumiendo un conocimiento inicial básico. Es un libro muy completo, que va más allá de patrones de integración presentando al lector una amplia gama de temas y de comparaciones entre los diferentes estilos, también se proporciona conocimiento y propone  formas de uso de la mensajería para solucionar diferentes problemas de manera efectiva, y proporciona una manera clara por medio de pasos para poder tener éxito en la implantación de las técnicas de integración. Me gusta especialmente la forma en que Bernard y Laurent diseña cada modelo usando el lenguaje y los estilos visuales para delimitar las secciones de forma natural del patrón, esto aumenta significativamente la legibilidad y el entendimiento de la idea de integración.

El libro es muy independiente de la tecnología, ya que se enfoca más hacia la generalización de la idea, ilustrando las ideas de los patrones y maneras de integración sin tener que ligarse con una tecnología o herramienta, lo que permite una generalización del conocimiento para poder aplicarlo a cualquier tecnología si ésta lo permite.

El problema por menor que le vi al libro es que eran muy largos sus capítulos,  lo que hacía que me perdiera el hilo, pero en general el lenguaje utilizado era bastante entendible, lo que si puede mejorase es  en ser más concreto y resaltar las características más importantes, ya que se pueden quedar en medio de las frase históricas, preguntas, etc.