Servicio de Refactoring

Problema

Después de su primera entrega, el rendimiento de imprevistos y los requisitos empresariales pueden demandar más de un servicio de lo que es capaz de proporcionar. Reemplazar el servicio completo puede no ser deseable, especialmente cuando varios programas tienen alrededor dependencias ya establecidas en su contrato de servicios establecidos.

Solución

Refactoring de software es una práctica de ingeniería de software por la cual el software existente puede ser mejorado gradualmente sin afectar la forma en que se

se comporta. Cuando se aplica al diseño de servicios, este enfoque ofrece más oportunidades para los servicios para evolucionar dentro de una organización sin interrumpir a sus consumidores existentes. Con la aplicación de este modelo la lógica y la aplicación de un servicio puede ser optimizado con regularidad, mejora, o incluso mejorado, mientras que se conserva el contrato de servicio.

Aplicación

La práctica de software Refactoring permitir que los programas se mejoren a través de una serie de pequeñas mejoras que se siguen para preservar sus interfaces y comportamiento en general. Al limitar el ámbito de aplicación de estas mejoras, el riesgo asociado a un impacto negativo en los consumidores se minimiza.

Impacto

El Refactoring de la lógica de servicio existente o de la tecnología introduce la necesidad que el servicio que experimenta cambios de diseño, remodelación, y los ciclos de repetición de pruebas a fin de asegurar que la actual

garantía expresadas en el contrato de servicios (que incluye SOA) puede seguir siendo cumplido como se esperaba.

Relaciones

La medida en que se puede aplicar el servicio de Refactoring depende de cómo el servicio en sí mismo fue diseñado en primer lugar. Es por eso que existe una relación directa entre este modelo y el Servicio Normalización.

La abstracción y la independencia obtenida por la aplicación exitosa de los patrones permite que los servicios de forma individual gobernado y evolucionado con el mínimo impacto los programas de los consumidor

Patrones de composición de capacidades

Estos patrones establecen posibles mecanismos que permitan ensamblar y/o componer la lógica de servicio debidamente estructurada a través del uso de los patrones de identificación y definición de servicios.

A continuación, se enuncian los 2 patrones representativos de composición:

1. Composición de capacidades: Cuando se requiere ofrecer una capacidad que requiere del uso de lógica que procede de otro contexto funcional, se crea un servicio capaz de invocar una o más capacidades que son ofrecidas por otros servicios para suplir la necesidad.

Las ventajas que ofrece es la reutilización de servicios en diferentes contextos, aparte de la reducción de esfuerzos de programación. El principal inconveniente es la pérdida de autonomía del servicio (pues requiere de la disponibilidad de otros servicios), seguido de la sobrecarga del sistema (al tener que usar invocación externa).

2. Recomposición de capacidades: El objetivo principal es maximizar el reuso de servicios independientes para estructurar la solución de diferentes problemas de negocio. Esto es posible a través del establecimiento de capacidades genéricas de servicio, las cuales se satisfacen mediante la invocación secuencial de un conjunto limitado de servicios.

Notificación de terminación

Problema

Como los servicios evolucionan con el tiempo, las diversas condiciones y circunstancias que pueden conducir a la necesidad de retirar un contrato de servicios, una parte de un contrato de servicio, o la totalidad del servicio en sí.

En las empresas de TI más grandes especialmente al hacer los servicios accesibles a las organizaciones externas asociadas, puede ser difícil de comunicar a los consumer owners en espera de la terminación de un servicio o cualquier parte de su contrato de manera oportuna.

Falta de reconocimiento de un retiro previsto conducirá inevitablemente a situaciones de error en tiempo de ejecución, donde los programas de los consumidores desconocen que tratan de invocar el servicio y son rechazados.

Solución

Los contratos de servicio están equipados con detalles de terminación, permitiendo a los consumidores estar al corriente del retiro anticipado del contrato

Aplicación

Este patrón es comúnmente aplicado para complementar el contenido del contrato técnico con anotaciones legibles que simplemente proporcionar la fecha de terminación. Sin embargo, para los Contratos de servicios web, también existe la opción de aprovechar el lenguaje WS-Policy para expresar las notificaciones de terminación a través de las afirmaciones de la política ignorable.

Impacto

Todas las técnicas explicadas requieren el uso de extensión no-estándar de contenido de los contratos de servicio. Esto se debe a que no existe un estándar de la industria para expresar la información de finalización. Notificación de la terminación depende de la existencia y la aplicación exitosa de los estándares de gobierno y por lo tanto tiene una dependencia directa en versiones canónicas

Relaciones

Tanto el cambio Compatible y Capacidad de Proxy pueden conducir la necesidad de la notificación de terminación.

Algunos patrones SOA

PROXY CAPABILITY
Cómo puede un servicio sujeto a la descomposición, continuar soportando a los clientes afectados por la descomposición?
PROBLEMA.
Si un servicio establecido necesita ser descompuesto en múltiples servicios, su contrato y sus clientes existentes pueden ser impactados.
SOLUCION
El contrato del servicio original se preserva, incluso si la capacidad lógica es separada al volver la capacidad establecida un proxy.
APLICACIÓN
Las lógicas de fachada necesitan ser introducidas para redirigir las peticiones y respuestas entre el proxy y las nuevas capacidades localizadas.
IMPACTO
La solución practica proporcionada por este patrón resulta en la medida de la des normalización del servicio.
PRINCIPIO
Service Loose Coupling
ARQUITECTURA
Servicio.


CAPACIDAD DESCOMPUESTA
Cómo puede un servicio ser asignado para minimizar las posibilidades de desconstrucción de capacidades lógicas?
PROBLEMA
La descomposición de un servicio para con su implementación puede requerir la descomposición de la lógica en sus capacidades, las cuales pueden ser disruptivas y hacer que la preservación del contrato del servicio sea problemática.
SOLUCION
Los servicios con tendencia a la descomposición futura pueden ser equipados con una serie de capacidades granulares que pueden hacer mas fácil la descomposición.
APLICACIÓN
Servicios adicionales de modelado son llevados a utilizados para la definición granular, haciendo posible la capacidades distribuidas.
IMPACTO
Hasta que el servicio ha sido eventualmente descompuesto, puede ser presentado por un contrato extremamente cargado que permanece con el siempre y cuando las capacidades del proxy sean soportadas.
PRINCIPIOS
Contratos de servicio estandarizados, Abstracción de servicios.
ARUITECTURA
Servicios.


