Publicación de Servicios en Internet

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Publicación de Servicios en Internet"

Transcripción

1 Publicación de Servicios en Internet Pautas y Recomendaciones de Arquitectura PATRONES APLICABLES Versión 0.9

2 1 Información del Documento 1.1 Identificación y versión ARQ-RFC-03-Internet-Patrones aplicables Versión RFC 1.2 Resumen Se presenta un conjunto de patrones aplicables a la publicación de servicios del BPS en Internet y la Extranet. A este documento seguirá otro que paute el Modelo de Arquitectura de Referencia para estos servicios, que instanciará estos patrones aplicables al caso concreto del BPS y sus iniciativas de publicación de servicios. 1.3 Estado RFC Request For Comments Liberado para el análisis y la elaboración de comentarios por parte de los arquitectos, diseñadores y desarrolladores de los Centros de Desarrollo, proveedores de servicios tercerizados, ASIT y CSEI. 1.4 Autores Luis Arregui (*) Mónica Borso Jorge Cabrera (*) Virginia Casciato Andrés Lema (*) Enzo Santamaría (*) Carlos Suárez Jorge Suárez Edición Revisión Coordinación (*) Participan en el Comité actuando en modalidad ampliada. Versión /09/2007 Página 2 de 82

3 TABLA DE CONTENIDOS 1 INFORMACIÓN DEL DOCUMENTO IDENTIFICACIÓN Y VERSIÓN RESUMEN ESTADO AUTORES 2 2 PRESENTACIÓN 5 3 CONTEXTO Y CONSIDERACIONES GENERALES CONTEXTO ENFOQUE PROPUESTO Introducción Metodología Aplicada 7 4 GENERALIDADES SOBRE PATRONES INTRODUCCIÓN Semántica y representación: PATRONES COMPUESTOS (COMPOSITE PATTERNS) PATRONES DE NEGOCIO (BUSINESS PATTERNS) PATRONES DE INTEGRACIÓN PATRONES DE APLICACIÓN Y DE EJECUCIÓN 11 5 PATRONES DE NEGOCIO COLABORACIÓN (COLLABORATION) AGREGACIÓN DE INFORMACIÓN (INFORMATION AGGREGATION) EXTENDED ENTERPRISE (EMPRESA EXTENDIDA -EE) Patrones de Aplicación de Empresa Extendida Razones de Negocio y de IT que conducen la determinación de los Patrones de Aplicación Análisis Razones de Negocio y de IT Contexto Visión general Pautas y Recomendaciones Características de cada Patrón Conexión Directa Expuesta (Exposed Direct Connection) Variante Router expuesto Broker Expuesto (Exposed Broker) Proceso Serial Expuesto (Exposed Serial Process) Variante Workflow Serial Expuesto SELF-SERVICE (AUTOSERVICIO) Patrones de Aplicación de Self-Service (Autoservicio) Razones de Negocio y de IT que conducen la determinación de los Patrones de Aplicación Análisis Razones de Negocio y de IT Contexto Visión general Pautas y Recomendaciones Características de cada Patrón Canal Único Autónomo (Stand-Alone Single Channel ) Canal Único Directamente Integrado (Directly-Integrated single Channel ) Directo a Host (As-Is Host ) Presentación Personalizada para Host (Customized Presentation to Host ) Router (Enrutador) Descomposición (Decomposition) Agente (Agent) 40 6 PATRONES DE INTEGRACIÓN 42 Versión /09/2007 Página 3 de 82

4 6.1 INTEGRACIÓN DE ACCESO Patrones de Aplicación de Integración de Acceso Razones de Negocio y de IT que conducen la determinación de los Patrones de Aplicación Características de cada Patrón Client (Cliente) Thin Client (TC, Cliente Fino) Voice-Enabled Client (VEC, Cliente con Interfaz de Voz) Distributed Presentation Client (DPC, Cliente de Presentación Distribuida) Distributed Application Client (DAC, Cliente de Aplicación Distribuida) Distributed Rich Client (DRC, Cliente Rico Distribuido) Distributed Multimodal Client (DMC, Cliente Multimodal Distribuido) Distributed Collaboration Client (DCC, Cliente de Colaboración Distribuida) Single Sign-On (Autenticación Única) Personalized Delivery (Entrega Personalizada) INTEGRACIÓN DE APLICACIONES Integración de Procesos Patrones de Aplicación de Integración de Procesos Razones de Negocio y de IT que conducen la determinación de los Patrones de Aplicación Características de cada Patrón Conexión Directa (Direct Connection) Conexión Directa usando un único adaptador Conexión Directa usando adaptadores federados Conexión Directa = Conexión por Mensaje (Message Connection) Conexión Directa = Conexión por Llamada (Call Connection) Variante Router Conexión Directa = Conexión por Llamada SOA (SOA Call Connection) Broker Broker SOA (patrón ESB) Broker SOA = Variante ESB Integrados (patrones Emergentes) Patrones de Topología ESB (patrones Emergentes) Patrones Adaptadores ESB (patrones Emergentes) Compuesto Proceso Serial (Serial Process) Proceso Serial SOA (patrón BSC) Variante Workflow Serial (Serial Workflow variation) Variante Workflow Serial SOA (SOA Serial Workflow) Proceso Paralelo (Parallel Process) Variante Workflow Paralelo Genérico (Parallel Workflow) Variante Workflow Paralelo SOA (Parallel Workflow) Integración de Datos Patrones de Aplicación para Integración de Datos Razones de Negocio y de IT que conducen la determinación de los Patrones de Aplicación Características de cada Patrón Federación ( Federation) Federación = Variante Caché Población (Population) Población = Variante Multi Paso (Multi Step variation) Población = Variante Acumulada Multi Paso (Multi Step Gather variation) Población = Variante Proceso Multi Paso (Multi Step Process variation) Población = Variante Acumulada Federada Multi Paso (Multi Step Federated Gather variation) Sincronización en dos sentidos (Two-way Synchronization) Variante Multi Paso Sincronización en dos-sentidos (Multi Step variation) 81 7 REFERENCIAS 82 Versión /09/2007 Página 4 de 82

5 2 Presentación El presente documento establece un conjunto de patrones aplicables para la definición de la arquitectura de los servicios de BPS a publicar en Internet o la Extranet. Le seguirá otro documento que pautará el modelo general de arquitectura correspondiente. Versión /09/2007 Página 5 de 82

6 3 Contexto y Consideraciones Generales 3.1 Contexto En su Plan de Sistemas y Servicios Informatizados [Ref.: 1] el Comité de Planificación de Sistemas de Información se plantea los siguientes objetivos: Introducir en forma generalizada tecnologías de tipo Portal Web. Si bien están orientadas principalmente para los Servicios por Internet a usuarios externos junto con mecanismos genéricos de intercambio de información con instituciones externas; también interesa analizar el uso de estas tecnologías para interfases de tipo Web orientadas a funcionarios que no sean especialistas de un área funcional. [OF-23] Implementar el Proyecto Servicios por Internet, que apunta a construir una plataforma de base única en la cual se inserten las aplicaciones asociadas a funcionalidades específicas, y que globalmente permita el acceso externo seguro y robusto a información y servicios del BPS [OF-35] Adaptar la lógica de interacción con el usuario de Sucursales y Agencias para las aplicaciones más relevantes, de forma que facilite su operación por parte de funcionarios con perfil multipropósito. Este objetivo está asociado al [OF-23] (Servicios por Internet). [OC-5] Implementar Proyecto de Servicios por Internet, liderado por las unidades internas del BPS Dicho proyecto ya fue creado [Ref.: 2]. Se marcan como OBJETIVOS DEL PROYECTO: La descripción macro se ubica en un aumento significativo en la interacción entre el Instituto con la ciudadanía, así como otras instituciones externas, para lo que se plantea extender la infraestructura común e implementar mecanismos homogéneos que soporten los nuevos servicios para lograr un mejor efectividad de los mismos. Se identifican 4 tipos de usuarios en Internet. Los usuarios contribuyentes Los usuarios empleados del BPS que necesiten utilizar algún sistema a través de Internet Los usuarios funcionarios de otras instituciones que necesiten utilizar los sistemas del BPS Aplicaciones externas que necesiten información del BPS. Esto corresponde al componente de integración externa de la Arquitectura definida. Se marcan como OBJETIVOS ESPECIFICOS DEL PROYECTO: 1. Definir un marco tecnológico unificado y homogéneo de servicios, apuntando a tener el concepto del BPS único, más allá de la tecnología a implantar 2. Construir las componentes tecnológicas comunes a ser usadas por el conjunto de los servicios, apuntando a detectar las piezas comunes en la horizontal para poder concentrarlos en forma unificada 3. Definir el contexto de explotación a utilizar y coordinar con las áreas involucradas la realización de las actividades de producción 4. Independizar la interacción con usuario de la lógica básica del negocio Entre sus COMPONENTES DE TRABAJO se encuentra: Arquitectura a implantar interna y externa o Mecanismos transaccional sincronismo de operaciones o Integración con las tecnológicas actuales, internas como externas Versión /09/2007 Página 6 de 82

7 o Modalidad de intercambio de información Web Service DTS El Comité Técnico de Arquitectura de Sistemas de Información, tomando el presente Contexto como entrada para el desarrollo de sus responsabilidades, elaboró las siguientes pautas (de aplicación obligatoria) y recomendaciones (de aplicación sugerida) de Arquitectura aplicables a Proyectos que involucren la publicación de servicios por Internet o Extranet. Se entiende que las mismas aportan a la concreción de las actividades reseñadas, en la medida en que constituyen criterios técnicos útiles para la determinación del alcance, contenido y características técnicas de estos Servicios. 3.2 Enfoque Propuesto Introducción La integración de aplicaciones es una tarea compleja que puede ser abordada desde una perspectiva estrictamente de IT [Ref.: 4] en respuesta a problemas de IT; o puede ser abordada como parte de una perspectiva más amplia por ejemplo, la construcción de una arquitectura enterprise orientada a exponer servicios. En este tipo de arquitecturas la integración de IT se alinea de manera continua con los objetivos del negocio y su dinámica. Pero a la vez aporta soluciones como las que inicialmente fueron de integración de aplicación en problemas de otro orden. Por ejemplo, la no disponibilidad de algún componente Web inhabilitaría la ejecución de una aplicación basada en la Web. En este caso. Los middleware de mensajería y sus mecanismos asincrónicos, antes que integrar desacoplan componentes de una arquitectura de servicios haciéndolos posibles. Los conceptos relativamente nuevos de Patterns y Arquitectura de IT aparecen relacionados cada vez con mayor frecuencia. Poco importa si hablamos de patterns en general o de integración en particular. En todos los casos hablamos de soluciones probadas de problemas recurrentes, expresadas mediante abstracciones. El éxito de los patrones radica precisamente en trasladar las mejores soluciones probadas aplicadas a cada instancia de la construcción de aplicaciones empresarias. Esta afirmación también se cumple si hablamos de patrones de negocio. Se habla de Arquitecturas conducidas por patterns, de Patterns de Arquitecturas, entre muchas propuestas; pero todas acuerdan en la necesidad de una capa que intermedie entre el negocio y la tecnología que lo soporta, expresando y administrando los requerimientos tanto funcionales como no funcionales desde el punto de vista más abstracto. Ese es, a nuestro entender, el rol clave de la Arquitectura de IT. Si es el caso que los objetivos de Institución requieren exponer procesos de negocio mediante interfaces de servicios, entonces es posible encontrar soluciones probadas -es decir, patternstanto de negocios como de tecnología para la construcción de esta capa de arquitectura Metodología Aplicada El presente trabajo aporte de un grupo de IT Architects de IBM al tema [Ref.: 5]- adopta tanto un punto de vista amplio como un tratamiento sistemático del tema de los Patterns, abarcando los casos genéricos de la exposición de servicios en la Web y el caso de las Arquitecturas Orientadas a Servicio (SOA). Versión /09/2007 Página 7 de 82

8 Sin llegar a ser metodología explícita, el enfoque propuesto permite ir desde la identificación del tipo de aplicación Web adecuada a nuestra realidad de negocio hasta la identificación de la arquitectura de integración que mejor responda a esa realidad. La reunión de ambos grupos de patterns faculta la generación de un grupo amplio y flexible de patrones aplicativos reunidos en unas pocas categorías identificadas por características fundamentales. Este trabajo se propone construir la Arquitectura vinculada a la exposición de servicios en la Web, en dos etapas: La primera cuyo resultado son las Recomendaciones presentes, despliega el subconjunto de Patterns que el Comité entendió de aplicación a nuestra realidad. Se analizan los Business Patterns y los Integration Patterns a la luz de la intención y necesidad de negocio de la Institución, y se determinan los motivos de selección guiados por las razones conductoras tanto de negocio como de IT asociadas a ellos los Business Drivers y IT Drivers. La segunda, será la construcción de la Arquitectura luego de estudiar cuáles son los puntos y los patrones de integración que habilitan la interacción entre los Business Patterns seleccionados. La conjunción de los patrones de Negocio y de Integración nos llevará a un tercer tipo de patrones llamados Patrones Compuestos (Composite Pattern), que serán la representación abstracta de la arquitectura determinada por la Institución. Esta segunda etapa generará su propio documento específico de Pautas y Recomendaciones. Versión /09/2007 Página 8 de 82

