Propuesta de una Arquitectura de Software Empresarial Orientada a Servicios

Propuesta de una Arquitectura de Software Empresarial Orientada a Servicios Pedro Nolasco Bonillo Ramos - [email protected] The present companies re...
0 downloads 0 Views 2MB Size
Propuesta de una Arquitectura de Software Empresarial Orientada a Servicios Pedro Nolasco Bonillo Ramos - [email protected]

The present companies require of models of complex businesses with a organizational structure, processes and systems that must be designed explicitly. The work to design these models of business is clearly interdisciplinary, since it requires knowledge of development of the business, the different processes that happen in the company and of the management of the processes and the technological applications. In the scope of the software engineering would be advisable to be able obtain on a system of methods, tools and techniques that allow to reuse the best practices. In this work Business Software Architectural Service Oriented is made compose of: physical plants, networks, infrastructure, architecture of corporative services (applications, services and data management of the business), layer of intelligent multi-channel access and the channels. Keywords: Business Software Architectural Service Oriented, Information Systems Management, Technology Management Las empresas actuales requieren de modelos de negocios complejos con una estructura organizacional, procesos y sistemas que deben ser diseñados explícitamente. El trabajo de diseñar estos modelos de negocio es claramente interdisciplinario, ya que requiere conocimientos de desarrollo del negocio, los diferentes procesos que ocurren en la empresa y de la gerencia de los procesos y las aplicaciones tecnológicas. En el ámbito de la ingeniería de software sería conveniente poder contar con un sistema de métodos, herramientas y técnicas que permitan reutilizar las mejores prácticas. En base a esto, en este trabajo se realiza una propuesta de Arquitectura de Sofware Empresarial Orientada a Servicios (ASEOS) compuesta de: planta física, redes, infraestructura, arquitectura de servicios corporativos (aplicaciones, servicios y gestión de datos del negocio), capa de acceso multicanal inteligente y los canales. Palabras Claves: Arquitectura de Software Empresarial Orientada a Servicios, Gerencia de Sistemas de Información, Gerencia de Tecnología.

2841

Introducción La interacción de los diferentes elementos de Tecnología de la Información (TI) de la corporación, su infraestructura de trabajo, la adaptación y evolución de sus elementos se define a través de la arquitectura de TI. La arquitectura de TI de la corporación, es el marco de trabajo estándar que permite unificar los criterios de las empresas que la conforman y define las reglas de uso para cada uno de sus elementos. En otras palabras, la arquitectura de TI es el componente que define la semántica y sintaxis de cada uno de los elementos que agrupa y organiza. Arquitectar, es entonces, una actividad que permite reunir las piezas del rompecabezas de TI y crear una figura multidimensional que los compone en algún sentido específico. Sin embargo, como la Rayuela de Julio Cortazar, las piezas pueden ser armadas de diversas formas para crear diferentes arquitecturas; la utilidad y efectividad de la arquitectura creada depende directamente de la claridad de los objetivos en la misma y el grado de cumplimiento de los mismos. La arquitectura descrita en este documento esta enmarcada en las políticas y normas del plan estratégico de la corporación, en las mejores prácticas y principios de la industria y en los lineamientos corporativos; definiendo de ésta forma una arquitectura apegada a los intereses y necesidades de la corporación. La primera parte de este documento aborda el marco conceptual a partir del cual se elaboró el diseño de la arquitectura, explicando los tipos de arquitectura y de integración utilizados en el diseño de la misma y los conceptos involucrados en su definición. Posteriormente, este documento expone la arquitectura diseñada en varios niveles de detalle modificando las vistas que varían la profundidad de los conceptos y definiciones expuestas. De ésta forma el capítulo Propuesta de Arquitectura expone la visión de Nivel 0 y las relaciones fundamentales entre los actores al más alto nivel de abstracción. El capítulo Descripción General muestra mayor nivel de detalle de los componentes involucrados en la arquitectura.

2842

1

Marco Teórico

La Arquitectura es la conjunción de elementos dispares en una única construcción con sentido y orientación definidos [Clements, 1996]. Definir la arquitectura de TI de la corporación, es por tanto, una actividad que involucra todos los elementos de TI necesarios y los integra para maximizar su uso minimizando su costo, enmarcados siempre dentro de los lineamientos estratégicos corporativos. Esta actividad debe tomar en cuenta dos elementos: la orientación de la arquitectura y el tipo de integración a utilizar para las aplicaciones. El primero para enmarcar el trabajo dentro de una línea conceptual clara, al definir y precisar los objetivos y delimitaciones, alcances y metas, así como los componentes a utilizar. El segundo elemento permite definir los mecanismos utilizados para generar las interacciones necesarias entre los diferentes componentes de la arquitectura, así como la interacción generada por instancias diferentes del mismo componente. Los lineamientos corporativos establecen que la arquitectura de TI de la corporación no debe incluir todos los posibles elementos de TI disponibles en el mercado, ni necesita obtener los mas recientes, por el contrario utiliza los elementos cuya madurez y efectividad han sido probados por terceros, manteniendo sin embargo una orientación vanguardista llevada de la mano de las posibilidades financieras que estas tecnologías. Estos lineamientos abarcan no sólo a las instancias de los conceptos utilizados (es decir los productos que los representan) sino a los conceptos en sí mismos, por lo tanto la arquitectura, sin ser conservadora, está basada en conceptos expuestos y probados por terceros. De manera que, para lograr exponer los resultados de la ejecución de la actividad de construir la arquitectura corporativa, es conveniente conocer la tipología de la arquitectura sobre la cual se basa el resultado final, a modo de comprender el marco de trabajo sobre el cual se instancian las relaciones entre los elementos. De la misma forma, es necesario también comprender como ocurre la integración de los elementos, basada en la tipología de la arquitectura seleccionada, cuales son sus implicaciones y prerrequisitos. Igualmente es importante conocer los elementos involucrados en la instancia de la arquitectura desarrollada para la corporación. Las siguientes secciones explican en detalle lo antes mencionado.

1.1

Tipos de Arquitectura

A pesar de existir múltiples posibilidades y variantes para la construcción del modelo, ésta sección hace foco exclusivamente en dos de ellas, debido a que son las que representan la estructura tradicionalmente usada en la corporación (Arquitectura Basada en Silos) y la utilizada para dar base al modelo expuesto a través de este documento (Arquitectura Basada en Componentes Funcionales), La diferencia fundamental entre ambos modelos de arquitectura es su orientación1, siendo la dirección de la primera los componentes caja negra y de la segunda los procesos y servicios. A continuación se describen en detalle estas arquitecturas. 1.1.1

Arquitectura Basada en Silos

Las arquitecturas basadas en silos tradicionalmente son el resultado del crecimiento no ordenado de las aplicaciones empresariales, la concatenación de políticas no alineadas de diferentes áreas dueñas de aplicaciones, la fusión de empresas con aplicaciones y políticas disímiles o una mezcla de varias opciones.