CAPACIDADES DISTRIBUIDAS
Cómo puede un servicio preservar su contexto funcional mientras también cumple con capacidades de procesamiento de requerimientos especiales?
PROBLEMA
Una capacidad que pertenece a la zona interna de un servicio puede requerir requerimientos de procesamiento únicos que no pueden ser acomodados por él la implementación por defecto del servicio, pero separando la capacidad lógica del servicio comprometerá la integridad del contexto del servicio.
SOLUCION
La lógica que está por debajo del servicio está distribuida, por tanto esto permite que la implementación lógica de una capacidad con requerimientos especiales de procesamiento pueda estar separada físicamente, mientras sigue siendo representada por el mismo contrato de servicio.
APLICACIÓN
Se mueve la lógica y se añade el proceso intermedio para actuar en llave ente la lógica que se ha movido y la lógica principal del servicio.
IMPACTO
La distribución de la lógica de las capacidades conlleva a una saturación del rendimiento asociado con la comunicación remota y la necesidad para un nuevo proceso intermedio.
PRINCIPIOS
Servicios de contrato estandarizados. Autonomía de Servicios.

Patrón de Identificación de Versión

Este patrón hace referencia a la forma en que los consumidores pueden estar notificados de las actualizaciones de versión del contrato de servicio.


Problema

Si un contrato, que por lo general ya ha sido publicado, está sujeto a la compatibilidad o a cambios incompatibles, cualquier modificación a su contenido, justifica una nueva versión del contrato. Sin un medio de asociación entre versiones que han generado cambios que afectan la compatibilidad entre un servicio y sus consumidores actuales y nuevos, se genera un riesgo permanente, dado que el servicio se vuelve menos detectable a los diseñadores de los consumidores, de modo que el diseño del servicio incrementa la dificultad para su gobernabilidad y evolución.

Solución

El contrato de servicio puede ser diseñado para expresar los identificadores de versión, que permite al consumidor determinar con seguridad si se trata de una versión compatible con el servicio. El uso de los identificadores de versión apoya aún más, la simultaneidad de contratos a fin de manejar el control de versiones, lo que permite a un consumidor elegir el contrato correcto, basado en su versión expresa.

Aplicación

Las versiones se suelen identificar de forma numérica, a través de valores que se incorporan al contrato de servicio, ya sea como anotaciones legibles o como una extensión efectiva de la operación técnica de contenido. La versión más común es a través del formato numérico con decimal, donde el primer dígito representa el número de versión principal, y los dígitos siguientes al punto decimal representan menores números de versión.

El significado de los números de versión realmente depende de los convenios celebrados por una estrategia global de versiones. A continuación se relacionan dos enfoques comunes:

• La cantidad de trabajo: Los números de versión mayor y menor se utilizan para indicar la cantidad de esfuerzo requerido en cada cambio. El incremento de un número mayor representa una cantidad importante de trabajo, mientras que el menor aumento de los números de versión representan mejoras de menor importancia.

• Garantía de compatibilidad: Números de versión mayor y menor se utilizan para expresar compatibilidad. El sistema más común se basa en que un aumento en el número de versión principal se traducirá en un contrato que no es compatible con versiones anteriores, mientras que los incrementos en el número de versión menor son compatibles con versiones anteriores. Como resultado de ello, no se espera que los incrementos de versión secundaria afecten a los consumidores existentes.

Se debe tener en cuenta que estos dos sistemas de identificación pueden ser combinados de manera que el número de versión incremental continúe indicando los cambios compatibles o incompatibles, al tiempo que representa la cantidad de trabajo que entró en los cambios.

Impacto

Los sistemas de identificación de versión y las convenciones suelen ser específicos para un inventario de servicios determinado y por lo general parte de una estrategia de versiones estandarizadas, según versiones canónicas. Como resultado, ellos no están estandarizados a nivel de la industria y por lo tanto, cuando se expresadan como parte del contrato técnico, imponen la necesidad constante de diseñar el servicio para que los consumidores puedan comprender el significado de los identificadores de versión y la programación de quienes consumen, según se requiera.

Cuando los servicios están expuestos a nuevos consumidores o a nivel externo, aplican los mismos requisitos, pero la aplicación necesaria de las normas puede ser más difícil de lograr.

Relaciones

Este patrón se aplica comúnmente como resultado del manejo de Versiones canónicas, y contempla una parte esencial en el proceso de generar un Cambio Compatible. La identificación de la versión hace referencia principalmente a otros modelos de contrato de control de versiones.

Patrón de Cambio Compatible

Este patrón hace referencia a la forma de modificar un contrato de servicio sin impactar a los consumidores.

Problema

Después de la implementación inicial de un servicio que hace parte de un inventario de servicio activo, sus capacidades estarán disponibles como un recurso de empresa. Por lo tanto, los consumidores estarán habilitados para invocar e interactuar con el servicio a través de su contrato con el fin de aprovechar sus capacidades a través de su consumo.

Como resultado, se genera dependencia de forma natural, entre el contrato de servicio y los programas para el consumidor. Si se requiere efectuar modificaciones al contrato, el cambio puede generar el riesgo de afectar a los consumidores existentes que fueron diseñados de acuerdo con un modelo original.

Solución

Siempre que sea posible, los cambios a los contratos de servicios establecidos deben asegurar la compatibilidad con las versiones anteriores de los contratos y con los consumidores actuales. Esto permite que el contrato de servicio pueda evolucionar de acuerdo con las necesidades, evitando el impacto negativo en las composiciones y dependencias de los programas para el consumidor.

Aplicación

Hay una variedad de técnicas mediante las cuales se puede aplicar este modelo, en función de la naturaleza del cambio requerido en el contrato. El propósito fundamental de este modelo es evitar tener que imponer cambios incompatibles de un contrato de servicios con las versiones anteriores, de las que dependen sus consumidores.

A continuación se mencionan los cambios que en general se requieren para los contratos de servicios Web y que pueden requerir compatibilidad con versiones anteriores:

• Adición de una nueva operación para una definición de WSDL
• Cambiar el nombre de una operación existente
• Extracción de una operación existente
• Cambio del MEP de una operación existente
• Adición de un mensaje de error a una operación ya existente
• Adición de un Nuevo tipo de puerto
• Adición de un elemento de mensaje nuevo esquema o atributos
• Eliminación de un elemento de mensaje de esquemas existentes o atributo
• La modificación de la restricción de un esquema de mensaje
• Adición de una nueva política
• Adición de afirmaciones políticas
• Adición de afirmaciones ignorable Política