9 4 Generalidades sobre Patrones 4.1 Introducción Un patrón es una solución efectiva probada a un problema recurrente en un cierto contexto. Aplica al dominio de la arquitectura IT y el diseño. Se caracteriza por su visión de alto nivel, por identificar y abstraer los aspectos claves del problema y de su contexto. Se centra en un problema concreto, y el esquema de la solución describe el conjunto de responsabilidades, relaciones y formas de colaboración entre sus componentes, que ofrece para su reuso. Las presentes Pautas y Recomendaciones de Arquitectura analizan los patrones de Arquitectura descritos en el trabajo del grupo de IT Architects de IBM. Lo hace en el marco del Contexto ya desarrollado, centrándose en los patrones que describen la exposición de funcionalidades en la Web, tanto para la interacción con el ciudadano como con las aplicaciones de otras organizaciones. Los patrones de negocio así como los de integración serán expresados en términos de patrones de aplicaciones y de ejecución. Cuando corresponda serán representados tanto su perfil genérico como su perfil SOA (Service-Oriented Architecture). Patrones de Negocio (Business Patterns) Patrones Compuestos Patrones de Integración (IntegrationPatterns) Patrones de Aplicación (Application Pattern) Patrones de Ejecución (Runtime Pattern) Perfil Genérico (Generic Profile) Perfil SOA (SOA Profile) Para cada patrón, su condición de Pauta o Recomendación se indicará explícitamente o mediante la utilización de las formas verbales se deberá o se preferirá. Versión /09/2007 Página 9 de 82

10 4.1.1 Semántica y representación: Se empleará la siguiente semántica y representación en los diagramas: (Ref: ) 4.2 Patrones Compuestos (Composite Patterns) Los Patrones Compuestos son combinaciones de Patrones de Negocio y Patrones de Integración que se han convertido en tipos de aplicaciones de e-business utilizados con frecuencia. Los patrones compuestos son aplicaciones de e-business avanzadas. Existen numerosas combinaciones posibles de los Patrones de Negocio y de Integración. El diseño de una solución compuesta de estos distintos bloques de construcción sólo se considera Patrón Compuesto si se utiliza repetidamente para resolver los problemas de las empresas pertenecientes a muchos sectores. Como ejemplos de Patrones Compuestos podemos citar los siguientes cuatro: Comercio electrónico (Electronic Commerce) Mercado electrónico (e-marketplace) Portales (Portals) Acceso de cuentas (Account Access) que se documentarán en la segunda etapa de estas Pautas y Recomendaciones. 4.3 Patrones de Negocio (Business Patterns) Los Patrones de Negocio son construcciones a alto nivel que se pueden utilizar para describir el principal propósito empresarial de una solución. Estos patrones describen los objetivos de la solución, los participantes a alto nivel que interactúan en ella y la naturaleza de las interacciones entre los participantes: (U) -Usuarios de la solución: el ciudadano, en general. (B) -Empresa u organización con la que interactúan los usuarios: esta entidad "empresarial" se puede utilizar para representar a la organización en sí o a sistemas (aplicaciones o programas de software) existentes dentro de la organización. (D) -Datos que existen en la organización: los datos se distinguen de las aplicaciones porque la naturaleza de las interacciones entre estas entidades es muy diferente. Versión /09/2007 Página 10 de 82

11 Estos patrones de negocio resaltan las interacciones más habituales entre usuarios, empresas y datos. Son los bloques de construcción fundamentales de la mayoría de las soluciones de e- business y presentan las siguientes características: Cada patrón es independiente. El ámbito de cada patrón abarca los flujos completos mínimos necesarios para implementar un proceso empresarial automatizado. Cada patrón normalmente interactúa con otros patrones a través de uno o varios puntos de integración. Estos puntos de integración pueden incluir transferencia de archivos, transferencia de mensajes, una base de datos común, un componente común, una aplicación común, un proceso común, un punto de acceso común o un flujo de trabajo común. Desde el punto de vista de la estructura, estos patrones están formados por al menos dos de las tres entidades antes mencionadas, que intervienen en las soluciones de comercio electrónico (e-business). Es decir, (entre otras construcciones): Son cuatro los patrones de negocio estudiados: U2B U2U U2D B2B Colaboración U2U Agregación de información U2D Empresa extendida B2B Autoservicio U2B 4.4 Patrones de Integración Los patrones de integración integran múltiples aplicaciones, modalidades de acceso y fuentes de información para crear una aplicación transparente. Se diferencian de los patrones de negocio porque no automatizan problemas empresariales específicos, sino que se utilizan para dar soporte a funciones avanzadas dentro de los patrones de negocio o para hacer accesibles los patrones compuestos al permitir la integración de dos o más patrones de negocio. En principio, IBM los clasifica en Access Integration y Application Integration patterns, que se desarrollarán más adelante. 4.5 Patrones de Aplicación y de Ejecución Los Patrones de Aplicación y de Ejecución dependen de los requisitos del cliente y describen la forma de las aplicaciones y el ambiente de ejecución necesario para crear la aplicación Web. En este trabajo se describirán los casos Genéricos (basados en un planteo no orientado a Servicios) y los casos SOA (orientados a Servicios). Versión /09/2007 Página 11 de 82

12 5 Patrones de Negocio Colaboración Patrones de Negocio Agregación de Información Empresa Extendida Autoservicio 5.1 Colaboración (Collaboration) Denominado de usuario a usuario, el patrón de negocio Colaboración se ocupa de las interacciones y colaboraciones entre usuarios. Este patrón se debe observar en soluciones que dan soporte a equipos pequeños o extendidos que necesitan trabajar juntos para lograr un objetivo común. Ejemplos de este patrón son: , On Line Meeting, etc. Pauta: Colaboración es un Patrón de Negocio que no es aplicable a la problemática tratada en el presente documento. 5.2 Agregación de Información (Information Aggregation) También conocido como de usuario a datos, se puede observar en soluciones e-business que permiten a los usuarios acceder a datos agregados de varias fuentes y manipularlos. Este patrón de negocio aplica al proceso de tomar grandes volúmenes de datos, texto, imágenes, video, etc. y utilizar herramientas para extraer información útil de los mismos. Pauta: Agregación de Información es un Patrón de Negocio que no es aplicable a la problemática tratada en el presente documento. Versión /09/2007 Página 12 de 82

13 5.3 Extended Enterprise (Empresa Extendida -EE) También conocido como patrón de Empresa a Empresa o B2B, el patrón Empresa Extendida (EE) se ocupa de las interacciones y colaboraciones entre procesos de gestión de organizaciones separadas. Este patrón se puede observar en soluciones que implementan interfaces de programación para conectar aplicaciones entre distintas organizaciones. En otras palabras, no se ocupa de las aplicaciones invocadas directamente mediante una interfaz de usuario. Aplicado a nuestra realidad, este patrón orienta la automatización de procesos de gestión entre nuestra institución y cualquier otra, sea pública o privada. A modo de ejemplo: BPS-DGI, BPS-ADUANA, BPS-Entidades de Salud Estas interacciones podrán ser tanto en serie como en paralelo; pero a diferencia del patrón EIA [Ref.: 5,. Cap.7 Patrones de Integración] no podrán realizarse ambas simultáneamente, como lo muestra el diagrama siguiente. Versión /09/2007 Página 13 de 82

14 5.3.1 Patrones de Aplicación de Empresa Extendida. El patrón de negocio Empresa Extendida (EE) se puede implementar utilizando cualquiera de los seis Patrones de Aplicación siguientes: Conexión Directa Expuesta : Conexión por Mensaje Conexión Directa Expuesta : Conexión por Llamada Patrón de Negocio Empresa Extendida Variante Router Expuesto Broker Expuesto Proceso Serial Expuesto Variante Workflow Serial Expuesto Es inmediato percibir la estrecha relación que guardan estos patrones con los de Integración de Procesos [Ref.: 5,. Cap.7 Patrones de Integración]: Direct Connection, Router, Broker, Serial Process, Serial Workflow, Parallel Process, Parallel Workflow Es que el patrón EE especializa el patrón EIA. Proyecta su alcance, llevándolo desde la integración intra.-organización a la integración inter-organizaciones. Habilita la automatización de procesos de negocio entre las organizaciones participantes, que los exponen para su integración. En resumen, el patrón EE agrega a los patrones EAI al calificador Expuesto, las aplicaciones de otras organizaciones y la infraestructura necesaria. A su vez, los patrones con perfil SOA especializan los patrones de perfil general; por lo tanto, también los de EE, incorporando middleware de servicios (ESB). En las presentes Pautas y Recomendaciones de Arquitectura se presentarán ambos perfiles, el genérico y la especialización SOA. Versión /09/2007 Página 14 de 82

15 Razones de Negocio y de IT que conducen la determinación de los Patrones de Aplicación. Razones de negocio conductoras Conexión Directa expuesta = Conexión por Mensaje Conexión Directa expuesta = Conexión por Llamada Variante Router expuesto Broker expuesto Proceso Serial Expuesto Variante workflow serial expuesto Mejorar la eficiencia organizacional Reducir los tiempos de propagación de los cambios Soportar un intercambio estructurado con otras organizaciones Soportar flujos de mensajes unidireccionales en tiempo real hacia los procesos de otras organizaciones Soportar flujos de mensajes pedido/respuesta (bidireccionales) en tiempo real con los procesos de otras organizaciones Soportar ruteo dinámico de mensajes a una entre varias aplicaciones destino pertenecientes a otras organizaciones Soportar distribución dinámica de mensajes a múltiples aplicaciones destino pertenecientes a otras organizaciones Soportar la coordinación automatizada del flujo de procesos entre varias organizaciones Soportar la interacción e intervención humana dentro del flujo de procesos entre varias organizaciones Tabla 1 (Ref: ) Versión /09/2007 Página 15 de 82

16 Razones de IT conductoras Conexión Directa expuesta = Conexión por Mensaje Conexión Directa expuesta = Conexión por Llamada Variante Router expuesto Broker expuesto Proceso Serial Expuesto Variante workflow serial expuesto Minimizar el Costo Total de Propiedad (TCO) Aprovechar las habilidades existentes Aprovechar las inversiones ya realizadas Habilitar la integración de aplicaciones del back-end Minimizar la complejidad de la aplicaciones Minimizar la complejidad de la organización Mejorar la mantenibilidad Mejorar la flexibilidad externalizando la lógica de procesos de la lógica de las aplicaciones Soportar transacciones largas Tabla 2 (Ref: ) Análisis Razones de Negocio y de IT Contexto Los seis patrones de aplicación Empresa Extendida, ordenados por grado de flexibilidad y sofisticación, se basan unos en otros. Sus funciones y su dependencia del middleware aumenta y requieren menor cantidad de desarrollo de aplicaciones. El patrón de Empresa Extendida puede consistir en todos o en algunos de los elementos que se indican a continuación: Entidades de la organización, generalmente programas, aplicaciones o bases de datos existentes en la Institución, que acceden y se conectan a otras entidades de organizaciones en la red. Una red que basada en TCP/IP y otras tecnologías de Internet, o una conexión de red de área amplia (WAN) dedicada. Reglas de gestión de la organización que gobiernan la integración entre las entidades de la organización. Reglas que describen los acuerdos entre organizaciones asociadas. Reglas de workflow para determinar la secuencia de pasos y el flujo de datos que se debe utilizar para facilitar la integración. Estas reglas describen la secuencia de pasos por los Versión /09/2007 Página 16 de 82

17 que debe transitar un mensaje antes de transferirse a otra entidad de la organización y especifican cómo y dónde debe entregarse el mensaje. Reglas de transformación para especificar las transformaciones de protocolo y de formato que se deben aplicar a los mensajes que circulan entre las entidades empresariales. Un conjunto de interacciones con otras organizaciones que incluyen la ejecución de un proceso acordado conjuntamente Visión general Desde el punto de vista Institucional, los siguientes han sido el conjunto de requerimientos generales de la Institución -manejadas como hipótesis de trabajo para la determinación de los patrones de aplicación más adecuado-, puestos a emplear el patrón de negocio Empresa Extendida. Adecuación de la Institución al Gobierno Electrónico como forma de brindar servicios integrados, orientados a Empresas Públicas o Privadas que necesita automatizar procesos Inter.-institucionales. Los procesos institucionales deben estar integrados con los sistemas institucionales y la información existentes El patrón Empresa Extendida responde con implementaciones distintas a las posibles razones claves de negocio y de IT. Expresados en orden de complejidad creciente, cada variante siguiente en ese orden se vincula con el anterior manteniendo cubiertas sus características y agregando otras (Cfr. Tabla 1 y 2). Las primeras 6 razones de negocio del Pattern EE: 1. Mejorar la eficiencia organizacional 2. Reducir los tiempos de propagación de los cambios 3. Soportar un intercambio estructurado con otras organizaciones 4. Soportar flujos de mensajes unidireccionales en tiempo real hacia los procesos de otras organizaciones 5. Soportar flujos de mensajes pedido/respuesta (bidireccionales) en tiempo real con los procesos de otras organizaciones 6. Soportar ruteo dinámico de mensajes a una entre varias aplicaciones destino pertenecientes a otras organizaciones si bien necesarias, no resultan suficientes para cubrir los requerimientos establecidos como hipótesis de trabajo. Es a partir de la implementación de las tres últimas, que estos requerimientos resultarán cubiertos: 7. Soportar distribución dinámica de mensajes a múltiples aplicaciones destino pertenecientes a otras organizaciones 8. Soportar la coordinación automatizada del flujo de procesos entre varias organizaciones 9. Soportar la interacción e intervención humana dentro del flujo de procesos entre varias organizaciones La razón de negocio principal para seleccionar estos patrones de aplicación es permitir que una aplicación interactúe con una o múltiples aplicaciones de organizaciones atravesando los límites de la Institución. Usar una arquitectura hub-and-spoke en lugar de una arquitectura punto-a-punto permite la integración transparente de aplicaciones mientras se minimiza la complejidad. Un requerimiento Versión /09/2007 Página 17 de 82