1

A pesar de que la arquitectura de la corporación ha sido creada ‘de facto’ por la unión de las arquitecturas de las diferentes empresas luego de la fusión funcional ésta posee elementos claves comunes que soportan la conceptualización y abstracción de la misma.

2843

Los silos son cajas negras que ejecutan funciones de forma integrada y generan un resultado no estándar basado en sus propias especificaciones. A partir de ésta perspectiva, cada grupo funcional cubre de forma independiente los datos y acciones que han de generarse sobre su segmento de la corporación. La estructura de TI de la corporación se convierte entonces en un gran mapa de aplicaciones que tratan de cubrir la totalidad de los espacios de forma independiente y segmentada como se muestra en la Figura 1. La segmentación realizada no sigue una regla preestablecida, siendo en algunos casos dependiente de la “data” (segmentación por grupos de clientes, equipos), en otros dependientes del alcance (segmentación por empresa de la corporación) y en otros dependiente de las limitaciones de las tecnologías utilizadas.

WEB

A1

PDA

A2

PDA

SMS

WEB

Desk

A3

A4

A5

A7

A10 A11 A12 A13 A14

SMS

A6

SMS

A8



A9

An

Figura 1 Arquitectura basada en silos

La Figura 1 muestra como las interacciones entre las aplicaciones se hacen en diferentes niveles directos o indirectos pero siempre con la noción absoluta del conocimiento de las aplicaciones con las cuales se está interactuando. Además existen múltiples conexiones salientes y entrantes de cada aplicación, una por cada interacción que tenga. En la Figura 1 también se ilustran las interacciones que estos componentes poseen hacia la interfase humano-computador donde usualmente estos poseen una única forma de comunicación íntimamente ligada a la especificación del componente. De ésta forma la creación de canales adicionales para la exposición de las mismas funcionalidades suele ser una tarea compleja que involucra el re-desarrollo de varios componentes de la aplicación, o muy frecuentemente, el desarrollo de una nueva aplicación funcionalmente idéntica, pero con canales distintos de interacción. Adicionalmente, dada la extensa heterogeneidad de las aplicaciones y las múltiples reglas utilizadas para definir las interfases, la usabilidad suele verse afectada al no existir un estándar de los formatos de pantallas y canales utilizados. Además suele ser complicado integrar varios canales para el uso de un solo componente ya que éstos son desarrollados como componentes independientes.

2844

1.1.2

Arquitectura Basada en Componentes Funcionales

Los componentes funcionales son aplicaciones caja blanca que exponen sus funcionalidades y se integran de forma transparente, sencilla y estandarizada con las funcionalidades provenientes de otras aplicaciones, lo cual es el soporte básico de estas arquitecturas. [D´Sousa, 1999]. Los componentes funcionales son entonces una desagregación de las funcionalidades de cada aplicación expuestos de formas independientes y utilizadas a discreción cuando son necesitados. Desde ésta perspectiva se puede hablar entonces de integración de aplicaciones y no de interacción de aplicaciones; esto se debe a que se pueden generar efectivamente procesos que sumen funcionalidades y no meramente servicios que combinen aplicaciones. La Figura 2 ilustra los componentes funcionales, allí se puede ver como la integración se ejecuta a nivel de funcionalidades y no de aplicaciones, lo cual permite lograr exactamente el resultado deseado y no un objeto que debe ser transformado. La interacción de los elementos a nivel de componentes funcionales permite sumar funcionalidades para lograr construir aplicaciones que virtualmente son una reorganización de las mismas para lograr otro objetivo.

PDA

A1

SMS

A2

WEB

Desk

A3



A4

A5

F1

F2

F1

F2

F1

F2

F1

F2

F1

F2

F3

F4

F3

F4

F3

F4

F3

F4

F3

F4

F5

F6

F5

F6

F5

F6

F5

F6

F5

F6

Figura 2 Basada en Componentes Funcionales

El conjunto de funcionalidades que conforman una aplicación, son módulos que interactúan entre sí y con el resto de las aplicaciones, para lograr los resultados asociados a la aplicación. Algunos de estos módulos son destinados a la generación de las interfaces humano-computador y gracias a la posibilidad de yuxtaposición de diversos módulos, es posible interactuar con diversos canales de comunicación simultáneamente sin tener que rehacer la aplicación. Aún cuándo es posible la heterogeneidad de las aplicaciones (a nivel de lenguajes e infraestructuras), la usabilidad no se ve impactada en mayor grado debido a que es posible reutilizar los componentes e integrar las interfaces humano-computador de múltiples aplicaciones de forma sencilla. Una vez especificadas las arquitecturas en las cuales se concentrará la discusión, a continuación se describen los tipos de integración presentes en cada una de ellas.

2845

1.2

Tipos de Integración

Aún cuando la arquitectura de TI abarca todos los componentes de TI presentes en la corporación y define las formas de interacción de los mismos, la interacción entre las aplicaciones tiene un rol preponderante al posibilitar la creación de procesos de negocio que recorran transversalmente los elementos de la arquitectura para lograr los objetivos del negocio. Las aplicaciones de todo sistema de TI deben interactuar para poder aprovechar al máximo la información que se encuentra distribuida entre ellas. El objetivo fundamental de estas interacciones es mantener repositorios de datos y funcionalidades independientes que proveen las informaciones y ejecutan las acciones de una forma mas organizada. Existen múltiples formas y variantes de ejecutar estas interacciones las cuales han evolucionado en el tiempo, adaptándose a los nuevos cambios y crecientes necesidades de información y rendimiento de las empresas modernas. Este capítulo muestra las principales formas de interactuar, las cuales además se encuentran presentes en la corporación. 1.2.1

1era. Generación (Punto a Punto)

La interacción entre las aplicaciones basadas en éste modelo se realiza a través de conexiones directas entre las aplicaciones, intercambios a través de formatos propietarios y múltiples conexiones como se ilustra en la siguiente figura:

Aplicación

Aplicación

Aplicación

Aplicación

Aplicación

Aplicación

Aplicación

Aplicación

Aplicación

Aplicación

Figura 3 Interacción de aplicaciones punto a punto

Los tipos de interacción que se plantean a nivel de este esquema son: (Gamma et al. ,1995) x Intercambio de archivos. La forma más básica de comunicación entre dos procesos es a través del intercambio de archivos planos propietarios, cuya definición se hace en base a las reglas de la operación y cuando es posible, de mutuo acuerdo entre los desarrolladores de ambas aplicaciones. Esta forma de comunicación usualmente involucra proceso para el movimiento de archivos entre servidores diferentes, creación de demonios FTP (Protocolo de Transferencia de Archivos) para la verificación de la existencia de un nuevo archivo o agendas de ejecución que esperan encontrar en determinado momento el archivo nuevo. Además necesariamente ha de incluir funciones de lectura/escritura y pase de la información que no tienen que ver directamente con la lógica del programa y que usualmente agregan costos de programación poco reusables. x Intercambio de mensajes. A través del uso de demonios que escuchan por puertos determinados, servicios o algún otro mecanismo de escucha, las aplicaciones reciben mensajes o peticiones para la ejecución de alguna función o la obtención de alguna