Impacto

Cada vez que un contrato de servicio ya publicado cambia de versión, se requiere un esfuerzo adicional, para asegurar que el cambio se representa como una nueva versión del contrato, que ha sido debidamente expresado y comunicado a los consumidores actuales y futuros.

Este patrón puede eventualmente transformarse en contratos robustos que son más difíciles de mantener. Además, estas técnicas a menudo conducen a la necesidad de una notificación de terminación, lo que puede aumentar tanto el contenido del contrato y mayor trabajo para el gobierno del servicio.

Relaciones

Para aplicar este patrón consistentemente a través de múltiples servicios, se requiere la presencia de un sistema de versiones oficiales, que esté muy bien estandarizado de acuerdo con las versiones canónicas. Adicionalmente, este modelo depende de la identificación de la versión, con el fin de asegurar que los cambios estén bien expresados y podrán exigir la notificación de terminación para una transición de contenido del contrato, informando a los consumidores de las nuevas versiones.

Ecosistema de servicios planeados y diagrama proceso bpel montado versión inicial

A continuación se provee el link con el archivo excel que contiene la especificación de servicios que se tienen planeados para implementar el proceso que hace uso del patrón propuesto. Se recomienda descargar el archivo en vez de usar el visor integrado, ya que en el visor no aparecen todas las columnas.

Vínculo archivo de ecosistema de servicios

A continuación se muestra el diagrama BPEL inicial del proceso que aplica el patrón propuesto, ya aplicado en el caso de VehiAlpes. En este caso, el proceso funciona para recibir inserciones/actualizaciones de clientes que compran un vehículo o que van a recibir servicios de mantenimiento provenientes de un taller.
Se muestran algunos de los servicios web definidos que se tienen que invocar (estan presentes todos los relacionados con el manejo de Clientes).

MODELADO ORIENTADO A SERVICIOS

Un modelo de diseño de software no hace referencia solamente a la definición clara de un direccionamiento que permita identificar la solución a los requerimientos actuales de una organización. Este modelo debe abarcar requerimientos de negocio, ambientes tecnológicos y estrategias de negocio, que pueden ser concebidas como premisas no negociables, de modo que el modelo pueda ofrecer herramientas y mecanismos que permitan establecer comunicación entre los servicios y sus correspondientes consumidores, generando un ecosistema correctamente coordinado.

Modelo General de Diseño Lógico Orientado a Servicio

Es el modelo enfocado en resolver un problema que se presenta en la organización. Utilizando para ello una estrategia y una ruta de acción que provee perspectivas que permiten visualizar los diferentes aspectos concernientes a la solución propuesta, ofreciendo artefactos tangibles para una implementación orientada a servicio.

Relación de Diseño Lógico Orientado a Servicio

Las relaciones con consumidores y servicios son influenciados principalmente, por requerimientos tecnológicos y de negocio que implican interacción de colaboración e intercambio de mensajes.

Conceptos que aportan a la estrategia de relación del diseño lógico orientado a servicios:

1. Aislamiento del servicio
2. Conocimiento compartido
3. Propagación del mensaje
4. Mensaje de autorización y autenticación
5. Contrato de servicio
6. Intermediarios y mediación.

MÉTODOS DE RELACIONES DE DISEÑO

Relación de Diseño Público: Este tipo de relaciones se establecen en el momento en el que la participación de los consumidores de intercambio de mensajes y los servicios se comunican directamentesin intermediarios.

Relación de Diseño Implícito: Se forma cuando un servicio o un consumidor no se comunica directamente con su grupo de intercambio de mensajes. El mensaje puede ser enrutado y tomar una vía indirecta, para ser manipulado por otra red o broker.

Relación de Diseño de Contención Aislado: Son usados para proveer protección para servicios internos a través de su aislamiento de consumidores remotos o servicios externos.

Relación de Diseño Interno: Los mensajes pueden ser intercambiados entre miembros internos o a través de estructuras agregadas. Esta relación de diseño se genera de forma interna debido a la comunicación dinámica interna entre los servicios contenidos que permiten interacción privada y estructuras agregadas.

Estructura de Composición de Diseño Lógico Orientado a Servicio
La composición de diseño lógico orientado a servicio es un paquete de software que, generalmente es modelado por patrones predefinidos.

• Elementos de la composición de diseño orientada a servicios: Bloques de construcción, Elementos de Soporte y estrategias de diseño.




• Estilos de Composición de Diseño orientado a Servicios: Estilo de composición de diseño circular, Estilo de Composición Jerárquico, Estilo de composición de diseño de Red, Estilo de composición de Diseño estrella.




• Estrategias de Composición de Diseño Lógico: Estrategia de Reusabilidad, Estrategia de distribución de servicio y pérdida de acomplamiento, Estrategia de alineamiento de granularidad de diseño lógico y Estrategia de Interoperabilidad de Diseño Lógico.

  
  

Patrones SOA

Para la construcción de aplicaciones orientadas a servicios que utilizan Arquitecturas SOA, se han desarrollado patrones clasificados bajo las siguientes categorías:

Los patrones fundamentales de inventario

Inventario de la empresa (ERL)
Cómo puede la exposición de los servicios maximizar recomposición dentro de la organización.

Inventario de dominio (ERL)
Cómo puede la exposición de los servicios maximizar la recomposición en toda la empresa cuando no es posible la normalización.

Servicio de Normalización (ERL)
Cómo puede un inventario de servicios evitar la lógica de servicio redundante.

Lógica de centralización (ERL)
Cómo evitar el mal uso de la lógica de servicio redundante.

Servicio de Capas (ERL)
Cómo crear un inventario de servicios, organizado sobre la base de similitud funcional

Canónica Protocolo (ERL)
Cómo evitar protocolo puente mediante los servicios.

Canónica de esquema (ERL)
Cómo evitar la transformación de los datos del modelo mediante los servicios.


Patrones de la capa de lógica de inventario

Utilidad de la abstracción (ERL)
Cómo unificar los conceptos de negocio comunes y la lógica de negocio centralizada que debe funcionar de forma separada, debe ser reutilizable, y debe regirse de forma independiente.

Entidad de abstracción (ERL)
Cómo puede la lógica de negocio independiente ser dividida, reutilizable, y regirse de forma independiente.