18 de información puede ser ruteado a una de muchas aplicaciones Destino o simultáneamente a múltiples aplicaciones. El mensaje requerido resultante puede descomponerse en múltiples mensajes requeridos; y los mensajes de respuesta pueden ser recompuestos, asimismo, en un solo mensaje que use reglas de recomposición apropiadas. Esta externalización del ruteo, descomposición y reglas de recomposición de las aplicaciones individuales Origen y Destino aumentan la mantenibilidad y flexibilidad, y reduce la complejidad de integración a lo ancho de la Organización Desde el punto de vista de Arquitectura, centrado fuertemente en los requerimientos no funcionales y orientado a Servicios, las siguientes han sido el conjunto de características consideradas como razones de IT necesarias a la Institución para satisfacer las de negocio, para la determinación del patrón de aplicación más adecuado, puestos a emplear el patrón de negocio Empresa Extendida: Las primeras 7 razones de IT del Pattern EE 1. Minimizar el Costo Total de Propiedad (TCO) 2. Aprovechar las habilidades existentes 3. Aprovechar las inversiones ya realizadas 4. Habilitar la integración de aplicaciones del back-end 5. Minimizar la complejidad de la aplicaciones 6. Minimizar la complejidad de la organización 7. Mejorar la mantenibilidad si bien necesarias, no resultan suficientes para cubrir los requerimientos establecidos como hipótesis de trabajo. Es a partir de la implementación de las dos últimas, que estos requerimientos resultarán cubiertos: 8. Mejorar la flexibilidad externalizando la lógica de procesos de la lógica de las aplicaciones 9. Soportar transacciones largas Pautas y Recomendaciones La determinación de los Patrones de Aplicación debe encontrarse en la intersección de los puntos de vistas anteriores, en este caso apuntando fuertemente a Patrones elegidos: Broker, Proceso serial expuesto, Workflow expuesto como patrones de aplicación que responde tanto a los requerimientos funcionales supuestos como a los no funcionales, y asimismo a la orientación a Servicios. Téngase en cuenta, además, que los patterns de mayor complejidad reusan, en general, características de los patterns de menor complejidad. Esta constante en la familia de patterns de negocio permite seleccionar patrones complejos sin pérdidas al establecer el nivel mínimo de razones de negocio y de IT que deben observar las soluciones de la Institución en la automatización de procesos de negocio entre organizaciones. Recomendación: Variante Workflow Serial Expuesto, es el Patrón Aplicativo Preferido a implementar Recomendación: Broker Expuesto Proceso Serial Expuesto Versión /09/2007 Página 18 de 82

19 son los Patrones Aplicativos preferidos tanto para la transición desde la Arquitectura Actual / Arquitectura Objetivo, como en casos de menor complejidad. Por tanto, se prefiere no aplicar los patrones: Dado que los patrones pautados y recomendados reusan los anteriores en la serie y por tanto los tres siguientes, no debieran ser empleados como patrones independientes: Conexión Directa expuesta = Conexión por Mensaje Conexión Directa expuesta = Conexión por Llamada Variante Router expuesto salvo casos justificados, tratados como de excepción en gestión de la Arquitectura Características de cada Patrón Conexión Directa Expuesta (Exposed Direct Connection) Descripción: El patrón de aplicación Conexión Directa Expuesta representa el tipo de interacción más simple basado en una topología 1-a-1. Permite a un par de aplicaciones comunicarse directamente entre sí a través de los límites de la organización. Las Interacciones entre una aplicación Origen y una Destino pueden ser arbitrariamente complejas. En general, esta complejidad puede ser manejada descomponiendo esas interacciones en interacciones más elementales. Las conexiones punto-a-punto más complejas tendrán modelos de reglas de conexión como reglas de negocio asociadas con ellos, como se muestra en la figura. Las reglas de conexión generalmente son usadas para controlan el modo de funcionamiento de un conector dependiendo de factores externos. Los ejemplos de reglas de conexión son: Reglas de mapeo a datos de la Organización (para los conectores del adaptador) Reglas Autónomas (como prioridad en un ambiente compartido) Reglas de seguridad Reglas de disponibilidad y capacidad El patrón de aplicación Conexión Directa Expuesta tiene dos variaciones: Conexión Directa Expuesta : Conexión por Mensaje Conexión Directa Expuesta : Conexión por Llamado Versión /09/2007 Página 19 de 82

20 Todas las aplicaciones de este patrón serán una de estas variaciones. Definir la variante depende de si la aplicación Origen iniciada necesita una respuesta inmediata de la aplicación Destino para proceder con la ejecución. Ambas variaciones pueden usarse con protocolos de comunicación síncronos o asíncronos. Hay preferencias sin embargo, por un tipo específico de protocolo que depende de la variante. Por ejemplo, la variante Conexión Directa por Llamada tiene un ataque más natural con protocolos síncronos mientras la variante Conexión Directa por Mensaje favorece a los protocolos asíncronos Conexión Directa expuesta = Conexión por Mensaje (Message Connection variation) Descripción: La variante del patrón de aplicación Conexión Directa Expuesta, Conexión por Mensaje - anteriormente conocida como patrón de aplicación Intercambio de Documentos-, aplica a las soluciones donde el proceso de gestión no requiere una contestación de la aplicación Destino, expuesta dentro del alcance de la interacción Conexión Directa expuesta = Conexión por Llamada (Call Connection variation) Descripción: La variante del patrón de aplicación de Conexión Directa Expuesta, Conexión por Llamada - anteriormente conocida Empresa Extendida : Aplicación Expuesta-, aplica a las soluciones donde el proceso de gestión de la Organización depende de la aplicación Destino expuesta en que procese un requerimiento y devuelva una respuesta dentro del alcance de la interacción. Versión /09/2007 Página 20 de 82

21 Variante Router expuesto Descripción: La variante Router Expuesto -del patrón de aplicación Broker Expuesto que se detallará más adelante-, aplica a las soluciones donde la aplicación Origen de la organización comienza una interacción remitida a lo sumo a una de varias aplicaciones Destino. La selección de la aplicación Destino es controlada por las reglas de distribución que gobiernan el funcionamiento del componente conector Broker Expuesto (Exposed Broker) Descripción: El patrón de aplicación Broker Expuesto (también conocido como Exposed Business Services), está basado en una topología 1-a-N. Permite que una sola interacción de la aplicación Origen de la Institución sea distribuida concurrentemente a N aplicaciones Destino de múltiples organizaciones mediante reglas de distribución a las aplicaciones. Broker Expuesto se emplea en soluciones donde la aplicación de Origen empieza la interacción que se distribuye a las aplicaciones Destino atravesando los límites de la Institución. Separa la lógica de la aplicación de la lógica de la distribución basándose en reglas contenidas en la capa del Broker, donde se gestiona la descomposición / recomposición de la interacción. Broker Expuesto reusa el patrón Conexión Directa Expuesta para proporcionar conectividad entre capas. Las reglas del Broker pueden soportar tanto la variante Conexión por Mensajes como la variante Conexión por Llamada (o ambas) de ese patrón. Versión /09/2007 Página 21 de 82

22 Descripción del Patrón de Ejecución Genérico El nodo Broker Expuesto abarca la funcionalidad de un nodo Broker (cfr. Cap.7 Patrones de Integración), y además, incluye los medios para exponer los procesos de nuestra Organización a los procesos a las Organizaciones externas Es optativo modelar el Conector en la Zona Desmilitarizada de la Organización. Proporciona la conectividad entre la Zona Segura de la Organización y la Zona Inter.-Organizaciones. Puede ser un componente de bajo nivel (Ej., de infraestructura TCP/IP) -que se omite en el diagrama- o puede tener capacidades más avanzadas como caching de contenido reusable (Ej. un Servidor Web). Los servicios de Directorio y Seguridad aportan los servicios de autenticación y autorización, que también dan soporte al ID de usuario y contraseña y los privilegios relacionados. Este nodo típicamente hace uso de directorios LDAP. También contiene la información de configuración necesaria para soportar acceso seguro entre nuestra Organización y los servicios de las organizaciones externas Descripción del Patrón de Ejecución para SOA Esta segunda sección de describe la especialización del patrón Broker Expuesto para el ambiente de SOA, agregándole la terminología de la orientación a Servicios. Sobre el Broker Expuesto genérico, Directorio de Reglas e Infraestructura de las organizaciones asociadas en la figura genérica, sobre se especializa en el perfil de SOA: Un Exposed ESB Gateway (soportando el requisito Expuesto) Un ESB (soportando los requerimientos del Broker y el Directorio de Reglas más los requerimientos de la infraestructura SOA para localización transparente e Versión /09/2007 Página 22 de 82

23 interoperabilidad, encapsulamiento de funciones de negocio reusables e interfaces explícitamente independientes de la implementación) Servicios Consumidores y Proveedores representando la infraestructura de las organizaciones externas. El nodo Exposed ESB Gateway hace que un servicio de la Organización esté disponible para las otras y viceversa, de una manera controlada y segura. Aunque esto podría requerir capacidades tales como proveer y gestionar asociadas, las cuales son diferente a las capacidades del ESB, la intención de este componente es diferente de la intención del ESB, que es proporcionar una infraestructura de servicio dentro de la organización. Por estas razones, el Exposed ESB Gateway posiblemente será integrado a -pero no será parte de-, el Enterprise Service Bus (ESB). La conexión entre los nodos App Server/Services en la zona de las organizaciones externas y la zona de infraestructura de red en la zona Inter.-organizaciones podría ser un servidor HTTP, un ESB, un Exposed ESB Gateway, o un Firewall. Por lo tanto, dependiendo de los requerimientos de seguridad, el nodo Exposed ESB Gateway podrá estar dentro o fuera de la DMZ. El ESB es una herramienta de apoyo clave para una SOA al proporcionar capacidades de ruteo y transporte de requerimientos de servicios, desde quien lo requiere, hasta al proveedor del servicio correcto. El verdadero valor del concepto ESB, asimismo, es habilitar una infraestructura SOA de forma tal que refleje las necesidades cotidianas de la organización: proveer niveles de servicios adecuados y manejables, operar e integrar en un ambiente heterogéneo. Un ESB necesita una gestión y administración centralizada y la capacidad de estar físicamente distribuido Proceso Serial Expuesto (Exposed Serial Process) El patrón de aplicación de Proceso Serial Expuesto (antes, conocido como patrón Proceso Público Manejado), extiende la topología 1:N proporcionada por el patrón de aplicación Broker Versión /09/2007 Página 23 de 82

24 Expuesto, facilitando la ejecución secuencial de servicios de la organización a través de varios aplicaciones destino. Habilita la orquestación de un proceso de gestión en serie a través de los límites de la organización, en respuesta a una interacción comenzada por la aplicación Origen. El patrón de aplicación de Proceso Serial Expuesto separa la lógica del proceso la lógica de aplicación, que es distribuida atravesando los límites de la organización. La lógica de proceso es gobernada por reglas de proceso en serie que definen reglas de ejecución para cada aplicación destino, junto con las reglas de flujo de control y flujo de datos También puede incluir cualquier regla de adaptador necesaria Descripción del Patrón de Ejecución Genérico El patrón modelado abajo representa una topología básica para el patrón Proceso Serial Expuesto. Puede ser mejorado mediante clustering de nodos claves para aportar características de disponibilidad. Esta topología básica hace uso de los siguientes nodos con sus responsabilidades asociadas: Nodo de gestión del Proceso Expuesto Este nodo contiene la ingeniería del flujo de ejecución del proceso. Provee las capacidades para la automatización del proceso de negocio model-driven. También habilita rastrear el uso dado a las reglas de ejecución de proceso almacenadas en la base de datos asociada. Estos procesos pueden abarcar múltiples aplicaciones y fronteras orgánicas dentro de la Institución. El nodo mantiene estado y traza a través del flujo del proceso. De este modo, hace uso frecuentemente del repositorio asociado para guardar resultados intermedios. Este nodo también es responsable de invocar las aplicaciones Destino como le sea necesario a través de sus conectores asociados. Nodo de Conectores Los Nodos de Conectores entre la gestión de proceso y los servidores de aplicaciones/nodos de servicios, no son explícitamente modelados en este patrón de ejecución. Esto permite hacer foco en la conexión partner-to-partner. Se muestra un patrón estándar de path de conectores (firewall e infraestructura de red), pero existen otras variaciones con más o menos firewall. Versión /09/2007 Página 24 de 82

25 Los conectores de la zona segura están principalmente preocupados en la conexión lógica del path de conectores a los servicios de la aplicación. Por consiguiente, a menudo se modelan como conector de adaptadores. Las aplicaciones y los conectores menos seguros pueden ser ubicados dentro de la DMZ, dependiendo de las políticas locales de seguridad. Ellos son habitualmente ubicados como se muestra en la figura. Los conectores en la DMZ pueden ser modelizados o no. Proveen conectividad desde la Zona Segura de la Organización a la Zona Inter.-organizaciones. Pueden ser componentes de bajo nivel (ej. infraestructura TCP/IP, omitida en el diagrama), o pueden tener capacidades avanzadas como caching de contenidos reusables (ej. un Web Server) Los servicios de Directorio y Seguridad aportan servicios de autenticación y autorización. También soportan userid, contraseña y privilegios relacionados. Este nodo típicamente las hace uso de los directorios basados en LDAP. También contiene la información de configuración necesaria para soportar acceso seguro entre la Institución y los servicios de las organizaciones socias Descripción del Patrón de Ejecución SOA Esta segunda sección especializa el patrón Router para el ambiente de SOA. El Gestor de Procesos Expuesto genérico, el Directorio de Reglas e Infraestructura de las Organizaciones socias, en la figura, especializan el perfil de SOA a: Versión /09/2007 Página 25 de 82