2846

x

información por medio de respuestas que utilizan los servicios o demonios similares con la otra aplicación. APIs (Del ingles Application Programming Interface). En algunas ocasiones las aplicaciones desarrollan (Aplication Program Interfase) api’s de comunicación entre ellas a modo de acelerar o facilitar el intercambio de información entre las mismas. Típicamente éstos api’s definen funciones particulares para cada interfaz que realiza la implementación, creando de éste modo métodos o funciones que pueden ser accesados fácilmente por otras aplicaciones.

Además de las diferentes formas de comunicación de la información que tienen este modelo y que usualmente (como en el caso de la corporación) éstas se encuentran difundidas de múltiples formas en las aplicaciones, éstas deben ser creadas de nuevo cada vez que se desea interactuar con otras aplicaciones. El número de interfaces a crear por aplicación es entonces la suma de las interacciones desde y hacia la aplicación como se puede apreciar en la siguiente figura.

Aplicación 1

Aplicación 1

Aplicación 1

Aplicación 1

Aplicación 2

Aplicación 1

Aplicación 3

Aplicación N

Aplicación 3

Aplicación 4

Aplicación 3

Aplicación 4

Aplicación 3

Aplicación 4

Aplicación 4

Figura 4 Interfaces de aplicaciones punto a punto

Estas interacciones crecen de forma exponencial a medida que se incrementan las necesidades de interacción de las diversas funciones cubiertas por las aplicaciones, degradando el rendimiento y efectividad de los canales de comunicación y de las aplicaciones en si mismas al generar una sobrecarga de actividades derivadas de las interacciones. Además el número de puntos de error e inconsistencia aumenta casi indefinidamente degenerando la confiabilidad de los resultados y produciendo situaciones cuyo costo de manutención (en tiempo y recursos) se eleva indiscriminadamente. 1.2.2

2da. Generación (Concentrador de Integración)

Uno de los principales problemas de la integración de aplicaciones de 1era. Generación es la heterogeneidad y multiplicidad de las conexiones creadas para poder suplir las distintas necesidades de comunicación de las aplicaciones. Los concentradores de integración como se puede apreciar en la siguiente figura reducen la heterogeneidad de las interfaces creadas por aplicación al crear interfaces sólo con el concentrador. [IBM, 1998]

2847

Aplicación

Aplicación

Aplicación

Aplicación

Aplicación

Broquer Aplicación

Aplicación

Aplicación

Aplicación

Aplicación

Figura 5 Hub de Aplicaciones

Sin embargo, la multiplicidad de las conexiones se mantiene y no existe una estandarización de las formas de comunicación utilizadas a través de las mismas. De ésta forma encontramos diversas formas de interactuar con las otras aplicaciones como se puede apreciar en la figura 6:

Aplicación 1 Aplicación 1 Aplicación 1

Aplicación

Aplicación 3

BROQUER

Aplicación

Aplicación 3 Aplicación 3 Aplicación 4

Figura 6 Interacción de Aplicaciones a través de HUB

En esta figura se especifica que debe crearse una interfaz por cada necesidad de interacción que las aplicaciones tengan y las definiciones del protocolo de comunicación se establecen entre ambas partes de la comunicación. Las interacciones de las aplicaciones de ésta forma reducen significativamente el descontrol generado en las interacciones punto a punto al tener un único punto de conexión ("Broquer") al cual las aplicaciones han de recurrir si desean interactuar con otra aplicación. Evidentemente esta forma de interacción de aplicaciones mejora el esquema tradicional, convirtiéndolo en un esquema punto a punto mejorado, con significativos avances en el control y mantenimiento de las interfaces, pero que aún mantiene las múltiples interfaces (y sus problemas) del esquema tradicional.

2848

1.2.3

3ra. Generación (ENS, Sistema Nervioso Corporativo)

El problema esencial de las interacciones de las anteriores generaciones es que el concepto subyacente es el de entes (aplicaciones) diferentes hablando entre si, así de ésta forma la 1era. Generación representa múltiples conversaciones descontroladas y desorganizadas y la 2da. Generación representa múltiples conversaciones moderadas a través de un concentrador. La tercera generación parte del concepto de integración, es decir múltiples partes de un todo comunicándose entre sí de forma natural, transparente y automática, de ésta forma no existen conversaciones a través de la 3ra. Generación, existe simplemente comunicación donde cada aplicación puede obtener lo que necesite del sistema sin tener que crear múltiples conexiones ni conocer al resto de las aplicaciones. La Figura 7, ejemplifica la integración de 3ra. Generación donde se puede apreciar claramente el sistema nervioso corporativo2. En él, las distintas aplicaciones que dan soporte a las funcionalidades expuestas deben coordinarse para generar resultados eficientes que permitan abarcar los diferentes procesos de las unidades de negocio.

Usuarios Externos

CRM

Usuarios Internos

Corporaciones

Activación

Sistema Nervioso Corporativo

Datos

Compras

Q/A

Workflow

Seguridad

Figura 7 ENS: Sistema Nervioso Corporativo [TIBCO, 2004]

La coordinación de los procesos entonces va a depender de la integración de las funcionalidades de las distintas aplicaciones a través de canales regulados y estándares, que delimitan y especifican las comunicaciones que sobre ellos se establecen (ver, Figura 8). Las integraciones de ésta naturaleza basan su ejecución en la creación de servicios virtuales que reúnen lógicamente las funcionalidades de un conjunto de aplicaciones para dar vida a meta-aplicaciones (aplicaciones que definen a otras aplicaciones) delgadas que son accedidas por todas las aplicaciones para el consumo de las funcionalidades provistas por ellos y el acceso a sus datos. De ésta forma las aplicaciones poseen exclusivamente los siguientes canales de comunicación con el mundo: x Canal de Consumo. A través de este canal las aplicaciones solicitan la ejecución de funcionalidades definidas en los servicios y obtienen los resultados. La ejecución de estas funcionalidades se hace a través de api´s definidos (formatos de comunicación establecidos y comunes a todos los servicios). x Canal de Servicio de funcionalidades. A través de éste canal las aplicaciones proveen funcionalidades apegadas al API definido para ello y ajustándose a los términos del protocolo de comunicación establecido. Básicamente a través de este rol se trabaja 2

De acuerdo con Gartner 2004 ENS (Enterprise Nervous System) es algo más que simplemente una forma inteligente de estructurar las redes, es todo un sistema integrado que permite generar una verdadera integración de sus componentes.

2849

x

