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 DE COMPONENTES 6 4.2. DESCRIPCIÓN DE COMPONENTES 6 4.2.1. CAPA DE PRESENTACIÓN EN CLIENTE DE LA ARQUITECTURA 6 4.2.2. CAPA DE PRESENTACIÓN DE LA ARQUITECTURA 7 4.2.3. CAPA DE APLICACIÓN DE LA ARQUITECTURA 7 4.2.4. CAPA DE DATOS DE LA ARQUITECTURA 8 4.2.5. CAPA DE APLICACIONES Y DATOS EXTERNOS A LA ARQUITECTURA 8 5. PRIMER ITERACIÓN 9 5.1. DIAGRAMA DE COMPONENTES 9 5.2. DESCRIPCIÓN DE COMPONENTES 9

1. INTRODUCCIÓN El modelo de componentes describe la jerarquía completa de componentes en términos de sus responsabilidades, sus interfaces, sus relaciones estáticas y la forma en que colaboran para entregar la funcionalidad requerida. La mayor parte de los componentes son Software, pero algunas veces es conveniente incluir una combinación de componentes de hardware y software en el modelo de componentes. Un componente puede ser un subsistema, un modulo de un programa, una colección de clases, un programa, una parte de un producto, o un dispositivo de hardware. Los componentes pueden en un principio ser de cualquier tamaño, sin embargo, como el propósito de este Work Product es arquitectónico, la descomposición tiene a detenerse a un nivel suficiente para poder asignar los diferentes grupos de trabajo. El trabajo detallado dentro de cada equipo es manejado en los work products de diseño.

2. OBJETIVO El modelo de componentes es usado para: Describir la estructura del software a alto nivel. Describir precisamente las responsabilidades, relaciones e interacciones de los componentes de la solución. Documentar como las aplicaciones y los componentes técnicos se relacionan entre si. Especificar como los componentes nuevos y los heredados se relacionan entre si. Definir los componentes que tienen que ser colocados en el Operacional Model, esto es, definir que componentes correrán en que plataforma de hardware con que sistema operativo. Ayudar a organizar el proyecto de desarrollo Reducir la complejidad mediante la encapsulación que ofrecen los componentes. Servir como separador entre las unidades de trabajo a asignar. La encapsulación proveída por los componentes reducen la interacción entre los grupos de desarrollo y hacen la administración general y técnica mas sencilla. Define precisamente las fronteras entre partes reusables del sistema.

3. NOTACIÓN La descripción de un componte es mantenido en texto y sigue un template como el siguiente: Responsabilidades: Una descripción de las responsabilidades del componente, esta descripción se volverá mas detallada a medida que el proyecto progresa. Eventualmente, se volverá la definición de las operaciones ofrecidas por el componente. Estas operaciones pueden ser organizadas en una o mas contratos ofrecidos por el componente. Requerimientos de servicio: De ser necesario, se podrán especificar en esta sección las capacidades que el componente debería ser capaz de cumplir. Existen algunas categorías en las cuales estos requerimientos se pueden catalogar: Riesgos: Presentación a Usuario. Performance y capacidad. Disponibilidad. Seguridad. Administración. Una evaluación de los riesgos técnicos asociados con el diseño, junto con una estrategia de migración en el caso que sea necesario. Justificación del Diseño: Una descripción del fundamento de las decisiones clave que se tomaron durante el diseño del componente. Enfoque de implementación: Indica las estrategias tecnológicas o de implementación seleccionadas para ese componente.

4. ARQUITECTURA GLOBAL 4.1. DIAGRAMA DE COMPONENTES Contenido Content Gestionado Management Los servidores de aplicación deben incluir los mecanismos que aseguren Navegador Usu Ext Reverse Servidor de Presentación Usu Externos la integridad transaccional Proxy Navegador Usu Int Balanceo de Carga Los AppServer Incluyen Web Servers Servidor de Aplicaciones Servicios de Acceso a Datos Bases de Datos Dispositivos Especializados Servidor de Presentación de Usu Internos Integración Asincrónica Paquetes Comerciales Reverse Proxy Otras Aplicaciones Integración Externa Integración Interna BPS Aplicaciones Externas Servicio de Autenticación Servicios de Autorización (Perfiles) Sistemas de Información Datos de Sistemas Información Bases de Datos Corporativas Repositorio Usuarios (LDAP) Repositorio de Perfiles Capa de Presentación en Clinete de la Arqutiectura Capa de Presentación de la Arqutiectura Capa de Aplicación de la Arqutiectura Capa de datos de la aplicaciones de la arqutiectura Sistemas o aplicaciones externas a la arquitecturas 4.2. DESCRIPCIÓN DE COMPONENTES 4.2.1. CAPA DE PRESENTACIÓN EN CLIENTE DE LA ARQUITECTURA Navegador Usuarios Externos Corresponde a los navegadores tradicionales que envían requerimientos a los servidores web y presentan la respuesta recibida. Navegador de Usuarios Internos Corresponde a los navegadores tradicionales de los usuarios internos al BPS. La diferencia con los Navegadores de Usuarios Externos es que se puede tener un mayor dominio de las posibles versiones de los navegadores a usar y sus configuraciones, lo que puede ser útil en el caso de desarrollo de aplicaciones internas más específicas