26 una Gateway ESB Expuesto (apoyando el requisito Expuesto) un ESB (soportando la infraestructura SOA requerida para la localización transparente de servicios, interoperabilidad, encapsulamiento de funciones de negocio reusables e interfaces explícitas independientes de la implementación) un nodo de BSC (Business Service Choreography, apoyando los requisitos de Gestión de Procesos) Los Consumidores y Proveedores de servicio representados por la infraestructura de las organizaciones socias (Partner Zone) Variante Workflow Serial Expuesto Descripción: La variante Workflow Serial Expuesto del patrón de aplicación de Proceso Serial Expuesto, extiende la capacidad de orquestación de proceso serial básica apoyando interacción humana por completar ciertos pasos del proceso. Versión /09/2007 Página 26 de 82

27 Tanto para la representación Genérica como para el perfil SOA, el nodo Staff Worklist Adapter es un adaptador especializado responsable de presentar los aspectos del trabajo a ser ejecutados por una persona particular o una sección. Este adaptador habilita la interacción humana dentro de los procesos de gestión automatizados. Es la interface primaria a través de la cual las personas actúan recíprocamente dentro del workflow del extremo-a-extremo Descripción del Patrón de Ejecución Genérico Básicamente, el perfil genérico del patrón de aplicación Workflow Serial Expuesto reproduce las características del patrón Proceso Serial Expuesto, agregando la representación del nodo de intervención humana en el proceso de gestión Descripción del Patrón de Ejecución SOA Ídem, para el perfil SOA del patrón de aplicación Workflow Serial Expuesto. Versión /09/2007 Página 27 de 82

28 Versión /09/2007 Página 28 de 82

29 5.4 Self-Service Service (Autoservicio) También conocido como patrón de usuario a empresa o U2B, el patrón Autoservicio se ocupa del caso general de usuarios internos y externos que interactúan con datos y transacciones de la empresa. Las funciones empresariales específicas soportadas por las aplicaciones que automatizan este patrón de negocio varían según el sector. Ciertos enfoques en común de casos de éxito de estas variaciones se resumen en los siete Patrones de Aplicación siguientes: Patrones de Aplicación de Self-Service Service (Autoservicio) Canal Único Autónomo Canal único directamente integrado Patrón de Negocio Autoservicio Directo a host Presentación personalizada para host Router Descomposición Agente Razones de Negocio y de IT que conducen la determinación de los Patrones de Aplicación. Razones de negocio conductoras Canal único autónomo Canal único directamente integrado Directo a host Presentación personaliza para host Router Descomposición Agente Minimizar los tiempos de implementación de soluciones Mejorar la eficiencia organizacional Reducir los tiempos de propagación de los cambios Integrar múltiples formas de atención al usuario Presentar al usuario la organización en forma unificada, ocultando la existencia de unidades y subprocesos específicos Permitir personalizar la interfaz según el perfil del usuario Tabla 3 (Ref: ) Versión /09/2007 Página 29 de 82

30 Razones de TI conductoras Canal único autónomo Canal único directamente integrado Directo a host Presentación personaliza para host Router Descomposición Agente Minimizar la complejidad de las aplicaciones Minimizar el Costo Total de Propiedad (TCO) Aprovechar las habilidades existentes Aprovechar las inversiones ya realizadas Habilitar la integración de aplicaciones del back-end Mejorar la mantenibilidad Facilitar la escalabilidad Tabla 4 (Ref: ) Análisis Razones de Negocio y de IT Contexto El patrón de negocio Autoservicio suele utilizarse en soluciones de e-business que permiten a los usuarios acceder a la información y modificarla, interactuando directamente con bases de datos y sistemas empresariales básicos (core). En esencia, permite captar las interacciones directas entre el ciudadano y la Institución. Dichas interacciones pueden ir desde simple información estática hasta complejas actualizaciones en las que se utilizan los datos de la Institución Visión general Desde el punto de vista Institucional, las siguientes han sido el conjunto de características que suponemos necesarias a la Institución, manejadas como hipótesis de trabajo para la determinación del patrón de aplicación más adecuado, puestos a emplear el patrón de negocio Autoservicio: El usuario final (beneficiario, contribuyente, Institución y Empresa Pública y Privada) necesita interactuar directamente con los procesos institucionales. Los procesos institucionales deben estar integrados con los sistemas institucionales y la información existentes Debe poderse acceder a los procesos institucionales en una forma simplificada, coherente y común a través de distintos canales de distribución Adecuación Institucional al Gobierno Electrónico como forma de brindar servicios al ciudadano Desde el punto de vista de Arquitectura -centrado fuertemente en los requerimientos no funcionales y orientado a Servicios-, las siguientes han sido el conjunto de características necesarias a la Institución para satisfacer las de negocio, manejadas como razones TI para la Versión /09/2007 Página 30 de 82

31 determinación del patrón de aplicación más adecuado, puestos a emplear el patrón de negocio Autoservicio: Reducir el costo total de propiedad (TCO) Aprovechar los conocimientos existentes Aprovechar aplicaciones existentes Integrar las aplicaciones back-end Reducir los tiempos de propagación de los sucesos de negocio Facilidad de mantenimiento Escalabilidad Pautas y Recomendaciones La determinación de los Patrones de Aplicación debe encontrarse en la intersección de ambos puntos de vistas, en este caso apuntando fuertemente a Agente como en patrón de aplicación que responde tanto a los requerimientos funcionales supuestos como a los no funcionales y a la orientación a Servicios. Como consideración adicional señalamos que Router y Descomposición exhiben las mismas características IT pero difieren en las de Negocio. Recomendación: Agente es el patrón de aplicación preferido a implementar Recomendación: La Recomendación anterior marca un patrón de arquitectura que por su complejidad abarca las razones fundamentales de negocio y de tecnología que nos conducen a la exposición de funcionalidades institucionales en la Web. Pero, precisamente por su complejidad, es el patrón de más costosa implementación. Es recomendable abordar inicialmente otros patterns, que nos permitan un planteo incremental y acompañen el período de transición entre la arquitectura actual y la objetivo. Por tanto, se recomienda aplicar los siguientes dos patrones de aplicación: Router Descomposición Téngase en cuenta, además, que los patterns de mayor complejidad reusan, en general, características de los patterns de menor complejidad. Esta constante en la familia de patterns de negocio permite seleccionar patrones complejos sin pérdidas al establecer el nivel mínimo de razones de negocio y de IT que deben observar las soluciones. Versión /09/2007 Página 31 de 82

32 Características de cada Patrón Canal Único Autónomo (Stand Stand-Alone Single Channel ) Este patrón es adecuado para aplicaciones stand-alone que no necesitan integrarse a datos o aplicaciones existentes. Asume un único medio de comunicación con el usuario, generalmente un cliente Web. Consiste en una capa de presentación que maneja toda la interacción con el usuario y una capa de aplicación que contiene la lógica de negocio y el acceso a una base de datos. La comunicación entre ambas capas es sincrónica. Consideramos que este patrón no satisface nuestras necesidades porque: no permite presentar al usuario una visión unificada de la organización, ni integrar múltiples formas de comunicación, ni permitir una personalización, tampoco permite integrar aplicaciones back-end y no favorece la escalabilidad Canal Único Directamente Integrado (Directly Directly-Integrated single Channel ) (Ref: ) Este patrón provee conectividad punto a punto entre el usuario y una aplicación existente. Se asume un único canal de comunicación con el usuario y la capa de presentación maneja la interacción con el usuario. La lógica de negocios reside en la capa Web y en la aplicación backend. La capa Web puede acceder a datos locales de la aplicación, también es responsable por el acceso a aplicaciones back-end. Las aplicaciones back-end contienen lógica de negocios y al acceso a datos. La comunicación entre la capa de presentación y el la capa Web es sincrónica. La comunicación entre la capa Web y las aplicaciones back-end puede ser sincrónica o asincrónica. Consideramos que este patrón no satisface nuestras necesidades porque: no permite presentar al usuario una visión unificada de la organización, ni integrar múltiples formas de comunicación, ni permitir una personalización, y no favorece la escalabilidad. Versión /09/2007 Página 32 de 82

33 Directo a Host (As As-Is Host ) (Ref: ) Este patrón provee acceso directo a aplicaciones monolíticas existentes. La aplicación no es cambiada pero se realiza una traducción entre la modalidad de terminal de caracteres de la aplicación existente a una presentación Web. Esta traducción es rápidamente implementada pero no cambia la interacción con el usuario. La presentación y la lógica de negocios es manejada en el host. Consideramos que este patrón no satisface nuestras necesidades porque: no permite presentar al usuario una visión unificada de la organización, ni integrar múltiples formas de comunicación, ni permitir una personalización, y no favorece la escalabilidad Presentación Personalizada para Host (Customized Presentation to Host ) (Ref: ) Es una mejora sobre el patrón anterior. La aplicación back-end se mantiene sin cambios, pero una aplicación Web traduce la presentación del back-end a una interface gráfica más amigable al usuario. Como en el caso anterior las aplicaciones back-end no se enteran de esta traducción. Consideramos que este patrón no satisface nuestras necesidades porque: no permite presentar al usuario una visión unificada de la organización, ni integrar múltiples formas de comunicación, ni permitir una personalización, y no favorece la escalabilidad. Versión /09/2007 Página 33 de 82

34 Router (Enrutador) (Ref: ) Este patrón provee ruteo inteligente entre múltiples formas de comunicación con el usuario y múltiples aplicaciones back-end usando una arquitectura de hub-and-spoke. La interacción entre el usuario y la aplicación back-end es uno a uno, lo que significa que interactúa con una aplicación a la vez. El Router mantiene las conexiones con las aplicaciones back-end, pero no existe verdadera integración entre las aplicaciones. La lógica de negocios reside en la aplicación back-end. Se asume que se utilizan múltiples formas de comunicación con el usuario. El Router provee una interface común para acceder a múltiples aplicaciones back-end y actúa como un intermediario entre ellas y los canales de comunicación con el usuario. De esta manera el Router puede usar elementos de los patrones de integración Descripción del Patrón de Ejecución Genérico Router (Ref: ) Versión /09/2007 Página 34 de 82

35 Los requerimientos dinámicos son reenviados al servidor de aplicación en la red interna. En este además de la lógica de presentación puede residir alguna lógica de negocio para construir los requerimientos que se pasan al servidor de integración. El servidor de integración examina los requerimientos y los reenvía a la aplicación back-end correspondiente, donde reside la lógica de negocios. Todo esto puede implicar transformación de mensajes, protocolos y manejo de seguridad Descripción del Patrón de Ejecución Genérico (Router Variante 1) (Ref: ) En esta variante 1 del Patrón de Ejecución Genérico Router, la lógica de presentación ha sido separada de la lógica de aplicación y ubicada en un servidor de presentación Web. Versión /09/2007 Página 35 de 82

36 Descripción del Patrón de Ejecución SOA (Ref: ) En el perfil SOA, el servidor de aplicación pasa a ser un consumidor de servicios, y el back-end un proveedor de servicios, siendo conectados vía un ESB. El ESB reemplaza al servidor de integración, esto tiene las siguientes ventajas: Minimiza el numero de adaptadores requeridos. Mejora el reuso Soluciona discrepancias entre los distintos modelos de servicios. Desacopla los proveedores y consumidores de servicios. Provee un punto de acceso común para los consumidores de servicios. Provee seguridad centralizada. El uso de SOA y de un ESB da flexibilidad pudiendo proveer un amplio rango de funcionalidad, cubriendo los patrones punto a punto, ruteo y descomposición. Versión /09/2007 Página 36 de 82

37 Descomposición (Decomposition Decomposition) (Ref: ) El patrón Descomposición extiende la arquitectura de hub-and-spoke del patrón Router, descomponiendo un requerimiento del cliente en múltiples requerimientos que son ruteados inteligentemente a las aplicaciones back-end. Luego las respuestas de estos back-ends son recompuestas en una sola respuesta y enviadas al cliente. Esto efectivamente provee una interface unificada para el usuario a partir de varias aplicaciones back-end Descripción del Patrón de Ejecución Genérico Decomposition Versión /09/2007 Página 37 de 82