simulando (la simulación se hace a través de la capa de integración) un servidor o demonio que espera recibir peticiones para ejecutarlas y emitir los resultados. Canal de emisión de eventos. El tercer canal que poseen las aplicaciones permite a otras aplicaciones registradas en la capa de integración conocer (o ejecutar una acción en caso de) la ocurrencia de un evento. Cuando los eventos ocurren las aplicaciones pasan a tener un rol proactivo de notificación de su ocurrencia a la capa de integración, quien a su vez se encarga de distribuir la información pertinentemente.

Aplicación Virtual 1

Aplicación Virtual 2

Aplicación Virtual 3

Aplicación Virtual 4

Canal de Integración

Aplicación 1

Aplicación 2

Aplicación 3

Aplicación 4

Aplicación 5

Figura 8 Canales de Integración de Aplicaciones

Los canales mencionados permiten acceder rápida y controladamente a lo adecuado, para suplir las necesidades de interacción que tengan las aplicaciones. De ésta forma hay independencia absoluta en las aplicaciones, quienes ahora no necesitan conocer sobre las aplicaciones reales con quienes interactúan. Por otra parte, los canales se definen en base a los roles que las aplicaciones cumplen y no en base a las interacciones que poseen con otras aplicaciones siendo así este un modelo muy escalable que permite definir nuevos roles sin mayor impacto en las aplicaciones, que las configuraciones necesarias para suplir esta nueva actividad para aquellas que necesiten hacerlo. Las reglas de la comunicación quedan establecidas por ende a partir de la capa de integración quien especifica los formatos de los servicios y estandariza la comunicación de forma que el proceso de integrar una nueva interfaz en los casos anteriores se transforma en la identificación del servicio corporativo a invocar y su posterior ejecución, sin necesidad de codificar nuevas interfaces o definir nuevos protocolos de comunicación. El basamento esencial de este modelo de integración se encuentra en una capa de integración de aplicaciones que permite definir procesos, servicios y comunicaciones virtuales a partir de los servicios que exponen las aplicaciones de forma independiente. Además esta capa de integración cumple el rol de fachada a las aplicaciones que necesitan consumir servicios, por lo cual permite la publicación automática de nuevos servicios o la actualización de las funcionalidades de los mismos. La escalabilidad del modelo se basa entonces en los siguientes factores esenciales: x Extensibilidad de los canales de comunicación. Como fue mencionado previamente los canales representan los roles que una aplicación puede cumplir dentro del sistema

2850

x

nervioso integrado de la corporación. De surgir nuevas necesidades de roles a cumplir la actualización de las aplicaciones es un proceso muy sencillo. API´s definidos y escalables. De ésta forma la actualización de las funcionalidades expuestas y provistas por las aplicaciones no afecta a ninguna aplicación que no necesite utilizar directamente la misma. Además para aquellas que si la afectan debe estar claramente definido el proceso por medio del cual se obtienen las definiciones de las nuevas funcionalidades y su ejecución es siempre de la misma forma.

2851

2

Propuesta de Arquitectura de Software Empresarial Orientada a Servicios

La arquitectura de TI es un modelo que permite identificar y representar a los elementos de hardware y software presentes en la corporación, así como las relaciones (forma y tipo) que se deben establecer e impedir entre ellos. Su objetivo es proveer el mejor soporte tecnológico a los procesos de negocio de la empresa a la cual modelan. [Clements, 1996] La arquitectura de TI explicada a través de este documento define los elementos (estructura, forma, uso y relaciones) que proveen servicios y soportan procesos de la corporación. La Figura 9 muestra una vista de nivel 0 de la arquitectura de TI de la Corporación con sus elementos e interacciones. Este modelo se fundamenta en una orientación a servicios y procesos a través de los cuales se modelan las necesidades de las unidades de negocio enmarcadas dentro de los planes estratégicos de la corporación, para lo cual los elementos deben permitir el modelado de los procesos de negocios de una forma sencilla e integrar rápida y fácilmente las funcionalidades provistas por las aplicaciones.

Figura 9 Arquitectura Nivel 0

2852

Desde ésta máxima perspectiva mostrada en la Figura 9, se pueden identificar los elementos que componen la arquitectura: Infraestructura con la infraestructura de TI como soporte; Arquitectura de Servicios Corporativos (ASC) y Capa de Acceso Multicanal Inteligente (CAMI) como elementos integradores; y las aplicaciones como entes centrales de los componentes de TI. A través de las interacciones logradas por ASC y CAMI los procesos que modelan al negocio logran acceder a las funcionalidades necesarias para su ejecución y generan las experiencias – usuario. A partir del gráfico anterior se pueden obtener tres visiones diferentes clasificadas según la perspectiva de uso de las mismas: la vista de aplicaciones, la vista de procesos y la vista de infraestructura. A partir de la vista de aplicaciones (como se muestra en la Figura 10), se puede apreciar claramente que las aplicaciones no poseen formas de comunicación directa entre si o con los dispositivos de acceso final para los usuarios. Estas interacciones se hacen exclusivamente a través de las capas de interacción destinadas para ello, donde ASC es la capa de integración que entre otras cosas para facilitar la obtención de los datos y ejecución de funciones provistas por otras aplicaciones. CAMI es un multiplexor, que permite que las aplicaciones en sus distintas modalidades (multi-modal) posean distintos canales de interacción (multi-canal) con los usuarios sin tener que reescribir la aplicación para adaptarla al nuevo canal.

PDA

SMS

WEB

Canal i

CAMI

Aplicación

Figura 10 Vista de Aplicaciones

2853

Aplicación Ideal

Aplicación Ideal

Aplicación Ideal

Aplicación Ideal

Aplicación Ideal

ASC

Las capas de interacción mencionadas antes simplifican las interfaces que las aplicaciones han de implementar para comunicarse con el resto del mundo, tanto en número como en complejidad, de ésta forma el mantenimiento de las aplicaciones se convierte en una actividad más sencilla y manejable que requiere menor esfuerzo para lograr nuevos objetivos o modificar los actuales. La vista de procesos mencionada anteriormente y expuesta en la Figura 11 muestra con claridad como a partir de las aplicaciones se obtienen sus funcionalidades y se reorganizan lógicamente en servicios en la capa de integración los cuales permiten el modelado lógico de los procesos de negocio a partir de las verdaderas herramientas con las que cuenta la corporación.

Aplicación Ideal

Aplicación Ideal

Aplicación Ideal

Aplicación Ideal

Aplicación Ideal

Aplicación Ideal

ASC

Figura 11 Vista de Procesos