Proceso de abstracción (ERL)
Cómo puede la lógica de los procesos agnósticos ser separada y gobernada de forma independiente.


Patrones de inventario de centralización

Proceso de centralización (ERL)
Cómo se puede gobernar de forma centralizada la lógica de procesos abstraida.

Esquema de centralización (ERL)
Cómo diseñar contratos para evitar la representación redundante de los datos.

La centralización política (ERL)
Cómo se pueden normalizar las políticas y ser aplicadas consistentemente a través de múltiples servicios.

Reglas de centralización (ERL)
Cómo se pueden abstraer las reglas de negocio para ser regidas de forma centralizada.


Patrones de inventario de la aplicación

Protocolos Dual (ERL)
Cómo puede un inventario de servicios superar las limitaciones de su protocolo canónico sin dejar de ser estandarizadas.

Recursos canónicos (ERL)
Cómo se puede evitar la disparidad de recursos innecesarios de infraestructura.

Estado del repositorio (ERL)
Cómo pueden los datos de estado de servicio ser persistidos por periodos, sin consumir recursos de servicio en tiempo de ejecución.

De estado de Servicios (ERL)
Cómo se pueden conservar los datos del estado del servicio y ser manejados sin consumo de recursos en tiempo de ejecución.

Grid Service (Chappell)
Cómo se puede aplazar los datos del estado de servicio para permitir escalar y mantenerse tolerante a fallos.

Inventario de puntos finales (ERL)
Cómo puede un inventario de servicios estar protegido contra el acceso externo y a la vez ofrecer capacidades de servicio a los consumidores externos.

Utilidad de capas de Dominio Cruzado (ERL)
Cómo puede la lógica de utilidad redundante evitarse a través de los inventarios de servicio de dominio.


Patrones de inventario de Gobierno

La expresión canónica (ERL)
Cómo pueden los contratos de servicios permitir la comprensión e interpretación de manera consistente.

La centralización de metadatos (ERL)
Cómo pueden los servicios de metadatos ser centralizdos y gobernados de manera pública.

Versiones canónicas (ERL)
Cómo pueden los contratos de servicio dentro del mismo inventario de servicio ser versionados con un impacto mínimo.


Los patrones fundamentales de servicio

Descomposición Funcional (ERL)
Cómo puede un problema empresarial de orden mayor, ser resuelto sin tener que crear un órgano independiente de la lógica de la solución.

Servicio de encapsulación (ERL)
Cómo puede la lógica de solución estar disponible, como un recurso de la empresa.

Agnóstico de contexto (ERL)
Cómo puede la lógica de servicios múltiples posicionarse como un recurso eficaz de la empresa.

No agnóstico Contexto (ERL)
Cómo puede una sola función lógica de servicio posicionarse como un recurso eficaz de la empresa.

Agnóstico Capacidad (ERL)
Cómo generar la lógica de múltiples servicios de forma efectiva consumible y compuesta.


Servicio de patrones de implementación

Servicio de Fachada (ERL)
Cómo puede un servicio adaptarse a los cambios de su contrato, al tiempo que permite la ejecución del servicio básico y la lógica para evolucionar de forma independiente.

Implementación redundante (ERL)
Cómo incremetar la fiabilidad y la disponibilidad de un servicio.

Servicio de replicación de datos (ERL)
Cómo puede ser preservada la autonomía de servicios, cuando los servicios necesitan tener acceso a orígenes de datos compartidos.

El aplazamiento parcial del Estado (ERL)
Cómo pueden los servicios ser diseñados para optimizar el consumo de recursos mientras que aún permanecen con estado.

La validación parcial (Orchard, Riley)
Cómo evitar hacer validación innecesaria de datos.

Mediador de interfaz de usuario (Utschig, Maier, Trops, Normann, Winterberg)

Cómo puede una solución orientada a servicios proveer una constante e interactiva experiencia de usuario.


Servicio de los patrones de seguridad