38 (Ref: ) En el patrón de ejecución genérico las funciones de descomposición son realizadas por el servidor de integración. Igual que en el Patrón Router, las funciones de presentación son realizadas por un servidor web y un servidor de aplicación. El servidor de integración examina los requerimientos y los reenvía a la aplicación back-end correspondiente, donde reside la lógica de negocios. Todo esto puede implicar transformación de mensajes, protocolos y manejo de seguridad. El servidor de integración puede usar una base de datos local para almacenar la información requerida para la descomposición y recomposición de los mensajes Descripción del Patrón de Ejecución Genérico (Variante ( Integration Server runtime pattern) La variante Integration Server runtime pattern del Patrón de Ejecución Genérico Descomposición es idéntica a la Variante 1 del Patrón de Ejecución Genérico Router, donde la lógica de presentación ha sido separada de la lógica de aplicación y ubicada en un servidor de presentación Web. (Cfr. Patrón de Ejecución Genérico Router (Variante 1)) El servidor de presentación Web ejecuta JSPs y servlets para proveer la lógica de presentación de la aplicación. El servidor de aplicaciones ejecuta lógica de EJB y envía requerimientos al servidor de integración. Los requerimientos son enviados desde el servidor de presentación Web al servidor de aplicaciones usando IIOP. Además, usando un servidor de presentación Web se traza la línea entre la lógica de presentación y la lógica de aplicación. Ello proporciona escalabilidad, permitiendo extender los recursos del sistema difundidos a través de múltiples máquinas -y aunque no está representado, puede extenderse para llevar a cabo balanceo de carga entre los servidores de aplicación Patrón de Ejecución Genérico (Variante ( Process Manager runtime pattern) El Patrón de Ejecución Genérico Descomposición, Variante Gestión de Proceso, es similar al Patrón de Ejecución Servidor de Integración con una diferencia significativa. Mientras que las funciones de la capa de descomposición en el patrón base son proporcionadas usando un nodo Servidor de Integración, la funcionalidad de descomposición en este patrón es proporcionada por procesos de negocio que ejecutan en un nodo Gestión de Procesos. Un proceso de negocio consiste en una serie de actividades coreografiada de manera tal que logre llevar a cabo una tarea de negocio específica. La entrada al proceso de negocio es proporcionada por el usuario vía una interface normal. Los servicios de negocio invocados desde el proceso normalmente son proporcionados por aplicaciones del back-end legadas que también han sido expuestas usando interfaces normales. Además de la lógica de presentación (por ejemplo, JSPs), el servidor de aplicaciones contiene lógica de negocio limitada, principalmente bajo la forma de servlets, controlando los requerimientos para acceder los procesos de negocio que ejecutan en el nodo de Gestión de Proceso. El servidor de aplicaciones construye una requerimiento basado en la entrada del usuario y lo pasa al nodo Gestión de Proceso. El nodo Gestión de Proceso mantiene la ingeniería de la ejecución los procesos de negocio. Tiene la capacidad de ejecutar actividades en modalidades serie o paralelo. Puede invocar que servicios del back-end sincrónicamente o asincrónicamente. En la eventualidad que la interacción humana sea requerida por el proceso de negocio, este nodo crea un "work item" e identifica una persona particular o una sección responsable para ejecutar esa tarea y agrega el "work item" a su "worklist". Los procesos que son interrumpidos pueden hacer un "rollback" completo de las tareas retornando las aplicaciones back-end a su estado original. Versión /09/2007 Página 38 de 82

39 Se usa una Base de Datos para proporcionar almacenamiento de datos persistentes y servicio de recuperación en apoyo de la ejecución del flujo del proceso. Soporta las reglas de ejecución de proceso y los resultados del intermedio de la ejecución de ciertas actividades dentro del contexto de un flujo de proceso completo. La implementación de este nodo puede involucrar varias tecnologías de persistencia de datos (tales como DBMS y archivo planos) para los diferentes tipos de datos. La lógica de negocio primaria reside en las aplicaciones back-end. Estas aplicaciones son expuestas como enterprise o Web services para acceder por el nodo Gestión de Proceso. (Ref: ) Versión /09/2007 Página 39 de 82

40 Descripción del Patrón de Ejecución SOA (Ref: ) Se puede ver que en virtud del uso de SOA y de un ESB este Patrón de Ejecución es idéntico al del Patrón Router Agente (Agent Agent) (Ref: ) El patrón Agente agrega a todo lo visto en el patrón Descomposición la posibilidad de mantener una vista unificada y persistente del cliente, que permite su explotación a efectos de personalización y venta cruzada. Versión /09/2007 Página 40 de 82

41 Patrón de Ejecución Genérico (Ref: ) Versión /09/2007 Página 41 de 82

42 6 Patrones de Integración Patrones de Integración Integración de Acceso Integración de Aplicaciones 6.1 Integración de Acceso El patrón de Integración de Acceso describe aquellos diseños reusables que habilitan el acceso a uno o más Patrones de Negocio. En particular, este patrón habilita el acceso desde múltiples canales (dispositivos) e integra los servicios comunes para soportar una interfaz de usuario y un modelo de programación consistentes para el rango completo de dispositivos (desde los que ofrecen escasas funcionalidades hasta los más ricos en capacidades). Este patrón de integración permite ofrecerles a los usuarios un mecanismo de acceso único, consistente y transparente a varias aplicaciones que podrían requerir el uso de varios mecanismos de acceso diferentes. Es aplicable cuando: Los usuarios necesitan acceso a múltiples aplicaciones y fuentes de información sin que cada una de ellas requiera autenticación separada de forma de establecer contextos de seguridad independientes Dichas aplicaciones necesitan ser accedidas desde múltiples dispositivos (cliente grueso, navegador, unidades de respuesta audible, dispositivos móviles, PDAs) Se requiere un look and feel común Los usuarios desean personalizar su elección de aplicaciones y la forma en que se le presentan Versión /09/2007 Página 42 de 82

43 6.1.1 Patrones de Aplicación de Integración de Acceso El patrón de Integración de Acceso introduce los siguientes patrones de aplicación: Client (Cliente) Thin Client (Cliente Fino) Voice-Enabled Client (Cliente con Interfaz de Voz) Distributed Presentation Client (Cliente de Presentación Distribuida) Patrón de Integración de Acceso Distributed Application Client (Cliente de Aplicación Distribuida) Distributed Rich Client (Cliente Rico Distribuido) Distributed Multimodal Client (Cliente Multimodal Distribuido) Distributed Collaboration Client (Cliente de Colaboración Distribuida) Single Sign-On (Autenticación Única) Personalized Delivery (Entrega Personalizada) Razones de Negocio y de IT que conducen la determinación de los Patrones de Aplicación. Indica capacidad provista por el Patrón Indica capacidad dependiente del dispositivo y los mecanismos de conexión Versión /09/2007 Página 43 de 82

44 Razones conductoras de IT y Negocio Cliente Fino Cliente con Interfaz de Voz Cliente de Presentación Distribuida Cliente de Aplicación Distribuida Cliente Rico Distribuido Cliente Multimodal Distribuido Cliente de Colaboración Distribuida Acceso desde múltiples dispositivos - navegación simple Acceso desde múltiples dispositivos - navegación basada en roles Integración de servicios dependiente de la ubicación geográfica Interfaz de usuario vía voz Acceso online multimodal Recepción de notificaciones simples de eventos (por ejemplo SMS) Notificación de eventos basada en suscripción Recepción y procesamiento de acciones asociadas a alertas Administración remota de configuración de dispositivos Administración remota de middleware Administración remota de aplicaciones Presentación desconectada de contenidos Web (incl. navegación offline) Procesamiento desconectado de formularios (incl. forms offline) Aplicación desconectable sin UI Aplicación desconectable con UI WEB Aplicación desconectable con UI rica Aplicación desconectable con UI multimodal Aplicación desconectable con sincronización de datos relacionales Aplicación desconectable usando mensajería transaccional Aplicación desconectable usando Web services Mensajería Instantánea Organizador Personal y acceso a desconectable Servicios de colaboración distribuidos Servicios de conectividad Versión /09/2007 Página 44 de 82

45 6.1.3 Características de cada Patrón Client (Cliente) Este grupo de patrones de aplicación busca acercar las aplicaciones a un amplio rango de dispositivos cliente, tales como PCs de escritorio, laptops, PDAs, teléfonos celulares y dispositivos embebidos Thin Client (TC, Cliente Fino) Este patrón resuelve los casos en que las aplicaciones usan un navegador instalado en el dispositivo como forma de acceder en forma sincrónica y en línea (siempre conectado) a aplicaciones Web. El navegador es la interfaz estándar usualmente provista con el dispositivo (por ejemplo, exploradores HTML o WML) Este patrón también asume que el contenido provisto por la aplicación del back-end es renderizada en forma adecuada según las capacidades del componente de presentación instalado en el dispositivo. (Ref: ) Voice-Enabled Client (VEC, Cliente con Interfaz de Voz) En este caso el cliente es una interfaz de usuario en un dispositivo con capacidades de voz (por ejemplo un teléfono fijo o móvil, o un software de telefonía VoIP instalado en un PC con parlantes y micrófono), e interactúa con una aplicación con capacidades de voz mediante redes orientadas a circuitos (por ejemplo PSTN1 o GSM2), recibiendo un canal dedicado para esa comunicación. La aplicación del back-end es capaz de comprender comandos recibidos por voz, y los convierte en comandos de computadora, usando su lógica para procesar datos. Los resultados son convertidos nuevamente a mensajes de voz comprensibles para el usuario humano y son transmitidos al cliente. La aplicación del back-end puede ser una aplicación Web, o un portal que necesita ser accedido desde clientes telefónicos. En este caso, el canal de voz se agrega al canal HTML. Versión /09/2007 Página 45 de 82

46 (Ref: ) Distributed Presentation Client (DPC, Cliente de Presentación Distribuida) Este patrón representa aplicaciones que proveen su propia capa de presentación y la ejecutan en el dispositivo cliente. El dispositivo accede en línea a la aplicación, pero también puede funcionar fuera de línea usando un almacenamiento de datos local (por ejemplo, navegando en modo offline contenidos Web almacenados en su cache local). Este patrón extiende el Thin Client con su propia interfaz de usuario específica de la aplicación (es su componente de presentación). Además del acceso sincrónico a los componentes de la aplicación back-end, este patrón permite el funcionamiento desconectado (offline) mediante la disponibilidad (en almacenamiento local del cliente) de un subset de los datos; servicios adicionales aseguran que los datos locales estén en sincronía con los datos del back-end. Además del ejemplo del navegador Web trabajando sobre su cache local, que se sincroniza cuando se restablece la conexión en línea, algunos formularios Web también pueden ser también llenados fuera de línea, y remitidos al back-end cuando la conexión esté disponible. Estos formularios pueden tener funciones sencillas de validación de campos, por ejemplo mediante JavaScript. (Ref: ) Distributed Application Client (DAC, Cliente de Aplicación Distribuida) Este patrón comprende aplicaciones que corren en el dispositivo sin proveer una interfaz de usuario. La lógica de aplicación es provista localmente, de forma tal que la aplicación puede operar independientemente de la lógica del back-end, esté o no conectada. El almacenamiento de datos necesario es provisto localmente y sincronizado con los datos del back-end bajo circunstancias configuradas (tiempo o eventos). La diferencia entre este patrón y el anterior (DPC) es la existencia de un componente de aplicación en el dispositivo y la opción de transmisión asíncrona. Además, éste no tiene componente de presentación (interfaz de usuario) en el dispositivo. Versión /09/2007 Página 46 de 82

47 Este tipo de clientes, no siempre en línea u ocasionalmente conectados, procesan datos en modalidad store and forward almacenando los datos localmente hasta que se puede establecer una conexión y transmitirlos para su posterior procesamiento en el back-end. La lógica de aplicación corre localmente aún en ausencia de conexión con el back-end. Las funcionalidades del cliente y los servicios que el dispositivo ofrece a la aplicación son altamente dependientes del dispositivo usado, por lo que es difícil generalizar este patrón. La multiplicidad de dispositivos móviles disponibles hace difícil determinar un común denominador y proveer una solución común que sirva a todos los diferentes clientes. Se define entonces un conjunto de servicios reducido sobre el que elaborar el patrón: Servicios de acceso Servicios para clientes administrados y administración de plataforma Acceso al hardware del dispositivo (Ref: ) Distributed Rich Client (DRC, Cliente Rico Distribuido) Un Cliente Rico Distribuido es un Cliente de Aplicación Distribuida con interfaz de usuario local. Esto genera mayor demanda de recursos (por ejemplo teclado y pantalla, software, bibliotecas gráficas) e implica que el usuario interactúe directamente con la aplicación en el dispositivo. Las interfaces de usuario pueden variar desde las basadas en Web hasta otras más ricas en funcionalidades. Los patrones DCC (Cliente de Colaboración Distribuido) y DMC (Cliente Multimodal Distribuido), variaciones del DRC, resuelven requerimientos específicos para aplicaciones de colaboración y multimodales. Este patrón requiere almacenamiento local de datos para lograr independencia de la aplicación del back-end en modalidad desconectada. Subconjuntos de los datos se mantienen en forma local y servicios de sincronización aseguran que los datos manipulados localmente se mantienen sincronizados con el back-end. Localmente existen entonces componentes de presentación, de lógica y acceso a los datos locales. Las capacidades provistas por la aplicación varían en complejidad y riqueza, desde una interfaz Web local hasta una altamente sofisticada interfaz rica en funciones. La multiplicidad de dispositivos móviles disponibles hace difícil determinar un común denominador y proveer una solución para un nodo intermedio que sirva a todos los diferentes clientes. Se define entonces un conjunto de servicios reducido sobre el que elaborar el patrón: Servicios de interacción (GUI) Servicios de acceso Servicios para clientes administrados y administración de plataforma Acceso al hardware del dispositivo Versión /09/2007 Página 47 de 82

48 (Ref: ) Distributed Multimodal Client (DMC, Cliente Multimodal Distribuido) Este patrón extiende el de Cliente Rico Distribuido agregándole capacidades multimodales (por ejemplo, navegación por voz en una aplicación. El uso de diferentes canales de entrada y salida para la navegación de la aplicación está especialmente cubierto por este patrón. El componente de presentación se extiende con capacidades de entrada-salida adicionales (por ejemplo micrófono y parlantes). El componente de aplicación cliente provee extensiones para los canales de presentación adicionales. El framework de la aplicación puede también proveer la tecnología para esta experiencia de usuario sobre una interfaz más rica. (Ref: ) Distributed Collaboration Client (DCC, Cliente de Colaboración Distribuida) Este patrón es una Variante del de Cliente Rico Distribuido. Cubre especialmente los requerimientos de colaboración en línea (por ejemplo mediante Mensajería Instantánea) y de servicios desconectados (por ejemplo ). Se trata de resolver los requerimientos de aplicaciones que (con fines de colaboración) necesitan conectividad en línea frecuente con su servidor. El cliente consiste en un nodo con componentes de presentación y aplicación. La lógica de aplicación se provee en forma local para asegurar una experiencia de usuario más rica y mejor desempeño. (Ref: ) Versión /09/2007 Página 48 de 82

49 Single Sign-On (Autenticación Única) El patrón de Autenticación Única provee un framework para el acceso transparente a aplicaciones a través de servicios de autenticación unificados. Este patrón admite variaciones: la primera corresponde al caso en que las funciones de autenticación se ejecutan en la capa Web. (Ref: ) El segundo caso corresponde a la situación en la que el contexto de seguridad es extendido para incluir los sistemas del back-end. (Ref: ) Personalized Delivery (Entrega Personalizada) Este patrón provee un framework para otorgar acceso a aplicaciones e información ajustadas a los intereses y los roles de un usuario o grupo específico. El patrón extiende la administración básica de usuarios recolectando perfiles ricos en datos que se pueden mantener actualizados en la sesión del usuario. Los datos recolectados pueden vincularse a preferencias de aplicaciones, de negocios, personales, de interacción o de dispositivos de acceso específicos. Versión /09/2007 Página 49 de 82

50 6.2 Integración de Aplicaciones El patrón de Integración de Aplicaciones sirve para integrar múltiples patrones de Negocio o integrar aplicaciones y datos dentro de un patrón de Negocio. Los requerimientos que ocasiona la llamada a este patrón para la ejecución transparente de múltiples aplicaciones y acceso a sus respectivos datos para automatizar una función de negocios nueva y compleja. La integración fiable de aplicaciones como ser aplicaciones separadas legadas, aplicaciones de paquetes de software, o aplicaciones personalizadas requiere el uso de patrones de replicación probados. En el nivel más alto, la integración de aplicaciones se puede dividir en dos aproximaciones esencialmente diferentes: Patrón de Integración de Aplicaciones Integración de Procesos Integración de Datos Integración de Procesos Integración del flujo funcional de procesamiento entre las aplicaciones. Los patrones de aplicación de integración de procesos son observados donde múltiples procesos de negocio son combinados para producir una nueva oferta de negocios o proveer una vista consolidada de alguna entidad del negocio con muchas representaciones en los sistemas de negocio corporativos. Este modo de integración es altamente flexible. En su forma más sofisticada permite unión tardía de los objetivos de integración y es particularmente útil atar diferentes plataformas y tecnologías. Versión /09/2007 Página 50 de 82

51 Patrones de Aplicación de Integración de Procesos Conexión Directa (Direct Connection) Variante Conexión por Mensaje (Message Connection variation) Variante Conexión por Llamada (Call Connection variation) Patrón de Integración de Procesos Broker Proceso Serial (Serial Process) Variante Router (Router variation) Variante Workflow Serial (Serial Workflow variation) Proceso Paralelo (Parallel Process) Variante Workflow Paralelo (Parallel Workflow variation) Los patrones de Integración de Procesos introducen los siguientes patrones, cuyas interacciones pueden ser tanto en la modalidad serial como paralela: Versión /09/2007 Página 51 de 82

52 Razones de Negocio y de IT que conducen la determinación de los Patrones de Aplicación. Razones de Negocio conductoras Conexión Directa = Conexión por Mensaje Conexión Directa = Conexión por Llamada Variante Router Broker Proceso Serial Variante workflow serial Proceso Paralelo Variante Workflow Paralelo Mejorar la eficiencia organizacional Reducir la latencia de los eventos del negocio Soporte a intercambio estructurado dentro de la organización Soporta flujos de mensajes de un solo sentido Soporta flujos de mensajes solicitud/respuesta en tiempo real Soporte de ruteo dinámico de mensaje a una de muchas aplicaciones destino Soporte de distribución dinámica de mensaje a múltiples aplicaciones destino Soporte de coordinación automática de flujo de procesos de negocio Reducir el ciclo de tiempo de la ejecución paralela de las porciones de un flujo de proceso Soporte de interacción e intervención humana dentro del flujo de proceso Tabla 5 (Ref: ) Versión /09/2007 Página 52 de 82

53 Razones de TI conductoras Conexión Directa = Conexión por Mensaje Conexión Directa = Conexión por Llamada Variante Ruteo Broker Proceso Serial Variante workflow serial Proceso Paralelo Variante Workflow Paralelo Minimizar costo total del propietario (TCO) Hacer uso de aptitudes existentes Hacer uso de inversiones legadas Permitir Integración de aplicación de back-end Minimizar la complejidad de la aplicación Minimizar la complejidad empresarial Mejorar Mantenibilidad Mejorar la flexibilidad externalizando la lógica de proceso desde la lógica de la aplicación Soporte de transacciones largas Características de cada Patrón Conexión Directa (Direct Connection) Tabla 6 (Ref: ) La aplicación origen usa un conector para acceder a la aplicación destino. El conector puede ser modelado explícitamente o implícitamente. Si el conector es modelado explícitamente, el modelador puede usar técnicas de descomposición y abstracción para expandir el conector al nivel de detalle apropiado. Las Reglas de Directorio y Proveedores Calidad de Servicio del Dominio pueden existir o no. Si existen, es una decisión de modelado. Versión /09/2007 Página 53 de 82

54 Ref: El Patrón de Ejecución Conexión Directa básica permite la integración entre una aplicación origen y destino que usan diferentes protocolos usando un único conector adaptador. La Conexión Directa que usa un único conector adaptador se ve en la figura siguiente: Conexión Directa usando un único adaptador Ref: Versión /09/2007 Página 54 de 82

55 La Conexión Directa puede también ser implementada usando adaptadores federados, tal como muestra la siguiente figura, para mejorar el reuso potencial en múltiples escenarios punto a punto. Soporta la conversión del request y response en un protocolo común entre adaptadores Conexión Directa usando adaptadores federados Ref: Conexión Directa SOA Hay dos formas de modelado del bus de servicios. La figura muestra un consumidor de servicios conectado a dos proveedores de servicios vía un bus de servicios simple. El consumidor de servicios (o Aplicación Origen) puede usar el bus de servicios para iniciar conexiones directas a dos proveedores de servicios; uno a la Aplicación Destino 1 y otra a la Aplicación Destino 2. Ref: Versión /09/2007 Página 55 de 82

56 Conexión Directa SOA con adaptadores federados La figura muestra el bus de servicios con los conectores adaptadores explícitamente modelados. El protocolo común o formato del bus de servicios es del tipo- X, y los conectores adaptadores del tipo- X son usados como puentes de varios consumidores/proveedores de servicio de diferentes tipos. Ref: Conexión Directa = Conexión por Mensaje (Message Connection) Permite que un par de aplicaciones dentro de la organización se comuniquen directamente. Aplica en soluciones donde el proceso de la organización no requiere una respuesta de la aplicación destino dentro del alcance de la iteración. Ref: Versión /09/2007 Página 56 de 82

57 Conexión Directa = Conexión por Llamada (Call Connection) Permite que un par de aplicaciones dentro de la organización se comuniquen directamente. Aplica en soluciones donde el proceso de la organización depende que la aplicación destino procese un requerimiento y devuelva una respuesta dentro del alcance de la iteración. Ref: Variante Router Aplica a soluciones donde la aplicación origen inicia una interacción que es remitida a más de una de las múltiples aplicaciones destino. Permite una conectividad 1:1 donde la capa de reglas del router selecciona el destino. Ref: El nodo Router provee la lógica para realizar un ruteo inteligente de mensajes a una aplicación destino por vez. No incluye la distribución simultánea o capacidades de descomposición que el nodo Broker provee. Ref: Versión /09/2007 Página 57 de 82

58 Conexión Directa = Conexión por Llamada SOA (SOA Call Connection) Los requerimientos de ruteo de Servicios desde los consumidores de servicios al proveedor de servicios relevante están basados en una tabla de ruteo. La transformación del protocolo, permite el desacople del protocolo que es usado entre los consumidores y los proveedores de servicios Broker Ref: Permite que una única interacción desde la aplicación origen sea distribuida a múltiples aplicaciones destino en forma concurrente. Este patrón de aplicación reduce la proliferación de conexiones punto-a-punto. Separa la lógica de la aplicación de la lógica de distribución basada en reglas del broker. La descomposición/recomposición de la interacción es administrada por la capa de reglas del broker. Ref: Versión /09/2007 Página 58 de 82

59 La capa Broker en el patrón de Aplicación está implementada con el nodo Broker. El nodo Broker es responsable del ruteo y distribución de los mensajes entrantes de las aplicaciones destino. Tiene la habilidad de descomponer y recomponer mensajes. Los nodos Servidor de Aplicaciones/Servicios ejecutan la lógica de las aplicaciones destino y origen. Ref: Pub/Sub es una variante del patrón de aplicación Broker. En esta variante, el nodo Broker ofrece una calidad dinámica de servicio llamado Pub/Sub. Es una Colaboración compuesta por dos tipos de interacciones. La primera de estas es la variante Conexión por Mensaje. Esto describe una interacción suscribir/desuscribir que permite a las Aplicaciones Destino alterar el contenido de las Reglas de Directorio para agregarse o removerse de las listas de distribución. El segundo tipo de interacción es la interacción Broker la cual describe como una única Aplicación Fuente puede usar el nodo Broker para interactuar con múltiples Aplicaciones Destino. La calidad de servicio Pub/Sub puede ser además calificada como sincrónica o asincrónica. Una interacción sincrónica ocurre cuando la Aplicación Destino solamente recibe mensajes desde el nodo Broker mientras está en línea. Una interacción asincrónica ocurre cuando los mensajes desde el nodo Broker son encolados para la Aplicación Destino mientras está fuera de línea. Versión /09/2007 Página 59 de 82

60 Ref: Broker SOA (patrón ESB) El uso de un Enterprise Service Bus ofrece los siguientes beneficios: El ESB es un bus con una única configuración e implementación distribuida. Administrar las comunicaciones a través del bus provee muchas ventajas, incluyendo desacople de los consumidores y proveedores de servicios, y el control descentralizado de un espacio de nombres de servicios. La conversión de protocolo ocurre dentro del ESB (por ejemplo, SOAP/HTTP a SOAP/JMS). Los Consumidores usan un protocolo para invocar servicios que son expuestos usando un protocolo diferente. El ESB provee requerimientos y respuestas de servicios de logging y transformación. El ESB puede proveer seguridad centralizada para invocaciones de Web Services. El ESB provee un punto de acceso común para los consumidores que necesitan acceso a los proveedores de servicios. El ESB intercepta y rutea los requerimientos que son relevantes al proveedor del servicio. Un cambio en la ubicación del proveedor del servicio solamente afecta al ruteo del ESB; la ubicación del proveedor del servicio permanece transparente al consumidor del servicio. Versión /09/2007 Página 60 de 82

61 Ref: Broker SOA = Variante ESB Integrados (patrones Emergentes) Los siguientes son todos los patrones emergentes que los arquitectos expertos en integración esperan ver en el futuro. Patrones de Topología ESB (patrones Emergentes) o ESBs Conectados Directamente o ESBs Brokered o ESBs Federados Patrones de Gobierno ESB (patrones Emergentes) Patrones de Adaptadores ESB (patrones Emergentes) o Conector Adaptador o Conector Adaptador Servicio de Limites o Compuesto Patrones de Topología ESB (patrones Emergentes) Describe relaciones topológicas entre ESBs ESBs Conectados Directamente El patrón ESBs Conectados Directamente para integrar ESBs es el tipo más simple de interacción y está basado en una topología punto-a-punto. Usar este patrón resultará en la comunicación directa entre ESBs. Versión /09/2007 Página 61 de 82

62 Ref: ESBs Brokered El patrón ESBs Brokered separa la lógica de interacción de las reglas del negocio de los ESBs. Este patrón reduce el número de conexiones punto-a-punto lo cual es un beneficio sobre el patrón ESBs Directamente Conectados. Ref: Versión /09/2007 Página 62 de 82

63 ESBs Federados El patrón ESBs Federados agrega orquestación a los requerimientos de consumo del servicio el cual se expande a múltiples ESBs y/o proveedores de servicios. También agrega la habilidad de anexar un consumidor del servicio directamente al componente Hub. Ref: Patrones Adaptadores ESB (patrones Emergentes) Los patrones Adaptador ESB describen como los ESBs enviarán y aceptarán mensajes y, lo más importante, el contexto del mensaje. La siguiente tabla lista las diferencias mayores entre los dos patrones Adaptadores ESB. Driver Conector Adaptador Conector Adaptador Servicio de Limites Servicio de Vinculación Tiempo de Diseño Tiempo de Ejecución Servicios Compartidos Pocos Muchos Colaboraciones Estático Dinámico Esfuerzo de Implementación Inicial Menor Mayor Esfuerzo de Modificación Mayor Menor Conector Adaptador El Patrón Conector Adaptador es un patrón establecido y no es único para la integración de ESB. Es un patrón común cuando se conectan aplicaciones heterogéneas. En el caso de integración este patrón soporta la interacción entre un consumidor del servicio en un ESB local y un proveedor del servicio en un ESB externo. La lógica para traducir los comportamientos de los ESB (por ejemplo logging, entrega segura, y seguridad) para soportar la interacción son Versión /09/2007 Página 63 de 82

64 construidos en el conector adaptador y luego vinculado al conector adaptador en tiempo de diseño. Ref: Conector Adaptador Servicios de Límites El Conector Adaptador Servicios de Limites es un patrón emergente para crear en tiempo de ejecución (opuesto a tiempo de diseño) interacciones configurables y compuestas entre aplicaciones. El Conector Adaptador Servicios de Límites vive en la frontera de una aplicación y toma el contexto de un evento fuera de los límites y lo traduce a un contexto entendido dentro del límite. También toma el contexto interno del evento y lo prepara para el consumo externo. Ref: Versión /09/2007 Página 64 de 82

65 Compuesto Como los patrones Gobierno y Topología es posible usar más de un patrón Adaptador ESB. Es dudoso que cualquier instancia de ESBs integrados sea implementada solamente usando el patrón Conector Adaptador o Conector Adaptador Servicios de Límites. Las razones de usar ambos patrones Adaptador ESB pueden ser financieras o técnicas y será necesario elegir entre implementar un patrón u otro Proceso Serial (Serial Process) Facilita la ejecución serial de servicios de la organización hospedadas por varias aplicaciones destino. Por tanto, permite la orquestación de un proceso de la organización serial en respuesta a la interacción iniciada por una aplicación origen. Ref: Esta topología básica utiliza los siguientes nodos con sus responsabilidades asociadas: Nodo Administrador de Proceso Este Nodo contiene el motor de ejecución del flujo del proceso. Provee la capacidad para la automatización del proceso del manejador del modelo del negocio. Permite seguir la pista aprovechando las reglas de ejecución del proceso almacenado en la base de datos asociada. Estos procesos pueden expandirse en múltiples aplicaciones y los límites organizacionales dentro de la empresa. El nodo mantiene el estado y sigue la pista de la secuencia a través del flujo del proceso. Haciendo esto, a menudo utiliza el repositorio asociado para almacenar los resultados intermedios. También es responsable de invocar las aplicaciones destino como a través de sus conectores asociados necesarios. Nodos Conectores Un nodo conector es usado para proveer la conectividad entre: o o El nodo servidor de aplicaciones/servicios y el nodo administrador de proceso. Esto permite que una aplicación fuente se comunique con un nodo administrador de proceso. Los administradores de Proceso usualmente soportan múltiples tipos de conectores. Versión /09/2007 Página 65 de 82

66 o o El nodo administrador de proceso y un nodo servidor de aplicaciones/servicios. Esto permite que un administrador de proceso se comunique con una aplicación destino. Los administradores de Proceso usualmente soportan múltiples tipos de conectores. Nodo Reglas de Directorio Este nodo provee un almacenamiento de datos persistente y servicio de recuperación en soporte de la ejecución del flujo del proceso. Contiene las Reglas del Proceso de Ejecución. Ref: Proceso o Serial SOA (patró( patrón BSC) El Patrón Coreografía Servicio de Negocio (Business Service Choreography -BSC) permite el desarrollo y la ejecución de la lógica del flujo del proceso del negocio y gobierna la secuencia y el control de las invocaciones del servicio. El proceso del negocio está controlado centralmente y no es parte de la lógica de los programas en las aplicaciones individuales. Por tanto, además de tener el proceso del negocio definido en múltiples aplicaciones y dentro de las interacciones entre estas múltiples aplicaciones, puede ser modelada e implementada por una función central. Esto facilita la implementación de los cambios en el proceso del negocio, monitoreo y análisis de la ejecución del proceso del negocio. Los principales beneficios de usar Coreografía de Servicios de Negocio son: Flexibilidad: Externalizando la lógica del proceso de las aplicaciones individuales. Interacción Humana: Facilitando varias funciones tales como aprobación, investigación y reclamo. Reusabilidad de los componentes de software o servicios en el proceso, resultando en el ahorro de costos. Versión /09/2007 Página 66 de 82

67 La construcción de procesos desde los servicios con interfaces explícitas permite la fácil sustitución de una interface de servicios en otra. Ref: Variante Workflow Serial (Serial Workflow variation) Extiende la capacidad de orquestación del proceso serial básico soportando la interacción humana para completar ciertos pasos del proceso. Ref: Esta topología básica utiliza los siguientes nodos con las responsabilidades asociadas: Nodo Administrador de Workflow Versión /09/2007 Página 67 de 82

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

Módulo 2. Arquitectura

Módulo 2. Arquitectura Módulo 2. Arquitectura Introducción Objetivos o Analizar la arquitectura física y lógica de la plataforma Agrega. o Identificar los componentes más importantes de la arquitectura física. o Exponer las

Más detalles

Introducción a Oracle Identity Management Informe Ejecutivo de Oracle Junio de 2008

Introducción a Oracle Identity Management Informe Ejecutivo de Oracle Junio de 2008 Introducción a Oracle Identity Management Informe Ejecutivo de Oracle Junio de 2008 Introducción a Oracle Identity Management INTRODUCCIÓN Oracle Identity Management, la mejor suite de soluciones para

Más detalles

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3

Más detalles

Acoplamiento e interoperabilidad

Acoplamiento e interoperabilidad Máster Universitario en Ingeniería Informá3ca Acoplamiento e interoperabilidad Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 Acoplamiento débil Tipos de acoplamiento Cabalgando el

Más detalles

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Implantación de una arquitectura orientada a servicios. Un caso de uso Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Introducción Los compromisos

Más detalles

Arquitectura de Referencia Arquitectura SOA de Referencia

Arquitectura de Referencia Arquitectura SOA de Referencia Especificación BPS -Arquitectura SOA de Referencia 2009-10-01 Documento de Especificación de la Arquitectura del BPS Arquitectura de Referencia Arquitectura SOA de Referencia Versión 0.9 Octubre 2009 ARCHIVO:

Más detalles

Tema 4: Diseño de flujos interaplicación

Tema 4: Diseño de flujos interaplicación Tema 4: Diseño de flujos interaplicación 4.1 Introducción a los Sistemas EAI Modelo de referencia (1) INTEGRACIÓN B2B INTEGRACIÓN DE APLICACIONES Y PROCESOS INTEGRACIÓN DE DATOS INTEGRACIÓN DE PLATAFORMA

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos Espiñeira, Sheldon y Asociados No. 4-2010 Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción 4 Qué

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic ARQUITECTURAS ORIENTADAS A SERVICIOS SOA en la Seguridad Social por Mario triguero garrido 48 boletic El deber de ofrecer al ciudadano el mejor servicio ha sido siempre la motivación por la cual la Gerencia

Más detalles

ARQUITECTURAS DE PROCESOS DE NEGOCIOS INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

ARQUITECTURAS DE PROCESOS DE NEGOCIOS INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN ARQUITECTURAS DE PROCESOS DE NEGOCIOS INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN ARQUITECTURA SOA Services Oriented Arquitecture SOA como arquitectura para BPM Las organizaciones deben

Más detalles

PG2010 Integración de Enterprise Service Buses

PG2010 Integración de Enterprise Service Buses PG2010 Integración de Enterprise Service Buses Integrantes: Fabián Álvarez Victor Dumas Carlos Gutiérrez Cliente: BPS - Carlos Suárez Tutores: Laura González Marcelo Caponi Martín Rantz Agenda Introducción

Más detalles

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Introducción a los Servicios Web Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Servicios Web y Soa En un contexto SOA y los servicios web son una oportunidad de negocios en la actualidad.

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Introducción a SOA (II) Huibert Aalbers Senior Certified Software IT Architect

Introducción a SOA (II) Huibert Aalbers Senior Certified Software IT Architect Introducción a SOA (II) Huibert Aalbers Senior Certified Software IT Architect IT Insight podcast Este podcast pertenece a la serie IT Insight Pueden suscribirse al podcast a través de itunes. El material

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Gestión de la Seguridad Informática

Gestión de la Seguridad Informática Documento de Gestión de la Seguridad Informática Versión 01 ARCHIVO: ANEXO6_GESTION DE LA SEGURIDAD INFORMATICA Nº. PÁG: 1 / 6 CREADO: 11/11/a TABLA DE CONTENIDO 1. GESTIÓN DE SEGURIDAD INFORMÁTICA...

Más detalles

6.1 Introducción a los sistemas EAI

6.1 Introducción a los sistemas EAI 6.1 Introducción a los sistemas EAI Integración de Aplicaciones (1) El problema de la integración de aplicaciones consiste en hacer colaborar entre sí a aplicaciones distribuidas, heterogéneas y posiblemente

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

Más detalles

Service Oriented Architecture: Con Biztalk?

Service Oriented Architecture: Con Biztalk? Service Oriented Architecture: Con Biztalk? Pablo Abbate Servicios Profesionales Danysoft SOA supone una nueva forma de pensar acerca de la arquitectura IT para las empresas. De hecho, es una asociación

Más detalles

Arquitectura SOA para la integración entre software libre y software propietario en entornos mixtos.

Arquitectura SOA para la integración entre software libre y software propietario en entornos mixtos. I JORNADAS DE SIG LIBRE Arquitectura SOA para la integración entre software libre y software propietario en entornos mixtos. Alejandro Guinea de Salas (1), Sergio Jorrín Abellán (2) (1) Director de Geograma

Más detalles

ARC 101 Architecture Overview Diagram

ARC 101 Architecture Overview Diagram ARC 101 Architecture Overview Diagram Estudio de Arquitectura para la evolución tecnológica de los aplicativos de ATyR Banco de Previsión Social ATYR Evolución Tecnológica Pág 1 of 10 Tabla de Contenidos

Más detalles

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico Capítulo II Guía Gerencial de la Plataforma de Gobierno Electrónico 12 Capítulo II Guía Gerencial de la PGE Introducción Este capítulo presenta el concepto de gobierno electrónico, los desafíos de interoperabilidad

Más detalles

Tema 1. Arquitectura Cliente/Servidor

Tema 1. Arquitectura Cliente/Servidor Tema 1. Arquitectura Cliente/Servidor SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs 27 de septiembre de 2009 FJRP, FMBR [sistemas cliente-servidor] CCIA 1.1 Sistemas

Más detalles

Oracle Application Server 10g

Oracle Application Server 10g Oracle Application Server Oracle Application Server 10g La plataforma de aplicaciones más completa e integrada del mercado Puntos a comparar Lo más importante antes de realizar un análisis comparativo

Más detalles

Introducción a Windows 2000 Server

Introducción a Windows 2000 Server Introducción a Windows 2000 Server Contenido Descripción general 1 Administración de los recursos utilizando el servicio de Directorio Activo 2 Administración de una red 3 Mejora del soporte de red y comunicaciones

Más detalles

WebSphere Message Broker como Entreprise Service Bus

WebSphere Message Broker como Entreprise Service Bus IBM Software Group WebSphere Message Broker como Entreprise Service Bus Irene Couso, IT Specialist, SWG WebSphere Services Agenda WebSphere Problemática En Los Clientes Por Qué Esta Arquitectura? Oferta

Más detalles

Indice TECNIMAP CACERES 2000 1

Indice TECNIMAP CACERES 2000 1 Indice Introducción 2 Enterprise Information Portals (EIP) o Portales Corporativos 3 Qué es un Enterprise Information Portal? 3 Necesidades a cubrir por un EIP 4 Servicios proporcionados por plataforma

Más detalles

Qué significa workflow? Qué es un proceso de negocio? Qué es un software de workflow? Qué es Q-flow?

Qué significa workflow? Qué es un proceso de negocio? Qué es un software de workflow? Qué es Q-flow? Qué significa workflow? Es un término en inglés para proceso de negocio. Su uso en ese idioma se extendió para todo lo vinculado a herramientas informáticas que contribuyen a la automatización y al control

Más detalles

Implantación Plataforma SOA. La experiencia del Principado de Asturias

Implantación Plataforma SOA. La experiencia del Principado de Asturias Implantación Plataforma SOA La experiencia del Principado de Asturias I. Situación inicial II. Necesidades III. Búsqueda de soluciones IV. Solución seleccionada V. Implantación I. Situación inicial La

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

Taller de Sistemas de Información 2

Taller de Sistemas de Información 2 Taller de Sistemas de Información 2 Clase 1 Aruitecturas y Middlewares Contenido Aruitectura de un sistema Evolución de las aruitecturas Monolíticas File sharing Cliente/Servidor En capas SOA Middlewares

Más detalles

Desarrollo de Software con enfoque en el Negocio

Desarrollo de Software con enfoque en el Negocio Desarrollo de Software con enfoque en el Negocio Andrea Delgado Instituto de Computación Facultad de Ingeniería Universidad de la República 11300, Montevideo, Uruguay adelgado@fing.edu.uy Resumen Las Organizaciones

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

SISTEMAS DE INFORMACIÓN III TEORÍA

SISTEMAS DE INFORMACIÓN III TEORÍA CONTENIDO: Introducción a los Web services Las bases de los Web services La nueva generación de la Web Interactuando con los Web services La tecnología de Web services XML: Lo fundamental WSDL: Describiendo

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

MIGRACIÓN DE UNA ARQUITECTURA TRADICIONAL A UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA)

MIGRACIÓN DE UNA ARQUITECTURA TRADICIONAL A UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA) MIGRACIÓN DE UNA ARQUITECTURA TRADICIONAL A UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA) Nelson Beltran Galvis Grupo de Investigación de Ingeniería de Software, Universidad Francisco de Paula Santander.

Más detalles

Por qué MobilityGuard OneGate?

Por qué MobilityGuard OneGate? Para Acceso de Cualquier Escenario Solo Una Solución Por qué MobilityGuard OneGate? Escenarios 1 Acceda desde cualquier lugar 2 Identifique sólidamente los usuarios 3 No más notas de recordatorio con ingreso

Más detalles

Arquitectura y Diseño de la Solución

Arquitectura y Diseño de la Solución Arquitectura y Diseño de la Solución Recuento de Conceptos importantes Modelamiente / Versionamiento de trámites Vista Conceptual Subsistemas Funcionales Principales Detalle de los subsistemas Vista de

Más detalles

Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. Contexto

Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio. Contexto Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio Parra Julián Matias 1, Mg. Patricia Bazán 2, Lic. José Martinez Garro 3 1 3 Facultad de Informática

Más detalles

El valor de una infraestructura optimizada

El valor de una infraestructura optimizada El valor de una infraestructura optimizada El Estudio del Estado del CIO 2006 (CIO Research, 2006) muestra que los CIO están buscando, cada vez más, introducir, de forma proactiva, soluciones de tecnología

Más detalles

ESB. Norberto Fernández Departamento de Ingeniería Telemática http://www.it.uc3m.es/berto/ Tecnologías de Distribución de Contenidos - UC3M 1

ESB. Norberto Fernández Departamento de Ingeniería Telemática http://www.it.uc3m.es/berto/ Tecnologías de Distribución de Contenidos - UC3M 1 ESB Norberto Fernández Departamento de Ingeniería Telemática http://www.it.uc3m.es/berto/ 1 Motivación EAI (Enterprise Application Integration) Una organización tiene distintas suborganizaciones con distintos

Más detalles

Boletín de Asesoría Gerencial* Arquitectura orientada a servicios (SOA)

Boletín de Asesoría Gerencial* Arquitectura orientada a servicios (SOA) Espiñeira, Sheldon y Asociados * No. 12-2009 *connectedthinking Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

Más detalles

D E S C R I P C I Ó N

D E S C R I P C I Ó N ADAPTOR pertenece a la nueva generación en herramientas de Integración de Sistemas (EAI) fuertemente inspirada en el paradigma SOA y capaz de funcionar en un bus de servicios (ESB), es la forma más eficiente

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

Q-expeditive Publicación vía Internet

Q-expeditive Publicación vía Internet How to Q-expeditive Publicación vía Internet Versión: 2.0 Fecha de publicación 11-04-2011 Aplica a: Q-expeditive 3 Índice Introducción... 3 Publicación de servicios... 3 Ciudadanos... 3 Terminales de auto

Más detalles

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario

Más detalles

Creando Arquitecturas

Creando Arquitecturas Creando Arquitecturas orientadas a servicios SOA Suite Abril 2013 Buenos Aires - Argentina Índice 1. Introducción. 2. Nuestro camino para la creación de SOAs. 3. Como justificar el cambio? 4. Nuestras

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

Cómo lograr una implementación exitosa de SOA?

Cómo lograr una implementación exitosa de SOA? Software Huibert Aalbers Certified Executive Software IT Architect BUE Technical Sales, SW Services Manager IBM de Mexico 2007 IBM Corporation Agenda!Interoperabilidad! De dónde viene SOA?!Las distintas

Más detalles

La integración de información. Presente y futuro de la empresa moderna

La integración de información. Presente y futuro de la empresa moderna La integración de información. Presente y futuro de la empresa moderna Ing. Josue Carralero Iznaga, MSc. ISPJAE, Facultad de Ingeniería Informática, Departamento de Ingeniería de Software. Complejo de

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

MARCANDO LA DIFERENCIA

MARCANDO LA DIFERENCIA MARCANDO LA DIFERENCIA INTEGRACIÓN RÁPIDA Y CONFIABLE entre sus sistemas Simplifique la integración y el mantenimiento de su lógica de negocio con nuestra arquitectura orientada a servicios. Ahorre dolores

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio Otro camino para el BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 El BPM El BPM (Business Process Management) no es solo una tecnología, además a grandes rasgos es una disciplina

Más detalles

INTEGRACIÓN DE SISTEMAS HEREDADOS

INTEGRACIÓN DE SISTEMAS HEREDADOS CAPÍTULO 2 INTEGRACIÓN DE SISTEMAS HEREDADOS En el presente capítulo, se presenta el problema de integración de sistemas de Software. Una de cuyas características es la presencia de los llamados Sistemas

Más detalles

CARRERA TITULO DEL TRABAJO CURSO

CARRERA TITULO DEL TRABAJO CURSO CARRERA Ingeniería Informática TITULO DEL TRABAJO SOA CURSO Tópicos de Ingeniería del Software CÉSAR ESTRADA CONDORI MAYRA GOMEZ QUEVEDO LUIS MUǸOS ESCAPA ALAN A. ROJAS MARROQUIN SEMESTRE IX 2010 Los alumnos

Más detalles

2.1 Compuertas para Bases de Datos

2.1 Compuertas para Bases de Datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Uno de los aspectos mas importantes en un sistema multibase de datos es la forma en como llevar a cabo la comunicación

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Notas. Introducción. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow. Palabras claves: Groupware, Workflow, BPCM, WfMC.

Notas. Introducción. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow. Palabras claves: Groupware, Workflow, BPCM, WfMC. Breve Introducción a los Sistemas Colaborativos: Groupware & Workflow Palabras claves: Groupware, Workflow, BPCM, WfMC. Introducción A partir de la llegada de las computadoras personales al ambiente empresarial

Más detalles

Taller de Sistemas de Información 3. Presentación SCA

Taller de Sistemas de Información 3. Presentación SCA Taller de Sistemas de Información 3 Presentación SCA Integrantes: Gustavo Fava Diego Salido Marcos Techera agosto de 2008 TSI 3 1 Introducción a SCA Aplicación: conjunto de componentes de software trabajando

Más detalles

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

Más detalles

Jaime Orlando Moreno, Jorge Humberto Arias Cámara de Comercio de Bogota {jaimem,arquitectodes}@ccb.org.co

Jaime Orlando Moreno, Jorge Humberto Arias Cámara de Comercio de Bogota {jaimem,arquitectodes}@ccb.org.co Caso de Estudio: Proyecto SIREP2 Estructura, rol e importancia de un ESB en un proyecto Empresarial centrado en procesos de negocio (BPM) y soportados en reusabilidad de Servicios (SOA) Jaime Orlando Moreno,

Más detalles

ARQUITECTURA DE DISTRIBUCIÓN DE DATOS

ARQUITECTURA DE DISTRIBUCIÓN DE DATOS 4 ARQUITECTURA DE DISTRIBUCIÓN DE DATOS Contenido: Arquitectura de Distribución de Datos 4.1. Transparencia 4.1.1 Transparencia de Localización 4.1.2 Transparencia de Fragmentación 4.1.3 Transparencia

Más detalles

Oracle WebLogic Server 11g: Manejo de Usuarios y Grupos

Oracle WebLogic Server 11g: Manejo de Usuarios y Grupos Newsletter Noviembre 2012 Oracle WebLogic Server 11g: Manejo de Usuarios y Grupos Contenido Por Ing. Iván García igarcia@datum.com.gt Página: El manejo de seguridad en los ambientes Web es uno de los puntos

Más detalles

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Isaac Gutiérrez Gómez, Salvador Otón Tortosa Universidad de Alcalá, Departamento de Ciencias de la Computación, 28871 Alcalá de Henares, Spain igutierrez09@yahoo.es, salvador.oton@uah.es

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

ARC 108 Component Model

ARC 108 Component Model ARC 108 Component Model Evolución Tecnológica de RNOM Banco de Previsión Social Tabla de Contenidos ARC 108 Component Model 1. INTRODUCCIÓN 3 2. OBJETIVO 4 3. NOTACIÓN 5 4. ARQUITECTURA GLOBAL 6 4.1. DIAGRAMA

Más detalles

Oracle Service Bus Enrique Martín Casado Presales Manager

<Insert Picture Here> Oracle Service Bus Enrique Martín Casado Presales Manager Oracle Bus Enrique Martín Casado Presales Manager Partimos de una Necesidad Para mejorar la productividad y la competitividad de nuestras organizaciones, cada día es más necesario

Más detalles

MODELADO DE OBJETOS DE DATOS

MODELADO DE OBJETOS DE DATOS Manual Página Web MODELADO DE OBJETOS DE DATOS MANUALES ESPECIALES Documento: Manual Páginas Web (SemanticWebBuilder). Fecha de Elaboración: Marzo de 2009. INFOTEC CONACYT FIDEICOMISO. Página i Glosario

Más detalles

Components & Connectors Viewtype. Estilos

Components & Connectors Viewtype. Estilos Components & Connectors Viewtype Estilos 1 Estilos Especializan el C&C viewtype introduciendo tipos de componente y conector a los cuales pertenecerán las instancias del modelo Especifican patrones de

Más detalles

Qué ofrece Autentia Real Business Solutions S.L?

Qué ofrece Autentia Real Business Solutions S.L? Avenida de Castilla,1 - Edificio Best Point - Oficina 21B 28830 San Fernando de Henares (Madrid) tel./fax: +34 91 675 33 06 info@autentia.com - www.autentia.com Qué ofrece Autentia Real Business Solutions

Más detalles

Integración de Aplicaciones de Negocio ÍNDICE: Presentación Integración de Aplicaciones de Negocio 01 Infraestructura Tecnológica de Integración 02 Servicios Web 03 Tecnología de portal 04 Arquitectura

Más detalles

Facultad de Ingeniería Informática. Informe de las Prácticas Profesionales

Facultad de Ingeniería Informática. Informe de las Prácticas Profesionales Facultad de Ingeniería Informática CEIS Informe de las Prácticas Profesionales Título: Informatización de los Procesos de Negocio Solicitud de Trabajo Extra laboral en el CITI, a través de la BPMS BizAgi

Más detalles

Trabajo de Investigación

Trabajo de Investigación Escuela Técnica Superior de Ingeniería Informática Departamento: Ingeniería de Software y Sistemas Informáticos Trabajo de Investigación Arquitecturas Software: Gestión de los atributos de calidad de un

Más detalles

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

Informe de avance Implementación herramientas de back-end (3-III).

Informe de avance Implementación herramientas de back-end (3-III). Proyecto RG-T1684 Desarrollo e implementación de las soluciones Prueba piloto del Componente III Informe Número 1. Informe de avance Implementación herramientas de back-end (3-III). Lautaro Matas 11/04/2013

Más detalles

www.microsoft.com/office/sharepointserver www.abd.es Contenido empresarial administrado en una interfaz de usuario basada en Web.

www.microsoft.com/office/sharepointserver www.abd.es Contenido empresarial administrado en una interfaz de usuario basada en Web. Microsoft Office SharePoint Server 2007 es un conjunto integrado de características de servidor que puede contribuir a mejorar la eficacia organizativa al ofrecer completas funciones de administración

Más detalles

Aproximación al CONCEPTO

Aproximación al CONCEPTO 18 Aproximación al CONCEPTO LA NECESIDAD DE INTERCAMBIAR INFORMACIÓN ENTRE DEPARTAMENTOS Y ÁREAS DE NEGOCIO SE HA VUELTO CRUCIAL Y HA HECHO QUE LAS EMPRESAS VEAN LA INTEGRACIÓN COMO UN ELEMENTO CLAVE PARA

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Gestión del Portfolio de Proyectos HP Portfolio & Project Management. Información de Producto. 2010 Dirección de Consultoría

Gestión del Portfolio de Proyectos HP Portfolio & Project Management. Información de Producto. 2010 Dirección de Consultoría Gestión del Portfolio de Proyectos HP Portfolio & Project Información de Producto 2010 Dirección de Consultoría 2 1. Introducción Actualmente las organizaciones necesitan hacer frente a la complejidad

Más detalles

SONIC ESB 7. CAPACIDADES CLAVE > Conecta, actúa de mediador y controla. BENEFICIOS CLAVE > Crea nuevos procesos utilizando las

SONIC ESB 7. CAPACIDADES CLAVE > Conecta, actúa de mediador y controla. BENEFICIOS CLAVE > Crea nuevos procesos utilizando las CONNECT EVERYTHING. ACHIEVE ANYTHING. TM HOJA DE DATOS CAPACIDADES CLAVE > Conecta, actúa de mediador y controla los servicios, donde sea que estén implantados > Comunicaciones rápidas, confiables y seguras

Más detalles

LA IMPORTANCIA DE SOA

LA IMPORTANCIA DE SOA LA IMPORTANCIA DE SOA En el mundo de negocios de ahora, la habilidad de adaptar la infraestructura de tecnología de información de manera rápida, es imperativa. Muchos están tomando la decisión de invertir

Más detalles

Utilizar los servicios de Index Service para buscar información de forma rápida y segura, ya sea localmente o en la red.

Utilizar los servicios de Index Service para buscar información de forma rápida y segura, ya sea localmente o en la red. Funciones de servidor La familia Windows Server 2003 ofrece varias funciones de servidor. Para configurar una función de servidor, instale dicha función mediante el Asistente para configurar su servidor;

Más detalles

La aplicación práctica en el mundo empresarial de los estándares Web

La aplicación práctica en el mundo empresarial de los estándares Web La aplicación práctica en el mundo empresarial de los estándares Web El problema de la integración inter/intra empresas y la familia "XML" Enrique Bertrand XML Business Integration, Regional Director Software

Más detalles

Service Broker. Bind. Service Consumer. Service Provider

Service Broker. Bind. Service Consumer. Service Provider En este capítulo, usted podrá empezar por mirar a la arquitectura orientada al servicio como un concepto en arquitectura para aplicaciones distribuidas. A continuación usted examinará cómo estas arquitecturas

Más detalles

ARQUITECTURAS DE SOFTWARE ORIENTADAS A SERVICIOS

ARQUITECTURAS DE SOFTWARE ORIENTADAS A SERVICIOS ARQUITECTURAS DE SOFTWARE ORIENTADAS A SERVICIOS ANDRES CAMILO ROJAS M. Universidad Piloto de Colombia Ingeniería de Sistemas Séptimo Semestre CONCEPTOS: AGENDA Que es Arquitectura de Software Que es una

Más detalles

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD BPMN Notación de modelado de procesos de negocio BPMN Fue desarrollado por la BPMI (Business Process Management Initiative) Objetivos: Proveer una notación entendible para cualquiera desde el analista

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Concepto. Las empresas como ecosistemas de relaciones dinámicas

Concepto. Las empresas como ecosistemas de relaciones dinámicas Concepto Las empresas como ecosistemas de relaciones dinámicas PÁG 02 Hoy en día, ante la creciente necesidad de integración de los procesos de negocio, las empresas se enfrentan al desafío de innovar

Más detalles

Fecha Publicación: 3 de Noviembre 2009. BPM Business Process Management Gestión de Procesos de Negocio

Fecha Publicación: 3 de Noviembre 2009. BPM Business Process Management Gestión de Procesos de Negocio BPM Business Process Management Gestión de Procesos de Negocio Palabras Clave: BPM, Business Process Management, Workflow, Gestión de Procesos de Negocio, Reingeniería de Procesos, Optimización de Procesos,

Más detalles