De acuerdo con lo expuesto anteriormente, podemos notar que la capa de integración (ASC) cumple un rol adicional al de permitir la interacción de las aplicaciones: el de exponer las funcionalidades para el modelado de los procesos de negocio. De ésta forma los procesos se basan realmente en las aplicaciones existentes para su ejecución, sin embargo su definición no está atada a las limitaciones propias de una u otra aplicación si no abierta completamente a la estructura funcional corporativa. A partir de ésta vista de procesos (ver, Figura 11) también se hace evidente la estrecha relación de la arquitectura con los procesos de la corporación, lo cual se debe a que justamente ésta ha sido diseñada con el firme propósito de dar soporte a los modelos de negocio requeridos por la corporación, los cuales se traducen en procesos que se ejecutan integrando funcionalidades provenientes de diversas aplicaciones. A continuación se describe con mayor detalle la arquitectura propuesta, en lo que se denominara el Nivel 1.del marco arquitectural.

2854

3

Descripción General

Los elementos mostrados en el capítulo anterior, muestran el nivel 0 y las interacciones que a un alto nivel ocurren para permitir la ejecución de los procesos, la integración de aplicaciones y la interfase usuario. La Figura 12 muestra la descomposición de estos elementos y da una vista de mayor precisión de las interacciones presentes.

Figura 12 Arquitectura Nivel 1

El plano multidimensional mostrado en la Figura 12 muestra los componentes de los soportes de infraestructura, la arquitectura de una aplicación, el Modelo de Objetos Corporativos (MOC) sobre ASC y los canales de CAMI. Cada uno de estos elementos es descrito en detalle en las siguientes secciones.

3.1

MOC: Modelo de Objetos Corporativos.

El MOC es el esquema teórico que define los objetos pertenecientes a la arquitectura, indica su amplitud, estructura y los estandariza para lograr un idioma de comunicación claro y preciso. El MOC al ser el elemento modelador de la arquitectura, define fundamentalmente la estructura de los datos y servicios3 que viajan a través de la capa de integración. MOC define en primer lugar, a los objetos que representan los datos corporativos (por ejemplo: cliente, facturación, etc.) definiendo el tipo, cantidad y estructura de los campos que los componen. 3

Los datos y servicios son representados como objetos de la arquitectura, estando de ésta forma dentro del alcance del MOC

2855

De ésta forma, una de las funciones que cumple el MOC es la de ser un diccionario de datos evolutivo que garantiza unicidad y claridad en las integraciones entre las aplicaciones. El segundo elemento que define el MOC y probablemente el de mayor relevancia, es la infraestructura de servicios que arropa y reagrupa lógicamente a las funcionalidades corporativas de acuerdo a estándares para el soporte a la operación, como es el caso de la iniciativa de java OSS/J (OSS/J 2005). El MOC es entonces también un diccionario de servicios corporativos que basado en el universo de funcionalidades disponibles y deseadas en la corporación, construye agrupaciones lógicas alineadas con el Mapa Ideal de Aplicaciones4. La importancia de los servicios corporativos (y del esquema generado por el MOC) se deriva de la utilidad que los mismos tienen como herramienta indispensable para el modelado de los procesos de negocio a partir de la implementación que de ellos se hace en ASC.

3.2

ASC: Arquitectura de Servicios Corporativos.

El corazón de la arquitectura expuesta a través de este documento es la capa de integración instanciada como ASC, esto se debe a: los múltiples roles que cumple y soporta, la estandarización que provee y al soporte que otorga a los procesos a partir de la implantación práctica del MOC, como veremos más adelante. A partir de la arquitectura, esta capa se define como de integración y no de interacción, por que a través de ésta, las aplicaciones descompuestas en sus funcionalidades básicas se recomponen para la generación de servicios de huella corporativa que abarcan múltiples funcionalidades provenientes de diversas aplicaciones. Es a través de ésta capa entonces, donde las aplicaciones acceden a las funcionalidades expuestas por otras; y es a través de ésta misma capa donde las aplicaciones exponen sus funcionalidades para ser utilizadas por cualquier aplicación. La capa de integración cumple entonces los roles de transporte y mediación entre las aplicaciones. La definición de ASC, es sin embargo, más amplia que la de una capa de integración. ASC es la implementación y el ambiente de ejecución del conjunto de servicios corporativos definidos por el MOC, es el integrador de funcionalidades (y por ende de aplicaciones) y el ambiente de ejecución de soporte para los modelos de procesos. Desde el punto de vista técnico ASC esta basado en las especificaciones sobre componentes de Middleware de J2EE5. ASC se define a si mismo como la implementación práctica del MOC, por que los servicios que el MOC define se crean y ejecutan en su infraestructura. La creación de los servicios es un proceso de modelado visual6 donde se componen las funcionalidades expuestas por las distintas aplicaciones, se agrega la lógica necesaria para esta composición y se publican. Esta composición debe considerar los detalles inherentes a la duplicidad de funcionalidades en diferentes compañías de la corporación, inexistencia o inaplicabilidad de funcionalidades para casos puntuales, etc.; siendo por lo tanto la lógica de ésta composición un elemento primordial para garantizar la correcta ejecución de las aplicaciones (incluyendo por su puesto los manejadores de error pertinentes). 4

El Mapa Ideal de Aplicaciones está constituido por las aplicaciones que deberían componer a la corporación suponiendo un escenario en el cual esta se rehace a si misma. Este mapa es naturalmente evolutivo y se adapta a las realidades corporativas en el tiempo. 5 La especificación del middleware utilizada como basamento para la construcción de ASC es el modelo J2EE según lo indicado por el documento de estándares y lineamientos. Documento hermano del presente, puede obtenerse a través de la unidad de planificación corporativa. 6 Este proceso se apoya en la herramienta de middleware quien debe proveer este ambiente de modelado visual. Ídem al comentario anterior

2856

El consumo de las funcionalidades expuestas por los servicios a través de ASC es un proceso que distribuye la ejecución de los mismos a las diversas aplicaciones dueñas de las funcionalidades utilizadas. De ésta forma el consumo de los servicios expuestos es un proceso que distribuye la capacidad de procesamiento a través de las diferentes plataformas soporte de las aplicaciones que exponen sus funcionalidades en él, siendo el resultado final procesos cuya ejecución es distribuida por naturaleza, relajando de ésta forma las necesidades de capacidad de cómputo de ASC, reduciendo así posibles cuellos de botella. La ejecución de un servicio es entonces, desde la perspectiva ASC, un conjunto de invocaciones a las funcionalidades expuestas por las aplicaciones. Desde la perspectiva de las aplicaciones, el consumo de servicios es un proceso similar que agrega el acceso a estos componentes a través de mecanismos distribuidos como CORBA, EJB, SOAP, etc. [Vollmer, et el al., 2004] Finalmente, ASC es también el contenedor de los servicios a través de los cuales se ejecutan los procesos. Los procesos basan su definición en los servicios expuestos por ASC siendo modelados a través de herramientas visuales instaladas sobre el middleware y conectados con ASC; luego de modelados los procesos éstos se ejecutan haciendo uso de los servicios y por ende consumiendo funcionalidades de las aplicaciones. La Figura 13 muestra un corte transversal de ASC donde se puede apreciar su composición. Este corte muestra como interactúan los elementos antes mencionados e introduce el último elemento de ASC: ASC.connect, quien permite la interacción de las aplicaciones con el mismo.