Aplicaciones Externas Corresponde a las aplicaciones de organizaciones externas al BPS. Estas aplicaciones tiene dos tipos de interacciones con el Banco, a) Necesitan integrar sus sistemas con los del BPS. Estos sistemas accederán a través de Web Services. B) BPS necesita integrarse con dichas aplicaciones. Se prevé un componente de Integración (véase Capa de Aplicación) que realice la conexión entre la tecnología de las Aplicaciones Externas y las aplicaciones de BPS. Dispositivos Especializados Corresponden a dispositivos con características excepcionales, que necesitan de recursos especiales y que se encuentran fuera de la seguridad de la red interna. (por ejemplo Kioscos de auto consulta). Estos dispositivos accederán por Web Services. 4.2.2. CAPA DE PRESENTACIÓN DE LA ARQUITECTURA Balanceo de Carga Es el encargado de distribuir según la situación las conexiones a los diferentes servidores web externos, balanceando su carga. Reverse Proxy Los reverse proxy ofician de servidores web para los clientes externos o internos. Son el único punto de contacto con la capa de cliente. Limitará los accesos a los servidores de presentación autenticando a los usuarios a través de procesos de autenticación provistos por el servicio de autenticación. El reverse proxy puede también proveer funciones de caching. 4.2.3. CAPA DE APLICACIÓN DE LA ARQUITECTURA Servidor de Presentación Usuarios Externos Servidor de aplicaciones en el cual residirá la lógica de presentación para los usuarios externos (App Server y Web Server) Servidor de Presentación Usuarios Internos - Servidor de aplicaciones en el cual residirá la lógica de presentación para los usuarios internos (App Server y Web Server). Servicio de Autentificación Brindará los mecanismos para autenticar a los clientes. Esto incluye por ejemplo los mecanismos y reglas de identificación. Repositorio de Usuarios (LDAP) Repositorio en el cual se almacenará la información de los usuarios de todos los sistemas. El servicio de autenticación accederá a este repositorio para verificar la autenticidad de los usuarios. Servicio de Autorización Servicios contra los cuales accederán las aplicaciones para controlar las funciones de las aplicaciones a las que podrán acceder los usuarios que las ejecutan. Repositorio de Perfiles - Repositorio en el cual se almacenará la información necesaria para autorizar la ejecución de funciones por parte de los usuarios. Integración Externa - Mecanismos de Integración del servidor de aplicaciones interno con las aplicaciones externas de las cuales se requiere información y ejecución, el mecanismo a utilizar dependerá de las características de la aplicación externa. Integración Asincrónica Componente de Integración de los Servidores de Presentación con los Servidores de Aplicaciones que permite controlar el flujo de trabajo que entra hacia los Servidores de Aplicaciones. A través de estos mecanismos asincrónicos se buscará tener un mayor control de los requerimientos de los usuarios externos. Este componente de la arquitectura debe poder integrar múltiples tecnologías.