Excepción de blindaje (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio evitar la divulgación de información sobre su implementación interna, cuando se produce una excepción.

Detección de mensajes (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio ser protegido de una entrada incorrecta o malintencionada.

Subsistema de confianza (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un consumidor impedir que un servicio sea aludido y evitar el acceso directo a sus recursos.

Servicio de Guardia del perímetro (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo pueden los servicios que se ejecutan en una red privada estar disponibles a consumidores externos sin exposición externa de recursos.


Servicio de Patrones de Diseño Contrato

Contrato de centralización (ERL)
Cómo se puede evitar el acoplamiento del consumidor para la implementación.

Contrato de desnormalización (ERL)
Cómo puede facilitar un contrato de servicio a los consumidores con programas que tienen diferentes requerimientos de intercambio de datos.

Los contratos simultáneos (ERL)
Cómo puede facilitar un servicio multi-consumidor los requisitos de acoplamiento y referirse a la abstracción, al mismo tiempo.

Contrato desacoplado (ERL)
Cómo puede un servicio expreso tener capacidades independientemente de su aplicación.

Validación de la abstracción (ERL)
Cómo pueden ser los contratos de servicios diseñados para adaptarse más fácilmente a cambios de validación lógica.

Patrones de herencia de encapsulación

Legado Wrapper (Erl, Roy)
Cómo los servicios de envoltura con contratos atípicos pueden prevenir la propagación indirecta del consumidor a la aplicación de acoplamiento.

Multi-canal de punto final (Roy)
Cómo puede ser centralizada y consolidada la lógica fragmentada legada y duplicada para la entrega de diferentes canales.

Archivo Gateway (Roy)
Cómo puede la lógica del servicio interactuar con otros sistemas que sólo pueden compartir la información mediante el intercambio de archivos.


Servicio de Patrones de Gobierno

Cambiar compatible (Orchard, Riley)
Cómo puede un contrato de servicio efectuar modificaciones sin afectar a los consumidores.

Identificación de la versión (Orchard, Riely)
Cómo pueden los consumidores estar al tanto de la versión del contrato de servicio de información.

Terminación Notificación (Orchard, Riley)
Cómo puede ser comunidado a los programas consumidores, el vencimiento de un contrato de servicio.

Servicio de refactorización (ERL)
Cómo se puede desarrollar un servicio sin afectar a los consumidores ya existentes.

Servicio de descomposición (ERL)
Cómo puede la granularidad de un servicio ser incrementada con posterioridad a su ejecución.

Proxy Capacidad (ERL)
Cómo puede un servicio sujeto a la descomposición continuar apoyando a los consumidores afectados por la descomposición.

Capacidad de descomposición (ERL)
Cómo puede un servicio de ser diseñado para minimizar las posibilidades de capacidad de descomposición lógica.

Capacidad distribuida (ERL)
Cómo puede un servicio preservar su contexto funcional al mismo tiempo que cumple requerimientos especiales de capacidad de procesamiento.


Patrones de la capacidad de Composición

Capacidad de Composición (ERL)
Cómo puede la capacidad de servicio resolver un problema que requiere la lógica fuera de los límites del servicio.

Capacidad de recomposición (ERL)
Cómo puede la misma capacidad ser utilizada para ayudar a resolver múltiples problemas.

Servicio de mensajería Patrones

Servicio de mensajería (ERL)
Cómo pueden los servicios interoperar sin formar conexiones persistentes, estrechamente unidas.

Mensajería de metadatos (ERL)
Cómo pueden los servicios ser diseñados para procesar los datos específicos de la actividad en tiempo de ejecución.

El servicio del Agente (ERL)
Cómo puede la lógica event-driven ser separada y gobernada de forma independiente.

Enrutamiento intermedio (Little, Rischbeck, Simon)
Cómo pueden los factores dinámicos en tiempo de ejecución afectar la ruta de un mensaje.

Estado de mensajería (Karmarkar)
Cómo puede un servicio recordar un estado de sesión, mientras participa en interacción de estado permanente.

Servicio de rellamada (Karmarkar)
Cómo puede un servicio tener comunicación asíncrona con sus consumidores.

Instancia de servicio de enrutamiento (Karmarkar)
Cómo pueden los consumidores contactar e interactuar con las instancias de servicio sin necesidad de lógica de procesamiento de propiedad.

Asíncrono Queue Server (Little, Rischbeck, Simon)
Cómo puede un servicio y sus consumidores manejar aislamiento de fallas y evitar bloqueo innecesario de recursos.

Reliable Messaging (Little, Rischbeck, Simon)
Cómo los servicios permiten una comunicación fiable cuando se implementan en un ambiente poco fiable.

Por eventos de mensajería (Little, Rischbeck, Simon)
Cómo pueden los consumidores de servicios recibir una notificación automática de un evento de servicio en tiempo de ejecución.


Patrones de composición de Aplicación

Subcontrolador Agnóstico (ERL)
Cómo pueden los agnósticos, cross-entidad lógica de la composición ser separados, reutilizados, y gobernados de forma independiente.

Composición de la Autonomía (ERL)
Como pueden las composiciones ser implementadas para reducir la pérdida de autonomía.

Transaction Service Atómica (ERL)
Cómo puede una transacción con la capacidad de rollback ser propagada a través de mensajería basada en los servicios.

La compensación de transacciones de servicios (Utschig, Maier, Trops, Normann, Winterberg, Loesgen, Little)
Cómo pueden las excepciones de composición en tiempo de ejecución ser consistentemente ajustadas sin requerir servicios de bloqueo de los recursos.


Servicio de Patrones de Interacción de Seguridad

Confidencialidad de los datos (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo pueden los datos dentro de un mensaje ser protegidos para que no sean revelados a personas ajenas, al mismo tiempo que son transferidos.

Los datos de autenticación de origen (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio verificar que un mensaje proviene de un emisor conocido y que el mensaje no ha sido alterado en tránsito.

Autenticación directa (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio verificar las credenciales proporcionadas por el consumidor.

Autenticación negociado (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio eficiente verificar las credenciales de los consumidores, si el consumidor y el servicio no confían unos en otros o si el consumidor requiere el acceso a múltiples servicios.


Patrones de transformación

Los datos del modelo de transformación (ERL)
Cómo pueden interoperar los servicios cuando se utilizan diferentes modelos de datos para el mismo tipo de datos.

Data Transformation Format (Little, Rischbeck, Simon)
Cómo pueden los servicios interactuar con los programas que se comunican con diferentes formatos de datos.

Protocolo de puente (Little, Rischbeck, Simon)
Cómo puede un servicio intercambiar datos con los consumidores que utilizan diferentes protocolos de comunicación.


Los patrones de diseño comunes Compuesto

Orquestación (Erl, Loesgen)
Co-existencia de aplicaciones de proceso de la abstracción, el Repositorio de Estado, la centralización de procesos, transacciones y servicios de compensación, se puede ampliar con Servicio de Transacción Atómica, centralización de reglas, y de transformación del modelo de datos.

Enterprise Service Bus (Erl, Little, Rischbeck, Simon)
Coexistencia de aplicaciones de cola asincrónica, enrutamiento intermedio, y el patrón de Service Broker compuesto, que puede ser extendido a través de la mensajería de confianza, la política de centralización, centralización de reglas y mensajería por eventos.

Service Broker (Little, Rischbeck, Simon)
Co-existencia de aplicaciones de transformación de modelos de datos, transformación de formato de datos, y el Protocolo de puente.

Bus del esquema canónico (Utschig, Maier, Trops, Normann, Winterberg, Erl)
Co-existencia de aplicaciones de Enterprise Service Bus, Contrato desconectado, la centralización del contrato, y el esquema canónico.

Punto final oficial (ERL)
Aplicación conjunta de la lógica y contrato de centralización.

Federados capa de punto final (ERL)
Aplicación conjunta de punto final oficial, normalización de servicios, el Protocolo de Canonizacíon, esquema canónico, y su forma canónica.

Tres capas de inventario (ERL)
Aplicación conjunta de la abstracción de utilidad, la abstracción de Entidad, y la abstracción del proceso.

EAI

Enterprise Integration Pattern

Ver diagrama

Servicios de Integración

Los servicios que se tienen que tener en cuenta para la integración entre aplicaciones se muestran a continuación:

A. Transporte y Conectividad: El objetivo es la transmisión de la información requerida entre las palicaciones.

1. Transporte de datos: Normalmente implica el uso de un bus de comunicación multicanal. Los servicios se pueden dividir en:

-Database Management Systems (DBMS): Si hay varias aplicaciones que comparten parte de un modelo de datos común representado en un motor de manejo de bases de datos, se puede intercambiar datos en común debido a que cada aplicación tiene acceso al modelo común.

-Transferencia de archivos: Se utilizan manejadores de transferencia de archivos, los cuales son capaces de recibir y enviar datos almacenados en archivos (como FTP por ejemplo). Algunos dejar configurar disparadores (triggers), que ante la llegada de un archivo puede invocar comandos sobre la máquina que lo recibió. Gracias a ello, una aplicación puede conocer cuándo le envía información otro programa para así efectuar diferentes acciones de procesamiento.

-Sistemas de mensajería interaplicación (MOMs): Se efectúa una comunicación a nivel de aplicación, a través del envío de mensajes, los cuales son gestionados por el MOM a través del uso de colas, el manejo de transacciones, las opciones de recuperación ante fallos, persostencia, monitoreo etc. Para poder hacer uso de un MOM debe modificarse a fondo la aplicación, definiendo la interacción con el MOM.

-Internet: A través del uso de esta red, se puede realizar intercambio de información entre aplicaciones a través del uso de protocolos como HTTP, SMTP, SOAP, eMS (EbXML Messaging Service), RNIF, EDIINT, etc.

2. Conectividad: Se usan buses de comunicación para poder transmitir tanto datos como eventos. Para conectar infraestructuras de intercambio de información con las aplicaciones, se puede hacer uso de adaptadores, los cuales permiten ese enlace, a través de la invocación de eventos sobre la infraestructura desde un programa.

3. Supervisión del transporte de la información Captura información de los eventos y datos transmitidos, con el fin de identificar fallos y/o compromisos, con el fin de identificar fallo o compromisos en el transporte de los datos y eventos.

B. Adaptación de la Información: A veces los datos o eventos recibidos no son comprendidos por una aplicación, por lo que se requieren mecanismos para que la misma pueda interpretarla. Estos mecanismos se muestran a continuación:

1. Transformación: Cuando se reciben eventos o datos que contienen información necesaria para desencadenar otros eventos o envío de información diferente.

Esto es posible a través de la definición de unas reglas de transformación:

a. A nivel de formatos de datos

- Formato plano: Datos que tienen una posición y tamaño fijo dentro del archivo.

- Formato plano, posición variable: Antes de cada dato se coloca la longitud del mismo.

- Formato plano, con delimitador: Se usa un caracter especial para indicar la separación entre uno y otro.

- Jerárquico: Hay datos que pueden considerarse compuestos, es decir, que son conformados por la unión de datos simples.

- Formato XML: Para la definición de elementos de datos estructurados usando etiquetas.

b. Transformación sintáctica: Cambia la representación de un evento para ser interpretado o procesado por la aplicación que hace uso de él.

c. Transformación semántica: Se modifica el significado de toda o parte de la información recibida de un evento base, para la creación de otros eventos que se van a introducir en un sistema de información. Durante la creación de estos eventos, puede resultar necesaria la realización de cálculos sobre los datos recibidos.

2. Enrutamiento: La idea es determinar quién va a recibir o procesar la información de un evento que es enviado por una aplicación. Para ello, se pueden utilizar mecanismos como el de publicación/suscripción. Normalmente, estas decisiones pueden ser administradas por un sistema de enrutamiento,

3. Almacenamiento: En algunos casos, los eventos se tienen que almacenar temporalmente, usando sistemas de archivos, bases de datos o manejadores de colas.

4. Realizar la definición de las reglas de transformación, enrutamiento y almacenamiento.

5. Supervisión de los intercambios de información: Puede ser posible mediante la generación de alertas, ya sea enlazadas a los errores disparados o deducidos de las reglas de verificación.

C. Automatizando los procesos de negocio: Si el intercambio de información es dependiente de alguna clasificación o de una serie de múltiples pasos se puede modelar en un motor de BPM. Para ello, se pueden definir los sguientes pasos:

1. Modelar los procesos de negocio: Implica la definición de actividades, relaciones, roles, el inicio y fin del proceso, las aplicaciones y datos intercambiados.Estas actividades pueden ser tanto manuales como automáticas.Se puede hacer uso de una notación como BPMN para realizar la descripción y el modelaje.

2. Ejecutar los procesos de negocio: Esta actividad se puede dividir en:

a. Orquestamiento de actividades. Consiste en la ejecución ordenada de las actividades, recuperando los resultado de cada paso, aplicando las reglas para cambiar o tomar una decisión, asegurarse que las actividades sucesivas sean enviadas con los datos o eventos requeridos, enviar información al módulo de monitoreo, y realizar la administración de cada paso. Este orquestamiento puede ser realizado por un motor de ejecución de procesos, la cual puede requerir que se de una descripción de cómo se va a realizar esta orquestación usando lenguajes como BPEL (Business Process Execution Language).
b. Ejecutando las reglas de negocio: Usando un motor de reglas de negocio, se establecen los lineamientos para lograr el avance de un proceso por un camino dado.
c. Supervisar los procesos de negocio: Es importante conocer el curso de las instancias de los procesos, para identificar puntos de falla y puntos de mejora de los procesos.

D. Mediación e integración: Los roles e interacciones dentro del proceso se deben definir estableciendo los niveles de procesos de negocio y de integración, definiendo los procesos de intercambio, y la interacción entre subniveles.

E. Escoger la arquitectura de intercambio: Se establece si la comunicación va a ser asíncrónica (a destiempo) o sincrónica (la interacción es bidireccional y acordada), y si los servicios e información a ofrecer va a distribuirse de manera centralizada (a través del uso de HUBs, que replican la información enviada por una aplicación a las demás aplicaciones conectadas), o de manera distribuida (usando buses de servicio, que establece un puente de comunicación punto a punto entre aplicaciones ofreciendo servicios de interpretación/traducción para mayor facilidad en la interpretación de la información.

PATRONES DE INTEGRACION EMPRESARIAL

Crear aplicaciones de negocios es difícil, y hacer que esta maneje todo un negocio es casi imposible. Luego distribuir funciones del negocio entre diversas aplicaciones provee la flexibilidad de escoger lo mejor de cada área de la empresa, sin embargo encontrar todo esto en una solución no es posible, puesto que cada empresa es distinta.
Estos, entre otros, son los problemas que se presentan en las empresas, haciendo necesaria la integración de las aplicaciones, de manera que esta sea eficiente, confiable y segura en el intercambio de datos entre diferentes aplicaciones empresariales.

RETOS DE INTEGRACION.
• Para la integración empresarial se requiere un cambio importante en las políticas corporativas.
• Debido a su amplio espectro, los esfuerzos de integración tienen profundas implicaciones en el negocio, volviendo a las soluciones empresariales una parte vital del negocio.
• Hay un control limitado en la integración de las aplicaciones, puesto que hay demasiado software legado que no puede ser modificado o enlazado adecuadamente con la solución de integración.
• Hay pocos estándares establecidos para llevar a cabo una integración de soluciones y en algunos casos (como el del WebService en XML) solo se ofrece una solución parcial.
• Las diferentes mezclas de tecnología y la naturaleza distribuida de las soluciones empresariales hacen el desarrollo de estas un reto en sí mismas.

ALGUNOS TIPOS DE INTEGRACION
Portal de información: reúnen información de múltiples fuentes en un solo lugar evitando con esto que el usuario tenga que abrir diferentes aplicaciones para lograr su objetivo.
Replicación de datos: nos permite mantener la integridad de diversos de los datos de diversos sistemas utilizando replicación de información.
Función de negocio compartida: evita la redundancia de funciones entre diversas aplicaciones mediante la exposición de dichas funciones como una función de negocio compartida que se implementa una vez y está disponible como un servicio para todos los demás sistemas.
Arquitectura orientada a servicios (SOA): SOA difumina la línea entre integración de aplicaciones y aplicaciones distribuidas. En SOA las funciones de del directorio de servicios y la interfaz de comunicación son elementos importantes para la arquitectura.
Procesos de negocio distribuidos: nos permite coordinar las aplicaciones en un entorno distribuido, permitiendo administrar la ejecución de cada una de estas entre múltiples sistemas.
Integración entre negocios: nos permite agrupar en un solo lugar los servicios de diferentes empresas para lograr un objetivo en particular.

ESTILOS DE INTEGRACION
La integración empresarial es la tarea de hacer que diferentes aplicaciones separadas trabajen juntas para producir un conjunto de funcionalidades. Para lograr lo anterior, se debe seguir una serie de criterios para lograr el objetivo principal.
Emparejamiento de aplicaciones: las aplicaciones integradas deben minimizar las dependencias entre ellas de manera que cada una pueda evolucionar sin provocar problemas a la otra.
Simplicidad de integración: cuando se integren aplicaciones, los desarrolladores deben luchar por minimizar el cambio de la aplicación y minimizar la cantidad de código requerido para la integración.
Tecnología de integración: evitar el casarse con un proveedor de tecnología de integración porque esto incrementa los problemas para el desarrollador y el entendimiento que este tiene de las herramientas.
Formato de los datos: las aplicaciones integradas deben tener un formato de intercambio de datos común o un traductor intermedio para unificar las aplicaciones que insisten en tener formatos propietarios o diferentes a los acordados.
No percepción de tiempo en los datos: el tiempo entre la compartición de la información y el uso de la misma entre aplicaciones integradas debe ser mínimo.
Datos o funcionalidad?: las aplicaciones integradas no deben compartir solo datos, sino funcionalidad entre ellas.
Asincronia: las aplicaciones integradas deben estar en capacidad de ejecutarse de manera asíncrona, de manera que el incorrecto funcionamiento de una, no termine por afectar a todo el sistema.

OPCIONES DE INTEGRACION DE APLICACIONES
Transferencia de archivos: hacer que cada aplicación produzca archivos para que las demás usen, y esta a su vez pueda usar lo que las demás aplicaciones produzcan.
Base de datos compartida: hacer que las aplicaciones guarden la información en un lugar común.
Invocación de procesos remotos: hacer que cada aplicación exponga algunos de sus procedimientos para que puedan ser invocados remotamente, y al mismo tiempo hacer que otras aplicaciones puedan invocar estos para ejecutar una labor de sistema e intercambio de información.
Mensajería: hacer que cada aplicación se conecte a un sistema de mensajería común, comparta información y ejecute funciones mediante el uso de mensajes.

SISTEMA DE MENSAJES
Los sistemas de mensajes hacen las aplicaciones “loosely coupled” al comunicarlas asíncronamente, haciendo la comunicación más confiable por que las dos aplicaciones no necesitan estar ejecutándose al mismo tiempo.
Canales: zona por donde se transmiten los mensajes, conectando al que envía con el que recibe.
Mensaje: paquete atómico que puede ser transmitido por un canal.
Entrega en varios pasos: un sistema de mensajes entrega estos directamente entre el que envía y el que recibe, requiriendo en muchas ocasiones el hacer alguna transformación en el mensaje antes de ser este enviado.
Enrutamiento: aplicación que determina como debe navegar el paquete en la red de canales de la empresa para llegar a su destino.
Transformación: filtro que formatea el mensaje de forma que el receptor lo pueda leer sin inconvenientes al recibirlo.
EndPoint: puente que permite a las aplicaciones el enviar y recibir mensajes entre sistemas de mensajes.

Pipes and Filters: pasos de proceso individuales (filters) están directametne relacionados mediante unos canales de mensajes (pipes). El “pipe” permite a un componente el enviar un mensaje dentro de este, de manera que pueda ser consumido posteriormente por otro proceso que puede ser desconocido por el componente inicial.
Pipeline processing: permite a cada unidad el ejecutar su propio hilo de proceso. Cuando una unidad ha completado el procesamiento de un mensaje, puede entonces enviar un mensaje al canal de salida y empezar un nuevo proceso, sin esperar que el proceso padre haya terminado. Si se compara con el modelo secuencia, el rendimiento del sistema se ve ampliamente incrementado.

Procesamiento en paralelo: mejora el rendimiento del sistema al lanzar varios procesos a que funcionen paralelamente, haciendo que las tareas más costosas en cuanto a tiempo se puedan realizar más rápida eficientemente, pero esta aproximación puede hacer que los mensajes se ejecuten de un modo “out-of-order”.

INTEGRACIÓN DE APLICACIONES

Las necesidades demandadas por un mundo globalizado han hecho que la información manejada por las empresas tenga que ser compartida con otras y sus clientes, por lo tanto, se han tenido que diseñar estrategias de intercambio de información de los diferentes sistemas de información que reciben y procesan estos datos.

Cuando se quería integrar adecuadamente información manejadas los dos o más aplicaciones de uso interno, nació la Integración Empresarial de Aplicaciones (EAI) y las conexiones A2A (aplicación a aplicación). Posteriormente, nació la necesidad de compartir información básica con empresas colaboradoras (o partners), por lo que surgieron los sistemas orientados a mensajeria (MOMs) y la arquitectura B2B.
Conforme han ido creciendo en tamaño las empresas, va surgiendo la necesidad de monitorear las actividades realizadas en sus procesos misionales, por lo que nacieron herramientas de monitoreo. que son conocidas como BAM (Business Activity Monitoring); pero a la vez los procesos misionales se han ido tornando más complejos, involucrando muchos actores internos y externos en el desarrollo de los mismos. Por lo tanto, se pueden utilizar dos estrategias para poder lograr un intercambio adecuado de la información manejada:
- Proveer servicios estandarizados consumibles por aplicaciones, a través del uso de la arquitectura orientada a servicios (SOA).
- Usar la metodología de modelamiento de procesos de negocio para entender y dirigir las actividades de los procesos de negocio0 en los que también puede existir intercambio de información entre aplicaciones.
La problemática principal para el departamento de TI de una empresa es lograr la comunicación de la información requerida entre las aplicaciones a través del uso de un lenguaje común. Para ello se identifica primero qué problema de integración es al que se tiene que enfrentar (propagación de datos, procesos multipaso, aplicaciones compuestas).Luego, hay que clasificar las aplicaciones actuales (en aplicaciones de procesos de lotes, transaccionales, cliente/servidor, web, tiempo real y paquetes de sofware). Finnalmente, teniendo toda la información previa recopilada, se puede determinar cuál puede ser la mejor estrategia de integracióm (EAI, A2A, B2B, BPM, SOA).

Patrón Integrador Consumidor Propuesto

Como aplicación de las innovaciones que presenta BPMN 2.0. Implementamos los conceptos de Call Activity, Escalation y Signal para la propuesta de un nuevo patrón, al que llamamos: Integrador Consumidor.

Problema:
El problema que soluciona la implementación del patrón es la necesidad de integración de información, concretamente la actualización de datos maestros, efectuada por varios procesos de negocio y que tienen una presentación y/o estructura diferente a la que es común para todos a través de una estructura centralizada.

Motivación: Poder consultar información de datos maestros (común entre los procesos de negocio), unificada desde un punto centralizado, que es consistente, confiable y única para todos los procesos de negocio, que la comparten.

Aplicación:
Caso 1 de Aplicación.
Actualización de los datos básicos de un paciente, en una EPS, que pueden ser
actualizados desde diferentes procesos de negocio como: Afiliaciones, Tesorería, IPS.


Caso 2 de Aplicación.
Actualización de información del cliente en VehiAlpes, desde procesos de negocio como:
Ventas, Servicio al cliente, Mercadeo.

Caso 3 de Aplicación.
Actualización de los datos básicos de un destinatario en una empresa de mensajería
desde diferentes procesos de negocio como: Distribución en Zona, Confirmaciones,
Servicio al cliente, Punto de Servicio, entre otros.


Estructura: La idea que proponemos mediante el patrón es la invocación de una señal al Integrador; al momento de generarse el evento de actualización de un dato maestro, desde cualquier proceso de negocio, éste a su vez, como respuesta, genera una cadena de señales hacia todos los procesos de negocio, sincronizando un tiempo de detención de actividades sobre el dato que se está actualizando. Una vez ha enviado todas las señales, escala a un llamado de actividad de actualización, dependiendo del dato maestro a actualizar, que contiene el código propio, definido por el proceso de negocio que gobierna al dato maestro. Y una vez finalizado la ejecución de la actividad que permite la actualización del dato. El Integrador, envía nuevamente una señal a todos los procesos, para reanudar las operaciones que utilizan el dato maestro. Finalmente los procesos reciben la señal y continúa la operación de negocio con normalidad.

Consecuencias: El uso de este modelo garantiza la aplicación de una solución a un problema común, que utiliza componentes de escalabilidad, de señales, llamados de actividades que permiten la reutilización de código y eventos informativos, de modo que lo hace flexible, modificable, escalable, proporcionando una alternativa de solución para la integración de información, en relación con la homogeneidad y gobernabilidad de Datos Maestros.

Ver Modelo en PDF

BPMN 2.0

Desarrollo de BPMN

Originalmente, BPMN fue desarrollado por Business Process Management Initiative (BPMI), un consorcio conformado por varias compañías desarrolladoras de software. Con una propuesta inicial para proveer una notación gráfica para descripciones de procesos expresada en BPML (Business Process Modeling Language), semejante a BPEL.
La primera versión de la especificación de BPMN fue desarrollada por Stephen A. White de IBM, publicada en 2004. En 2006, BPMN versión 1.0 fue oficialmente aceptada como un estándar OMG.

Innovaciones de BPMN 2.0

La versión 2.0 contiene las siguientes extensiones de tipos de diagramas existentes para procesos y modelos de colaboración:

√ Nuevos tipos de eventos: Eventos de múltiple paralelismo y escalamientos.
√ Paralelo basados en eventos.
√ Eventos subprocesos que son sólo externalizados cuando los eventos definidos, ocurren.
√ Opciones extendidas para el modelado de datos en procesos.
√ Actualizaciones de modelado de colaboración. Como ejemplo, el de participantes multi-instancia.
√ Símbolos para diferentes tipos de tareas.
√ Nuevas formas de modelado e invocación de actividades que son definidas en otro lugar.
√ Diferentes marcas de actividades multi-instancia.
√ Nuevo tipo de diagrama de coreografía.
√ Nuevo diagrama de conversación.

Considero que de los cambios más interesantes propuestos en la versión BPMN 2.0, está la introducción de los dos nuevos diagramas. Por esta razón menciono a continuación las ventajas del uso de las coreografías como reemplazo de los diagramas de colaboración:

* En una coreografía, la representación de intercambio de mensajes es independiente de los procesos asociados.

* La secuencia de mensajes intercambiados incluyen divisiones que dan mayor claridad. A diferencia de un diagrama de colaboración, que no visualiza explícitamente esta información.

* Una representación de coreografía, especialmente, para escenarios extensos, es más compacta y clara que un diagrama de colaboración con menos de un proceso público.

* Las coreografías pueden ser descompuestas con subprocesos de coreografía. Lo que genera una presentación compacta y comprensible.

* El manejo de colaboración dificulta la verificación de la compatibilidad de procesos, a diferencia de los diagramas de coreografía que pueden ser más fácilmente analizados, con respecto a la factibilidad del intercambio de mensajes.