Aplicación ASC

MOC Modelado Middleware ASC.connect

Conector Aplicación

Figura 13 Corte Transversal ASC

2857

Asc.connect es el protocolo de comunicación que estandariza la publicación de los servicios a partir de las aplicaciones. Similarmente a ASC que se basa en J2EE para su construcción, Asc.connect se basa en la especificación de JCA7, convirtiéndose entonces en una particularización de este adaptado a las necesidades funcionales de integración de la corporación y la presente arquitectura, (JCA define un modelo de programación portable para soportar sistemas de información empresariales bajo JAVA y ha demostrado ser altamente confiable y mantenible). Asc.connect define con precisión los conectores que las aplicaciones deben desarrollar para integrarse con ASC y exponer sus funcionalidades. El conector definido por esta especificación posee varias características, en primer lugar su comportamiento es el de un traductor que como se muestra en la Figura 14, permite la comunicación entre las aplicaciones en su lenguaje de desarrollo nativo y ASC con JCA. Esta característica de traducción es la que permite la integración de las aplicaciones desarrolladas en cualquier lenguaje contra el cual se pueda desarrollar una interfaz de comunicación efectiva entre éste y JCA.

ASC/JCA Aplicación

Aplicación

Figura 14 Conector ASC

La segunda característica importante del conector, es que éste es liviano, es decir no incluye funciones de adaptador. La Figura 15 muestra la diferencia entre ambos conceptos, la cual radica en definir donde se ejecutan las reglas de negocio que se aplican sobre las funcionalidades a ejecutarse. Como puede verse en la Figura 15, un adaptador es un conector liviano que incluye ejecución de reglas de negocio, mientras que los conectores son simplemente los traductores de la aplicación hacia asc.connect relegando la aplicación de las reglas de negocio a los servicios definidos en ASC.

7

JCA. Java Connector Architecture, especificación de J2EE para el desarrollo de conectores.

2858

Reglas de Negocio

ASC

ASC/JCA Aplicación

ASC/JCA Reglas de Negocio Aplicación

Aplicación

Aplicación

Figura 15 Conectores vs. Adaptadores

El conector definido por ASC a través de Asc.connect especifica las clases y métodos que han de implementarse para lograr un conector ASC-compatible. Esto junto con la especificación del formato de los datos a compartir definidos por MOC genera un sistema de comunicación sin ambigüedades y sencillo de implementar que facilita la integración. A continuación se describe la gestión de datos del negocio dentro de ASC.

3.3 Gestión de Datos del Negocio. La Gestión de Datos del Negocio, se refiere a la gerencia de los procesos a través de los cuales se modelan los datos del negocio y se gestionan los mismos a fin de dar respuestas a las necesidades de integración a nivel de data para soportar aplicaciones de soporte de decisiones (inteligencia de negocio). [Gunnar et al., 2002] La Figura 12 expresa en su parte central la arquitectura de servicios corporativos (color verde oscuro), dentro de ésta arquitectura del lado izquierdo de la figura 12, se muestran las aplicaciones (en color azul claro) las cuales se fundamentan en el maestro de especificaciones técnicas (descrito en el capítulo de funcionalidades y soluciones del MAC), en el caso de la Gestión de Datos del Negocio estas aplicaciones son: Reportes y Consultas, Estadísticas, OLAP, Minería de datos e Inteligencia de Negocio. Es importante citar que en la parte superior de la columna de aplicaciones se define una aplicación especial (en anaranjado) denominada Capa de Procesos ("Processware"), esta aplicación se encarga de realizar la orquestación de los procesos del resto de las aplicaciones que se definen en la arquitectura (según lo definido en el capítulo de procesos del MAC) su fundamentación es la gerencia de los procesos del negocio (BPM). Del lado derecho de la figura 12 se encuentran los servicios. En el caso particular de la Gestión de Datos del Negocio, los servicios se definen como de movimientos de datos y son los siguientes (SMD): Inspección (Change Data Capture – valida las modificaciones recientes y activa el resto de los servicios de extracción, transformación y carga -), extracción, limpieza, transformación, carga, agregación y selección. (Calidad de Datos) De acuerdo a las aplicaciones y los servicios se presenta la gestión de datos del negocio a través de: los Repositorios de Datos Operacionales (ODS), los Data Mart y el Data WareHouse. La representación de los servicios y la integración de los datos necesarios

2859

para proporcionar la gestión se representa en el dibujo a través del Maestro de Integración (verde agua) el cual también se relaciona con el MOC. En la Figura 16, se muestran en detalle la interacción entre los componentes de Gestión de Datos del Negocio (aplicaciones en azul claro y servicios en verde claro, maestro de integración en verde agua, intercambio de meta-data en gris). Se describen seis niveles generales, del lado izquierdo de la figura los niveles de fuentes de datos, reconciliación de datos y consumo de datos, estos tres niveles unidos están en el plano de los usuarios (según lo descrito en el capítulo de usuarios del MAC); del lado izquierdo se describen los niveles de fuentes de meta-data, reconciliación de meta-data y consumo de meta-data, estos niveles están en el ámbito arquitectónico del MOC como repositorio centralizado de meta-data, con especial énfasis en el maestro de integración y en la Administración del Intercambio de la meta-data. A continuación se describen cada uno de estos niveles. Nivel de Fuentes de Datos: En este nivel se encuentran las fuentes de datos operacionales y las fuentes de datos externas. Estas fuentes de datos tienen además una representación de los modelos de datos que en ellas se contienen. Nivel de Reconciliación de Datos: En este nivel se tienen los servicios de inspección (Change Data Capture –CDC-), extracción, limpieza, transformación, carga, agregación y selección; además del ODS y el Data WareHouse con sus respectivas representaciones de los modelos de datos que contienen. En general el servicio de inspección de datos (que se expresa a través de un replicador de datos) verifica las modificaciones recientes de acuerdo a criterios previamente establecidos (ultima actualización, en lote cada hora, etc.) en el nivel de fuentes de datos federados y motiva al servicio de extracción, el cual a su vez motiva los servicios de limpieza de datos, transformación y carga, estos servicios de movimientos de datos (SMD), tiene a su vez una representación en un modelo de datos locales, mediante los SMD se alimenta el ODS y el Data WareHouse según sea el caso, como se muestra en la figura los servicios que interactúan directamente con el nivel de fuentes de datos son los de inspección, extracción y carga. Por otra parte el servicio de agregación se alimenta de los Data WareHouse y motiva los servicios de selección y carga a fin de establecer la relación con el nivel de consumo de datos. El Data WareHouse se relaciona directamente con el nivel de consumo de datos alimentando las aplicaciones de Inteligencia de Negocio o "Business Intelligence" (BI). Nivel de Consumo de Datos: en este nivel se encuentran las aplicaciones de Consumo de Datos con sus respectivos modelos de datos locales, los Data Mart se alimentan a través de los servicios de agregación selección y carga del nivel inferior de reconciliación de datos, estos datos son utilizados en aplicaciones ad hoc, reportes y consultas, Minería de Datos y OLAP. Es de hacer notar que en los 3 niveles antes descritos cada aplicación y sección de servicios tiene una representación a través de un modelo local de datos (datos que definen a otros datos –). A continuación se describen los niveles de administración de estos modelos. Nivel de Fuentes de Meta-Data: En este nivel se encuentran las fuentes de meta-data operacionales y las fuentes de meta-data externas. Estas fuentes de meta-data serán el insumo fundamental del repositorio centralizado de meta-data. Las mismas son exactamente iguales a los Modelos Locales de las Fuentes de datos Originales que se