Servicios Transaccionales Mecanismo provisto por los Application Server para asegurar la transaccionalidad de las operaciones a través de todos los componentes que se involucran en estas. Servidor de Aplicaciones - Servidor de aplicaciones en el cual residirá la lógica de negocio y los procesos necesarios para llevar a cabo las transacciones. El servidor de aplicaciones debe proveer servicios transaccionales de forma de asegurar la transaccionalidad de las operaciones a través de todos los componentes que se involucran en estas. Integración Interna Mecanismos de Integración del servidor de aplicaciones interno con las aplicaciones, paquetes comerciales o datos internos que no se ejecutan sobre un servidor de aplicaciones o que pertenecen a una Base de datos corporativa. Sistemas de Información Aplicación de Manejo y visualización de los datos de inteligencia de negocio. Content Management Administrador de contenido que se desea presentar a los usuarios Internos como Externos. Contenido Gestionado Repositorio del contenido gestionado estático o no que se desea presentar. 4.2.4. CAPA DE DATOS DE LA ARQUITECTURA Servicios de Acceso a Datos Capa de lógica que controla el acceso la información desde los Servidores de Aplicaciones y de las aplicaciones internas que no ejecutan en estos. Contiene la definición de las entidades, en dos categorías, de nivel de Negocio, que son publicas y visibles desde los Servidores de Aplicaciones, de nivel de Datos, que son solo accesibles por las entidades de nivel de Negocio, y administran su acceso a los dispositivos de almacenamiento. Base de Datos Repositorio de los datos que pertenecen a las aplicaciones. Datos de Sistemas de Información Información extraída de los datos de producción para los sistemas de información. 4.2.5. CAPA DE APLICACIONES Y DATOS EXTERNOS A LA ARQUITECTURA Paquetes Comerciales Soluciones preconstruidas implantadas en el Banco, se prevé un mecanismo de comunicación para con estas particulares para cada una. Otras Aplicaciones Aplicaciones Legadas del Banco que necesitan acceder a la información contenida en la estructura de esta arquitectura, pero que no fueron desarrolladas dentro de este marco. Bases de Datos Corporativas Bases de datos que contienen la información corporativa y están mantenidas fuera del contexto de ATyR. Es necesario poder acceder a dicha información mediante algún mecanismo que pueda asegurar un tiempo de respuesta dentro de las limitantes que se establezcan para las aplicaciones desarrolladas dentro del marco tecnológico de esta Arquitectura que dependen de esta información.

5. PRIMER ITERACIÓN 5.1. DIAGRAMA DE COMPONENTES Action Handlers Integrador Asíncrono Proxy RegEmp Business Objects RegEmp Data Acces Objects Servlets Contract layer Business Logic Business Objects Data Access Objects Result lay er Integracion interna PL/SQL legacy Base de Datos Recaudación Security Presentation Logic Replicación Base de Datos Registro de Empresas External Security admin. Integracion interna Asincronica legacy Asinc Integration MQ driver Asinc Integration Oracle driver Validaciones Legacy Systems Calculos Legacy Systems Recalculo Legacy Systems 5.2. DESCRIPCIÓN DE COMPONENTES Servlets Punto de entrada al sistema. La responsabilidad de las servlets es: Recibir requerimientos desde los browser Realizar el control de seguridad pertinente. Realiza las llamadas necesarias a los action handlers que realizan las llamadas al negocio, y preparan la información para ser desplegada.

Security Debe existir un encapsulamiento de las API's de seguridad externas a las cuales se accederá, de forma de poder optimizar el acceso a esta información y simplificar su utilización para el resto del sistema. Estas clases se encargarán de manejar, interpretar y traducir al sistema los niveles de seguridad. External Security admin. Componente externo que realice la autorización basado en un identificador de usuario. Action Handlers Las Servlets permiten el ingreso de requerimientos, pero estos requerimientos no son manipulados por los servlets, sino derivados, dependiendo de su naturaleza a un Action Handler específico. Estas clases java encapsulan el conocimiento de la generación de los contratos en base a los objetos de la presentación, así como el conocimiento de a que objeto de lógica de negocio se debe pedir el servicio para atender ese requerimiento. Escondiendo a su vez la implementación a la capa de presentación. Contract Layer Los contratos son clases con comportamiento, estas clases, no solo almacenan la información que debe viajar de una capa a otra, sino que estandarizan el uso de los servicios de la capa de lógica de negocio, el formato de los datos que estas necesitan para ejecutar y se encargan de validaciones mínimas de formato, tipo, tamaño para los datos que transporta. Estos objetos deben ser serializables. Result Layer La capa de lógica se comunica con las capas de presentaciones mediante contratos, estos contratos son de dos tipos, de requerimientos (Contract Layer) y de respuesta (Result Layer), implementados de la misma forma, ambos contienen atributos, pero mientras los contract entran a la capa de negocio con datos primitivos, los result salen de esta con imágenes de los objetos de negocio. Estas imágenes no son objetos de negocio, ya que no poseen lógica, solo presentan información de los objetos. Estos objetos deben ser serializables. Integrador Asincrónico Entre la capa de presentación y la capa de negocio, deberá existir la posibilidad de tener un conector asincrónico que permita controlar la cantidad de solicitudes que pasan de una capa a la otra. Este integrador esta compuesto por tres componentes, una cola de mensajes, y dos procesos (uno en cada capa a comunicar) que se encargan de encapsular el acceso a ese mecanismo. Business Logic Esta lógica de negocio será implementada en Session Beans Stateless, estos session beans presentarán (exportarán) funcionalidades a las presentaciones existentes (sea Web intranet, Web Internet, otras aplicaciones J2EE, etc.). Esta funcionalidad, contiene el flujo de ejecución principal (entre otros) que se encarga de instanciar y enviar mensajes a los objetos de negocio. Debe ser capaz de entender los contratos, el estado y extraer la información necesaria para realizar la ejecución del servicio que se le solicita mediante estos. Es el responsable de generar los result beans que contendrán los objetos copia del negocio, estos objetos de imagen serán creados por los objetos de negocio. Business Objects