2860

describieron en el nivel de Fuentes de Datos, dado que contienen los modelos de datos asociados a las fuentes. Nivel de Reconciliación de Meta-Data: En este nivel se tienen los servicios extracción, limpieza, transformación y carga asociados a los movimientos de meta-data del nivel inferior, junto con la administración de estos intercambios de meta-data; además del repositorio centralizado de meta-data el MOC (con especial énfasis en el maestro de integración) el cual intercambia meta-data con los modelos locales de los niveles descritos con anterioridad y en el que se sustentan las aplicaciones de acceso (las cuales se relacionan con el CAMI y que se describirán posteriormente en este documento) a través de la meta-data de acceso en el siguiente nivel de consumo de meta-data. Nivel de Consumo de Meta-Data: Este nivel contiene la meta-data de administración, ad hoc, de los reporteadores y los visualizadores, que sirve de insumo al CAMI de forma independiente de las aplicaciones que se invoquen, esto permite reemplazar por ejemplo un reporteador o un visualizador sin impactos mayores a que se pueda consumir la representación de meta-data que se proporciona a este nivel.

Figura 16 Gestión de Datos Nivel 1. Fuente: Adaptado de [Gunnar et al., 2002]

3.4

CAMI: Capa de Acceso Multicanal Inteligente.

Como se puede apreciar en la Figura 12, las aplicaciones poseen dos formas de comunicarse con el resto del mundo, a través de ASC para integrarse a las funcionalidades expuestas por las otras aplicaciones o a través de CAMI para lograr establecer interfaces humano-humano mediadas por la TIC .CAMI es entonces la capa que hace posible esta interfaz al permitir la interacción con

2861

múltiples canales (multi-canal) de forma directa, transparente y automática para las diferentes modalidades de comunicación que ofrecen (multi-modal) las aplicaciones. Similarmente a ASC, la definición de CAMI es más amplia que la de una simple capa de abstracción que posibilita las relaciones humano – computador. CAMI es la infraestructura tecnológica que posibilita la comunicación inmediata de una aplicación con múltiples canales simultáneos, que controla los lineamientos de usabilidad y que define con precisión los canales efectivamente utilizados. La Figura 17 muestra la especificación de nivel 1 de la arquitectura para CAMI, allí se puede apreciar con claridad los múltiples canales de CAMI y el acceso que los dispositivos tienen hacia ellos. También se puede apreciar el camlet como el elemento intermediador entre las aplicaciones y CAMI, que permite a la primera exponer sus interfaces sobre la segunda.

Celular HTML

PDA WAP

Laptop SMS

PC IVR

Call Center

WIN32

… …

NE’s

Soft Logic

CAMI Figura 17 CAMI Nivel 1

Los elementos que componen a CAMI son entonces los canales, los camlets y el portal de comunicación. Los canales de CAMI son la conjunción de los protocolos de comunicación con los cuales se puede establecer comunicación y los dispositivos que soportan este protocolo; los camlets son los componentes que permiten configurar las funciones de salida de las aplicaciones a partir de la conjunción de funciones de la aplicación y de funcionalidades consumidas directamente desde ASC. El portal de comunicación es el núcleo de CAMI, es el software que permite la multiplexión de los canales a través de él. Seguidamente se describe el tema de las aplicaciones que interactúan con ASC.

3.5

Aplicaciones

Las aplicaciones son las representantes por excelencia de la lógica de negocio, a través de ellas se controlan los procesos internos de las unidades, se mantiene el control de los datos, se ejecutan las acciones que permiten modificar o crear nuevas actividades, etc. Es decir, a través de las aplicaciones se ejecutan los procesos de negocio; y a medida que estos sean más integrados y efectivos serán más eficientes en su ejecución. La Figura 188 muestra la vista de nivel 1 de la arquitectura para las aplicaciones, donde además de detallarse los elementos, se puede apreciar que la separación entre cada uno de ellos está perfectamente delimitada y establecida, creando así una arquitectura de aplicaciones de 3 capas.

2862

CAMI

Lógica de Presentación

CAMLET

Lógica del Negocio ASC.Conn Lógica de Integración

ASC

Figura 18 Arquitectura de las aplicaciones nivel 1

Los elementos que componen la arquitectura de aplicaciones8 se listan y explican a continuación: x Lógica del Negocio. Es el elemento primordial de las aplicaciones. La lógica del negocio son aquellos componentes de software que ejecutan los procesos básicos de la aplicación o que configuran la ejecución de servicios expuestos por otras aplicaciones para su ejecución en conjunto con los procesos básicos. x Acceso a Datos. El encapsulamiento del acceso a los datos es esencial para mantener el control y una visión abstracta de los mismos; esto permite independencia de infraestructura de datos y garantiza que el acceso a los mismos se realice de forma transparente desde cualquiera de los componentes que los acceda, sin mayor relevancia sobre las formas de almacenamiento de los datos. x Datos. Para cualquier aplicación es imprescindible contar con datos reales, completos y precisos que apoyen la ejecución de los procesos proporcionando información completa y correcta; su acceso como fue mencionado en el punto anterior debe hacerse exclusivamente (desde las aplicaciones) a través de los conectores proporcionados para ello (las reglas para la definición de las estructuras de datos están definidas por el documento de estándares y lineamientos hermano de este documento). x Conector ASC. El acceso a las funcionalidades de otras aplicaciones, es decir, la interacción con aplicaciones hermanas se hace exclusivamente a través de los servicios que exponen las funcionalidades definidas desde el MOC, esto puede ejecutarse consumiendo los servicios dispuestos desde ASC. Sin embargo, la exposición de los servicios sólo se hace a través del conector ASC, por lo tanto, para lograr una efectiva integración de las aplicaciones, es necesario que todas se expongan a través de este conector. x CAMLET. El acceso a las interfaces humano – computador provistas por CAMI se logra a través de los portlets9 especializados (camlets) quienes configuran las funciones a interactuar con los usuarios, haciéndolas disponibles para su distribución en cualquiera de los canales de CAMI. La interacción entre estos elementos se produce sólo a través de los canales explícitamente diseñados para ellos, logrando con esto aplicaciones realmente modulares cuyos componentes 8

La arquitectura de aplicaciones es un sub-producto directo de la arquitectura de TI particularizada para las aplicaciones. 9 Similares a los servlets, los porlets son componentes Web que han sido generados sobre un contenedor y generan contenido dinámico,, técnicamente es una clase que es implementada por la interfase javax.portlet.Portlet y es desarrollada y empaquetada en un archivo de extensión war que conforma el contenedor del portlet (OnJava.com, 2005)

2863

pueden ser reemplazados, mejorados u optimizados sin afectar al resto. Esta separación de los componentes de interfaz, lógica y datos es el producto de un diseño de la arquitectura basado en 3 capas las cuales se pueden ver lógicamente a través de la Figura 19.

Lógica del Negocio

Objetos de Acceso a BD

CAMLET

ASC.Connect

Figura 19 Arquitectura de Aplicaciones de 3 capas

A continuación se describe en base a todo lo anterior el concepto de Aplicación Ideal.

3.6

Aplicación Ideal

Las aplicaciones enmarcadas en el modelo de 3 capas expuesto en la sección anterior pueden prescindir sin mayores problemas de cualquiera de sus componentes y cambiar sin mayores implicaciones en el resto de los componentes. Así podemos apreciar en la Figura 2020 una aplicación que es descompuesta en otras dos aplicaciones representando a la lógica de ejecución y a la lógica de interacción respectivamente.

CAMI CAMLET

ASC.Conn

CAMLET

ASC.Conn

ASC Aplicación Tradicional

Aplicación ASC Figura 20 Aplicación Ideal

2864

Aplicación Ideal

Las aplicaciones ideales son aquellas que configuran en el camlet las funcionalidades del MOC que desean exponerse y darles vida. Es decir las aplicaciones ideales (Figura 20) sólo están compuestas por un elemento de CAMI, mientras que las aplicaciones reales les dan soporte a las mismas sin generar interfaces con el usuario. Estas aplicaciones son ideales por que no están expuestas a los cambios de lógica propios de una aplicación y su interacción se hace de forma exclusiva con servicios lógicos ejecutándose sobre ASC. De ésta forma, las aplicaciones que percibe el usuario son siempre las aplicaciones que representan al modelo ideal de funcionalidades de la corporación y no al subconjunto de funcionalidades que son expuestas por una aplicación particular. Las aplicaciones descritas hasta este punto requieren de una infraestructura de TI, la cual se describe a continuación.

3.7

Infraestructura TI

La infraestructura de TI son todos aquellos componentes de software que forman parte de las soluciones o que son necesarios para la ejecución de las mismas y no son propiamente aplicaciones. Ésta perspectiva se ilustra muy bien a través de la Figura 21 donde se explicitan los componentes de ésta capa de soporte de la arquitectura.

Middleware Corba SOAP EJB

DBMS Oracle



DB2

Natural



Sistema Operativo Solaris Linux Win32



Infraestructura TI Figura 21 Infraestructura TI Nivel 1

Como se puede apreciar en la Figura 21, la infraestructura de TI está compuesta por tres elementos esenciales: Sistemas Manejadores de Bases de Datos (DBMS), Herramientas de integración (Middleware) y Sistemas Operativos (SO). Este último es la base fundamental a partir de la cual se instalan los diferentes componentes de software necesarios (su tipología y uso están especificados en el documento de estándares y lineamientos). Los manejadores de base de datos son junto al middleware los soportes de las aplicaciones garantizando la información y la ejecución; además la herramienta de integración agrupa y coordina de forma virtual, explicita o configurable los distintos elementos que dan vida a la ejecución de una aplicación y que permiten su interacción con el resto de la arquitectura. Todos los elementos descritos en este documento se pueden apreciar de forma integrada a través de la Figura 212, la cual es el punto de partida para la definición del nivel 2 de la arquitectura corporativa, la cual se discutirá en detalle en versiones futuras de este documento.

2865

Figura 22 Arquitectura Nivel 2

3.8

Conclusiones generales

El desarrollo de esta propuesta de arquitectura ha dado como resultado una serie de aportaciones en el campo del uso de componentes y arquitecturas de software, Las principales contribuciones pueden resumirse como sigue: 1. Arquitectura Corporativa Basada Orientada a Servicios en base a la construcción basada en componentes software: un estudio de las alternativas existentes para la selección aplicación y verificación de patrones y de la composición de componentes software desde el punto de vista de los condicionantes planteados aquí. 2. Una definición de arquitectura abierta y aplicable en muy diversos ámbitos del diseño, desarrollo y mantenimiento del software sin perder de vista que el software es uno sólo a pesar de los diversos enfoques de construcción que existen, y debe existir un marco referencial que integre estos enfoques en pro de una sola actividad de construcción. 3. Una arquitectura cuya finalidad es la trazabilidad. Esta arquitectura tiene además características especiales: a. Puede ser utilizada con facilidad por una organización, sin necesidad de conocimientos sobre métodos formales. b. Fomenta la colección y uso de conocimiento que habitualmente se pierde. c. Permite gestionar este conocimiento.

2866

4.

3.9

Un sistema de verificación de componentes plenamente viable en la práctica:

Referencias Bibliográficas

[Clements, 1996] Clements, P. Formal Methods in Describing Architectures. En Proceedings of the Workshop on Formal Methods and Architecture. California: Monterey. 1996 [D’Souza, 1999] D’Souza, D., y Wills, A. Objects, Components and Frameworks with UML. The Catalysis approach. Addison-Wesley. 1999 [Gamma et al. ,1995] Gamma, E., Helm, R., Johnson, R., y Vlissides, J. Design Patterns. Addison Wesley. 1995 [Gunnar et al, 2002] Gunnar A., Eitel von M., Helfert M. A Model-based Software Architecture for Metadata Management in Data Warehouse Systems. Institute of Information Management University of St. Gallen. 2002. [IBM, 1998] Patrones de e-Business. Requisitos para la solución de integración de aplicaciones. 1998. Documento en Línea: http://www-28.ibm.com/developerworks/patterns/es_es/application/eairequirements.html [OnJava.com, 2005] What Is a Portlet?. 2005. Documento en línea: http://www.onjava.com/pub/a/onjava/2005/09/14/what-is-a-portlet.html?page=2#what_are_portlets [OSS/J, 2005]. OSS through Java Initiative 2005. Documento en línea: http://www.ossj.org/aboutus/index.shtml [TIBCO, 2004] Software de sistema nervioso corporativo 2004. Documento en Línea: http://www.tibco.com/international/spain/software.jsp [Vollmer et al, 2004]Vollmer, K. Market Overview: Business Process Management, Giga Research, Planning Assumption, RPA-022004-00001. 2004.

2867