El core del sistema, los objetos propios del negocio, que conocen las relaciones, las transformaciones y las validaciones de la información que el sistema procesa. Estos objetos, JAVA puros, se encargan del procesamiento, relegando en los Session Beans el control del hilo de ejecución. No existe un objeto main, sino que la lógica y las responsabilidades están dispersas por la totalidad de la capa y accesible desde los session beans. Proxy RegEmp Business Object El acceso a Registro de Empresas estará restringido por estos objetos proxy, los cuales ofrecerán reducida funcionalidad de Registro de Empresas a Recaudación, encapsulada en Objetos familiares para el negocio de Recaudación, que no necesariamente coincidan uno a uno con los objetos de una futura versión de Registro de Empresas en la misma arquitectura. En una primera versión, estos objetos son implementados mediante objetos de acceso a las replicas realizadas contra ATyR - Registro de Empresas. Data Access Objects El acceso a la base de datos se realizará mediante el patrón DAO. El modelo de objetos a utilizar se divide en dos categorías, los data access que administran objetos de lógica, responsables de realizar contra la base de datos las transacciones o consultas correspondientes para que la lógica de negocio pueda ejecutar correctamente. La segunda categoría, son objetos generales que encapsulan las consultas complejas necesarias para algunas transacciones especiales. RegEmp Data Access Objects implementación de Objetos Registro de Empresas Proxy - Acceso a Replicas mediante DAO. Debido a que estos objetos acceden a registro de empresas mediante replicas, estos objetos son en un principio solo de consulta. En caso de necesitar acceder a objetos de Registro de empresas de forma transaccional, estos accesos se realizarán mediante integración interna, y se describirán en ese caso en particular dependiendo de la implementación concreta que se seleccione para dicho componente de integración. Integración Interna PL/SQL Legacy Es necesario realizar, al menos momentáneamente mientras las aplicaciones coexistan dos tipos de integraciones, la primera, mediante la capa de aplicaciones, la segunda, mediante la tecnología de los sistemas legados PL/SQL. Para realizar esta conexión, se desarrollan estos componentes de acceso que encapsulan las llamadas a los PL y transforman los resultados en conjuntos de objetos a procesar en la lógica de negocio. Estos componentes será utilizados para acceder a parte de los componentes de registro de empresas, ya que algunos accesos a las replicas de dicho sistema serán resueltos mediante interfaces PL/SQL provistas por el sistema Registro de Empresas. Integración Interna Asincrónica Legacy Debe ser posible enviar mensajes asincrónicos entre el sistema J2EE y las tecnologías anteriores (C / C++). Esta integración, en principio será mediante MQ series y DBMS_PIPE pero debe encapsular el envío real del mensaje. Asinc. Integration MQ driver Driver que implementa el manejo de colas MQ.

Asinc. Integration Oracle driver Driver que implementa el manejo de colas Oracle. Recalculo Legacy Systems Programas de Recalculo actuales, implementados en C. Cálculos Legacy Systems Programas de Cálculos actuales, implementados en C. Validaciones Legacy Systems Programas de Validaciones actuales, implementados en C++. Base de Datos Recaudación Base de datos Interna de Recaudación. Base de Datos Registro de Empresas Base de datos del registro de Empresas, Contribuyentes y Obras, externas a Recaudación. Esta base de datos es parcialmente replicada hacia la base de datos de Recaudación, y utilizada mediante interfaces.