TESIS I NSTITUTO POLITÉCNICO NACIONAL QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS. De la INFORMÁTICA P R E S E N T A :

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

Download "TESIS I NSTITUTO POLITÉCNICO NACIONAL QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS. De la INFORMÁTICA P R E S E N T A :"

Transcripción

1 I NSTITUTO POLITÉCNICO NACIONAL UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN INTEGRACIÓN DE UN SISTEMA NUCLEAR BANCARIO CON UN SISTEMA DE PAGOS ELECTRÓNICOS INTERBANCARIOS TESIS QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS De la INFORMÁTICA P R E S E N T A : Roberto Daniel Velásquez Portilla DIRECTOR: M.C. Abraham Gordillo Mejía México, D.F. 2013

2 06 19:00 11

3 INSTITUTO POLITÉCNICO NACIONAL SECRETARÍA DE INVESTIGACIÓN Y POSGRADO CARTA CESIÓN DE DERECHOS En la Ciudad de México D.F. el día 5 del mes de Junio del año 2013, el que suscribe Roberto Daniel Velásquez Portilla del Programa de Maestría en Informática con el número de registro B091973, manifiesta que es autor intelectual del presente trabajo de Tesis bajo la dirección del M.C. Abraham Gordillo Mejía y cede los derechos del trabajo intitulado Integración de un Sistema Nuclear Bancario con Sistema de Pagos Electrónicos Interbancarios, al Instituto Politécnico Nacional para su difusión, con fines académicos y de investigación. Los usuarios de la información no deben reproducir el contenido textual, gráficas o datos del trabajo sin el permiso expreso del autor y/o director del trabajo. Este puede ser obtenido escribiendo a la siguiente dirección Si el permiso se otorga, el usuario deberá dar el agradecimiento correspondiente y citar fuente del mismo. Roberto Daniel Velásquez Portilla Nombre y Firma

4 Con dedicatoria a la gente que ha sido testigo de mi vida y le da significado a la misma. Donde está la vida, está la fe Liev Nikoláievich Tolstói

5 Integración de un Sistema Nuclear Bancario con Sistema de Pagos Electrónicos Interbancarios Roberto Daniel Velásquez Portilla. UPIICSA, IPN, MÉXICO D.F. 1

6 Contenido Contenido Contenido... 2 Resumen... 7 Abstract... 8 Introducción Breve reseña del estudio Capítulo I Sistemas Distribuidos Introducción Características de un Sistema Distribuido Heterogeneidad Extensibilidad Seguridad Escalabilidad Tratamiento de Fallos Concurrencia Transparencia Independencia de locación Balance de Cargas Computacionales Implementación Arquitecturas de Sistemas Distribuidos Capas de Software Arquitectura Cliente-Servidor Middleware Comunicación Entre Procesos Sockets HTTP Protocolo Petición-Respuesta Interfaces Paso de Mensajes Servicios Web Descripción Servicio Web, WSDL SOAP Capítulo II Arquitectura SOA Introducción

7 2.2 Objetivos y Principios SOA Objetivos Efectividad Confianza Principios Orientación al Negocio en SOA Modelo de las Partes Interesadas y Participantes Modelo de Recursos Modelo de Propiedad Modelo de necesidades y capacidades Modelo de la Estructura Social Modelo de Estado Compartido y Hechos Sociales Administración de Proyecto enfocado a un sistema basado en SOA Introducción Planeación Definición y Alcance Alcance del Plan de Administración Alcance de la Definición del Proyecto Análisis del Proyecto Estructura y Distribución de Trabajo Control y Seguimiento Transición de Soporte y Liberación Capítulo 3 Caso Práctico Descripción del Objeto de Estudio Sistema de Pagos Electrónicos Interbancarios SPEI Plataformas del Banco en estudio para SPEI Sistema Principal Bancario Sistema MiddleWare Bancario Sistema SPEI Bancario Análisis del Proceso Objeto de Estudio Proceso SPEI del Banco Áreas del Banco de estudio Proceso SPEI de Envío

8 Contenido Proceso SPEI de Recepción y Rechazo Capítulo IV Propuesta de Implementación Definición del Proyecto Objetivo del proyecto Participantes del Proyecto y Recursos Organizacionales Rol desempeñado por Roberto Daniel Velásquez Portilla Análisis del Proyecto Arquitectura Punto de partida Proceso del Negocio Actual Análisis de las Propiedades de la Transacción del Proceso Actual Puntos de Oportunidad y Punto de Arribo Plan de Trabajo Principales participantes del Proyecto detalle Alcance del Proyecto Línea de Tiempo Costo Beneficio Requerimientos Puntuales Arquitectura SOA Análisis de Software y Hardware Implementación SOA Comunicación Servicio Web Esquema de Seguridad Balance de Carga, alta disponibilidad Integración de Participantes e Interesados Esquema de Soporte y Mantenimiento Dueños de recursos y Responsables de proporcionar los mismos Implementación Solución SOA completa Conclusiones Observaciones Bibliografía

9 Listado de Figuras Figura Arquitectura en Capas de un Sistema Distribuido Figura Capas básicas en una arquitectura de software Figura Arquitectura Cliente-Servidor Figura Middleware enmascara la heterogeneidad Figura Abstracción de Sockets Figura HTTP protocolo petición/respuesta Figura Estructura de un mensaje petición-respuesta Figura Middleware orientado a mensajes Figura Interfaz y descripción de un servicio web Figura Elementos de un mensaje SOA Figura Orientación al Negocio en SOA Figura Modelo de Recursos Figura Modelo de Necesidades y Capacidades Figura Modelo de la Estructura Social Figura Modelo de Estado Compartido y Hechos Sociales Figura Plan de Administración del Proyecto, entradas y salidas Figura Alcance de la Definición, entradas y salidas Figura Estructura y Distribución de trabajo PMI Figura Estructura y Distribución de Trabajo, entradas y salidas Figura Control y Seguimiento de un Proyecto Figura Transición de Soporte y Liberación Figura Sistema de Pagos Electrónicos Interbancarios SPEI Figura Interacción entre plataformas en relación con el flujo de una transacción SPEI Figura Diagrama de Arquitectura Física Sistemas Banco de Estudio Figura Tuxedo, middleware orientado a transacciones Figura Arquitectura general del sistema SPEI Figura Áreas del Banco y el SPEI Figura Cliente Activo y Atención a clientes Figura Atención a clientes y Sistema Principal Bancario Figura Sistema Principal Bancario y Servidor de Transferencia de Archivos, flujo Figura Servidor de Transferencia de Archivos y Sistema Middleware, flujo Figura SPEI de envío donde le Banco en estudio envía un pago electrónico interbancario SPEI al Banco de México Figura Flujo SPEI de Recepción y Rechazo Figura Participantes del Proyecto y Recursos Organizacionales Figura Participantes del Proyecto y Recursos Organizacionales Figura Arquitectura Punto de Partida Figura Proceso del Negocio actual, envío de pago Figura Proceso del Negocio actual, recepción de pago Figura Puntos de quiebre en proceso actual de una transacción Figura Procesos Manuales, posible inconsistencia Figura Aislamiento no cumplido en proceso actual

10 Contenido Figura Proceso de Envío de Pago, Punto de Arribo Figura Proceso de Recepción de Pago, Punto de Arribo Figura Diagrama de arquitectura de sistemas de nuestro nuevo punto de arribo, eliminación de sistemas innecesarios Figura Proceso de Recepción de Pago, Punto de Arribo, flujo homogeneo Figura Proceso de Recepción de Pago, Punto de Arribo, flujo homogeneo en sentido opuesto Figura Procesamiento de pagos electrónicos interbancarios en línea Figura Procesamiento de pagos actual no es seguro ni confiable Figura Paquete Implementación SOA - SPEI Figura Sub paquetes: Sistema Principal Bancario y Sistema SPEI Figura Sub paquetes: Sistema Principal Bancario, Sistema SPEI y Comunicación Figura Sub Paquete Sobre SOAP anidado a Sub Paquete Comunicación Figura Delimitación Servicio Web Figura Delimitación Servicio Web, WSDL y XSD Figura Seguridad Integrada en Sub Paquetes Figura Implementación de Balanceadores Figura Encapsulamiento Servicios de Pagos Electrónicos Interbancarios Figura Integración de Participantes e Interesados Figura Integración de Participantes e Interesados Figura Esquema de Soporte y Mantenimiento Figura Implementación Solución SOA completa Listado de Tablas Tabla Estructura base del WSDL Tabla Objetivos del Proyecto Tabla Principales participantes del proyecto, detalle Tabla Línea de Tiempo Tabla Costo Beneficio Tabla Requerimientos Puntuales Tabla Arquitectura y Técnología de Sistemas Principal Bancario y SPEI Tabla Estándares de acuerdo al banco de estudio por sistema Tabla Estándares de acuerdo al banco, observaciones Tabla Estructura XML de Petición y Respuesta

11 Resumen Resumen El presente trabajo está orientado a la implementación de una solución SOA (Service Oriented Architecture), dicha solución se da a partir de la necesidad de integrar dos plataformas tecnológicas diferentes en un banco en estudio determinado con el fin de establecer una comunicación en línea para poder enviar y recibir pagos electrónicos interbancarios de acuerdo a los requerimientos regulatorios que demandan una reducción considerable en el tiempo de procesamiento tanto de pagos de entrada como de salida, adicional a esto, la solución SOA proporciona al negocio una optimización de procesos actuales tanto tecnológicos como manuales, reduciendo el riesgo de vulnerabilidad y seguridad tecnológica de la información y proporcionando servicios tecnológicos de acuerdo a las mejores prácticas de implementación de arquitectura de sistemas basados en SOA. Como principal trabajo se tiene el correcto y detallado análisis de los requerimientos y flujo de trabajo de los procesos del negocio. De forma breve son dos principales, el flujo de recepción de pagos electrónicos interbancarios los cuales se reciben y procesan en el sistema del banco en estudio llamado SPEI y manualmente se capturan en el sistema principal bancario, el segundo proceso es el envío de pagos electrónicos interbancarios el cual consiste en capturar en el sistema principal bancario el retiro y este sistema a su vez envía un archivo plano con el registro de los pagos por enviar cada determinado tiempo a un sistema intermediario el cual posteriormente le da el formato aceptado por el sistema SPEI que de forma manual se le carga dicho archivo y se procesan finalmente los pagos de salida. Ambos procesos se mejoran con la solución SOA, exponiendo servicios web en ambos sistemas para poder enviar y recibir mensajes con la información correspondiente de cada tipo de pago de envió y recepción, proporcionando seguridad, integridad de datos, aplicación en línea por ende reducción de tiempo de procesamiento, conciliación reducida y de mayor confianza. El trabajo expuesto detalla la implementación de la solución SOA mediante la aplicación de técnicas de administración de proyectos con la referencia de las mejores prácticas expuestas por la PMI, detallando las diferentes fases desde el inicio, estimación de esfuerzo, tiempo y costo, análisis, diseño e implementación del proyecto. 7

12 Abstract Abstract The present work is focused on the implementation of a solution SOA (Service Oriented Architecture), this solution is given from the need to integrate two different technology platforms in a particular bank under study, in order to establish a communication line to send and receive wire interbank payments according to regulatory requirements that demand a considerable reduction in processing time payments of both input and output, in addition to this, the SOA solution provides technological and manual business process optimization, reducing the risk of vulnerability and technological security of the information and providing technological services according to best practices for implementing system architecture based on SOA. The main work consists on performing the correct and detailed analysis in the business needs, breaking them down in requirements, as well as the workflow business processes. In brief are two major business processes, incoming wire payments flow which are received and processed in the bank system under study called SPEI and manually captured in the core banking system, the second process is outgoing wire payments flow which consists on to capture in the core banking system the withdrawal and then this system generates a flat file with all the records of withdrawals performed in order to be pushed every half an hour to an intermediate system which later gives the format accepted by the SPEI system and business manually load the file into the system, then SPEI processes the file with all the payments. Both processes are enhanced with SOA solution, exposing web services in both systems to send and receive messages with relevant information for each type of workflow: incoming and outgoing payments, providing security, data integrity, online application, hence there is a business process time reduction, minimized and more trusted reconciliation. This presented work details the implementation of the SOA solution by applying project management techniques with the benchmark of the best practices set by the PMI, detailing the different stages from the beginning, estimation of effort, time and cost, analysis, design and implementation of the project. 8

13 Introducción. El problema que pretende solucionar esta iniciativa y propuesta de tesis es a nivel general integrar dos sistemas fundamentales para la operación del banco en Estudio, su sistema principal bancario (sistema donde se encuentra la información financiera de los clientes del banco, sus cuentas eje, sus productos y estado financiero) con su sistema de pagos electrónicos interbancarios (sistema certificado por el banco central y especializado en el manejo de pagos electrónicos) ambos sistemas están desarrollados en tecnologías diferentes y deben ser conectadas siguiendo las mejores prácticas de arquitectura de software así como los estándares de trabajo reconocidos y validados por el grupo tecnológico del banco en estudio para garantizar la seguridad y estabilidad del funcionamiento de la integración. El problema se vuelve más puntual al considerar dentro de la integración, la identificación de todo aquel proceso manual que intervenga en el flujo de operación que se busca como punto de arribo ya sea para la consolidación o para el control y ejecución de pagos electrónicos, estos procesos manuales se deben analizar y determinar si son necesarios considerarlos y automatizarlos o definitivamente ya no serán necesarios una vez puesta en producción la solución en línea. Por lo anterior es necesario llevar a cabo un análisis exhaustivo de los objetivos del proyecto para definir el proceso nuevo que tendrá el banco en la operación de este tipo de transacciones, los pagos electrónicos interbancarios. Otro problema es la transición del proceso, el entrenamiento y mitigación de reducción de personal, definiendo nuevos procesos, tareas y responsabilidades para ejercer la operación ahora en línea con el correspondiente control, monitoreo y consolidación de transacciones entre sistemas requeridos por el nuevo paradigma propuesto. El tema propuesto de tesis surge a partir de la identificación de una oportunidad de mejora en la operación de un banco de su sistema de pagos electrónicos interbancarios. El banco ha operado durante más de 5 años bajo el mismo esquema, bajo los mismos procesos de operación sin tener la necesidad de cambiarlo, sin embargo; el incremento en la demanda de su operación de pagos electrónicos interbancarios mas las regulaciones de ley que cada vez exigen una operatividad de alta calidad han causado que la operación del banco se encuentre bajo constante riesgo y estrés operacional tanto en los recursos humanos como en los recursos técnicos, lo cual incrementa las probabilidades de error en la operación, consolidación y atención al cliente, quedando en desventaja en el mercado y degradando el prestigio del banco. La operación actual del banco está compuesta por diversos procesos manuales y depende en gran magnitud de procesos por lotes para proveer el servicio completo de pagos electrónicos interbancarios. Los procesos manuales van desde la atención al cliente telefónica hasta la carga manual de archivos electrónicos con lotes de pagos electrónicos para ser procesados por el sistema correspondiente y ser enviados al banco central. Estas actividades son de alto riesgo para la operación del banco, ya que se manejan cantidades de dinero de gran magnitud, en caso de existir un error manual puede costar 9

14 Introducción desde los cientos de pesos hasta los millones de pesos que en parte involucran sanciones por parte del banco central debido a la mala operación. Otro proceso manual que también pone en alto riesgo la operación eficaz y eficiente del banco es la recepción de pagos electrónicos, ya que hoy en día el banco mantiene a un par de recursos monitoreando las intenciones de pago electrónicos, una vez recibidos por la plataforma encargada, los recursos validan manualmente la integridad de los datos y que la cuenta destino este activada, si la validación manual es correcta se procede con la captura manual en la plataforma nuclear del banco del pago electrónico interbancario, aquí es donde se identifica un riesgo alto, ya que desde la validación hasta la captura manual del pago el usuario puede cometer un error de captura y registrar una cantidad menor o superior a la intencionada, lo cual repercute en procesos de aclaración y justificación ante el cliente y le banco central, asumiendo la responsabilidad y consecuencias pertinentes, como lo son el pago de multas. Por lo anterior se propone mitigar los riesgos descartando todos aquellos procesos manuales que pongan en riesgo la operación y no sean necesarios de llevar a cabo ante la integración de las dos plataformas. Como se menciono en el objetivo de este tema de tesis, aunado a la integración de las plataformas se busca una alta disponibilidad y carga balanceada de operaciones entre las plataformas, principalmente la encargada de gestionar los pagos electrónicos interbancarios, conocida como SPEI. Lo anterior se debe a que actualmente el banco cuenta con un solo servidor Activo de operación y en caso de que el servidor presente alguna falla técnica la operación de pagos electrónicos se detendrá por completo poniendo en riesgo el cumplimiento de tiempos de operación estipulados por el banco central. Actualmente el banco cuenta con un servidor de producción y un servidor de respaldo, lamentablemente no es tan sencillo y rápido el cambio de ambientes ya que se debe analizar que es más factible si restaurar el servidor productivo o proceder con el servidor de respaldo, lo segundo implica analizar que los pagos electrónicos tanto enviados como recibidos estén sincronizados con el banco central para evitar duplicidad y/o rechazo de pagos correctos. Finalmente se considera dentro de la iniciativa propuesta, la implementación de un vínculo de comunicación secundario al principal, el principal hoy en día consiste en establecer un vinculo directo punto a punto entre el banco central y el banco participante mediante un equipo de ruteo que administra la conectividad entre los dos puntos, si este equipo llega perder conectividad se detiene la operación de pagos electrónicos interbancarios, el banco central tiene la opción de establecer no solo conectividad por este esquema sino también por un esquema de red virtual privada, aprovechando esta posibilidad se propone implementar esta red e incluirla dentro de la arquitectura final a esta iniciativa. Proponer una solución tecnológica que mejore y automatice el proceso de pagos interbancarios de un banco que no tiene integrado su sistema nuclear bancario con su sistema de pagos electrónicos interbancarios. Esta solución reducirá tiempo y costo al banco en la operación de pagos electrónicos interbancarios. La integración de las dos principales plataformas de operación del banco no solo reduce tiempo de operación del proceso del negocio también busca que la operatividad y comunicación entre estas dos plataformas sea en línea, por lo que se debe proponer además de la arquitectura de conectividad la correspondiente solución para garantizar el correcto flujo de operación entre ambas plataformas, esta solución debe dar al banco la seguridad de que la operación llevada a cabo en la plataforma nuclear bancaria sea congruente con la registrada en la plataforma 10

15 de sistema de pagos electrónicos interbancarios. Adicionalmente el flujo de la operación a través de las plataformas debe de cumplir con las regulaciones de ley estipuladas con el banco central. Considerando otro punto importante que esta solución proveerá al beneficio de la operación del banco, esta la propuesta de implementar las herramientas tecnológicas necesarias para tener una alta disponibilidad de las plataformas, una carga balanceada de operatividad y un enlace de comunicación secundario que respalde la conectividad con el banco central. El alcance de la iniciativa de SPEI En Línea estará sujeto a los siguientes puntos: Integrar dos plataformas fundamentales para la operación de pagos electrónicos interbancarios del banco: el sistema nuclear bancario con el sistema de pagos electrónico interbancarios SPEI, estableciendo una operación en línea, SPEI En Línea. El sistema nuclear bancario se encarga de gestionar las cuentas eje de los clientes del banco, en el se hacen créditos y débitos a las cuentas de los clientes, su operación por lotes debe ser consolidada la operación del sistema de pagos electrónicos interbancarios, la iniciativa busca la eliminación de procesos por lotes y tener una consolidación puntual sobre la operación en línea. Descartar todos los procesos manuales que no sean necesarios al tener la solución en línea y que pongan en riesgo la operación del banco, sistematizándolos en lo posible en la iniciativa propuesta. Definir la arquitectura adecuada para la integración de las plataformas que están construidas en diferentes tecnologías haciendo uso de estándares de conectividad y comunicación electrónica. Definir el flujo operativo en línea de acuerdo al proceso actual de operación del banco y las regulaciones de operación estipuladas por el banco central. Definir la arquitectura de alta disponibilidad y balanceo de carga de operación en la plataforma de pagos electrónicos interbancarios una vez puesta en línea. Definir el esquema de comunicación secundario con el banco central para mitigar el riesgo de no operación por falla de comunicación con el enlace primario mediante el uso de una red privada virtual. La iniciativa depende de muchos estándares tecnológicos y metodología de operación definidos por el banco participante. Adicionalmente se debe ajustar a las reglas de operaciones estipuladas por el banco central y el presupuesto asignado a la iniciativa. El sistema nuclear bancario está diseñado para ofrecer un servicio de alta operación por lo que su interfaz de usuario es bastante austera y no proporciona módulos de consulta a la base de datos tan amigable y fácilmente, por lo que si la necesidad no está lo suficientemente justificada se seguirá trabajando con las herramientas de consolidación y reporteo que hoy en día se tienen, estas consisten en correr procesos por lotes al final del día operativo para que al día siguiente el negocio pueda hacer sus procesos de reporte y consolidación correspondientes. De lo anterior es que un modulo de reporteo en línea no será una opción viable, se limitará a trabajar bajo un esquema de reportes por lotes y horarios, con el fin de evitar el incremento de tráfico de información en la plataforma e impactar la operación del banco. 11

16 Introducción Otra limitante es que el sistema nuclear del banco participante no puede tener integrada la funcionalidad del sistema de pagos electrónicos interbancarios y de esta manera omitir el hecho de tener dos sistemas en teoría haciendo dos cosas iguales. Esto se puede confundir ya que, el sistema de pagos electrónicos interbancarios es una aplicación dedicada y certificada por el banco central de México, esta solución dedicada tiene muchos módulos y funcionalidades especiales para el manejo de una transacción y su sincronización de datos con el banco central, por lo que el sistema nuclear bancario solo es un mensajero y receptor de transacciones electrónicas que han pasado por diversos procesos, validaciones y estados a cargo del sistema especialista y certificado en estas tareas, el SPEI. El sistema de pagos electrónicos interbancarios, como ya se mencionó; es un sistema certificado por el banco central, por lo que su flujo de operación esencial no puede ser cambiada y las operaciones deben ajustarse a las reglas del banco central, esto significa respetar los estados de cada operación que se manejan de a cuerdo al manual de operación definido por el banco central. Esto impacta a la iniciativa ya que limita el manejo de estados de operaciones para poder tener un seguimiento más puntual sobre el estado de cada operación que se envía en línea entre las dos plataformas. Se espera presentar una solución tecnológica a una problemática en el mundo real, puntualmente en el ámbito financiero. Dicha solución tecnológica se espera proporcione todos los elementos necesarios para implementar un servicio de pagos electrónicos interbancarios en línea tales como: fundamentos teóricos sobre la metodología y prácticas sugeridas, análisis de procesos del negocio y análisis de flujo operativo de sistemas informáticos, identificación de equipos de trabajo necesarios e impactados tanto operativos como técnicos, planificación y organización de un proyecto informático que permita la implementación de la solución tecnológica, diseño tecnológico y modelado de procesos del negocio como resultado de la propuesta de la solución a implementar. Adicionalmente se espera tener como resultado tecnológico presentar el diseño de una Arquitectura de Sistemas basada en SOA, que muestre de forma clara de lo general a lo particular la solución al problema en el mundo real, los servicios ofrecidos y su correspondiente flujo de trabajo en un banco de estudio determinado. 12

17 Breve reseña del estudio El presente trabajo está enfocado en un problemática del mundo real de un determinado banco de estudio, dicha problemática básicamente consiste en no tener un proceso de operación tanto organizacional como tecnológico que proporcione un servicio de pagos electrónicos interbancarios los suficientemente seguro, rápido y confiable. Este trabajo presenta la solución a la problemática mostrando un robusto marco teórico que fundamenta su correspondiente diseño tecnológico y modelado del proceso del negocio al banco en estudio. El diseño tecnológico está enfocado en el estudio y puesta en práctica de una arquitectura de sistemas basado en SOA (Service Oriented Application por sus siglas en inglés) aplicación orientada a servicios, donde el servicio principal que se busca ofrecer es el de pagos electrónicos interbancarios. La solución se presenta de tal forma que se pueda aplicar en lo posible en cualquier organización siendo así una forma de iniciar una nueva buena práctica en la implementación de una arquitectura de sistemas basado en SOA. Esta buena práctica considera tanto aspectos técnicos como aspectos organizacionales de tal forma que se identifique claramente los puntos de vinculación y su correspondiente impacto permitiendo tener un panorama amplio del alcance de la problemática y de su solución, facilitando a los equipos de trabajo la fluidez de la implementación con el menor impacto posible. 13

18 Capítulo I Sistemas Distribuidos 1.1 Introducción Un sistema distribuido es aquel en el que los componentes localizados en computadores, conectados en red, comunica y coordinan sus acciones únicamente mediante el paso de mensajes. Como características de los sistemas distribuidos se tienen: concurrencia de los componentes, carencia de un reloj global y fallos independientes de los componentes [1]. Una arquitectura centralizada a diferencia de una distribuida, cada persona tiene una terminal local que se conecta por un mecanismo de comunicación a la instalación central de procesamiento de datos. Una instalación centralizada se caracteriza por hacer uso de computadores centralizados, seguir un procesamiento centralizado donde todas las aplicaciones se ejecutan en las instalaciones centrales de procesamiento de datos y finalmente trabaja con datos centralizados, todos los datos se almacenan en ficheros y bases de datos en las instalaciones centrales y son controlados y accedidos por el computador central. Un sistema distribuido debe proporcionar concurrencia, en una red de computadores, la ejecución de programas concurrentes es la norma, una persona puede realizar su trabajo en su computador, mientras otra realiza su trabajo en la suya compartiendo recursos cuando es necesario. La inexistencia de reloj global, aplica cuando los programas necesitan cooperar, coordinan sus acciones mediante el intercambio de mensajes. La coordinación estrecha depende a menudo de una idea compartida del instante en el que ocurren las acciones de los programas. Pero resulta que hay límites a la precisión con lo que los computadores en una red pueden sincronizar sus relojes, no hay una única noción global del tiempo correcto [2]. Todos los sistemas de información pueden fallar y los diseñadores de sistemas tienen la responsabilidad de planificar las consecuencias de posibles fallos. En un sistema distribuido se debe buscar la operatividad a base de fallos independientes en lo mayor posible. Motivos para implementar un sistema distribuido están por ejemplo el hecho de compartir recursos. Los recursos pueden ser administrados por servidores y accedidos por clientes o pueden ser encapsulados como objetos y accedidos por otros objetos clientes. Otro motivo es analizar la idea de tener más componentes lo cual significaría más usuarios, más datos y más patrocinadores, o pensar en tener más componentes que daría como resultado una mayor habilidad para hacer cosas a la razón de log(n) años de anticipación que otros. Pero hay otro motivo por el cual es necesario llevar a la práctica la implementación de un sistema distribuido, el cual es la interconexión de sistemas totalmente diferentes que debido a un proceso determinado se requiere de la participación de los dos sistemas para ser cumplimentado, 14

19 Sistemas Distribuidos convirtiéndose así en un sistema único distribuido para al menos este proceso en particular. Lo cual en realidad estaría definiendo más lo que sería un proceso distribuido. Lo anterior se puede alcanzar diseñando adecuadamente el sistema distribuido, este diseño debe estar basado en una arquitectura en capas: Sistema Distribuido Clustering Multiprocesamiento Simétrico Hilos, distribución de medios y Tareas Vectorización - Registros Figura Arquitectura en Capas de un Sistema Distribuido Cada capa es una disciplina separada, la idea esencial es entender que la implementación adecuada de cada una de las capas fortalecerá y facilitará la implementación de la siguiente. Un sistema distribuido se da gracias a la utilización de clúster, un clúster proporcionará una alta disponibilidad, Un clúster de alta disponibilidad es un conjunto de dos o más máquinas que se caracterizan por mantener una serie de servicios compartidos y por estar constantemente monitorizándose entre sí. Teniendo una alta disponibilidad de servicios compartidos, es ideal aplicar multiprocesamiento simétrico para ejecutar hilos de tareas independientemente. Los sistemas SMP (Symmetric Multi- Processing) permiten que cualquier procesador trabaje en cualquier tarea sin importar su localización en memoria; con un propicio soporte del sistema operativo, estos sistemas pueden mover fácilmente tareas entre los procesadores para garantizar eficientemente el trabajo. Las tareas procesadas pueden ser optimizadas al trabajar directamente en registros, y no en transformaciones de los mismos, esto agiliza el procesamiento y transferencia de mensajes. 15

20 1.2 Características de un Sistema Distribuido Los sistemas distribuidos tienen diversos desafíos que resolver al momento de su implementación: heterogeneidad, extensibilidad, seguridad, escalabilidad, tratamiento de fallos, concurrencia, transparencia, independencia de locación, balance de cargas computacionales e implementación [7] Heterogeneidad La variedad y diferencia, heterogeneidad se debe aplicar a los siguientes elementos: Redes. Hardware de computadores. Sistemas operativos. Lenguajes de programación. Implementaciones de diferentes desarrolladores. Una herramienta clave para la heterogeneidad es el Middleware, es el software que provee una abstracción de programación, así como un enmascaramiento de la heterogeneidad subyacente de las redes, hardware, sistemas operativos y lenguajes de programación, CORBA es un ejemplo. La mayoría de middleware se implementa sobre protocolos de Internet, enmascarando éstos la diversidad de redes existentes. Aun así cualquier middleware trata con las diferencias de sistema operativo y hardware. Adicionalmente proporciona un modelo computacional uniforme al alcance de los programadores de servidores y aplicaciones distribuidas. Los posibles modelos incluyen invocación sobre objetos remotos, notificación de eventos remotos, acceso remoto mediante SL y procesamiento distribuido de transacciones Extensibilidad La extensibilidad de un sistema de cómputo es la característica que determina si el sistema puede ser extendido y re implementado en diversos aspectos. La extensibilidad de los sistemas distribuidos se determina en primer lugar por el grado en el cual se pueden añadir nuevos servicios de compartición de recursos y ponerlos a disposición para el uso por una variedad de programas cliente. La extensibilidad debe proveer una estandarización de interfaces, la publicación de interfaces sólo es el punto de arranque de la adición y extensión de servicios en un sistema distribuidos. 16

21 Sistemas Distribuidos Los diseñadores de los protocolos de Internet presentaron una serie de documentos denominados <<Solicitudes de Comentarios>> (Request For Comments), o RFC, cada una de las cuales se conoce por un número. Los sistemas diseñados de este modo para dar soporte a la compartición de recurso se etiquetan como sistemas distribuidos abiertos (open distributed systems) para remarcar el hecho de ser extensibles. En resumen: Los sistemas abiertos se caracterizan porque sus interfaces están publicadas. Los sistemas distribuidos abiertos se basan en la providencia de un mecanismo de comunicación uniforme e interfaces públicas para acceder a recursos compartidos. Los sistemas distribuidos abiertos pueden construirse con hardware y software heterogéneo, posiblemente de diferentes proveedores. Sin embargo, la conformidad con el estándar publicado de cada componente debe contrastase y verificarse cuidadosamente si se desea que el sistema trabaje correctamente Seguridad La seguridad de los recursos de información tiene tres componentes: confidencialidad (protección contra el descubrimiento por individuos no autorizados); integridad (protección contra la alteración o corrupción); y disponibilidad (protección contra interferencia con los procedimientos de acceso a los recursos). En un sistema distribuido, los clientes envían peticiones de acceso a dato administrados por servidores, lo que trae consigo enviar información en los mensajes por la red. Por ejemplo en comercio electrónico y banca, los usuarios envían su número de tarjeta de crédito a través de Internet. El reto se encuentra en enviar información sensible en un mensaje, por la red, de forma segura. Pero la seguridad no sólo es cuestión de ocultar los contenidos de los mensajes, también consiste en conocer con certeza la identidad del usuario u otro agente en nombre del cual se envía el mensaje Escalabilidad S dice que un sistema es escalable si conserva su efectividad cuando ocurre un incremento significativo en el número de recursos y el número de usuarios. El diseño de sistemas distribuidos escalables presenta los siguientes retos: Control del coste de los recursos físicos: según crece la demanda de un recurso, debiera ser posible extender el sistema, a un coste razonable, para satisfacerla. Para que un sistema con n usuarios sea 17

22 escalable, la cantidad de recursos físicos necesarios para soportarlo debe ser como máximo O(n), es decir proporcional a n. Control de las pérdidas de prestaciones: el tiempo que lleva acceder a datos estructurados jerárquicamente es O(log n), donde n es el tamaña del conjunto de datos. Para que un sistema sea escalable, la máxima pérdida de prestaciones no debiera ser peor que esta medida. Prevención de desbordamiento de recursos software: es difícil predecir la demanda que tendrá que soportar un sistema con años de anticipación, pero se debe considerar un rango de prevención de desbordamiento de recursos software para los servicios en cuestión. Evitación de cuellos de botella de prestación: para evitar cuellos de botella de prestación, los algoritmos deberían ser descentralizados Tratamiento de Fallos Los fallos en un sistema distribuido son parciales; es decir, algunos componentes fallan mientras otros siguen funcionando. Consecuentemente, el tratamiento de fallos es particularmente difícil. Algunas técnicas para tratar fallos son [1], [2]: Detección de fallos: algunos fallos son detectables llevando a cabo rutinas de revisión de integridad de datos por el sistema operativo como sumas de comprobación (checksums) para detectar datos corruptos en un mensaje o un archivo. Enmascaramiento de fallos: algunos fallos que han sido detectados pueden ocultarse o atenuarse, por ejemplo retransmisión de mensajes ante falla de la recepción. Tolerancia de fallos: los clientes pueden diseñarse para tolerar ciertos fallos, por ejemplo, cuando un visualizador web no puede contactar con un servidor web no hará que el cliente tenga que esperar indefinidamente mientras hace sucesivos intentos; informará al usuario del problema, dándole la libertad de intentarlo más tarde. Recuperación frente a fallos: la recuperación implica el diseño de software en el que, tras una caída del servidor, el estado de los datos pueda reponerse o retractarse (roll back) a una situación o estado anterior. Redundancia: puede lograrse que los servicios toleren fallos mediante el empleo redundante de componentes. Por ejemplo dos rutas diferentes entre cualesquiera dos Encaminadores (Routers en inglés), otro ejemplo es usar un sistema de nombres de dominio. 18

23 Sistemas Distribuidos Concurrencia Cada objeto que represente un recurso compartido en un sistema distribuido debe responsabilizarse de garantizar que opera correctamente en un entorno concurrente. De este modo cualquier programador que recoge una implementación de un objeto que no está concebido para su aplicación en un entorno distribuido deberá realizar las modificaciones necesarias para que sea seguro su uso en un entorno concurrente. Para que un objeto sea seguro en un entorno concurrente, sus operaciones deben sincronizarse de forma que sus datos permanezcan consistentes. Esto puede lograrse mediante el empleo de técnicas conocidas como los semáforos, que se usan en la mayoría de los sistemas operativos Transparencia Se define transparencia como la ocultación al usuario y al programador de aplicaciones de la separación de los componentes en un sistema distribuido, de forma que se perciba el sistema como un todo más que como una colección de componentes independientes. El manual de referencia ANSA y el modelo de referencia para el procesamiento distribuido abierto identifican ocho formas de transparencia. Transparencia de acceso: que permite acceder a los recursos locales y remotos empleando operaciones idénticas. Transparencia de ubicación: que permite acceder a los recursos sin conocer su localización. Transparencia de concurrencia: que permite que varios procesos operen concurrentemente sobre recursos compartidos sin interferencia mutua. Transparencia de replicación: que permite utilizar múltiples ejemplares de cada recurso para aumentar la fiabilidad y las prestaciones sin que los usuarios y los programadores de aplicaciones necesiten su conocimiento. Transparencia frente a fallos: que permite ocultar los fallos, dejando que los usuarios y programas de aplicación completen sus tareas a pesar de fallos del hardware o de los componentes software. Transparencia de movilidad: que permite la reubicación de recursos y clientes en un sistema sin afectar la operación de los usuarios y los programas. Transparencia de prestaciones: que permite reconfigurar el sistema para mejorar las prestaciones según varía su carga. Transparencia al escalado: que permite al sistema y a las aplicaciones expandirse en tamaño sin cambiar la estructura del sistema o los algoritmos de aplicación. 19

24 1.2.8 Independencia de locación Un sistema distribuido no debe depender una locación geográfica en particular, sus nodos, interconexiones, componentes, servicios, datos y usuarios pueden estar distribuidos geográficamente en su totalidad. Y esta distribución debe resultar transparente para el usuario haciendo referencia a la aplicación correcta de transparencia de ubicación y movilidad. Un sistema distribuido puede involucrar la interacción entre dos organizaciones diferentes con distintas rutas de red de trabajo computacional y con diferente proveedor de servicios de internet ISP. No depende de la zona horaria de alguna zona geográfica en particular, el tiempo se ajusta a las necesidades del proceso, en algunos casos por fines regulatorios y de auditoría se puede definir una zona horaria para el registro de los procesos pero en su totalidad no Balance de Cargas Computacionales Uno de los propósitos de los sistemas distribuidos es permitir que las aplicaciones y los procesos de servicio evolucionen concurrentemente sin competir por los mismos recursos y explotando los recursos computacionales disponibles (procesador, memoria y capacidades de red). Por ejemplo la implementación de un cliente SOA con tecnología.net ahorra recursos y tiempo de ejecución de procesos, ya que se busca un balance en la carga computacional por lo que no todo el trabajo recae en un servidor. Otro ejemplo es la implementación de dispositivos dedicados al balance de cargas de un servicio expuesto, el objetivo del dispositivo es distribuir adecuadamente la carga computacional que se recibe entre los diferentes nodos disponibles que exponen el mismo servicio, de esta forma no se consume de manera centralizada los recursos de un solo servidor. No todo servicio expuesto debe ser balanceado, parte de la implementación de un sistema distribuido es encontrar la armonía entre los recursos disponibles, esto significa optimizar al máximo estos recursos cubriendo en lo posible las características y mejores prácticas de un sistema distribuido. Un servicio puede no ser tan demandado y si implica un costo alto implementar un balance de cargas computacionales podría ser no realmente necesario llevarlo a cabo. Este tipo de definiciones se llevan a cabo en una fase de análisis detallada en conjunto con el analista del sistema, el analista del proceso y el arquitecto técnico Implementación La implementación de un sistema distribuido requiere de una perfecta planeación, coordinación y extremo consumo de tiempo. Como todo proyecto pasa por las fases correspondientes: definición, planeación, análisis, diseño, construcción, pruebas integrales, pruebas de usuario, manejo de versiones, liberación, monitoreo y control. 20

25 Sistemas Distribuidos Durante la fase de definición, se establecen los objetivos que se quieren alcanzar implementando un sistema distribuido, se define el sistema distribuido como una práctica que aportará un gran beneficio al proceso nuevo o existente. Se definen las partes involucradas tanto técnicas como administrativas y un alcance general de la implementación. En la planeación se trabaja en la distribución de objetivos y tareas de acuerdo al orden de su necesidad, el tiempo en que cada tarea debe ser cumplida así como sus correspondientes responsables, se hace un cálculo del presupuesto requerido para todo el proyecto considerando: recursos humanos, recursos materiales, periodos de garantía y mantenimiento así como un margen de contingencia. La fase de análisis es una de las más influyentes en el éxito de la implementación de un sistema distribuido, en esta fase se deben involucrar a los analistas de sistemas, analistas de procesos, al arquitecto técnico, al grupo de infraestructura, redes y datos. De acuerdo al objetivo global del sistema distribuido, este grupo tecnócrata en conjunto deben exponer claramente cada uno de los requerimientos del sistema distribuido: requerimientos funcionales, no funcionales, de reporte, de infraestructura, de comunicaciones y datos. Adicionalmente se analizan los pasos necesarios para llevar a cabo la instalación independiente de cada nodo, componente, servicio y configuración necesaria en cuanto a comunicaciones. Los requerimientos en conjunto deben estar lo suficientemente claros y detallados con el fin de evitar ambigüedades que puedan impactar en tiempo, costo y esfuerzo al proyecto. La siguiente fase totalmente dependiente de la anterior, es la del diseño, en esta fase de acuerdo a los requerimientos analizados, cada grupo de trabajo se enfoca en el diseño de su correspondiente responsabilidad, el cual debe encajar en la estructura completa del sistema distribuido cumpliendo no solo con los requerimientos analizados si no también aplicando las mejores prácticas y estándares de implementación de procesos y tecnología que apliquen. En la construcción los equipos de trabajo siguen al pie de la letra dos documentos entregables los requerimientos derivados del análisis y el documento de diseño final del sistema distribuido. Trabajan en la construcción de su correspondiente asignación ya sea en la documentación de un proceso que se implementará en el sistema distribuido, ya sea en la programación de una interfaz de procesos entre dos sistemas. El seguimiento al progreso de la construcción mediante juntas continuas, minutas y reporte de avances fortalecerá esta fase proporcionando un porcentaje de garantía alto en el cumplimiento en tiempo de acuerdo al plan de trabajo. Una vez concluida la construcción se pueden llevar a cabo pruebas integrales, estas pruebas no dependen necesariamente de la construcción completa del sistema distribuido, pueden llevarse a cabo pruebas integrales de comunicación entre dos nodos que ya estén listos antes que el resto de las demás partes. Las pruebas integrales de comunicación y visibilidad entre los nodos participantes suelen ser las primeras. En las pruebas integrales se debe asegurar que al final el sistema distribuido está listo para ser probado por un usuario del proceso completo de principio a fin y evaluar el comportamiento del sistema distribuido. Las pruebas de usuario se ejecutan de principio a fin en el sistema distribuido monitoreando el comportamiento del mismo en cada parte involucrada, revisando no solo los resultados finales de 21

26 interés para el usuario si no también el tiempo de envío y respuesta de los mensajes que se intercambian entre componentes. Pruebas de estrés y concurrencia deben llevarse a cabo, simulación de caídas de nodos y poner a prueba la implementación de la arquitectura de alta disponibilidad. Dependiendo del plan de trabajo y la prioridad de los requerimientos se puede implementar una primera versión del sistema distribuido, su objetivo es cubrir los requerimientos de alta prioridad y una segunda versión cubrirá los requerimientos restantes, un ejemplo de este escenario se da cuando por regulaciones legales y tiempos acortados es necesario primero cumplir con los requerimientos que están relacionados directamente con la regulación legal y posteriormente con los requerimientos que complementaran al sistema distribuido. La fase de liberación implica un gran de trabajo de comunicación y capacitación con diferentes grupos, el grupo de usuarios que utilizaran el sistema distribuido, el grupo de soporte técnico que se hará responsable del sistema distribuido, los puntos principales de contacto de cada grupo debe estar completamente enterado del objetivo y alcance del sistema distribuido. Al llevar a cabo la liberación la siguiente fase es el monitoreo y control del comportamiento del sistema distribuido, en caso de presentarse una falla se debe actuar con rapidez y eficacia debido a que el sistema distribuido ya está liberado el proceso productivo se ve directamente impactado, la comunicación y clara identificación de los responsables de cada componente es importante para poder llevar a cabo el análisis y solución de la falla. El periodo de estabilidad varía de la complejidad de un sistema a otro pero en una media debe darse en un mes de trabajo productivo aproximadamente. Todas las fases en un sistema distribuido requieren de un gran liderazgo por parte de todos los participantes clave del proyecto y una acción inmediata en caso de una respuesta contraria o resultados no alcanzados de acuerdo al plan de trabajo. 1.2 Arquitecturas de Sistemas Distribuidos La arquitectura de un sistema es su estructura en términos de componentes especificados por separado. El objetivo global es asegurar que la estructura satisfará las demandas presentes y previsibles sobre él. Existen diversos modelos arquitectónicos empleados en los sistemas distribuidos. Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de información. Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes para cada caso en concreto. Así, las arquitecturas distribuidas más universales son [7], [9], [12], [13]: Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes independientes pero sin reparto claro de funciones. 22

27 Sistemas Distribuidos Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relación con la siguiente. Orientada a Servicios SOA (Service Oriented Architecture). Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros Capas de Software Toda arquitectura de software esta descrita por capas de software que se complementaran con elementos de infraestructura hardware. Las capas básicas en una arquitectura de software son: el hardware que incluye computador y hardware de red, sistema operativo, middleware y aplicación de servicios. Computador y hardware de red Sistema Operativo Middleware Aplicación de servicios Figura Capas básicas en una arquitectura de software La plataforma de la arquitectura de un sistema distribuido la conforman el nivel de hardware y las capas más bajas de software. Estas capas más bajas proporcionan servicios a las que están por encima de ellas, y que son implementadas independientemente en cada computador, proporcionando una interfaz de programación del sistema a un nivel que facilita la comunicación y coordinación entre procesos. El middleware como capa de software tiene el propósito de enmascarar la heterogeneidad y proporcionar un modelo de programación conveniente para los programadores de aplicaciones. Se representa mediante procesos u objetos en un conjunto de computadores que interactúan entre sí 23

28 para implementar mecanismo de comunicaciones y de recursos compartidos para aplicaciones distribuidas. Mejora las actividades de comunicación de los programas de aplicación soportando abstracciones como: procedimiento de invocación remota, comunicación entre un grupo de procesos, notificación de eventos, replicación de datos compartidos y transmisión de datos multimedia en tiempo real. Entre los productos estándares de middleware orientados al objeto están CORBA (Common Object Request Broker Architecture), invocación de objetos remotos en Java RMI (Remote Method Invocation), Modelo Común de Objetos Distribuidos de Microsoft (DCOM). La aplicación de servicios es el software encargado de procesar la información obtenida mediante el middleware, un middleware esta en el medio de dos software, por lo que en la capa de aplicación de servicios se procesa la información en base a las reglas del negocio, para su posterior distribución y/o dar respuesta a la petición del servicio a través del middleware en sentido opuesto Arquitectura Cliente-Servidor Al momento de diseñar la arquitectura de un sistema, se deben analizar detalladamente los objetivos de los mismos, las partes involucradas deben identificar puntualmente los componentes necesarios y su distribución correspondiente con el fin de optimizar todos los recursos disponibles: hardware, comunicación, tiempos de respuesta, carga computacional, almacenamiento y replicación de datos, procesos centralizados entre otros. En un sistema distribuido, los procesos con responsabilidades bien definidas interactúan con los otros para realizar una actividad útil. La arquitectura cliente-servidor en esencia se muestra a continuación: 24

29 Sistemas Distribuidos Servidor Web Servidor de Aplicaciones LAN, WAN, Internet Cliente Servidor Base de Datos Cliente Cliente Cliente Figura Arquitectura Cliente-Servidor Cada servidor en un entrono cliente-servidor proporciona un conjunto de servicios compartidos a los clientes. El tipo más común de servidor es un servidor de bases de datos, que normalmente controla una base de datos relacional. Un tercer elemento importante en esta arquitectura es el componente de red. La interacción entre clientes y servidores se da mediante una red de trabajo computacional la cual puede ser LAN, WAN o inclusive Internet. La característica fundamental de esta arquitectura es la distribución de tareas de la aplicación entre el cliente y el servidor. El cliente contará con los siguientes elementos: servicios de presentación, lógica de aplicación, software de comunicaciones, sistema operativo cliente, plataforma hardware. El servidor por su lado estará formado por la lógica de aplicación, software de comunicaciones, sistema operativo servidor, plataforma hardware. Su correspondiente software de comunicaciones interactuara en la red de trabajo computacional y su correspondiente lógica de aplicación empleara el software de comunicación de manera óptima a través de un middleware el cual enmascara la heterogeneidad ejecutando tareas de petición, respuesta e interacción del protocolo de comunicación. 25

30 Cliente Middleware Servidor Servicios de presentación Petición Lógica de aplicación Lógica de aplicación Respuesta Software de comunicaciones Software de comunicaciones Interacción del protocolo Sistema operativo servidor Sistema operativo cliente Plataforma hardware Plataforma hardware Figura Middleware enmascara la heterogeneidad La arquitectura tradicional cliente-servidor implica normalmente dos niveles o capas: la capa del cliente y la capa del servidor, en la figura anterior se expone el middleware. También es habitual una arquitectura de tres capas. En esta arquitectura el software de la aplicación se distribuye en tres tipos de máquinas: una máquina de usuario, un servidor en la capa central, y un servidor en segundo plano. Las máquinas de la capa central son normalmente una pasarela entre los clientes ligeros y varios servidores de bases de datos en segundo plano. Las máquinas de la capa central pueden convertir protocolos y cambiar de un tipo de consulta de base de datos a otra. La interacción de la capa central y el servidor en segundo plano también sigue el modelo cliente-servidor Middleware El Middleware son interfaces de programación, protocolos y estándares que ayudan a enmascarar la heterogeneidad de un sistema distribuido. Empleando estos elementos, interfaces, protocolos y estándares resulta sencillo implementar la misma aplicación en varios tipos de servidores y estaciones de trabajo, eliminando por completo la posible dependencia de una solo tecnología. En la arquitectura cliente-servidor se hizo mención de un Middleware que interactuaba entre el cliente y el servidor. De manera más detallada el middleware en realidad se encuentra en ambos puntos cliente y servidor, que de acuerdo a los protocolos y estándares definidos para trabajar se desarrollarán e implementarán las interfaces en cada lado, de esta forma tanto las componentes middleware del cliente como las componentes middleware del servidor serán capaces interactuar una con la otra sin inconvenientes. El propósito básico del middleware es permitir a una aplicación o 26

31 Sistemas Distribuidos usuario en el cliente acceder a una variedad de servicios en el servidor sin preocuparse de las diferencias entre los servidores. En un sistema distribuido, el middleware se define como la capa de software que se encuentra entre el sistema operativo y las aplicaciones en cada lado del sistema, cliente-servidor [14]. Debido al gran crecimiento de los sistemas computacionales en las organizaciones de cualquier índole, se ha hecho necesario el estudio dedicado a la implementación eficaz y eficiente de un middleware. Esta capa de software hace que los sistemas existentes y nuevos sean más robustos y capaces de interactuar con otros de tecnologías totalmente ajenas a la suya, abriendo un amplio camino de opciones de crecimiento a los procesos organizacionales dependientes de sistemas computacionales principalmente que en plataforma web. Algunas de las funcionalidades principales de un middleware son: Ocultamiento de la distribución. Enmascaramiento de la heterogeneidad de varios componentes hardware, sistemas operativos, protocolos de comunicación y lenguajes de programación. Provee uniformidad, estándares y un alto nivel de interfaces a los desarrolladores de aplicación así como a los integradores de las mismas, de tal manera que la aplicación puede ser fácilmente compuesta, reutilizada, portable y operable. Provee un conjunto de servicios comunes para llevar a cabo funciones de propósito general con el fin de evitar esfuerzos duplicados. Existe una variedad de productos middleware, básicamente todos se basan en uno o dos mecanismos: el paso de mensajes y las llamadas a procedimiento remoto. 1.3 Comunicación Entre Procesos El paso de mensajes entre un par de procesos se puede basar en dos operaciones: envía y recibe, definidas en función del destino y del mensaje. Para que un proceso se pueda comunicar con otro, el proceso envía un mensaje (una secuencia de bytes) a un destino y otro proceso en el destino recibe el mensaje. Esta actividad implica la comunicación de datos desde el proceso emisor al proceso receptor y puede implicar además la sincronización de los dos procesos. La comunicación entre procesos se puede dar de dos tipos síncrona y asíncrona, en la forma síncrona, los procesos receptores y emisor se sincronizan con cada mensaje. En este caso, tanto envía como recibe son operaciones bloqueantes lo cual significa que a cada envía producido, el proceso emisor se bloquea hasta que se produce el correspondiente recibe. Cuando se invoca un recibe, el proceso se bloquea hasta que llega un mensaje. 27

32 En la forma de comunicación asíncrona, la utilización de la operación envía es no bloqueante, de modo que el proceso emisor puede continuar tan pronto como el mensaje haya sido copiado en el búfer local, y la transmisión del mensaje se lleva a cabo en paralelo con el proceso emisor. La operación recibe puede tener variantes bloqueantes y no bloqueantes. En la variante no bloqueante, el proceso receptor sigue con su programa después de invocar la operación recibe, la cual proporciona un bufe que será llenado en un segundo plano, pero el proceso debe ser informado por separado de que su búfer ha sido llenado, ya sea por el método de encuesta o mediante una interrupción. La comunicación per se incluye un mensaje, el mensaje precisa de un medio de transmisión, un origen y un destino, en términos de sistemas computacionales los mensajes son enviados a direcciones construidas por pares: dirección, puerto local, donde un puerto local es el destino de un mensaje dentro de un computador, este puerto es especificado como un numero entero. Un puerto significa un receptor pero puede tener muchos emisores y los procesos pueden utilizar diversos puertos para recibir sus mensajes. Un proceso cliente para que pueda enviar un mensaje necesita saber claramente el destino, bajo los protocolos de internet una máquina es identificada por una dirección IP, la cual puede ser fija o no. Bajo esta sentencia un proceso tiene que tener siempre la dirección actual de la máquina destino así como sus puertos de recepción actualizados para poder enviar correctamente los mensajes al destino. En caso de que el servicio llegará a cambiar de máquina sería necesario actualizar al proceso emisor con los nuevos datos del destino para poder seguir enviando los mensajes necesarios correctamente. Esto se puede evitar utilizando alguna de las siguientes opciones que proporcionan transparencia de ubicación: Los programas cliente se refieren a los servicios por su nombre y utilizan un servidor de nombres o enlazador para trasladar esos nombres a ubicaciones del servidor en tiempo de ejecución, permitiendo reubicar los servicios en otro lugar, pero no migrarlos. El sistema operativo, proporciona identificadores para los destinos de los mensajes independientes de localización, haciéndoles corresponder con direcciones de más bajo nivel utilizadas para entregar los mensajes en los puertos, permitiendo tanto la migración como la reubicación de los servicios en otro lugar. La comunicación entre procesos debe ser fiable, se dice que un servicio de mensaje punto a punto es fiable si se garantiza que los mensajes se entregan a pesar de poder dejar caer o perder un número razonable de ellos. Adicionalmente algunas aplicaciones necesitan que los mensajes sean entregados en el orden de su emisión, esto es, en el orden en el que fueron transmitidos por el emisor. La entrega de mensajes desordenados, por esas aplicaciones se considera un fallo. 28

33 Sistemas Distribuidos Sockets Para ambas formas de comunicación UDP y TCP se utiliza la abstracción de sockets, que proporciona los puntos extremos de la comunicación entre procesos. La comunicación entre procesos consiste en la transmisión de un mensaje entre un conector de un proceso y conector de otro proceso. Socket Cliente n puerto Cualquier Puerto Mensaje n puerto Socket Servidor Puerto acordado Figura Abstracción de Sockets Para los procesos receptores de mensajes, su conector debe estar asociado a un puerto local y a una de las direcciones Internet del computador donde se ejecuta. Cada computador permite un numero (2 16 ) de puertos posibles, que pueden ser usados por los procesos locales para recibir mensajes. Cada conector se asocia con un protocolo concreto que puede ser UDP o TCP. Muchos de los servicios utilizados se ejecutan sobre conexiones TCP, con números de puerto reservados. Por ejemplo: HTTP: el protocolo de transferencia de hipertexto se utiliza en comunicación entre un navegador y un servidor web. FTP: el protocolo de transferencia de archivos permite leer los directorios de un computador remoto y transferí archivos entre los computadores de una conexión. SMTP: protocolo simple de transferencia de correo se utiliza para mandar correos electrónicos entre computadores. La información que se transporta de un punto a otro en los mensajes consiste en secuencias de bytes. Independientemente de la forma de comunicación utilizada las estructuras de datos deben ser aplanadas antes de su transmisión y reconstruidas en el destino. Para que dos computadores puedan intercambiar datos se puede utilizar uno de los dos métodos siguientes: Los valores se convierten a un formato externo acordado antes de la transmisión y se revierten al formato local en la recepción. Los valores se transmiten según el formato del emisor, junto con una indicación del formato utilizado, y el receptor los convierte si es necesario. 29

34 Al estándar acordado para la representación de estructura de datos y valores primitivos se denomina representación externa de datos. El empaquetado (marshalling) consiste en tomar una colección de ítems de datos y ensamblarlos de un modo adecuado para la transmisión en un mensaje. El desempaquetado (unmarshalling) es el proceso de desensamblado en el destino para producir una colección equivalente de datos. Una alternativa para empaquetar todos los objetos a transmitir es utilizar texto ASCII, lo cual es relativamente simple de implementar, pero implica un empaquetado generalmente más grande. El protocolo HTTP es un ejemplo de esta aproximación HTTP Protocolo Petición-Respuesta Un protocolo de tipo petición-respuesta está basado en un trío de primitivas de comunicación: hazoperación, damepetición, envíarespuesta [15], [2]. Cliente Mensaje Servidor hazoperación petición damepetición espera respuesta ejecución del método sobre el objeto seleccionado continuación envíarespuesta Figura HTTP protocolo petición/respuesta Este protocolo hace corresponder a cada petición una respuesta. La primitiva hazoperación se utiliza en los clientes para invocar las operaciones remotas, empaqueta la petición y desempaqueta la respuesta. La primitiva damepetición se usa en el servidor para hacerse con las peticiones de servicio. Cuando el servidor ha invocado el método sobre el objeto especificado, utiliza el método enviarespuesta para mandar el mensaje de respuesta al cliente. Estructura de un mensaje peticiónrespuesta: 30

35 Sistemas Distribuidos tipomensaje int (0=Petición, 1=Respuesta) idpetición int referenciaobjeto RemoteObjectRef idmetodo int o Method argumentos //cadena de bytes Figura Estructura de un mensaje petición-respuesta Un ejemplo de un protocolo de comunicación de tipo petición-respuesta es el HTTP. HTTP es un protocolo que especifica los mensajes involucrados en un intercambio petición-respuesta, los métodos, argumentos y resultados y las reglas para representar todo ello en los mensajes. Soporta un conjunto fijo de métodos (GET, PUT, POST, etc.). El protocolo permite la negociación de contenidos y una autenticación de tipo clave de acceso. La última versión del protocolo permite conexiones persistentes, que son aquellas que permanecen abiertas durante una serie de intercambios petición-respuesta entre el cliente y el servidor. Las peticiones y respuestas se empaquetan en los mensajes como cadenas de caracteres ASCII. Cada mensaje HTTP especifica el nombre de un método, el URL de un recurso, la versión del protocolo, algunas cabeceras y un cuerpo de mensaje opcional. Los métodos elementales HTTP de acuerdo a la RFC 2616 se describen a continuación: - GET: significa obtener información cualquier información identificada por la URL. Si la URL hace referencia al proceso de generar datos, los datos generados deben ser devueltos en la correspondiente respuesta como una entidad y no la fuente del texto del proceso a menos que sea el texto la salida del proceso. -HEAD: idéntico al método GET excepto que el servidor no debe regresar un cuerpo del mensaje en la respuesta. Este método puede ser usado para obtener meta-información acerca de la entidad en cuestión sin necesidad de obtener el cuerpo entero. -POST: método usado para pedir que el servidor acepte la entidad encapsulada en la petición como un subordinado en la fuente identificada en la URL. Es decir especifica el URL de un recurso que puede tratar los datos aportados en la petición. Está diseñado para: Proporcionar un bloque de datos, por ejemplo los de un formulario a un proceso de gestión de datos. Enviar un mensaje a un tablón de anuncios, lita de correo o grupo de noticias. Modificar un a base de datos con una operación de añadir registro. 31

36 -PUT: indica que los la entidad encapsulada debe ser almacenada en la URL dada. Ya sea como una modificación de datos existentes o como la creación de un recurso nuevo. - DELETE: solicita al servidor origen que borre la fuente de datos identificada por la petición en la URL. No siempre se permite esta función. - TRACE: el servidor envía de vuelta el mensaje de petición. - OPTIONS: el servidor proporciona al cliente una lista de métodos aplicables a un URL y sus requisitos especiales. 1.4 Interfaces En el campo de la computación, una interfaz es una herramienta y concepto que permite la interacción entre dos componentes, lo cual puede aplicarse tanto a la capa de hardware como a la capa de software. En cuanto a la comunicación entre dos componentes una interfaz proporciona los medios para organizar, coordinar y controlar los módulos encargados de ejecutar los procedimientos necesarios para la comunicación entre procesos. El uso de interfaces permite la una correcta operación entre dos componentes evitando errores en los sistemas diseñados bajo componentes. Si dos o más interfaces son compatibles, se puede asegurar que los componentes correspondientes trabajaran correctamente al en tiempo de ejecución. En una interfaz se definen los métodos, procedimientos, tipos de datos y datos de entrada y salida que describen a un proceso en particular, de tal forma que dos componentes puedan interactuar uno con el otro entendiendo completamente su correspondiente funcionalidad. El componente a requerir el servicio sabe claramente que pedir y el componente a proveer el servicio sabe claramente que ejecutar al ser ejecutado, así como las respuestas generadas son las esperadas. La especificación de un método o procedimiento en la interfaz de un módulo en un programa distribuido describe los parámetros como de entrada o salida y algunas veces ambos. Los parámetros de entrada se pasan al modulo remoto mediante el envío de valores de los argumentos en el mensaje de petición y posteriormente se proporcionan como argumentos a la operación que se ejecutará en el servidor. Los parámetros de salida se devuelven en el mensaje de respuesta y se sitúan como la respuesta de la llamada o reemplazando los valores de las correspondientes variables argumento en el entorno de la llamada. Cuando se proporciona un parámetro tanto como para entrada como para salida, el valor debe transmitirse tanto en los mensajes de la petición con en los de la respuesta. En el mundo de los Servicios Web por ejemplo, se ofrece un particular, importante y natural dominio de la aplicación de formalismos de interfaces. Un Servicio Web en ocasiones depende de otro que ha sido implementado en otros sistemas y su uso correcto depende cien por cien de la descripción de su interfaz, regida por reglas. Dichas reglas pueden restringir tipos de datos, 32

37 Sistemas Distribuidos métodos, respuestas, errores inclusive. Este tipo de interfaz son de un nivel más alto en comparación con el párrafo anterior, es una interfaz que se define sobre otra de bajo nivel, la cual es la interfaz del protocolo HTTP. 1.5 Paso de Mensajes El middleware realizará la comunicación entre dos sistemas, el sistema cliente y el sistema servidor, esta comunicación se da en base a protocolos y estándares. Un mecanismo empleado para esta comunicación es el paso de mensajes. Un proceso cliente necesita de algún servicio en particular del servidor por ejemplo, leer un archivo, imprimir, y envía un mensaje con la petición del servicio a un proceso del servidor. El proceso servidor realiza la petición y envía un mensaje con la respuesta. En una forma muy básica solamente hay dos funciones la de Enviar el mensaje y la de Recibir el mensaje. La función de Enviar especifica un destinatario e incluye el contenido del mensaje. La función Recibir indica quien se desea recibir un mensaje y proporciona un buffer donde se almacenará el mensaje entrante. Cliente Aplicación Middleware Orientado a Mensajes Transporte Red Mensajes específicos de aplicación Servidor Aplicación Middleware Orientado a Mensajes Transporte Red Proceso Emisor Middleware orientado a mensajes Proceso Emisor Módulo de Paso de Mensajes Id Proceso Mensaje Módulo de Paso de Mensajes Figura Middleware orientado a mensajes En ambos lados cliente-servidor se trabaja el envío y recepción de mensajes por medio de procesos dedicados. Las peticiones de servicio se pueden expresar en términos de primitivas y parámetros, donde una primitiva especifica la función que se desea realizar y los parámetros se utilizan para pasar los datos y la información de control. 33

38 La primitiva Enviar se utiliza cuando un proceso quiere enviar un mensaje. Sus parámetros son el identificador del proceso destinatario y el contenido del mensaje. El módulo de paso de mensajes construye una unidad de datos que incluye esto dos elementos. Esta unidad de datos se envía a la maquina que hospeda el proceso destinatario, utilizando algún tipo de servicios de comunicación como el TCP/IP. Cuando se recibe el destino la unidad de datos, el servicio de comunicación se la pasa al modulo de paso de mensajes. Este modulo examina el campo ID de proceso y almacena le mensaje en el buffer de dicho proceso. En este escenario, el proceso receptor debe dar a conocer su deseo de recibir un mensaje, designando un área de buffer e informando al módulo de paso de mensajes a través de la primitiva Recibe. El paso de mensajes se puede llevar a cabo mediante distintos protocolos de red, como TCP/IP, HTTP, IIOP (protocolo para comunicar objetos de CORBA), DCOM (protocolo para componentes ActiveX de Microsoft). Debido a la alta popularidad y practicidad de las aplicaciones web en las organizaciones el uso de comunicación bajo el protocolo HTTP se ha vuelto cada vez más en el estándar de comunicación más solicitado. Los middleware mejor conocidos que utilizan este protocolo son los llamados Servicios Web. 1.6 Servicios Web Un servicio web es un método expuesto en un servidor web que permite la comunicación entre dos aplicaciones sobre la web, siguiendo los estándares web: identificador de recurso uniforme URI, protocolo de transferencia de hipertexto HTTP, lenguaje de marcado de hipertexto HTML, lenguaje de marcado extensible XML, en el cual debe existir un método a consumir y método que consume. Adicionalmente diversas prácticas han establecido estándares para el paso de mensajes [3]. La W3C define a los Servicios Web como: Un Servicio Web es un sistema de software diseñado para apoyar la interoperabilidad de máquina a máquina con interacción en la red. Cuenta con una interfaz que se describe en un formato procesable por máquina (específicamente WSDL). Otros sistemas interactúan con el Servicio Web de una manera prescrita por su descripción mediante mensajes SOAP, por lo general transmitida a través de HTTP con una serialización XML en conjunto con otras relacionadas con los estándares Web. [16] A diferencia de los sistemas distribuidos existentes, los Servicios Web se montan en la web, teniendo como protocolo HTTP por defecto, la mayoría de las tecnologías de computación distribuida tienen incluido su protocolo de comunicación como parte de su arquitectura. En los Servicios Web el protocolo de comunicación ya existe, y es altamente utilizado, la Web. Los Servicios Web como middleware de paso de mensajes se clasifican como un Sistema de Mensajes Empresarial, EMS por sus siglas en ingles (Enterprise Messaging System). Este tipo de 34

39 Sistemas Distribuidos middleware (EMS) facilita el paso de mensajes entre sistemas distribuidos o componentes en formatos estandarizados, usualmente usan XML, SOAP o Servicios Web. Los Servicios Web para poder ser procesables por algún sistema, aplicación o componente deben ser claramente descritos en un formato procesable por la máquina. Explicando un poco la funcionalidad, un Servicio Web precisa de una interfaz la cual va a recibir un mensaje XML estandarizado desde el ambiente de red, la interfaz transforma los datos XML en un formato entendible para un software back-end particular, y, opcionalmente contesta otro mensaje. La capa de software en cargada de la correcta recepción, transformación y procesamiento de datos puede estar desarrollado en cualquier lenguaje de programación, bajo cualquier sistema operativo o sistema middleware. Aplicación Cliente Llamada Local Descripción WSDL Descripción Middleware Envío Mensaje Mensaje Recepción Mensaje Servicio Web (Interfaz) Middleware HTTP Llamada Local Aplicación Servidor Figura Interfaz y descripción de un servicio web En el ejemplo anterior se hizo mención de un XML estandarizado para la correcta transformación de los datos. Este XML estandarizado es la descripción del Servicio Web, WSDL por sus siglas en ingles (Web Services Description Language), el WSDL es un esquema XML que define un marco de trabajo extensible para describir interfaces de Servicios Web. Al ser un documento XML es bastante extensible y tiene muchas opciones para asegurar la compatibilidad e interoperabilidad a través de diferentes implementaciones. Si el que envía el mensaje y el que recibe el mensaje pueden compartir y entender la misma definición del Servicio Web, WSDL, podrán operar el Servicio Web de manera correcta. Existen distintos estilos de uso de los Servicios Web: 35

40 RPC Remote Call Procedure. Son una variante del modelo básico de paso de mensajes. Lo esencial en esta técnica es permitir a los programas en diferente máquina interactuar a través del uso de llamadas a procedimiento, tal y como lo harían dos programas que están en la misma máquina. Los RPC en Servicios Web presentan una interfaz de llamada a una función o método distribuido que es familiar a los desarrolladores involucrados. La unidad base de los RPC en Servicios Web es el WSDL. SOA, Arquitectura Orientada a Servicios. Los Servicios Web pueden ser usados para implementar una arquitectura SOA (Service-Oriented Architecture), donde la unidad básica de comunicación es un mensaje más que una operación. Esto es conocido como servicios orientados a mensajes. REST Transferencia de estado representacional. Intenta describir arquitecturas que usan HTTP o un protocolo similar por medio de restricciones en la interfaz trabajando con operaciones estándar como GET, POST, PUT, DELETE para HTTP. En este estilo el enfoque está en la interacción del estado de los recursos, más allá de mensajes y operaciones. Autores como [13] recomiendan fuertemente considerar como último paso la integración de los servicios web en arquitecturas orientadas a servicios en el desarrollo de una aplicación con una integración middleware Descripción Servicio Web, WSDL WSDL describe la interfaz pública del Servicio Web. Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje. La descripción del Servicio Web es una parte muy importante para poder acceder al servicio. La mayoría de los lenguajes de descripción de servicios están orientados a la interpretación de una máquina, permitiendo la creación de esqueletos de código de manera automática para su consumo, búsqueda y clasificación de servicios, pero también la descripción puede ser consumida por el humano con el fin de clarificar parámetros, semántica u operaciones llevadas a cabo. La estructura base del WSDL debe contener los tipos de datos que el Servicio Web trabajará, los elementos de mensaje, operaciones permitidas, protocolos usados y conjunto de puertos y dirección de los mismos. 36

41 Sistemas Distribuidos Datos Mensajes Esta sección define los tipos de datos usados en los mensajes. Se utilizan los tipos definidos en la especificación de esquemas XML. Aquí definimos los elementos de mensaje. Cada mensaje puede consistir en una serie de partes lógicas. Las partes pueden ser de cualquiera de los tipos definidos en la sección anterior. Puertos Con este apartado definimos las operaciones permitidas y los mensajes intercambiados en el Servicio. Bindings Especificamos los protocolos de comunicación usados. Servicios Conjunto de puertos y dirección de los mismos. Esta parte final hace referencia a lo aportado por las secciones anteriores. Tabla Estructura base del WSDL Una forma de localizar un Servicio Web y su correspondiente descripción es mediante el uso de la herramienta web pública UDDI. UDDI Es un modelo de directorios para Servicios Web. Es una especificación para mantener directorios estandarizados de información acerca de estos servicios, sus capacidades, ubicación, y requerimientos en un formato reconocido universalmente. UDDI utiliza WSDL para describir las interfaces de los Servicios Web. Es un lugar en el cual se puede buscar cuales son los Servicios web disponibles, una especie de directorio en el cual se puede encontrar los Servicios Web publicados y también publicar los Servicios Web desarrollados propiamente. UDDI es un protocolo estándar de OASIS [18] que define un método estandarizado para publicar y descubrir componentes de software basados en la red de trabajo computacional de una arquitectura orientada a servicios. La especificación UDDI define un grupo de Servicios Web e interfaces programables para su publicación, recuperación, y administración acerca de dichos servicios SOAP SOAP, Simple Object Access Protocol, es un protocolo estándar que define como dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Este intercambio de datos XML es el mensaje que se utiliza en una interfaz de servicios web. De acuerdo a la World Wide Consortium [16] abreviado W3C, SOAP se define como un conjunto de convenciones que gobiernan el formato y las reglas de procesamiento de un mensaje XML, en este caso SOAP. Estas convenciones incluyen la interacción entre los nodos que interactúan en el protocolo, generando y 37

42 aceptando los mensajes para el propósito de intercambio de información a lo largo de la ruta del mensaje del protocolo SOAP. Un nodo SOAP, es aquel elemento capaz de procesar la lógica necesaria para transmitir, recibir, procesar y/o retransmitir un mensaje SOAP, de acuerdo a las convenciones definidas por la W3C. Un nodo SOAP es responsable de hacer cumplir las reglas que gobiernan el intercambio de mensajes SOAP. El ligado del mensaje SOAP hace referencia al conjunto de reglas a seguir para poder transportar el mensaje SOAP dentro o encima de otro protocolo, de acuerdo a los propósitos de intercambio. Por ejemplo el ligado SOAP para poder transportar un mensaje SOAP dentro del protocolo HTTP o flujo de datos por TCP. La encapsulación de los datos en el protocolo SOAP incluye: Mensaje: la unidad básica de comunicación entre nodos SOAP. Sobre: el elemento de información más externo de un mensaje SOAP. Encabezado: una colección de cero o más bloques de encabezados cada uno de los cuales puede ser objetivo de cualquier receptor SOAP dentro de la ruta del mensaje SOAP. Bloque de Encabezados: elemento de información usado para delimitar los datos que lógicamente constituyen una simple unidad computacional dentro del encabezado SOAP. Cuerpo: es una colección de cero o más elementos de información dirigidos a un receptor SOAP dentro del mensaje SOAP. Un mensaje SOAP puede pasar por intermediarios por eso es importante definir la ruta del mensaje SOAP especificando el nodo que envía, cero o mas intermediarios y el ultimo receptor SOAP. SOAP puede aplicarse a diferentes tipos de modelo de procesamiento, todos incluyen al menos dos nodos el que envía el mensaje y el que lo recibe. Un modelo de procesamiento distribuido en SOAP puede soportar diferentes patrones de intercambio de mensajes por ejemplo mensajes de un solo camino, petición/respuesta, conversaciones punto a punto, lo anterior dependiendo de los servicios web expuestos y sus propósitos [17]. A continuación se muestra una imagen que muestra los elementos de un mensaje SOAP. 38

43 Sistemas Distribuidos Sobre SOAP Encabezado SOAP Cuerpo SOAP Figura Elementos de un mensaje SOA Como ejemplo se muestra la forma en que un cliente solicitaría información de un producto a un proveedor de servicios Web: <soap:envelope xmlns:soap= > <soap:body> <getproductdetails xmlns= > <productid>827635</productid> </getproductdetails> </soap:body> </soap:envelope> Y esta sería la respuesta del proveedor: <soap:envelope xmlns:soap= > <soap:body> <getproductdetailsresponse xmlns= > <getproductdetailsresult> <productname>toptimate 3-Piece Set</productName> <productid>827635</productid> <description>3-piece luggage set. Black Polyester.</description> <price>96.50</price> <instock>true</instock> </getproductdetailsresult> 39

44 </getproductdetailsresponse> </soap:body> </soap:envelope> A pesar de no ser la única opción posible, HTTP fue elegido como protocolo de transporte por sus ventajas, para lidiar con cortafuegos, por ejemplo. Otros protocolos como GIOP/IIOP o DCOM (utilizados en CORBA, RMI y DCOM) suelen ser repelidos por estos cortafuegos. Lo importante es que ambos nodos que forman parte del Servicio Web el que provee el servicio y el que consume el servicio estén siguiendo las reglas y convenciones SOAP de la W3C al pie de la letra, ya que esto permitirá una comunicación fluida entre ambos participantes. Los detalles de SOAP pueden consultarse directamente en la W3C, es un protocolo bastante robusto y seguro que permite agilizar e implementar con toda confianza un Servicio Web. 40

45 Capítulo II Arquitectura SOA 2.1 Introducción Una referencia arquitectónica modela de manera abstracta los elementos arquitectónicos de un domino independientemente de una tecnología, protocolos, productos usados en la implementación del dominio. El modelo de arquitectura SOA como su nombre lo indica está orientado a servicios, servicios no solamente de la índole tecnológica, servicios considerando los diversos puntos de interacción entre todos los componentes del dominio como lo son sistemas computacionales, sistemas middleware, elementos hardware, usuarios de los sistemas, propietarios de los sistemas, proveedores de los sistemas incluso equipo encargado de dar soporte a los sistemas involucrados. Un dominio es un área de trabajo que abarca todos los elementos participantes en un proceso completo de operación incluyendo elementos de software, hardware, recursos humanos, áreas de trabajo, documentos, protocolos, estándares y mejores prácticas entre otros, todos involucrados en el proceso operativo objeto del área de trabajo. En la arquitectura SOA se busca ver a los sistemas de una manera holística haciendo una analogía con un ecosistema, en un ecosistema todos los seres vivos, sistemas naturales, ambiente están de cierta forma relacionados, un ecosistema no se puede estudiar por medio de uno de sus elementos individualmente se estudia como un todo, de esta forma se deben estudiar los sistemas basados en SOA. Desde una perspectiva holística un sistema basado en arquitectura SOA es una red de trabajo de servicios independientes, maquinas, dispositivos, y la gente que opera, usa, afecta y gobierna dichos servicios así como los proveedores de servicios profesionales necesarios para implementar, soportar y controlar el sistema. Resumiendo, SOA debe estudiase como un ecosistema de forma holística, se considera como un medio de intercambio de valores entre dos sistemas entre el actuar independiente de los participantes. Los participantes tienen derecho de pertenencia sobre los recursos hechos disponible por los servicios SOA. El comportamiento y desenvolvimiento de los participantes son sujeto de reglas de participación que son estable idas como políticas y contratos [5], [6]. 41

46 Arquitectura SOA 2.2 Objetivos y Principios SOA En esta sección se analizaran los objetivos de la arquitectura y los principios de la misma que recaen en el alcance de este documento Objetivos De acuerdo a OASIS son tres los principales objetivos de SOA: - Un sistema SOA debe ser efectivo. - Los participantes deben tener un alto nivel de confianza en los servicios del sistema SOA. - Los sistemas SOA deben poder ser escalables en sistemas más grandes Efectividad Un sistema basado en la arquitectura SOA debe ser efectivo para con los participantes, no todos los requerimientos de los participantes pueden estar cubiertos por el sistema pero aquellos que si, debe ser totalmente efectivos. La efectividad se determina por la visibilidad que los participantes tienen entre ellos mediante el sistema, que puedan tener una comunicación efectiva y que tanto los efectos del mundo real y sociales se puedan realizar. Como parte de la esencia de un sistema SOA las acciones llevadas a cabo por los participantes en el mismo deben realizar efectos en el mundo real, los servicios deben tener un efecto real. OASIS propone tres modelos que permiten el hacer efectivos los sistemas en un mundo real: 1. Modelado de los participantes. 1. Modelo de requerimientos y capacidades del sistema. 2. Modelado de recursos. La mayoría de los efectos buscados en un sistema basado en SOA son efectos sociales más que físicos, por ejemplo el acto de crear una cuenta bancaria de un cliente es el efecto de la relación entre el cliente y el banco, el hecho de bloquear una cuenta abierta es un cambio de estado siendo así otro ejemplo de efecto social. Los modelos que se aplican en los efectos sociales son los mismos que los aplicables para los efectos en el mundo real, adicional a estos se considera el modelo de la semántica de comunicación entre los participantes del sistema, esta comunicación permitirá la efectividad del sistema en lo social. Para tener una correcta y efectiva interacción los participantes deben ser capaces de verse uno al 42

47 otro de manera clara. Por lo anterior el sistema basado en SOA debe tener una buena visibilidad exponiendo los servicios ofrecidos así como su correspondiente descripción clara y entendible para los participantes incluyendo todos los artefactos y componentes del sistema y sus servicios. Para poder llevar a cabo la efectividad de las capacidades del sistema y cumplir con las necesidades requeridas, los participantes no solo deben ser capaces de verse el uno al otro también deben poder interactuar entre ellos como se menciono anteriormente mediante una comunicación. Los modelos que aportan a la comunicación efectiva son los modelos de los servicios, de los recursos y el de la semántica de la comunicación Confianza Los sistemas basados en SOA deben permitir tanto a los proveedores como consumidores de los servicios conducir sus intereses con un alto nivel de confianza. La confianza es sumamente importante sobre todo en situaciones y/u operaciones de alto riesgo. La confianza se forma mediante la fidelidad, manejabilidad o administración, un gobierno sólido y la predicción de su comportamiento. Por lo anterior la confianza es un objetivo primordial para la arquitectura SOA. Administrar y gobernar un sistema es un factor cien por cien critico en la arquitectura SOA debido a que muchos servicios en diferentes dominios pueden estar expuestos ante también muchas personas que usan dicho sistema, por lo anterior una buena administración y gobierno darán la confianza que se busca en SOA. La administración se aplica sobre los servicios y como deben ser usados por la gente, el gobierno hace referencia a la relación entre estos servicios y la gente que los utiliza. El gobierno de los sistemas basados en SOA implica que los responsables de la toma de decisiones creen las políticas necesarias para los participantes, servicios y sus relaciones y que estas políticas se cumplan de acuerdo a su descripción y alcance. Dos cosas que aportan a la confianza que se busca en un sistema basado en SOA es la fidelidad y previsibilidad, la fidelidad debe darse en la infraestructura, en las relaciones que se dan a partir de los servicios así como los efectos que generan, la integridad y confidencialidad también deben tener alta fidelidad sobre todo cuando hay factores externos involucrados. En cuanto a la previsibilidad el modelo SOA busca que lo que se ve es lo que se obtiene, el sistema debe cumplir con las expectativas de los participantes. Una documentación adecuada facilitara el entendimiento y alcance funcional de los servicios provistos por el sistema a los participantes. 43

48 Arquitectura SOA Escalabilidad El tercer objetivo del modelo SOA de acuerdo a OASIS es la escalabilidad, en términos de arquitectura este objetivo debe alcanzarse a través de un crecimiento suave en complejidad y numero de servicios que se ofrecen a los participantes así como las interacciones entre estos dos, los participantes y los servicios. Otra medida de crecimiento es la naturalidad con que los servicios pueden cruzar diferentes fronteras de pertenencia y administración, factores que aportan a esta naturalidad son el gobierno, la administración, y previsibilidad principalmente, un trabajo adecuado en estos tres puntos que forman parte del objetivo de la confianza aportaran al crecimiento natural del sistema basado en SOA en términos de su escalabilidad Principios A continuación se mencionaran lis principios bajo los cuales el modelo SOA trabaja. No siguen un orden en particular. Principio 1. Neutralidad tecnológica. SOA trabaja con una total independencia tecnología separando los problemas o retos propios de la tecnología empleada de los problemas o retos propios del modelo SOA aplicado al sistema. La tecnología por su lado seguirá evolucionando y SOA busca ser capaz de poder interactuar con diferentes y nuevas tecnologías es responsabilidad de los arquitectos y de los encargados de toma de decisiones hacer esto posible. Principio 1. Parsimonia. La parsimonia busca la economía en el diseño evitando en lo posible una complejidad y cantidad de servicios, componentes y relaciones. El diseño del sistema basado en SOA debe tener lo necesario y no más que eso. Esto aporta al buen entendimiento del sistema y el alcance de sus servicios a todos los participantes, si el elemento a considerar no hace diferencia considerable entonces no debe ser considerado. Principio 2. Separación de intereses. Los modelos en un sistema basado en SOA deben estar orientados a los participantes que les interesan de tal forma queso participantes puedan ver de manera individual o grupal los servicios que son de su interés sin necesidad de tratar de entender todo el modelo completo del sistema SOA, los sistemas SOA son bastante complejos y grandes por lo que esta separación de intereses facilita la comprensión del mismo a los participantes involucrados puntualmente en lo que les interesa. 44

49 Principio 3. Aplicable El modelo SOA debe aplicarse de manera que sea algo relevante, la arquitectura debe ser relevante a las necesidades del problema a resolver y sus correspondientes capacidades en los diferentes dominios de trabajo intranet (SOA dentro de la empresa), internet (SOA fuera de la empresa), extranet (SOA dentro de una empresa extendida con proveedores y terceros participantes). 2.3 Orientación al Negocio en SOA El modelo de arquitectura SOA menciona varios puntos de vista que se tienen que considerar durante su diseño, uno de ellos es el punto de vista del negocio. En este punto de vista SOA se enfoca en que es lo que significa para la gente que lo utiliza el negocio un sistema basado en SOA y como pueden utilizarlo para llevar a cabo su negocio. La manera en que se caracteriza el modo del negocio en un sistema SOA es por medio de proveer y consumir servicios que mutuamente llevan a cabo efectos en el mundo real. Las personas y organizaciones involucradas en un sistema basado en SOA forman una comunidad la cual puede ser una empresa sencilla o una muy compleja con conexiones punto a punto por ejemplo. Las actividades que los unen en su mayoría se consideran relaciones, los participantes tienen una relación con otros e incluso con grupos de participantes como una organización que se puede modelar en el sistema SOA. El objetivo de este punto es modelar a los participantes, las organizaciones, terceros involucrados sus respectivas relaciones así como sus funciones responsabilidades y capacidades en un sistema basado en SOA. <<vista>> Comunidad del Servicio <<modelo>> Actuando en una Comunidad del SOA Servicio <<modelo>> Estructura Social <<punto de vista>> Comunidad del Servicio <<punto de vista Especifico>> participantes = Gente que usa SOA, Tomadores de Decisiones, Empresarios y Arquitectos, Analistas Técnicas de modelado = UML <<modelo>> Actuando en Comunidad del Contexto Social Comunidad del Servicio Servicio Figura Orientación al Negocio en SOA Comunidad del Servicio 45

50 Arquitectura SOA Modelo de las Partes Interesadas y Participantes En esta sección se revisaran las relaciones que hay entre las partes involucradas, los participantes y los servicios provistos en el sistema basado en SOA. Una parte interesada es una entidad individual, humana o no, o un grupo de entidades que forman una organización. Esta entidad está interesada en los diferentes estados de un servicio en el sistema basado en SOA así como de las salidas y resultados de los mismos. La parte interesada no necesariamente hace uso de los servicios por ejemplo debido a una regulación gubernamental el gobierno está interesado en la correcta interacción entre el banco central y el banco participante en cuanto a transacciones electrónicas, esta parte interesada el gobierno le interesa que el sistema y sus servicios trabajen bajo las especificaciones de una regulación. Un Participante es también una Parte Interesada pero se caracteriza por interactuar directamente con los servicios ofrecidos por el sistema basado en SOA. Los participantes de manera más puntual requieren de Agentes que los representen de manera electrónica en la interacción con los servicios. Un agente es una entidad capaz de actuar en nombre de una persona u organización. Estos se clasifican en Servicios de Participantes Consumidores y en Servicios de Participantes Proveedores. Un participante puede ser una entidad que provee un servicio dentro del sistema y que otro participante como entidad consumidora alcanzara su meta y/o sus objetivos al consumir estos servicios ofrecidos de acuerdo a los resultados y salida que generen. De manera más detallada unos Servicios de Participantes Proveedores son participantes que ofrecen un servicio que da ciertas capacidades de uso a otros participantes para alcanzar sus objetivos. Los Servicios de Participantes Consumidores son participantes que interactúan con un servicio con el fin de adquirir capacidades para poder cubrir las necesidades del negocio así como alcanzar sus objetivos. Dentro de los agentes se encuentran los Servicios Mediadores los cuales son participantes en cargados de facilitar el ofrecimiento de los servicios para su uso en alguna forma. Existen varios tipos de mediadores un ejemplo es el registro en un servicio para poder consumirlo y/o ofrecerlo de tal forma que los dos tipos de participantes consumidor y proveedor puedan verse el uno al otro. Otro ejemplo de mediador es el servicio de encripción y desencripción de información entre el participante consumidor y el proveedor. 46

51 2.3.2 Modelo de Recursos En un sistema basado en SOA es importante identificar los elementos que le pertenecen y a los que son capaces de usar a los participantes interesados. Estos elementos son Recursos que de acuerdo a OASIS pueden ser por ejemplo: los servicios provistos, su descripción, los agentes que representan electrónicamente a los participantes, la documentación de los servicios, pólizas, contratos, licencias, grupos de soporte técnico, entre otros. Detalladamente un Recurso se define como una entidad de un valor perceptible que puede variar con el tiempo y que este valor puede darse en función a lo que lleva a cabo o intrínseco en la naturaleza misma de la entidad. Todo recurso tiene al menos un dueño y puede tener varios identificadores pero sin ambigüedades apuntando a su única identidad, donde una identidad es un conjunto de características propias del recurso que lo identifican de manera única dentro del contexto del dominio de trabajo Modelo de Propiedad Figura Modelo de Recursos Entender el significado de propiedad en un sistema basado en SOA es muy importante para tener bien claro las obligaciones y derechos que se tienen sobre los recursos. Propiedad es la relación existente entre una entidad, recurso y un conjunto de responsabilidades y derechos. Cuando una Entidad es dueña de un recurso esta puede ejercer derechos sobre los recursos y transferir dichos derechos a otra entidad. La pertenencia de un recurso va de la mano con la adquisición de responsabilidades por lo que la entidad es responsable de los actos que pueda realizar el recurso. 47

52 Arquitectura SOA La pertenencia de un recurso adicionalmente implica responsabilidades como la creación, mantenimiento, distribución, disposición a otros de dicho recurso. El dueño puede delegar las responsabilidades a otro pero al final de cuentas el dueño es el responsable total del recurso. El dueño puede compartir la propiedad del recurso cuando este esquema sea aplicable. La propiedad en SOA es difícilmente absoluta por ejemplo una parte interesada puede ser dueña de la instalación y publicación del servicio, otra puede ser la dueña de los resultados generados por el servicio y una más la dueña del uso de los servicios. La clave en el modelo es identificar a las partes interesadas los recursos y definir claramente su relación en el sentido de pertenencia, derechos y responsabilidades. Esto ayuda a interactuar en tiempo y forma con las partes interesadas correctas sobre los recursos provistos ya sean servicios, infraestructura, recursos humanos entre otros. Figura Modelo de Propiedad Modelo de necesidades y capacidades La motivación de los participantes para interactuar con los servicios son los beneficios que obtienen de ellos cubriendo sus necesidades. Desde la perspectiva del participante consumidor de un servicio lo que le motiva para interactuar con el servicio es poder satisfacer sus necesidades y alcanzar sus objetivos que están relacionados con el rol que juega en la estructura social. Por el lado del participante proveedor su motivación está en la obtención de un beneficio económico. 48

53 Una capacidad se puede ver como un recurso que el proveedor de servicios utiliza para poder lograr un efecto en el mundo real en nombre del participante consumidor. Las necesidades son requerimientos medibles que un participante proveedor de servicios esta activamente buscando satisfacer. Consumidor de Servicios Tiene Necesidad Tiene Proveedor de Servicios Ofrece Satisfecha en Estado Servicio Estado Privado Estado Compartido Accedida via Capacidad Cambios Efecto en el Mundo Real Cambios Logro Figura Modelo de Necesidades y Capacidades En el modelo presentado se muestra que tanto el consumidor como el proveedor de servicios tienen necesidades, las cuales son satisfechas de diferentes formas. Por un lado el proveedor de servicios tiene la necesidad de satisfacer al consumidor pero esto se logra mediante sus servicios ofrecidos los cuales accedidos adecuadamente por las capacidades, que como se mencionó anteriormente son los recursos necesarios para poder lograr un efecto en el mundo real accediendo a los servicios provistos por el proveedor. De esta forma se logran estos efectos en el mundo real los cuales se reflejan en cambios del estado del mundo real estos cambios satisfacen al estado deseado por la necesidad del consumidor. 49

54 Arquitectura SOA Modelo de la Estructura Social Las acciones asumidas por los participantes, ya sean mediante servicios o en alguna otra forma, son normalmente llevadas a cabo en el contexto social que define el significado de las acciones por sí mismas. El contexto se puede formalizar como una estructura social: la encarnación de un contexto social particular. El contexto social o ya específicamente el modelo de su estructura social es de suma importancia para definir y entender las implicaciones del cruce de fronteras de responsabilidades. Este modelo es el fundamento para entender la seguridad en el sistema basado en SOA y también provee el contexto para determinar cómo estos sistemas pueden ser manejados y gobernados efectivamente. Interesados Definida por Estructura Social Constitución Miembro de Rol Acatado por Participante Adopta / Lleva a cabo Figura Modelo de la Estructura Social Una estructura social encarna algunos de los aspectos culturales que caracterizan las relaciones y acciones entre un grupo de participantes. De acuerdo a la referencia de arquitectura SOA provista por OASIS, es importante tener cierta preocupación por la estructura social y el reflejo anticipado de los participantes en todo sistema basado en SOA los cuales usualmente están involucrados en marcos de trabajo legales. Las partes interesadas deben estar conscientes de la estructura social que marca el contexto de trabajo del sistema basado en SOA. Esta estructura social está formada por participantes que llevan a cabo un rol, y el participante se acata por una constitución, donde la constitución es un acuerdo compartido por un grupo de participantes que como se menciono definen a la estructura social. En este acuerdo se definen los roles con sus respectivos derechos y obligaciones. Para fines de este estudio dichos derechos y obligaciones se dan sobre el sistema basado en SOA. 50

55 2.3.6 Modelo de Estado Compartido y Hechos Sociales Los estados compartidos son el conjunto de hechos y compromisos que se manifiestan a participantes proveedores de servicios como un resultado de interactuar con sus servicios. Un estado compartido es accedido por varios participantes. Un hecho social es un elemento del estado de la estructura social que es sancionado por esta misma. Por ejemplo la existencia de una orden de compra válida con un cliente particular tiene un significado que es definido primeramente por la compañía misma. En este ejemplo el hecho social de la estructura social es la compra y tiene estados de completada, pendiente, cancelada por mencionar algunos, para que le hecho social sea reconocido como tal debe tener un cambio válido en su estado como pasar de pendiente a completada lo cual significa que paso por todos los procesos y validaciones requeridas por la estructura social que ella misma define darán validez al hecho social compra. Los participantes que interactúan en un hecho social tienen acceso a los elementos compartidos del estado de dicho hecho social incluso si un dado participante no tiene acceso a todos los elementos del hecho social. Un participante en el ejemplo de compra, puede ver el estado de la compra por ejemplo en estado pendiente, lo cual significaría que el hecho social está pasando por varios procesos antes de ser completada en caso de que fuera válida, a estos elementos no tiene acceso el participante pero al estado compartido si, el cual al actualizarse debido a los efectos ocasionados por los servicios provistos genera un efecto social. Como se menciono un estado compartido es un conjunto de compromisos también, los compromisos son hechos sociales en el futuro, en el futuro algunos hechos sociales serán validos y un participante tendrá la responsabilidad de asegurarse que ese hecho social sea en realidad. La estructura social está constituida por participantes los cuales perciben hechos sociales, pero también tienen compromisos por cumplir, dichos compromisos reflejaran hechos sociales y este conjunto de hechos sociales son estados compartidos que pueden ser accedidos por varios participantes. El modelo aplicado a sistemas basados en SOA se da cuando un proveedor de servicios se compromete a proveer servicios que al ser consumidos cumplan con los resultados esperados dentro del contexto de acciones validas en el marco social en cuestión, y los consumidores de servicios perciban dichos resultados y los validen, un hecho social al ser generado y validado adquiere dos estados finales, generado y validado, esto se encuadra en un solo estado un estado compartido, que mas de un participante accede. 51

56 Arquitectura SOA Estructura Social Miembro de Participante Tiene Compromiso Hecho Social Percibe Estado Compartido Figura Modelo de Estado Compartido y Hechos Sociales 2.4 Administración de Proyecto enfocado a un sistema basado en SOA Introducción En puntos anteriores se realizo un estudio sobre las características más relevantes de la arquitectura orientada a servicios. Los principios y objetivos nos van a ayudar a estar propiamente enfocados en la implementación de un sistema basado en SOA, los modelos nos ayudan a identificar participantes, componentes, acciones, relaciones y el flujo que debe considerarse durante el diseño e implementación de un sistema basado en SOA. Lo siguiente, propuesto en este trabajo de tesis; es desglosar la correspondiente Administración de un proyecto de un sistema basado en SOA. Como toda iniciativa, proyecto o desarrollo debe tener una administración lo suficientemente ejecutada para poder alcanzar los objetivos establecidos. Un proyecto es el emprendimiento de un esfuerzo temporal para crear un producto o servicio único. En el caso de sistemas distribuidos tanto el producto como el servicio pueden ya existir y aparentemente no ser únicos pero por citar un ejemplo, el servicio provisto a incrementado su demanda lo cual requiere de una distribución de procesos, esto genera el emprendimiento de ese esfuerzo temporal para crear el servicio mejorado convirtiéndose en algo único. Lo anterior enfocado a la distribución de procesos, si se trabaja con SOA de acuerdo a la definición de la arquitectura a emplear, la distribución en determinados procesos del nuevo proyecto se dará mediante las mejores prácticas de este modelo [10]. Si bien la administración de proyectos ha ido evolucionando con forme la experiencia en los desarrollos de nuevos proyectos se ha dado, en el caso de un sistema basado en SOA es un campo relativamente joven y que debido a su naturaleza las experiencias son aun más variadas. 52

57 La administración de un proyecto de un sistema basado en SOA demanda una organización, planeación y control principalmente más detallados esto debido a que el sistema tiene varios componentes distribuidos e interactúa con diversos participantes, lo cual incluso requiere de sub proyectos que deben ser igualmente administrados. En los siguientes puntos se trataran temas de administración de proyectos siempre enfocados a la implementación de sistema distribuido basado en SOA Planeación La planeación forma parte de la administración de un proyecto de cualquier rubro, la planeación tiene como requisito elemental la clara determinación de los resultados que se pretenden alcanzar. Agustín Reyes Ponce define la planeación como: La planeación consiste en fijar el curso concreto de acción que ha de seguirse, estableciendo los principios que habrán de orientarlo, la secuencia de operaciones para realizarlo, y la determinación de tiempos y números necesarios para su realización. La planeación en un proyecto se da de principio a fin, difícilmente existe una planeación perfecta sobre todo en un proyecto que involucra demasiados grupos de trabajo, recursos, elementos y componentes técnicos. Durante el ejercicio del proyecto la planeación va sufriendo una serie de cambios de acuerdo a las vicisitudes que se vayan presentando. En la práctica el ser humano como recurso y participante del proyecto ya es una variable en demasía vulnerable al cambio. En la planeación de un proyecto enfocado a un sistema distribuido basado en SOA, requiere de una formulación de supuestos más amplia que permita la toma de decisiones lo más acertada posible las cuales darán el mejor curso posible al proyecto hacia el alcance de sus objetivos. La planeación es la siguiente actividad inmediata que dispara la necesidad claramente identificada de un proyecto para la creación de un servicio o producto único. Esta fase del proyecto no debe definirse como la fase número uno como tal si como la fase base del proyecto sobre la cual las subsecuentes se desarrollaran y esta base durante el ciclo de vida del proyecto se irá adecuando, perfeccionando. La planeación inicial debe tener ya bien claro: Los objetivos del proyecto. Los principales participantes del proyecto. Patrocinadores. Beneficiados e impactados. Los grupos de trabajo involucrados terceros inclusive. 53

58 Arquitectura SOA Usuarios. Responsables del proyecto como un todo. Los sistemas informáticos involucrados en el proyecto. El presupuesto aproximado mínimo requerido. Punto de partida, como está actualmente el servicio o producto. Punto de arribo, como estará una vez concluido el proyecto el servicio o producto. Riesgos. Una vez definido e identificado los puntos anteriores, se establece una fecha de inicio y una fecha de fin del proyecto como un todo. La PMI en su PMBOK señala el desarrollo de un plan de administración de proyecto como el proceso necesario para definir, preparar, integrar y coordinar todos los planes subsidiarios dentro del plan de administración del proyecto. El plan del proyecto se convierte en la primera fuente de información de cómo el proyecto será planeado, ejecutado, monitoreado, controlado y cerrado. En la planeación del proyecto se debe planear el alcance del mismo, este proceso se describirá en la sección siguiente. Plan de Administración del Proyecto, entradas y salidas. Entrada Salida Objetivo del proyecto. Participantes del proyecto. Recursos Organizacionales. Procesos organizacionales. Punto de Partida. Plan de Administración del Proyecto. Figura Plan de Administración del Proyecto, entradas y salidas 54

59 2.4.3 Definición y Alcance En esta sección basada en su similar expuesta en el libro publicado por la PMI, PMBOK Guide, con complementos de estudios en análisis de sistemas, se describirán los siguientes puntos: Alcance del Plan de Administración del Proyecto, Alcance de la Definición del Proyecto, Análisis del Proyecto, Estructura y Distribución de trabajo. Esta sección trata sobre los procesos requeridos para asegurar que el proyecto incluya el trabajo requerido, y solo el trabajo requerido, con el fin de llevar a cabo y finalizar el proyecto exitosamente. Este trabajo parte de la administración de un proyecto de implementación de un sistema SOA es aún más critica que un proyecto en el cual el sistema informático es único, si la definición y alcance no están bien declarados, participantes, patrocinadores, procesos, usuarios pueden prestarse a la confusión y demandar requerimientos totalmente ajenos al alcance del proyecto, impactando en tiempo, costo y éxito del proyecto Alcance del Plan de Administración La creación de un Alcance del Plan de Administración documenta como el proyecto será definido, analizado, verificado, controlado, la estructura de la distribución de trabajo. La definición y administración del alcance del proyecto influye en el éxito general del mismo. Cada proyecto requiere de un balance cauto de herramientas, fuente de datos, metodologías, procesos y procedimientos, y otros factores para asegurar que el esfuerzo extendido en el alcance de las actividades es de acuerdo al tamaño, complejidad e importancia del proyecto. Este entregable, Alcance del Plan de Administración, es una herramienta de descripción de cómo el equipo definirá el alcance del proyecto, desarrollara una declaración detallada del alcance del proyecto, definirá y desarrollara la estructura de desglose del trabajo. El documento inicialmente se construye a partir de un primer análisis de la información que dispara el proyecto, lo que origino la necesidad de este proyecto. Alcance del Plan de Administración del Proyecto, entradas y salidas. Entrada Salida Plan de Administración del Proyecto. Procesos organizacionales. Punto de Partida. Alcacne del Plan de Administración del Proyecto. Figura Alcance del Plan de Administración del Proyecto, entradas y salidas 55

60 Arquitectura SOA Alcance de la Definición del Proyecto La declaración detallada del alcance del proyecto se construye sobre los documentos generales, supuestos y restricciones que son documentados durante la iniciación del proyecto en los preliminares. Durante la planeación, como se menciono anteriormente se toma como una fase base para toda la vida del proyecto, el alcance del proyecto es definido y descrito con mayor claridad porque se tiene más información del proyecto. Las necesidades, deseables y expectativas de los participantes son analizadas y convertidas en requerimientos. Los supuestos y restricciones se analizan para ser complementadas según se requiera. Alcance de la Definición, entradas y salidas. Entrada Salida Procesos organizacionales. Punto de Partida. Definición preliminar del alcance del proyecto. Plan de Administración del Proyecto y su alcance. Aprobación de solicitud de cambios. Declaración del alcance del proyecto. Cambios solicitados. Administración del plan del proyecto actualizado. Figura Alcance de la Definición, entradas y salidas Para poder definir claramente el alcance de la definición del proyecto es necesario llevar a cabo un análisis del proyecto con el fin de entender y visualizar cual es el objetivo a cubrir detalladamente, el desarrollo, cambios en sistemas requerido los procesos involucrados, etc. Este análisis es un entregable que se complementa a la propuesta de la PMI PMBOK en este trabajo de tesis. A continuación se detallara el entregable Análisis del Proyecto Comprender los requerimientos de un problema es una de las tareas más difíciles e importantes en un proyecto. Una mala interpretación o entendimiento puede dar como consecuencia resultados totalmente diferentes a los esperados por todo el equipo involucrado en el proyecto. 56

61 El análisis del proyecto ayuda a entender mejor el problema en cuya solución se trabajara. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del producto sobre el negocio, que es lo que el cliente quiere y como interactuaran los usuarios finales con el producto final [12]. Antes de concretar cualquier definición, diseño o solución de un proyecto, es importante entender lo que realmente se necesita, quiere y espera como producto final. Roger S. Pressman presenta en su libro Ingenieria el Software la ingeniería de requisitos y trabajo bastante completo sobre el análisis en sistemas informáticos. Esta ingeniería proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sin ambigüedades, validar la especificación, y administrar los requisitos conforme estos se transforman en un sistema operacional. Este proceso se lleva a cabo a través de siete distintas funciones: inicio, obtención, elaboración, negociación, especificación, validación y gestión. El Inicio en esta propuesta de proceso de análisis por Pressman, consiste en algunos casos con una conversación informal. La mejor práctica es que se dé cómo consecuencia a un comunicado oficial del inicio del proyecto y la problemática general. Esto dará paso a que el analista se acerque al equipo inicial de trabajo del proyecto incluyendo gente del negocio y haga una serie de preguntas libres de contexto: - Quiénes están detrás de la solicitud de este trabajo? - Quién usara la solución? - Cuál será el beneficio económico de una solución exitosa? - Existe otra fuente para la solución requerida? El objetivo es establecer una compresión básica del problema, las personas que quieren una solución, la naturaleza de la solución que se desea, y la efectividad de la comunicación preliminar entre el cliente y el desarrollador. La Obtención a primera instancia podría parecer una tarea simple, considerándola como solo realizar la petición de información al usuario, pero no es tan simple. Pressman en su libro indica que Michael G. Christel y Kyo C. Kang identifican una serie de problemas que ayudan a entender por qué es difícil la obtención de requisitos: -Problemas de ámbito, donde el límite del sistema está mal definido o los clientes/usuarios especifican detalle técnicos innecesarios. -Problemas de comprensión. Los clientes/usuarios no están seguros por completo de qué es lo que se necesita. - Problemas de volatilidad. Los problemas cambian conforme transcurre el tiempo. Para superar estos problemas y obtener cuales son los objetivos para el sistema, servicio o producto, que es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y por 57

62 Arquitectura SOA ultimo como se utilizara el sistema, producto o servicio día a día, se deben realizar en forma organizada la actividad de recopilación de requisitos. La información conseguida en los primeros dos pasos de inicio y obtención se expande y se refina durante la Elaboración. Esta actividad de la ingeniería de requisitos se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software. La elaboración según Pressman es una acción del modelado del análisis. Se conduce mediante la creación y el refinamiento de escenarios del usuario que describen la forma en que el usuario final y otros actores interactuaran con el sistema. Cada escenario del usuario se analiza para obtener clases de análisis, entidades del dominio de negocios visibles para el usuario final. Se definen los atributos de cada clase de análisis y se identifican los servicios que requiere cada clase. Se identifican las relaciones y la colaboración entre las clases y se produce una variedad de diagramas complementarios. Dados los recursos limitados del negocio, no resulta inusual que los usuarios pidan más de lo se puede lograr. También es relativamente común que diferentes usuarios propongan requisitos que entran en conflicto entre sí al argumentar que su versión es esencial. El analista debe conciliar estos conflictos por medio de un proceso de negociación. Se pide a los clientes, usuarios y otros interesados que ordenen sus requisitos y después discutan los conflictos relacionados con la prioridad. Se identifican y analizan los riesgos asociados con cada requisito. Se hacen estimaciones preliminares del esfuerzo requerido para su desarrollo y después se utilizan para evaluar el impacto de cada requisito en el costo del proyecto y sobre el tiempo de entrega. Mediante un enfoque iterativo, los requisitos se eliminan combinan o modifican de forma que cada parte alcance cierto grado de satisfacción. El siguiente paso es proceder con la especificación la cual puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de éstos. La Especificación es el producto de trabajo final que genera la ingeniería de requisitos. Es un consolidado final de lo que se requiere en el proyecto así como sus restricciones riesgos y limitaciones. Aportando a esta ingeniería de requisitos acuerdo al trabajo presentado, durante esta especificación no solo se debe considerar los requerimientos del sistema de manera aislada también deben considerarse los requerimientos técnicos y de infraestructura así como de procesos internos dependiendo de la organización. Los requerimientos técnicos están basados en los estándares técnicos de la organización así como las mejores prácticas de desarrollo de software. Como ejemplo, en un determinado Banco el lenguaje de programación estándar para desarrollos informáticos es Java en la implementación de su último JDK versión 5, como sistema operativo Linux Red Hat 4.0 y un motor de base de datos mainframe DB1. Si este tipo de especificaciones técnicas no son mencionadas en el entregable de especificaciones en un futuro pueden ser causa de retrasos, incremento de costos e inclusive una completa reingeniería del producto, servicio elaborado. 58

63 Similar a los requerimientos técnicos se propone incluir de manera clara la especificación de requerimientos de infraestructura, por ejemplo si se va a requerir el uso de ambientes de desarrollo, pruebas de usuario, si será necesario adquirir nuevos servidores, establecer canales de comunicación, registro de accesos en la lista de accesos de los firewalls de la organización, etc. Esto requerimientos al estar considerados en el documento de especificación durante la ejecución del proyecto ahorraran bastante tiempo y darán mayor agilidad al desarrollo del proyecto. En la Especificación se debe considerar también los procesos internos de la organización que deben gestionarse con el fin de no caer en retrasos administrativos. Todo proyecto tiene excepciones y dependiendo de las políticas y procesos de cada organización algunas son más tolerables que otras, unas requieren de un proceso de validación y control por especialistas y gente de análisis de riesgos, estos procesos pueden requerir semanas entre trámites y reuniones así como el tiempo necesario para justificar la excepción. Por lo anterior en lo posible incluir también en el documento de Especificaciones los procesos administrativos que se deban llevar a cabo es altamente recomendable. La calidad de los productos de trabajo procedentes de la ingeniería de requisitos se evalúa durante un paso de validación. La validación de requisitos examina la especificación para asegurar que todos los requisitos del proyecto se han establecido de manera precisa; que se han detectado las inconsistencias, omisiones y errores y que estos han sido corregidos, y que los productos de trabajo cumplen con los estándares establecidos para el proceso, proyecto y producto. Finalmente Pressman menciona un paso final en su ingeniería de requisitos, la gestión de requisitos, la cual es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto. El entregable complementario al alcance y definición de un proyecto es el documento de especificación de requerimientos Estructura y Distribución de Trabajo La estructura y distribución de trabajo es un entregable que forma parte de la definición y alcance del proyecto. Este entregable jerárquico es una descomposición de trabajo que se ejecutara por el equipo del proyecto, para cumplir los objetivos del mismo y crear los entregables requeridos. Este entregable subdivide el trabajo del proyecto en pequeñas y más manejables piezas de trabajo, cada pieza con un nivel descendiente hasta el trabajo puntual final. El trabajo planeado contenido dentro del nivel más bajo en esta estructura y distribución de trabajo, puede ser programado, estimado en términos de costo monitoreado y controlado. Este entregable representa el trabajo especificado en el presente documento de alcance del proyecto aprobado. Si bien cada proyecto es único, la estructura y distribución de trabajo puede ser en muchos casos basada en una plantilla para un nuevo proyecto. 59

64 Arquitectura SOA La PMI propone una guía para la generación, desarrollo y aplicación de la estructura de una descomposición de trabajo. Esta guía puede tomarse como una base y ajustarse a las necesidades puntuales del proyecto y organización. Proyecto Fase 1 Fase 2 Entregable 3 Sub Proyecto 4 Sub Proyecto n Entregable 2.1 Entregable 2.2 Entregable 2.3 Entregable 4.1 Entregable 4.m Entregable Entregable Entregable Entregable Entregable 4.1.x Paquete de Trabajo Paquete de Trabajo Paquete de Trabajo Sub Proyecto Sub Proyecto Paquete de Trabajo Paquete de Trabajo 3.1 Paquete de Trabajo 3.2 Paquete de Trabajo 3.3 Paquete de Trabajo Paquete de Trabajo Paquete de Trabajo Paquete de Trabajo Paquete de Trabajo 3.4 Figura Estructura y Distribución de trabajo PMI La descomposición es la subdivisión de los entregables del proyecto en pequeños y más manejables componentes hasta que el trabajo y entregables sean definidos hasta el nivel de un paquete de trabajo puntual. Un paquete de trabajo puntual es el nivel más bajo en una estructura de distribución de trabajo, y es el punto en el cual el costo y el programa del trabajo pueden ser estimados. El nivel del detalle del trabajo para los paquetes variara con el tamaño y complejidad del proyecto. La descomposición total de un proyecto generalmente involucra las siguientes actividades: Identificar los entregables relacionados al proyecto Estructurar y organizar la distribución de trabajo 60

65 Descomponer los niveles superiores de la distribución de trabajo en niveles inferiores con componentes detallados. Verificar que el grado de descomposición del trabajo es necesario y suficiente. Los entregables consecuentes de este trabajo se presentan en el siguiente diagrama. Estructura y Distribución de Trabajo, entradas y salidas. Entrada Salida Procesos organizacionales. Definición del alcance del proyecto. Plan de Administración del Proyecto y su alcance. Aprobación de solicitud de cambios. Plantilla de Estructura y Distribución de Trabajo. Descomposición Preliminar Declaración del alcance del proyecto actualizado. Administración del plan del proyecto actualizado. Estructura y Distribución de Trabajo. Diccionario de Estructura y Distribución de Trabajo. Cambios solicitados. Figura Estructura y Distribución de Trabajo, entradas y salidas Control y Seguimiento El control en la administración de un proyecto está enfocado a la observación e inspección de los factores que crean cambios en el alcance del proyecto y dar seguimiento al impacto que estos cambios tienen en el proyecto. El control se asegura que todos los cambios y acciones correctivas sean procesados a través de un proceso integral de control de cambios. El control también es usado para administrar los cambios actuales, cuando se lleven a cabo y se integren con el resto del proyecto. Cambios no controlados son también identificados como cambios corruptos o alcance corrupto del proyecto. Los cambios son inevitables de ahí que es mandatorio se defina un proceso de control de cambios. Por supuesto el control se lleva a cabo sobre el alcance estipulado en la fase de definición y se encarga de inspeccionar que lo acordado se ejecute en tiempo y forma cualquier variación implica un cambio y debe ser controlado. Algunas herramientas que aportaran a llevar a cabo un buen control son los reportes de desenvolvimiento del proyecto, estos documentos registran puntualmente que el alcance definido 61

66 Arquitectura SOA para el proyecto paquete a paquete de trabajo se esté ejecutando en cuanto se identifique un cambio se toma acción inmediata siguiendo el proceso correspondiente. Una buena práctica de control es programar reuniones de seguimiento con los puntos de contacto de los diferentes equipos de trabajo con la finalidad de dar un comunicado del avance de sus respectivas responsabilidades, de esta forma el equipo completo esta informado del buen avance o en su defecto de algún retraso y/o cambio. Al definir un proceso integral de control de cambios este debe considerar al menos un documento de control de cambios, sistema de registro y niveles de autorización en caso de ser necesario autorizar los cambios por responsabilidades específicas. Los cambios probados afectan al alcance del proyecto y requieren modificaciones en la estructura y distribución de trabajo,la declaración del alcance del proyecto, el plan de administración del proyecto. Un sistema formal de administración de cambios proporciona procedimientos formales para asegurar que los cambios requeridos l proyecto se integren al proyecto bajo el mismo procedimiento que integro los requerimientos preliminares y así tengan la misma validez. 62

67 A continuación se muestra un diagrama donde se visualiza de mejor manera la participación y acción del control y seguimiento en la administración de un proyecto: Plan del Proyecto Dirigir Administrar y Ejecutar Proyecto Entregables Cambios Requeridos Implementación de Cambios Implementación de Acciones Correctivas Implementación de Acciones Preventivas Implementación de Reparación de Defectos Estructura y Distribución de Trabajo Monitorear y Controlar el Trabajo del Proyecto Análisis y Definición del Proyecto Sistema Integral de Control del Proyecto Solicitud de Cambios Transición de Soporte y Liberación Figura Control y Seguimiento de un Proyecto Durante la ejecución de un proyecto es importante involucrar al equipo de soporte que se hará responsable del mantenimiento diario a la operación del sistema. Al hablar de sistemas distribuidos pueden también existir equipos de trabajo de soporte a la producción distribuidos. Al momento de integrar estos sistemas distribuidos hay un flujo de trabajo que los relaciona, esto no significa que se integre un equipo de trabajo de soporte a la producción. Lo importante es identificar los equipos de soporte para los componentes sistemas participantes en 63

68 Arquitectura SOA el proyecto, con la finalidad de mantenerlos informados acerca del nuevo flujo de trabajo implementado o los cambios pertinentes. Normalmente los equipos de desarrollo de proyectos suelen dedicarse a lo propio, a desarrollar proyectos, estos equipos involucran administradores de proyectos, analistas de sistemas, analistas del negocio, arquitectos de sistemas, administradores de bases de datos, usuarios expertos por mencionar algunos. Durante la ejecución del proyecto estos equipos están al tanto de todo lo relacionado al proyecto y se encuentran disponibles para análisis, desarrollo, pruebas, control e implementación. Resulta que cuando se implementa el servicio, producto o solución, los equipos anteriormente mencionados continúan su camino trabajando en nuevos proyectos, al implementar el proyecto y haber transcurrido el periodo de garantía, no son ya más responsables del producto en cierta forma. Un punto de oportunidad que se identifica en diversas metodologías como la propuesta por la PMI es involucrar una fase de administración asociada a la transición del producto, servicio o solución final al equipo de trabajo responsable en dar el soporte a producción post tiempo de garantía. Existen metodologías especializadas en las mejores prácticas para la entrega de servicios como ITIL y CMMI sin embargo no hay información clara al proceso de transición del equipo de trabajo del proyecto en ejecución al equipo de trabajo encargado del soporte a la producción diaria. La documentación del proyecto siempre va a ser fundamental y de alta importancia en sus diferentes fases, por ejemplo de los cambios implementados en un sistema dependiendo de la complejidad del mismo no es suficiente para que un equipo responsable del soporte entienda el comportamiento de los mismos a través de un documento. Por lo anterior se recomienda involucrar al equipo de soporte durante la fase de transición al equipo de soporte, la cual se recomienda llevar acabo como una sombra atrás desde la fase de pruebas de usuario hasta el cumplimiento del periodo de garantía. Definición Análisis Diseño Construcción Pruebas Integrales Pruebas de Usuario Implementaci ón Liberación y Garantía Soporte a Producción Involucramie nto Equipos de Soporte Proceso de Transición al los Equipos de Soporte a Producción Impactados. Figura Transición de Soporte y Liberación En la figura anterior se puede apreciar las diferentes fases del ciclo de vida de un proyecto, las cuales pueden variar dependiendo la metodología usada. Generalizando se tiene que involucrar a los equipos de soporte a producción impactados en la fase de definición de esta forma están formalmente informados del proyecto y su alcance en los sistemas existentes o nuevos. 64

69 Durante las consecuentes fases no es necesaria la participación del grupo de soporte ya que las fases de análisis, diseño, construcción y pruebas unitarias o integrales están totalmente relacionadas al equipo de ejecución del proyecto. Una vez que el equipo de ejecución del proyecto haya validado sus pruebas unitarias, el siguiente paso es proceder con las pruebas de usuario. Durante las pruebas de usuario, el objetivo es realizar pruebas de regresión considerando todos los escenarios posibles válidos y no válidos simulando la operación que se daría en producción, inclusive los ambientes de pruebas tanto software, hardware e infraestructura idealmente deben ser iguales a los usados en producción. En esta fase es el mejor punto para requerir la participación de los equipos de soporte identificados en la fase de definición, como impactados, futuros responsables del continuo soporte al servicio implementado por el proyecto. La participación del equipo de soporte en esta fase consiste en dar seguimiento a los casos de prueba entendiendo el flujo de trabajo implementado o modificado tomando como referencia la documentación del proyecto. En caso de presentarse un error o inconsistencia es responsabilidad del equipo de ejecución del proyecto resolverlo así como notificar el análisis de la causa raíz del problema y como se resolvió, el equipo de soporte a producción tiene la responsabilidad de documentar esta información. El visto bueno de las pruebas de usuario adicional a las partes interesadas también lo deben dar los equipos de soporte a producción impactos. Durante la implementación los equipos de soporte a producción participan en el monitoreo y seguimiento de actividades llevadas a cabo por el equipo de ejecución del proyecto con el fin de validar que se implemente solo lo definido y como alcance al proyecto, y técnicamente no impactar otro software, hardware o infraestructura. Al llevarse a cabo correctamente la implementación también el equipo de soporte a producción debe dar su visto bueno ya que en la siguiente fase ellos serán parte del punto de contacto en caso de presentarse un problema con el servicio, producto o solución implementado. Durante el periodo de garantía el equipo de soporte debe trabajar junto con el equipo de ejecución del proyecto para resolver los problemas y estabilizar el servicio, producto o solución implementada. Al término del periodo de garantía es total responsabilidad del equipo de soporte el soporte a producción de la solución implementada. Para sistemas distribuidos basados en arquitectura SOA, los equipos involucrados de soporte a producción pueden ser diferentes. Se debe tener un sesión particular con estos equipos durante la fase de definición con la finalidad de dejar claro el alcance del soporte con el nuevo flujo de trabajo implementado o modificado. Al integrar sistemas existentes se debe proporcionar una lista de puntos de contacto responsables de interactuar con los diversos equipos de soporte durante el análisis de un problema presentado en producción. 65

70 Arquitectura SOA Durante la fase de pruebas con el usuario, los flujos de trabajo deben entenderse completamente, e identificar las limitantes del soporte en la solución completa, que procesos, componentes y servicios son responsabilidad de que equipos de soporte, esta definición es responsabilidad del equipo de ejecución del proyecto y debe ser aprobado por los equipos de soporte a producción delegados. 66

71 Capítulo 3 Caso Práctico 3.1 Descripción del Objeto de Estudio Sistema de Pagos Electrónicos Interbancarios SPEI La presente introducción solo pretende dar una visión general del Sistema de Pagos Electrónicos Interbancarios aplicado a la operación de un Banco en Estudio, el estudio no está enfocado en los detalles puntuales del Sistema en su totalidad. El Sistema de Pagos Electrónicos Interbancarios (SPEI), es un sistema de pagos desarrollado bajo el esquema cliente-servidor con el cual las instituciones participantes podrán realizar pagos propios y a terceros por cualquier monto no negativo. El SPEI liquida Órdenes de Pago usando los recursos provenientes de las cuentas en moneda nacional de los participantes en el SPEI. La arquitectura utilizada en este sistema contempla lo siguiente: Un proceso básico del sistema, denominado Servidor del SPEI Un procesador de comunicaciones, denominado Front End de Comunicaciones (FEC) Un cliente para el acceso y control del sistema. Figura Sistema de Pagos Electrónicos Interbancarios SPEI La comunicación entre el cliente y el servidor se logra a través de un protocolo de comunicación, el cual debe respetarse para garantizar su correcto funcionamiento. Dicho protocolo es abierto, ya que no depende de una arquitectura, lenguaje de programación o sistema operativo determinado. Con base en este protocolo de comunicación, las instituciones que deseen participar en este sistema podrán desarrollar su cliente de acuerdo a sus necesidades particulares, o bien, conectar sus sistemas directamente al servidor del SPEI. 67

72 Caso Práctico Plataformas del Banco en estudio para SPEI El Banco en Estudio utiliza hoy en día tres Sistemas para llevar a cabo el proceso de operación de SPEI: Sistema Principal Bancario Sistema Middleware Bancario Sistema SPEI del Banco Adicionalmente el Banco en Estudio al cual a partir de ahora nos dirigiremos hacia el cómo BE, precisa de una infraestructura de comunicaciones para establecer conectividad y transferencia de información con el Banco Central, los dispositivos fundamentales en esta infraestructura son: Servidores Router Corta Fuegos A continuación se muestra un diagrama de secuencia en el cual se visualiza la interacción entre las tres plataformas en relación con el flujo de una transacción SPEI. Sistema Principal Bancario Envio de Transacción Archivo Plano Sin Formato Sistema MiddleWare Envío de Transacción Archivo Plano Con Formato Usuario Carga de Archivo Plano Manual SPEI Procesamiento y Envío de SPEI s Banco Central Sistema Principal Bancario Carga Manual de Pagos SPEI Usuario Monitoreo Manual SPEI Procesamiento y Envío de SPEI s Banco Central Figura Interacción entre plataformas en relación con el flujo de una transacción SPEI El sistema principal bancario es operado por un usuario de atención al cliente, el cual recibe una llamada de un cliente del banco para procesar una solicitud de una transacción SPEI. El usuario de atención al cliente captura la información en el sistema principal bancario a través de su aplicación cliente, la transacción es procesada y registrada en la base de datos del sistema principal bancario, este a su vez cada determinado tiempo genera un archivo plano con 68

73 transacciones electrónicas que se deben enviar al sistema middleware sin formato legible para el sistema SPEI. Al archivo se envía por una herramienta de transferencia de archivos. El sistema middleware toma el archivo que se le envía y procesa la información contenida, clasifica las transacciones incluidas en el archivo recibido y genera la salida correspondiente a cada tipo de transacción, en este caso genera un archivo de salida con el formato para el sistema SPEI. Manualmente un usuario valida y concilia la información para finalmente cargar dicho archivo con formato SPEI en el sistema SPEI el cual procesa las transacciones enviándolas al Banco Central. El flujo de entrada, cuando el Banco Central envía un pago al Banco de Estudio, consiste de manera general en que el Banco Central realiza el envío automático del pago, el Banco de Estudio lo recibe de acuerdo al protocolo y reglas de operación del SPEI, un usuario encargado de monitorear manualmente la recepción de pagos SPEI, se encarga de validar la información cuentas que son beneficiadas por el pago, como su existencia, disponibilidad y formato, finalmente procede a la captura manual en el sistema principal bancario. Como se puede notar no existe en el flujo de entrada ni siquiera una interfaz de archivos planos para dicho proceso lo cual expone altamente la operación del Banco de Estudio Sistema Principal Bancario Este sistema se utiliza para llevar a cabo la gestión y operación de las cuentas y productos de los clientes del Banco en Estudio. En este sistema se pueden crear clientes capturando su información de identificación y demográfica que hace único a cada registro de cada cliente. El sistema principal bancario esta bajo el diseño de Front-to-Back, soporta transacciones de gran escala en un alto volumen y con alta criticidad en línea, su transaccionalidad se clasifica como OLTP (Online Transaction Processing por sus siglas en ingles), la aplicación usa la arquitectura cliente-servidor para el procesamiento distribuido. El sistema principal bancario esta bajo el diseño de un Modelo en Tres Capas. Capa 1 Clientes y Gateways. Tiene un administrador de aplicación de cliente, CAM que por sus siglas en ingles significa Client Application Manager, administra la presentación de los formularios, y ejecuta las reglas del negocio para con el cliente así como triggers (disparadores). El Gateway actúa como una interfaz entre el Sistema Principal Bancario y otras aplicaciones, responde a peticiones externas como Cajeros, IVR, Internet entre otros. Las transacciones son iniciadas por el cliente CAM o el Gateway y se envían al administrador de aplicación de servidor. Capa 2 Servidor SAM Server Application Manager, administrador de aplicación de servidor, un procesador periódico y programas del servidor operan en esta capa. 69

74 Caso Práctico El SAM maneja las reglas del negocio del lado del servidor para con las aplicaciones cliente y los gateways, controla las funciones de procesamiento de transacciones. SAM como cliente de SQL server envía sus peticiones a través de una capa ODBC optimizada, manejada por un controlador ODBC. Este regresa la información pedida al cliente CAM o al Gateway. El procesador periódico maneja los procesos batch transaccionales. Ambos SAM y el procesador periódico pueden correr concurrentemente. Capa 3 Base de Datos Esencialmente, el SQL server forma la tercera capa. Todas las aplicaciones de servidor se comunican con el SQL server a través de una conectividad a base de datos abierta (ODBC). Es importante mencionar que no cuenta con el servicio de Pagos Electrónicos Interbancarios, conocido como SPEI. A continuación se muestra un diagrama de red aplicativo en el cual se puede visualizar claramente las principales secciones y distribución de los sistemas: sistema principal bancario, sistema de transferencia de archivos y sistema middleware. Esta arquitectura general no representa el detalle de una arquitectura correspondiente a una propuesta de sistemas distribuidos, sin embargo; más adelante se aplicará la teoría expuesta anteriormente proponiendo una arquitectura de sistemas distribuidos acorde, esto con el fin de implementar las mejores prácticas de sistemas distribuidos en pro de proveer la mejor operación tecnológica posible. Operación Centro de Datos Regional Centro de Servidores Matriz Centro de Servidores Local Capa de Aplicación Usuarios Reportes de Conciliación Usuarios Reportes de Seguridad Servidor de Internet Servidor de VR Servidor Gateway (Conectores) Capa de Aplicación Servidor SAM Servidor de Transferencia de Archivos Servidor Aplicación MiddleWare Banco Central Capa de Datos Servidor ATM Capa de Presentación Servidor SQL Server Usuarios de Sistema Principal Bancario Servidor CAM Figura Diagrama de Red Aplicativo, Sistema Principal Bancario, Sistema de Transferencia de Archivos y Sistema Middleware 70

75 3.1.4 Sistema MiddleWare Bancario Un sistema MiddleWare es un software que asiste a una aplicación para interactuar o comunicarse con otras aplicaciones, software, redes, hardware y/o sistemas operativos, como ya se menciono en la sección de este trabajo de tesis. Éste simplifica el trabajo de los programadores en la compleja tarea de generar las conexiones que son necesarias en los sistemas distribuidos. De esta forma se provee una solución que mejora la calidad de servicio, seguridad, envío de mensajes, directorio de servicio, etc. En el caso del Banco de Estudio el Sistema middleware Bancario procesa archivos con transferencias electrónicas como por ejemplo: TEF, Depósitos, Domiciliaciones, Cheques, Retiros, SPEIs, entre otros. Esta aplicación es usada en el Banco de Estudio para convertir archivos con un formato de entrada a un formato de salida correspondiente a las diversas plataformas y sistemas con los que interactúa el banco de estudio. El sistema middleware permite elaborar diferentes consultas, reportes e información estadística, esta información sirve para tener un control sobre todas las operaciones que la operación lleva a cabo. El sistema está bajo plataforma web contando con servicios de tipo Windows para la ejecución de los procesos en automático cada determinado tiempo. Middleware Servidor Base de Datos Entidad Legal Conciliadora INTRANET http PC Win XP IE 6.0 Usuario del sistema middleware Middleware Servidor de Aplicación Servidor de SFT Otros Bancos Sistema Principal Bancario Figura Diagrama de Arquitectura Física Sistemas Banco de Estudio 71

76 Caso Práctico En el diagrama de arquitectura física arriba mostrado señala a un alto nivel la distribución de los elementos que interactúan con el sistema middleware. El sistema principal bancario envía y recibe información a través del sistema middleware. De izquierda a derecha y de arriba abajo, se encuentra el usuario del sistema middleware, el cual debe contar con una PC con sistema Windows XP e IE 6.0 al menos, es un usuario técnico y con conocimientos financieros para la conciliación y uso del sistema middleware. El usuario tiene acceso al sistema middleware para la supervisión de la ejecución de los procesos automáticos y en caso de requerirlo ejecutar manualmente algún proceso que por algún motivo no se corrió automáticamente ya sea por un error técnico por una regla del negocio. Realmente el usuario es un supervisor de la ejecución de los procesos y la aplicación web a la que accede funciona como una herramienta de monitoreo, reporte e información estadística principalmente. El sistema principal bancario es la principal interfaz del lado del banco en estudio, el sistema principal bancario cada determinado tiempo envía información al sistema middleware para ser procesada y enviada a las correspondientes interfaces participantes. Pero no sólo envía información también recibe ya sea por devoluciones o por intenciones de pagos. Las interfaces externas participantes principales son la Entidad Legal Conciliadora y Otros Bancos, estas interfaces envían y reciben información al banco en estudio, en este diagrama como se puede visualizar no se incluye una interfaz que corresponda a los pagos tipo SPEI, estos pagos requieren de la interacción del sistema encargado del procesamiento de este tipo de pagos llamado SPEI y la interfaz externa de Banco Central. Si bien el sistema middleware recibe información de pagos tipo SPEI y los procesa pero no hay una interfaz de salida ni entrada entre el sistema externo y el sistema middleware, este proceso es manual Sistema SPEI Bancario El sistema SPEI, SPEI (Sistema de Pagos Electrónicos Interbancario ) es un sistema que se utiliza en el banco de estudio para formar parte del sistema complejo del Banco Central destinado para los Pagos Electrónicos Interbancarios, pagos entre diferentes Bancos, este sistema complejo como se menciono en la introducción se llama SPEI. El sistema informático que el banco participante implemente para el servicio SPEI, puede ser un desarrollo propio del mismo banco participante o un desarrollo de un tercero. La opción que se elija independientemente, el sistema informático debe ser certificada por el banco central. Para el caso del Banco en estudio el desarrollo pertenece a un Tercero, a un proveedor. El sistema SPEI está desarrollo con el marco de trabajo de Java J2EE, (Java Platform, Enterprise Edition), es una plataforma de programación para desarrollar y ejecutar software en lenguaje de programación Java con arquitectura de N capas distribuidas y que se apoya ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. 72

77 El sistema SPEI instalado en el Banco de estudio está diseñado para trabajar sobre BEA WebLogic. BEA WebLogic es un servidor de aplicaciones J2EE y también un servidor web HTTP de Oracle, para Unix, Linux, Microsoft Windows, y otras plataformas. WebLogic puede utilizar Oracle, DB2, Microsoft SQL Server, y otras bases de datos que se ajusten al estándar JDBC. El servidor WebLogic es compatible con WS-Security y cumple con los estándares de J2EE 1.3 desde su versión 7 y con la J2EE 1.4 desde su versión 9 y JEE 5 para las versiones 9.2 y 10.x. El sistema SPEI trabaja con Microsoft SQL Server en el Banco de estudio. Otro componente importante para la operación del sistema SPEI es Tuxedo. Tuxedo (Transactions for Unix, Extended for Distributed Operations) es una plataforma de middleware usada para gestionar procesos transaccionales distribuidos en entornos de computación distribuida. Tuxedo es un middleware orientado a transacciones (en inglés Transaction Oriented Middleware, TOM). Actualmente es muy utilizado en instituciones financieras donde se tiene alto flujo transaccional. En conjunto con Weblogic logran ser una capa importante para el servicio a todos los medios electrónicos (Front). Base de Datos SPEI Tuxedo Weblogic Aplicación de Servidor SPEI SPEI Banco de Mexico Figura Tuxedo, middleware orientado a transacciones El SPEI se encuentra dividido en dos partes, los cuales mantienen comunicación entre sí mediante el uso de mensajes. La función principal de la primera parte es proveer de un medio gráfico de ingreso de solicitudes de órdenes, cancelación y devoluciones de las mismas, así como traspasos. Permite la comunicación entre el usuario y el sistema denominado SPEI. La segunda parte mantiene la comunicación con el Banco Central y se encarga del procesamiento de las solicitudes enviadas por la Interfaz. A continuación se muestra la arquitectura general del sistema SPEI de la primera parte. 73

78 Caso Práctico Capa de Interfaz (JSP s) Capa del Negocio (EJB s) Modulo de Comunicación Banco Central Base de Datos Capa de Acceso a Datos (DAO s) Figura Arquitectura general del sistema SPEI 3.2 Análisis del Proceso Objeto de Estudio Proceso SPEI del Banco Cada institución financiera con participación en el sistema SPEI propuesto por parte el Banco Central tiene un proceso general que lleva a cabo para poder operar dicho sistema SPEI. Los procesos varían de Banco en Banco participante de acuerdo a su forma de servicio al cliente, sistemas involucrados, tecnología que tienen a su alcance tanto de software como de hardware, estándares de tecnología y seguridad informática, proveedores y presupuesto entre otros factores. Si muchos Bancos llegaran a compararse sus procesos definidos para la operación del sistema SPEI podrían parecer muy similares incluso hasta iguales sobre todo cuando sus soluciones informáticas son provistas por la misma tecnología y/o proveedor de servicios informáticos y los servicios financieros ofrecidos de igual manera son los mismos aunque no en sus características puntuales por supuesto, lo cual marca la diferencia entre un banco y otro, sin embargo; nunca los procesos internos de un banco son exactamente iguales a los de otro, por lo que no podría decirse que un determinado banco no cumple con un estándar aplicado a la operación interna del sistema SPEI. El Banco de estudio en este análisis tiene un proceso interno muy particular para operar en el sistema SPEI a diferencia de otros bancos de mayor envergadura operativa, el Banco en estudio no cuenta con un servicio web público para la operación de pagos electrónicos SPEI, el Banco en estudio en su afán de caracterizarse como un Banco de servicio y atención al cliente personal ha mantenido procesos muy detallados que lo han mantenido alejado de las nuevas facilidades tecnológicas disponibles que permiten mayor velocidad de servicio, puntualmente SPEI, seguridad e integridad de las transacciones por medios electrónicos, escalabilidad y por supuesto participación e integración en la competencia del mercado. 74

79 A continuación se analizara el proceso SPEI del Banco de estudio desde lo general a lo particular con el fin de identificar los puntos de mejora que de acuerdo a los recursos y alcance del banco en estudio se pueden cubrir, se espera tener un cambio radical pero no totalmente modernizado, la actualización tecnológica es un proceso gradual cuando se cuenta con recursos limitados Áreas del Banco de estudio Para poder saber cuáles son las opciones y oportunidades de mejora que se pueden ofrecer a un negocio se tiene que entender que es lo hace el negocio, sus objetivos, su alcance, sus áreas, las funciones de las mismas y los procesos que llevan a cabo así como la manera en que se relacionan entre ellas para alcanzar los objetivos del negocio. En esta sección se describirán de manera general las áreas del Banco en estudio que están involucradas en el proceso de la operación del sistema SPEI. Cuentas Nuevas. Esta área se encarga de la administración de las cuentas nuevas de clientes del Banco en estudio. Una persona física se convierte para el Banco en estudio en un cliente prospecto al momento en que hace su primer acercamiento al Banco en estudio interesándose en los servicios y productos que ofrece. El área se encarga del registro al cliente prospecto en un sistema informático CMR (customer management relationship) en el cual se da seguimiento al interés de cliente prospecto hasta que se convierta en cliente activo. El cliente activo se define como aquel que ha firmado un contrato de servicios financieros con el Banco en estudio y se le ha generado un número de cliente y un número de cuenta eje. La activación de un cliente prospecto se realiza desde el CMR y se envía esta información al sistema Bancario principal, el cual es el encargado de generar el número de cliente y número de cuenta eje. Otra función del área de Cuentas Nuevas es el registro de terceros autorizados, se les llama así a las personas que un cliente activo desea registrar como una persona autorizada para hacerle una transacción SPEI entre otras características. En otras palabras para que un cliente del Banco en estudio pueda realizar una transacción SPEI debe solicitar el registro de la persona a la que le hará el pago electrónico, el área de Cuentas Nuevas es la encargada de esta gestión. Atención a Clientes. Esta área se encarga de la atención directa y telefónica de los clientes del Banco en estudio. Cuando un cliente activo desea realizar un pago electrónico tipo SPEI, realiza una llamada a esta área, el área se encarga de verificar la identidad del cliente, que la persona a la que desea hacerle el pago electrónico este previamente registrada como un tercero autorizado, en caso contrario se re direccionara al cliente al área de Cuentas Nuevas para el registro de su tercero autorizado. Atención a Clientes, al identificar al cliente y a su tercero autorizado también revisa el estado de la cuenta eje del cliente activo, la cuenta debe estar activa y con fondos suficientes para llevar a cabo el pago electrónico por el monto señalado por el cliente. Estas validaciones se hacen tanto en el sistema CMR para la identificación verbal del cliente como en el sistema principal Bancario para la revisión del estado de la cuenta del cliente. Atención a clientes lleva a cabo la operación del pago electrónico en el sistema principal Bancario que a su vez llevara a cabo los procesos necesarios para proceder con la transacción. 75

80 Caso Práctico Trastienda de la Oficina (Back Office). Esta área se encarga de los procesos trastienda de la oficina, una vez que el área de Atención a Clientes llevo a cabo su proceso en relación a pagos electrónicos esta área se mantiene a la espera de los procesos del sistema principal bancario los cuales generan archivos electrónicos planos con la información de las transacciones operadas por el área de atención a clientes. Estos archivos electrónicos se envían a un sistema middleware del banco el cual al recibirlos los procesa y genera un salida para que personal del área de Trastienda de la Oficina los tome valide y cargue en el sistema SPEI del Banco en estudio. Personal de esta área hace uso directo del sistema SPEI del Banco en estudio, cargando las transacciones en lotes en el sistema para su procesamiento y envío al sistema SPEI del Banco de México. También utiliza este sistema SPEI del Banco para monitorear la recepción de intenciones de pagos electrónicos emitidos por otros bancos participantes, el área se encarga de validar estas intenciones de pagos y hacerlas efectivas o rechazarlas según sea el caso. Adicional a lo anterior el área también se hace cargo de las conciliaciones de las operaciones efectuadas durante el día de las transacciones de pagos electrónicos tipo SPEI entre otras más. Área de Tecnología Local. El área da soporte y servicios tecnológicos diversas áreas de la compañía entre ellas la del Banco en estudio. Para el objeto de estudio, el área de Tecnología Local ofrece principalmente los servicios de soporte productivo, soporte a pruebas, seguimiento a requerimientos regulatorios, análisis de mejora tecnológica para el Banco en estudio entre otras cosas. Proveedores. Los proveedores no son parte de la organización del Banco en estudio, debido a que el Banco en estudio cuenta con un proveedor de servicios de TI que le desarrollo la solución del sistema informático local para pagos electrónicos SPEI, el banco en estudio a través del área de Tecnología Local solicita los servicios de soporte y actualización para dicho sistema al proveedor. El área de Tecnología Local en realidad funge como un intermediario de servicios de soporte a producción, cuenta con un nivel avanzado de soporte al aplicativo SPEI pero siempre cuenta con el apoyo del proveedor para cada soporte de este aplicativo por parte del proveedor. 76

81 Áreas del Banco Solicitud de Servicio Cuenta Nueva Cuentas Nuevas SPEI Trastienda de la Oficina SPEI Banco de México Cliente Activo Atención a clientes SPEI Área de Tecnología Local Área de Tecnología Global Proveedor SPEI Figura Áreas del Banco y el SPEI Teniendo identificadas las áreas involucradas del Banco en estudio en el proceso de pagos electrónicos de tipo SPEI se procederá a analizar el flujo completo del proceso SPEI para el Banco en estudio con el objetivo de identificar puntos de oportunidad y mejora Proceso SPEI de Envío A continuación se describirá el proceso de envío de pagos electrónicos de tipo SPEI que sigue el Banco en estudio. El proceso de operación del sistema SPEI tiene dos principales flujos: flujo de salida y flujo de entrada. El flujo de salida, es aquel en el que el Banco en estudio es el originador de una transacción de tipos SPEI. El flujo de entrada, es aquel en el que el Banco en estudio es el receptor de una transacción de tipo SPEI originada por otro Banco o institución financiera. 77

82 Caso Práctico Flujo de salida El envío de pagos electrónicos de tipo SPEI tiene origen en la solicitud del servicio por parte de un cliente activo al área de atención a clientes, esto se hace llevando a cabo una llamada telefónica por parte del cliente hacia el Banco en estudio a su área de Atención a Clientes. Cliente Activo Atención a clientes Figura Cliente Activo y Atención a clientes Atención a clientes llevará a cabo un proceso de validación de identidad verbal, preguntará por información que sólo el titular de la cuenta podría proporcionar. Una vez comprobada la identidad del cliente, el siguiente paso consiste en que Atención a Clientes verifique el previo registro de la persona receptora o beneficiaria del pago electrónico en el sistema principal Bancario llamada por el Banco en estudio como tercero autorizado y con la correspondiente asociación a la cuenta del cliente activo que solicita realizar el pago electrónico. Cuando Atención a Clientes ha determinado que se puede proceder con un pago electrónico de tipo SPEI, en el sistema principal Bancario lleva a cabo la transacción Retiro SPEI. Continúa con el llenado de los datos requeridos por la transacción para que finalmente presione el botón indicado en el sistema principal Bancario para procesar el pago electrónico. Valida y Completa Transacción Atención a clientes Sistema Principal Bancario CAM (Client Application Manager/Administrador de Aplicación Cliente) Figura Atención a clientes y Sistema Principal Bancario 78

83 Una vez enviada la transacción de envío de pago electrónico tipo SPEI al sistema principal Bancario este último a través del CAM (Administrador de Aplicación Cliente) procesa la información y la envía al SAM (Administrador de Aplicación Servidor), el SAM (Administrador de Aplicación Servidor) del sistema principal Bancario validara la integridad de los datos y almacenará la transacción en su base de datos. Este proceso hasta este punto se lleva a cabo para cada solicitud de pagos electrónicos de tipo SPEI que debe procesar el Banco en estudio. En el capítulo 3.1 se mencionó que el sistema principal Bancario cuenta con un procesador periódico que se encarga de llevar a cabo procesos en lotes transaccionales. El procesador periódico del sistema principal Bancario, cada media hora revisa las transacciones pendientes almacenadas en la base de datos del sistema principal Bancario, selecciona estas transacciones y comienza a generar un archivo plano incluyendo las transacciones seleccionadas. El sistema principal Bancario al terminar la generación del archivo plano con las transacciones pendientes ya sean de tipo SPEI u otra, lo coloca en un buzón determinado para que el archivo a través de una herramienta de transferencia de archivos segura, SFT (Secure File Transfer por sus siglas en inglés), sea descargado. La generación del archivo se realiza cada media hora, adicional a este tiempo se debe sumar el tiempo que el servicio de transferencia de archivos seguro requiere para revisar el buzón y descargar los archivos colocados en este. Envía Transacción Sistema Principal Bancario CAM (Administrador de Aplicación Cliente) Procesador Periódico Sistema Principal Bancario SAM (Administrador de Aplicación Servidor) Selecciona Procesa y Almacena Txns Txn Pendientes Colocación de Archivo Plano Descarga De Archivo Plano Sistema Principal Bancario Base de Datos Buzón FTP Servicio de Transferencia de Archivos Segura Descarga Transferencia De Archivo Plano Servidor de Archivos Figura Sistema Principal Bancario y Servidor de Transferencia de Archivos, flujo 79

84 Caso Práctico El sistema principal Bancario al generar el archivo plano considera un formato estandarizado para todas las transacciones pendientes seleccionadas, este formato proporciona información correspondiente al formato del pago electrónico del tipo SPEI Participante a Tercero. La transacción en su forma cambia lo cual no corresponde con la solicitud real, y lo que se envía al Banco Central para que este a su vez lo envíe a la institución participante que recibe (Banco receptor) no es en realidad la que debería de ser. El cliente receptor, el tercero con cuenta en la institución participante que recibe, estará recibiendo un pago electrónico SPEI del Banco en estudio y no del tercero con cuenta en la institución participante que envía. Dando un ejemplo práctico de esta situación, supongamos que el cliente Roberto con cuenta activa en el Banco A desea hacer un pago electrónico de tipo SPEI Tercero a Tercero a Daniel con cuenta activa en el Banco B. Durante el proceso de la transacción el Banco A en lugar de enviar la información del cliente Roberto como el Tercero que está haciendo el pago electrónico, envía información propia dando a entender que el que envía el pago electrónico es el Banco A al cliente Daniel en el Banco A. El cliente Daniel del Banco B no sabe realmente que Roberto cliente del Banco A fue quien le realizó el pago y en su lugar cree que el Banco A es el que le esa haciendo dicho pago. Para fines prácticos posiblemente lo importante para ambos clientes es que el pago se haya efectuado, que Daniel cliente del Banco A haya recibido el pago sin importar la información de quien es el que le hizo el pago. Pero para fines de control, auditoría y seguridad financiera el impacto es enorme, ya que no existe una transparencia en la información del pago electrónico y se puede prestar a malos manejos de la información lo cual amerita una sanción por parte del Banco Central por un mal control de datos. El Banco en estudio tiene que recurrir a la generación de reportes diversos de los dos sistemas involucrados en esta recepción, transformación y envío de pagos electrónicos, el sistema principal bancario y el sistema local SPEI, hacer la conciliación de sus respectivos reportes para poder enviar información regulatoria de control al Banco Central y de esta manera evitar sanciones por mal control de datos. Continuando con la descripción del proceso de envío de pagos electrónicos de tipo SPEI, el archivo plano con las transacciones ya con el formato cambiado, es descargado por la herramienta SFT (transferencia de archivos segura) y colocado en un servidor de archivos local. El siguiente paso en el proceso lo toma el Sistema middleware del Banco en estudio, el Middleware se encarga de tomar el archivo plano generado por el sistema bancario Principal y procesarlo. El sistema Middleware del banco en estudio clasifica la información de este archivo plano y lo almacena en su base de datos. Las transacciones almacenadas se consideran como pendientes. El flujo del middleware se describe a continuación. 80

85 Toma Archivos Planos de Entrada Servidor de Archivos Sistema MiddleWare del Banco Selecciona Procesa y Almacena Txns Txn Pendientes Genera Archivos Planos de Salida Servicio Windows Inicia Procesos Servidor de Archivos Sistema MiddleWare del Banco Base de Datos Figura Servidor de Transferencia de Archivos y Sistema Middleware, flujo El sistema Middleware del Banco cuenta con un servicio Windows que se encarga de iniciar los procesos de procesamiento de archivos de entrada y generación de archivos de salida. Este servicio inicia los procesos cada 15 minutos, accede a las interfaces configurables en el servidor de archivos y toma los archivos que de acuerdo a los horarios deben ser procesados, en el caso del archivo plano generado por el sistema principal bancario con información de pagos electrónicos de tipo SPEI no tiene restricción de horario, procesa los registros contenidos en dicho archivo y los almacena en su base de datos. Así como el servicio Windows del Middleware se encargo de iniciar el proceso para la toma de archivos planos de entrada, también inicia el proceso que se encarga de seleccionar de la base de datos aquellos registros clasificados como pendientes para incluirlos en un archivo plano de salida. El flujo de una transacción dentro del sistema middleware independientemente de su formato y tipo, es así; se procesa el registro y se almacena en la base de datos con un estado de pendiente, en caso de no ser un registro valido se clasifica como rechazado, posteriormente se seleccionan todos los registros pendientes y/o rechazados y se incluye en un archivo plano de salida que se enviará al sistema destino u origen en el caso de los rechazados. Los registros pendientes cambian su estado a procesados y los rechazados se mantienen en dicho estado. El área de Trastienda de la Oficina se encarga de monitorear el correcto funcionamiento de la aplicación Middleware, revisa que las interfaces configuradas en el sistema se procesen a tiempo tanto las interfaces de entrada como las de salida. Hasta este punto el pago electrónico solicitado por el cliente activo del banco en estudio no ha sido enviado al Banco Central, a penas esta por ser cargado en el sistema local SPEI del Banco en estudio. El pago electrónico ahora se encuentra en otro archivo plano pero con un formato distinto y como un tipo de transacción diferente a la original. 81

86 Caso Práctico El archivo plano de salida generado por el Middleware es colocado en un servidor de archivos local con acceso a ciertos usuarios. Una vez que la información ha sido validada el archivo es cargado manualmente en el sistema local SPEI el cual procesara su contenido para continuar con el proceso del banco para la aplicación de un pago electrónico interbancario SPEI. A continuación en el proceso de envío de un pago electrónico tipo SPEI, ya que la información ha sido cargada en el sistema local SPEI de manera manual, debido a que este no cuenta con un servicio o procesador periódico que tome el archivo para su proceso automático, el sistema local SPEI procesara la información validando su integridad y almacenando la transacción en su base de datos. Similar al sistema Middleware, el sistema local SPEI almacena los registros de transacciones con pagos electrónicos de tipo SPEI Participante a tercero en su base de datos con un estado de pendiente. Cada transacción debe ser liberada y autorizada por la Trastienda de la Oficina, debido a que se manejan montos muy altos y el personal del área de Atención a Clientes tienen acceso a cuentas de la compañía es necesario llevar a cabo validaciones que mitiguen el riesgo por una operación indebida. El sistema local SPEI desarrollado en J2EE, cuenta con Deamons (Demonios) que cada determinado periodo de tiempo (30 segundos) consulta la base de datos y selecciona los registros autorizados por procesar y enviar a Banco de México. Los Demonios toman la información y la empaquetan, foliando cada pago electrónico incluido en el paquete para su control y seguimiento, estos paquetes son enviados al Middleware del sistema local SPEI, Tuxedo, el cual haciendo uso de colas de memoria reservadas empieza a procesar los paquetes de pagos electrónicos de tipo SPEI para enviarlos a Banco Central. Por supuesto el sistema local SPEI debe tener una conexión electrónica habilitada con el sistema SPEI del Banco Central, al tener esta conexión el sistema middleware del sistema local SPEI, Tuxedo, podrá enviar la información a través del socket de comunicación a Banco de México, este a su vez al recibir el paquete por parte del Banco en estudio enviará un acuse de recibo, el sistema local SPEI hasta este punto ha logrado liberar por completo las transacciones autorizadas por el área de Trastienda de la Oficina, aquí se podría notificar puntualmente al cliente que solicitó el servicio de pago electrónico interbancario SPEI que se ha llevado a cabo satisfactoriamente el servicio, sin embargo; esto no es así el banco notifica un tiempo estimado de aplicación del pago el cual oscila entre la hora y media y las dos horas a partir de su envío desde el sistema principal bancario. De esta manera se concluye el proceso SPEI de envío donde le Banco en estudio envía un pago electrónico interbancario SPEI al Banco Central. 82

87 Archivo Plano de Salida Del Sistema Middleware Bancario Con Formato SPEI Carga de Archivo Carga de Archivo Procesa Solicitud Empaque de Txns TUXEDO MIDDLEWARE Envío de Paquete Usuario Sistema local SPEI Interfaz Web Sistema local SPEI Sistema local SPEI Selecciona Procesa y Almacena Txns Txn Pendientes Demonios Banco de Mexico Sistema local SPEI Base de Datos Figura SPEI de envío donde le Banco en estudio envía un pago electrónico interbancario SPEI al Banco de México 83

88 Caso Práctico Figura Proceso SPEI de Envío 84

89 3.2.4 Proceso SPEI de Recepción y Rechazo A continuación se describirá el proceso de recepción de pagos electrónicos de tipo SPEI que sigue el Banco en estudio. El sistema SPEI del Banco Central enviará paquetes de información con pagos electrónicos de tipo SPEI a través del socket de comunicación establecido con el banco en estudio que es participante de este sistema SPEI. El banco en estudio a través su sistema local SPEI va recibir los paquetes enviados por parte del sistema SPEI del Banco Central y se gestionaran por medio de su aplicación middleware llamada Tuxedo, la cual administrara las colas de información e ira enviándolas a la base de datos del sistema local SPEI desempaquetándolas y confirmando al Banco Central que han sido liquidadas, este es un mensaje incorrecto ya que en la realidad el verdadero beneficiario de la transacción aún no se le ha abonado el pago correspondiente en este punto el pago electrónico esta en el sistema SPEI del Banco en estudio. Los pagos electrónicos recibidos en el sistema local SPEI son revisados por personal de la Trastienda de la Oficina, los cuales evaluaran transacción por transacción validando la información de cada pago, por ejemplo que la cuenta de recepción corresponda a una cuenta CLABE bancaria y cuenta de cheques no una tarjeta de crédito, otra validación es que la cuenta receptora del pago exista y esté activa en el sistema del banco principal. El personal de la Trastienda de la Oficina son usuarios del sistema local SPEI y también son usuarios del sistema principal bancario, en el primero monitorean la recepción de pagos electrónicos bancarios y en el segundo acceden para corroborar la existencia y estado activo de la cuenta a la que se le aplicara el pago electrónico. Si la cuenta receptora es válida, el personal de la Trastienda de la Oficina accederá al sistema principal bancario, y procederá a realizar el depósito del pago electrónico en la cuenta del cliente tercero del banco en estudio de forma totalmente manual. Como se habrá notado existen diversas acciones manuales y con dependencia de la valides humana, esto significa que en algún momento se pueden presentar errores humanos, como incorrecta validación de la información que se recibe, un error en la captura del pago electrónico que puede depositar de mas al cliente o incluso puede depositar en una cuenta que no es la beneficiaria. Lo anterior se valida y concilia pero estas conciliaciones se llevan a cabo al día siguiente después de que el sistema bancario principal genera reportes generales de operaciones efectuadas durante el día. Por lo anterior el negocio del banco es capaz de detectar inconsistencias y malas operaciones hasta el día siguiente, lo cual significa un riesgo alto para la economía del banco en estudio, suponiendo que se hizo un pago incorrecto, para el otro día posiblemente el cliente ya habrá sacado su dinero y no habrá manera de recuperarlo ya que es responsabilidad del banco en estudio el correcto proceso de los pagos electrónicos. Adicionalmente se puede incurrir en sanciones por parte del Banco Central por una mala operación de pagos electrónicos y también por no cubrir la demanda del volumen de operaciones que se trabajan en el sistema SPEI, ya que existen muchos procesos llevados a cabo manualmente puede pasar que no sean 85

90 Caso Práctico suficientes recursos humanos para poder cubrir el volumen de operación y sobre todo en horas y fechas pico como quincenas donde los pagos son mas recurridos. Sistema local SPEI Muestra Recepcion De Pagos Valida Txn Banco Central Envío de Paquete TUXEDO MIDDLEWARE Desempaque de Txns Demonios Selecciona Procesa y Almacena Txns Txn Pendientes Interfaz Web Sistema local SPEI Personal Trastienda de la Ofic. Valida Txn Aplica Txn Sistema local SPEI Base de Datos CAM Sistema Principal Bancario Figura Flujo SPEI de Recepción y Rechazo En caso de que alguna validación no sea correcta el personal de la trastienda de la oficina procederá con el rechazo del envío del pago electrónico de tipo SPEI, esto lo lleva a cabo utilizando el front end del sistema local SPEI, seleccionará la el pago electrónico invalido y procederá con la funcionalidad de rechazo del pago electrónico en el sistema local SPEI, especificando el motivo del rechazo, cuenta invalida, código de banco incorrecto, cuenta CLABE incorrecta etc. De igual forma estas transacciones devueltas al banco de México son controladas manualmente y se lleva un registro de las mismas. 86

91 3.2.5 Proceso SPEI de Conciliación Figura Proceso SPEI de Recepción El proceso SPEI de conciliación consiste en llevar a cabo una revisión y comparación de todas las transacciones llevadas a cabo durante el día del tipo SPEI tanto de envío como de recepción. Los dos sistemas a revisar son el sistema principal bancario y el sistema SPEI. En el caso del sistema principal bancario al final del día es cuando se genera por proceso batch un reporte con todas las transacciones efectuadas durante el día, tanto las recibidas como las enviadas. Esto ya representa un gran riesgo en la correcta operación ya que en el dado caso de existir una diferencia esta no se podrá identificar puntualmente hasta el cierre del día operacional. Para el sistema SPEI bancario, la información está disponible en línea, los reportes de transacciones operadas tanto de envío como recepción e incluso rechazos se pueden obtener directamente de la aplicación por el usuario sin necesidad de esperar al final del día para obtener esta información. El negocio lleva a cabo una pre conciliación basándose en los archivos planos que genera el sistema principal bancario al sistema middleware bancario, se asigna una persona a la revisión de la información de estos archivos y llevar a cabo la conciliación con un reporte del sistema SPEI. La conciliación completa se lleva a cabo al cierre del día cuando el informa completo del sistema principal bancario es generado. 87

92 Capítulo IV Propuesta de Implementación. En este capítulo se desglosará de forma pragmática y en lo posible genérica el desarrollo de un proyecto de integración de dos sistemas informáticos desde su definición hasta su implementación. El principal objetivo de este capítulo es exponer la relación de la teoría con un caso práctico, aplicando las mejores prácticas estudiadas en esta integración. 4.1 Definición del Proyecto. En esta sección se describirá el objetivo del proyecto, participantes, recursos organizacionales, procesos organizacionales y el punto de partida a un alto nivel Objetivo del proyecto. En un Banco de Estudio se requiere integrar dos sistemas informáticos de diferentes plataformas de tal forma que su comunicación sea en línea. Ninguno de los dos sistemas cambiará su plataforma al del otro. La integración debe seguir las mejores prácticas de implementación de sistemas distribuidos aplicando la Arquitectura SOA considerando todas las implicaciones de infraestructura para proveer al negocio una solución de alta disponibilidad. Objetivo Meta del Negocio Medida de Éxito del Proyecto Integrar dos sistemas informáticos de diferentes plataformas. Tener una solución tecnológica automática libre de riesgos operacionales manuales. Sistemas informáticos integrados sin intervención de procesos manuales. Proveer una arquitectura de sistemas distribuida aplicando SOA Contar con una solución tecnológica confiable, libre de dependencias rígidas capaz de soportar escenarios con fallas y necesidades futuras. Solución informática implementada de forma heterogénea, extensible, segura, escalable, con trato a fallos, concurrente, transparente, independiente de locación y 88

93 Propuesta de Implementación carga balanceada. Implementar una arquitectura de alta disponibilidad. Contar con una solución tecnológica que permita la operación continua independientemente del fallo de la misma ya sea de forma transparente o haciendo uso de un ambiente alterno pero con información actual. Solución tecnológica implementada bajo un esquema de alta disponibilidad. Tabla Objetivos del Proyecto Participantes del Proyecto y Recursos Organizacionales Los principales participantes requeridos en un proyecto de esta índole se presentan a continuación, esta información puede variar dependiendo la organización de cada banco, empresa, organización. 89

94 Director Operaciones Director Gestión de Proyectos Gerente de Operaciones Gerente de Portafolio Líder de Operaciones Probador de Sistemas Usuario Experto Administrador de Proyectos Usuario Validador Analista de Sistemas Equipo del Negocio Gestión de Proyectos Figura Participantes del Proyecto y Recursos Organizacionales Rol desempeñado por Roberto Daniel Velásquez Portilla El Rol que un servidor llevo a cabo en este proyecto de principio a fin fue el de Analista de Sistemas, el cual como parte de sus responsabilidades se incluyen: - Análisis completo del punto de partida, ver Capítulo anterior y en el presente sección completa de Análisis del Proyecto. - Identificación de puntos de oportunidad. - Participación analítica y técnica en la definición del punto de arribo. - Relevamiento de requerimientos regulatorios, funcionales y técnicos que cumplimenten por completo las necesidades del negocio de acuerdo a los objetivos planteados. - Modelado UML de los procesos impactados, describiendo claramente procesos decomisados y procesos nuevos. - Identificación puntual de los participantes necesarios para poder llevar a cabo el proyecto. 90

95 Propuesta de Implementación - Definición del alcance del proyecto. - Participación en la definición del plan de trabajo, con base a los requerimientos relevados y el punto de arribo se calcula el tiempo mínimo requerido para llevar a cabo el proyecto. - Junto con el equipo del Arquitecto Tecnológico, se define la arquitectura a emplear, analizando los flujos de los procesos, diagramas de secuencia, mapeo de información, definición de mensajes sus estados y su flujo. - Diagramación de la solución final. Cabe mencionar que en el trabajo de tesis presente, se incluye una propuesta mejorada del trabajo llevado a cabo, esto como consecuencia de la experiencia de la ejecución del proyecto en el mundo real. El proyecto desglosado no pretende ser un procedimiento único y rígido, por el contrario busca aportar una forma más de ejecutar un proyecto de esta índole implementando las mejores prácticas de análisis y administración de proyectos de acuerdo al escenario y circunstancias presentadas. 91

96 Director Infraestructura Tecnológica Director Comunicaciones Tecnológicas Arquitecto Tecnológico Gerente de Comunicaciones Probador Técnico Técnico en Seguridad y Redes Líder Técnico Técnico en Gestión de Accesos y Rutas Analista Técnico Analista Técnico de Redes Infraestructura y Tecnología Infraestructura y Tecnología 4.2 Análisis del Proyecto Figura Participantes del Proyecto y Recursos Organizacionales En esta sección se presentará un análisis del proceso del negocio y la arquitectura tecnológica actuales que se emplean para el envío y recepción de pagos electrónicos interbancarios, el objetivo es mostrar de forma clara los puntos de oportunidad y mejora que se cubrirán con la próxima propuesta de solución. En este punto me tomo el atrevimiento de hacer una pequeño recordatorio sobre cuál es el problema que se quiere resolver con el trabajo de tesis presente, esto con el fin de tener este punto de referencia y partida forma fresca lo cual nos facilitará el entendimiento de las siguientes secciones. El problema que pretende solucionar esta iniciativa y propuesta de tesis es a nivel general integrar dos sistemas fundamentales para la operación del banco en Estudio, su sistema principal bancario (sistema donde se encuentra la información financiera de los clientes del banco, sus cuentas eje, sus productos y estado financiero) con su sistema de pagos electrónicos interbancarios (sistema certificado por el banco central y especializado en el manejo de pagos electrónicos) ambos sistemas 92

97 Propuesta de Implementación están desarrollados en tecnologías diferentes y deben ser conectadas siguiendo las mejores prácticas de arquitectura de software así como los estándares de trabajo reconocidos y validados por el grupo tecnológico del banco en estudio para garantizar la seguridad y estabilidad del funcionamiento de la integración. El problema se vuelve más puntual al considerar dentro de la integración, la identificación de todo aquel proceso manual que intervenga en el flujo de operación que se busca como punto de arribo ya sea para la consolidación o para el control y ejecución de pagos electrónicos, estos procesos manuales se deben analizar y determinar si son necesarios considerarlos y automatizarlos o definitivamente ya no serán necesarios una vez puesta en producción la solución en línea. Por lo anterior es necesario llevar a cabo un análisis exhaustivo de los objetivos del proyecto para definir el proceso nuevo que tendrá el banco en la operación de este tipo de transacciones, los pagos electrónicos interbancarios. Otro problema es la transición del proceso, el entrenamiento y mitigación de reducción de personal, definiendo nuevos procesos, tareas y responsabilidades para ejercer la operación ahora en línea con el correspondiente control, monitoreo y consolidación de transacciones entre sistemas requeridos por el nuevo paradigma propuesto. 93

98 4.2.1 Arquitectura Punto de partida A continuación se muestra un diagrama de arquitectura de sistemas como punto de partida del proyecto. Sistema Principal Bancario Sistema de Transferencia de Archivos Aplicación Servidor Gestor de STA Aplicación Cliente Transferencia de Archivo a Buzón del Middleware Sistema Middleware Servicio Procesador Sistema de Pagos Electrónicos Interbancarios Procesamiento Transacciones Componente Web UI Carga de Archivos Oficina de Operaciones Descarga Manual Carga Manual Captura Manual Usuario de Operaciones Figura Arquitectura Punto de Partida En este diagrama se observa que para que el Sistema Principal Bancario pueda enviar y/o recibir información del Sistema de Pagos Electrónicos Interbancarios, SPEI, se requieren de tres componentes adicionales. Un sistema de transferencia de archivos, que al detectar la presencia de un nuevo archivo plano lo tomará y enviará al buzón del Sistema Middleware. Un sistema Middleware que tomará el archivo plano del Sistema Principal Bancario proporcionado por el sistema de transferencia de archivos. Procesará el archivo y generará una salida. El usuario de Operaciones tomará la salida y lo cargara finalmente en el sistema SPEI, en el sentido opuesta capturara directamente. 94

99 Propuesta de Implementación Proceso del Negocio Actual El proceso organizacional actual sigue diferentes pasos y subprocesos para el envío de una transacción y para la recepción de una transacción. En ambos procesos los dos puntos de inicio y fin son los mismos en su sentido opuesto, para una transacción de envío por ejemplo: A envía a B y para una transacción de recepción B envía a A. De lo anterior se agrega que las transacciones son del mismo tipo, bajo el mismo protocolo por lo que sus flujos deben ser homogéneos en sentidos opuestos solamente. Lo cual en este caso de estudio no se cumple ya que el proceso de envío sigue pasos totalmente diferentes a los de la recepción. Estos procesos no son eficientes, confidentes y muchos menos escalables, más adelante se revisará como al implementar la solución basada en SOA estas características se cubrirán. Conceptualmente un proceso del negocio posee las siguientes características: Pueden ser medidos y están orientados al rendimiento Tienen resultados específicos Entregan resultados a clientes o stakeholders Responden a alguna acción o evento específico Las actividades deben agregar valor a las entradas del proceso. El proceso actual cuenta tiene diversas conciliaciones manuales lo cual es pesado y no está orientado al rendimiento. Los resultados del proceso si bien son específicos no son los máximos ni óptimos. Los resultados que se entregan a los clientes y stakeholders son limitados por la fuerza de trabajo manual y la capacidad de abarcar el volumen de operación en un determinado tiempo. Adicionalmente en lugar de aportar un valor a las entradas de este proceso aportan un riesgo a la integridad de su valor. Para mejorar el proceso del negocio anterior es preciso recurrir a diversas prácticas de modelado de procesos del negocio, identificando cual es el objetivo principal del proceso, los puntos de origen y destino, la información que se trabaja y procesa los participantes y su función para finalmente proponer el camino más óptimo y corto que beneficie al negocio. A través del modelado de los procesos de negocio, al interior de una organización, puede lograrse un mejor entendimiento de la operación de la empresa y muchas veces esto presenta la oportunidad de mejorar los procesos y con ello mejorar el desempeño. La estructuración de los procesos reduce errores, asegurando que los procesos se comporten siempre de la misma manera, reduciendo el margen de error y dando elementos que permitan visualizar el estado de los mismos durante cada etapa. Para soportar esta estrategia es necesario contar con un conjunto de herramientas que den el soporte necesario para cumplir con el ciclo de vida de BPM. Este conjunto de herramientas son llamadas Business Process Management System (BPMS), y con ellas se construyen aplicaciones BPM. 95

100 Normalmente siguen una notación común, denominada Business Process Management Notation (BPMN). A continuación se mostrará como una comparación del modelo del proceso actual y el modelo del proceso deseado. A continuación se diagraman los principales procesos organizacionales al alcance de este proyecto bajo la notación BPM, Business Process Modelling. Envío de Pagos Retiros Envío de Devoluciones por Recepción de Pagos no válidos Se registra el pago en el Sistema Principal Bancario. Figura Proceso del Negocio actual, envío de pago Cada determinado tiempo el Sistema Principal Bancario genera un archivo plano con los pagos registrados. 96

101 Propuesta de Implementación Un segundo sistema, Sistema Middleware toma el archivo plano lo procesa y genera otro archivo plano con el formato requerido por el sistema SPEI. Manualmente la Oficina de Operaciones toma el archivo plano generado por el Sistema Middleware y lo carga en el sistema SPEI. El sistema SPEI procesa el archivo y envía los pagos al Banco Central. Recepción de Pagos Depósitos Recepción de Devoluciones por Envío de Pagos no válidos Figura Proceso del Negocio actual, recepción de pago El sistema SPEI recibe los pagos por parte del Banco Central. Un usuario de la Oficina de Operaciones monitorea constantemente la recepción de pagos en el sistema SPEI. Al detectar un pago(s) el usuario de la Oficina de Operaciones lleva a cabo tanto el registro de la cuenta que envía el pago como la captura manual del pago (depósito) en el sistema Principal Bancario. 97

102 4.2.3 Análisis de las Propiedades de la Transacción del Proceso Actual Independientemente del caso de estudio, el procesamiento de transacciones debe cumplir con las siguientes propiedades: 1. Atomicidad: es la propiedad que asegura que la operación se ha realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias. 1. Consistencia: es la propiedad que asegura que sólo se empieza aquello que se puede acabar. Por lo tanto, se ejecutan aquellas operaciones que no van a romper la reglas y directrices de integridad de la base de datos. 2. Aislamiento: es la propiedad que asegura que una operación no puede afectar a otras. Esto asegura que la realización de dos transacciones sobre la misma información nunca generará ningún tipo de error. 3. Permanencia: es la propiedad que asegura que una vez realizada la operación, ésta persistirá y no se podrá deshacer aunque falle el sistema. En base a la información de los procesos organizacionales y el punto de partida arquitectónico tenemos lo siguiente: Atomicidad: Las transacciones de envío no son atómicas, ya que el flujo de la misma esta segmentado y en determinado punto depende de la operación manual del negocio. En caso de que un paso, sistema posterior a la ejecución del pago en el sistema principal bancario llegue a fallar esta transacción no es atómica, ya que en el sistema principal bancario se llego a completar dicha transacción lo cual en su realidad no lo fue. Lo mismo sucede en el flujo opuesto, la transacción es recibida en el Sistema SPEI del banco en estudio pero depende de varios procesos manuales que se lleve a cabo su procesamiento completo al sistema principal bancario. A continuación se grafica los puntos de quebrantamiento con el proceso organizacional actual de envío de una transacción. Cada punto rojo indica un estado final al flujo, cuando en realidad el único estado final debería ser Fin Transacción. Figura Puntos de quiebre en proceso actual de una transacción 98

103 Propuesta de Implementación Consistencia: El caso más claro sobre el incumplimiento de la consistencia en el flujo operacional actual se da en la recepción de pagos, en este flujo el usuario es prácticamente responsable de la validación de la consistencia de los datos, de revisar la integridad de la cuenta, registrar en caso de no estarlo el remitente del pago por temas de seguridad y finalmente proceder a la captura del depósito. Un usuario de un sistema no debe validar tipos de datos, si son numéricos o no, si cumple con el formato de una cuenta determinada o no o si la cuenta esta activa o no esto pone en riesgo la consistencia correcta de una transacción ya que se puede completar algo que no debió completarse y viceversa. Figura Procesos Manuales, posible inconsistencia Aislamiento: Esta propiedad no se cumple tampoco, como ejemplo tenemos la solicitud de una transacción de salid, envío; en este flujo cuando una transacción pasa por un sistema depende de varios factores por mencionar uno el tiempo de procesamiento de cada estado, de capturado en el sistema principal bancario a enviado al servidor de transferencia de archivos después de un determinado tiempo, posteriormente pasaría al middleware y finalmente al SPEI, este flujo toma demasiado tiempo y como se mencionó con varios puntos de quiebre, esto es susceptible a malas interpretaciones del flujo y puede causar una doble captura manual de la transacción o su omisión, infringiendo con su aislamiento ya que una tercero intervino en el procesamiento de la transacción corrompiendo su flujo y causando incumplimiento de la transacción o duplicidad o captura incorrecta y diferente de la información original. 99

104 Figura Aislamiento no cumplido en proceso actual Persistencia: definitivamente con los procesos organizacionales y la arquitectura de punto de partida de este proyecto, esta propiedad está completamente fuera de ser cumplimentada. Existiendo tantos puntos de quiebre, riesgo de omisión y incorrecta manipulación de datos, la transacción está al límite de su incumplimiento total y veraz. La transacción en caso de ser quebrantada deben realizarse procesos fuera de los planeados para lograr mantener dicha persistencia lo cual es en realidad el procesamiento de otra transacción. El breve análisis anterior está enfocado al tratamiento de transacciones, ya que el proyecto tiene como parte de sus objetivos integrar dos plataformas para llevar a cabo transacciones en línea lo cual actualmente como ya se demostró no se cumple analizando cada propiedad de una transacción informática Puntos de Oportunidad y Punto de Arribo A continuación se presenta el punto de arribo del proceso del negocio esperado para el envío y recepción de pagos electrónicos interbancarios. Envío de Pagos Retiros Envío de Devoluciones por Recepción de Pagos no válidos 100

105 Propuesta de Implementación Figura Proceso de Envío de Pago, Punto de Arribo En el punto de arribo, nuestra solución; lo que se está proponiendo como se puede ver es que una vez que se ha capturado el pago en el área de Atención a Clientes, este sea procesado por el Sistema Principal Bancario en inmediatamente se envíe el Mensaje de Envío de Pago por un Canal Seguro al Sistema SPEI este a su vez lo procesara y lo enviara de forma usual al Banco Central. Hasta este momento el usuario solo sabe que se ha enviado el pago sin embargo no sabe su estado y no puede confirmar aún al cliente si fue exitoso o no, por lo cual se propone que se aproveche el mensaje de acuse de recibo que hoy en día el Banco Central envía por cada paquete de transacciones, pagos enviados, una vez que el SPEI reciba el correspondiente acuse de recibo genera un Mensaje de Confirmación de Pago para el Sistema Principal Bancario, este mensaje así como el de envío de pago se enviará de por un canal seguro, el Sistema Principal Bancario procesara este Mensaje de Confirmación de Pago el cual puede ser también una Devolución, si es una Devolución realizará el reverso del correspondiente retiro, en otro caso solo actualizará el estado del Envío de Pago como Confirmado, lo que significa que el pago fue recibido exitosamente por el Banco Central, permitiendo al área de atención a clientes confirmar al cliente el estado final de su pago en cuestión de segundos. Recepción de Pagos Depósitos Recepción de Devoluciones por Envío de Pagos no válidos 101

106 Figura Proceso de Recepción de Pago, Punto de Arribo En este flujo, opuesto al anterior, el Banco Central envía información al Banco de Estudio, un depósito o abono, el Sistema SPEI lo va a recibir de forma usual de acuerdo a las reglas estipuladas por el Banco Central, la diferencia es que ahora la solución de propuesta se deshace por completo de cualquier proceso manual, la recepción del pago es envuelto en un Mensaje de Recepción de Pago y enviado al Sistema Principal Bancario mediante un Canal Seguro, el Sistema Principal Bancario lo procesará y evaluará si causa una Devolución o no respondiendo al Sistema SPEI con un Mensaje de Confirmación de Pago el cual puede ser una confirmación simple de que el depósito o abono fue llevado a cabo exitosamente, si es motivo de una Devolución el Sistema Principal Bancario realizará dos cosas la primera reversará el depósito y generará un retiro, como segunda acción enviará dicha información a través del mensaje al sistema SPEI y este identificará el tipo de mensaje, el cual es una Devolución, y emitirá la orden de pago de tipo Devolución al Banco Central, el Mensaje de Confirmación de Pago se enviará de igual forma por un canal seguro. El punto de arribo como servicio se va a implementar aplicando el concepto de arquitectura de software SOA, enfocándonos en la integración de servicios entre el Sistema Principal Bancario y SPEI (ver Mensaje Envío de Pago ), en el punto de partida el sistema SPEI se encuentra vinculado con el Sistema Principal Bancario solamente por la intervención humana, esta es la interfaz que permite la comunicación entre ambos sistemas, en el punto de arribo se busca establecer un canal de comunicación directo. 102

107 Propuesta de Implementación A continuación se actualiza el diagrama de arquitectura de sistemas de nuestro nuevo punto de arribo. Sistema Principal Bancario Sistema de Pagos Electrónicos Interbancarios Aplicación Cliente Aplicación Servidor Conector con el Sistema Principal Bancario Procesamiento Transacciones Modulo de Conciliación Módulo de Concialiación Sistema de Transferencia de Archivos Oficina de Operaciones Gestor de STA Conciliación en línea Conciliación en línea Usuario de Operaciones Sistema Middleware Servicio Procesador Componente Web UI Figura Diagrama de arquitectura de sistemas de nuestro nuevo punto de arribo, eliminación de sistemas innecesarios Con base en el análisis técnico llevado a cabo en el punto anterior, a continuación se identifican y describen los puntos de oportunidad que proporcionaran al negocio una plataforma integral, eficaz, eficiente, económica y segura. Flujo homogéneo en sentido opuesto. El primer punto de oportunidad consiste en establecer un flujo de operación homogéneo tanto para transacciones de salida como transacciones de entrada, esta oportunidad de mejora se puede llevar a cabo debido a que el emisor y receptor de las transacciones es el mismo, por lo cual los canales de comunicación entre un sistema y el otro deben ser homogéneos, no necesariamente el mismo pero si respetar un protocolo de comunicación común el cual garantice la integridad de la transacción. En la figura siguiente se muestra el flujo de un envío de pago y su correspondiente confirmación. 103

108 Figura Proceso de Recepción de Pago, Punto de Arribo, flujo homogéneo De igual forma el sentido opuesto, la Recepción de Pago se muestra la misma conectividad en línea entre los dos sistemas mencionados. 104

109 Propuesta de Implementación Figura Proceso de Recepción de Pago, Punto de Arribo, flujo homogéneo en sentido opuesto Es importante mencionar que con esta mejora los siguientes componentes de la arquitectura original ya no están en el alcance de la solución: Sistema de Transferencia de Archivos. Sistema Middleware Conciliación Sistemática y Controlada En el proceso actual existen varios puntos de control manual, debido a que el procesamiento de transacciones actuales se lleva a cabo de forma prácticamente separada y pasa por diversos sistemas, es necesario conciliar la operación diariamente de forma manual, debido al tipo de información sensibilidad de la misma y su volumen el riesgo de cometer un error o hacer mal uso de la misma es muy alto, de aquí que al poner los dos principales sistemas en línea surge la oportunidad de mejorar los procesos de conciliación, al momento de no requerir más la participación de sistemas intermediarios los puntos de control se resumen en dos: 105

110 Sistema Principal Bancario SPEI Cada sistema al estar en línea proporcionará reportes de conciliación de las correspondientes transacciones llevadas a cabo en cada uno, de tal forma que el usuario será capaz de consultar en línea cada reporte de cada sistema bajo las mismas especificaciones, facilitando enormemente el proceso de conciliación. Procesamiento En Línea Algo que es muy importante mencionar es que al tener los dos principales sistemas en línea el negocio ya no depende de temporizadores o servicios bajo un esquema de horarios para poder: Capturar, Procesar y Enviar una simple transacción al Banco Central, esto será en línea lo cual significa al momento de capturar la transacción en el Sistema Principal Bancario esta se procesa y envía al instante al Banco Central. Validar información sensible como cuentas válidas y formatos de número de cuentas, al estar en línea tanto el Sistema Principal Bancario como el SPEI validarán al instante la integridad y veracidad de la información. Conciliar la operación, al estar en línea la operación y su conciliación se puede llevar a cabo en cualquier momento por el negocio sin depender de temporizadores ni horarios. Análisis y aclaraciones, así como la conciliación estas actividades se pueden llevar a cabo en el momento requerido dando un mejor y puntual servicio al cliente. Figura Procesamiento de pagos electrónicos interbancarios en línea 106

111 Propuesta de Implementación Procesamiento de Pagos Seguro y Confiable El hecho de estar en línea no solo nos ahorra tiempo, también está la oportunidad de mitigar riesgos de carga manual de archivos planos con transacciones electrónicas. En el proceso actual para el flujo de Envío de Pagos es necesario que la oficina de operaciones cargue de forma manual un archivo plano lo cual es de alto riesgo desde la simple oportunidad de manipulación y alteración del archivo original hasta una falta de atención y coordinación omitiendo archivos que deben ser cargados lo cual ocasionaría una falta en la conciliación, esto no se detectaría hasta el final del día operativo. La oportunidad de mejora consiste en omitir este proceso del negocio, las transacciones se enviarán sistemáticamente de forma segura y confiable de un sistema a otro mitigando al cien por cien los riesgos anteriormente mencionados. Técnicamente hablando la información se puede asegurar transmitiéndola por un canal seguro y/o encriptando los datos. Figura Procesamiento de pagos actual no es seguro ni confiable 107

112 Reducción del Tiempo de Procesamiento Otro punto de oportunidad es el hecho de que el tiempo requerido para poder enviar y/o recibir una transacción se puede reducir de minutos a segundos, de hecho se puede garantizar un volumen de hasta 240 transacciones en fila en un máximo de tiempo de 30 segundos por ejemplo (considerando todas las validaciones y procesos requeridos por sistema), debido a que la comunicación se realizará en línea se puede solicitar al Sistema Principal Bancario la exposición de servicios que funcionen de forma multi hilo lo cual permitirá al SPEI no enviar transacciones de una en una si no en tuplas, lo cual podría significar el procesamiento por ejemplo de 8 transacciones simultaneas en menos de un segundo, si estas tuplas se encolaran por segundo en 30 segundos estaríamos enviando 240 transacciones, de momento estas cifras son demostrativas pero muy cercanas a la realidad. El negocio actualmente, como ya se menciono le toma alrededor de 1 hr. enviar a Banco Central un conjunto no mayor a 30 transacciones debido a los procesos dependientes de temporizadores, horarios y procesos manuales. Aprovechar esta oportunidad posicionaría competitivamente al negocio de forma significativa. Mejor Servicio y Atención al Cliente El cliente ya no tendría por qué esperar alrededor de 1 hora para poder ver los resultados efectivos de su transacción tanto de envío como de recepción, esto por supuesto es una mejora en el servicio y atención al cliente, adicionalmente permitiría al negocio a invertir este tiempo en otras actividades que proporcionen más atención, calidad e incluso mejoras en procesos internos, el hecho de tener un sistema en línea no significa que la gente involucrada ya no sea necesaria, significa que el esfuerzo de estas personas pueden enfocarse en asuntos más propositivos y que sigan aportando beneficios a la empresa con esto se cumple la filosofía ganar ganar. Escalabilidad La oportunidad de implementar una solución en línea mediante la técnica de sistemas basados en arquitecturas SOA (servicios orientados a aplicaciones) nos permite tener la ventaja de mejorar continuamente de forma conjunta y/o independiente de los sistemas involucrados, sin importar que el Sistema Principal Bancario este en una tecnología y el SPEI en otra ambos pueden actualizarse sin impactar al otro, incluso la completa migración de tecnología de cualquiera de los dos es transparente para el otro. 108

113 Propuesta de Implementación 4.3 Plan de Trabajo Como breve introducción en esta sección se planteará un plan de trabajo de forma genérica para un proyecto que implemente una solución tecnológica enfocada a sistemas distribuidos, algunos aspectos pueden variar de empresa en empresa o escenarios Principales participantes del Proyecto detalle A continuación se presentan los principales participantes del proyecto, los grupos de trabajo y roles pueden variar de escenario en escenario (empresa en empresa) en esta propuesta genérica se pretende hacer mención de aquellos participantes que en su correspondiente equivalencia son críticos y los mínimos requeridos en un proyecto de esta índoles. Patrocinadores. Aquellos participantes que proporcionaran los recursos económicos y humanos para que se lleve a cabo el proyecto, el tipo de información que les interesa es de un alto nivel, pero con el detalle del costo beneficio del proyecto. Pueden ser directores, vicepresidentes principalmente del lado del negocio encargado de la operación de pagos electrónicos interbancarios o el área que se beneficia por el uso de dichos servicios. No se menciona el área de tecnologías ya que esta es la que busca el patrocinador por parte del negocio beneficiado con esta iniciativa. Beneficiados e impactados. Son los participantes que dan seguimiento al proyecto en los puntos clave milestones del proyecto, el representante o personal asignado al proyecto por parte del área debe estar informado de manera constante, por lo general de forma semanal en juntas de estatus sobre el proyecto, los beneficiados son tanto el área operativa como el área de que ofrece los servicios SPEI a los clientes, los impactados son aquellos que debido al cambio y mejora en los procesos tanto sistemáticos como de negocio se ven impactados en menor o mayor grado, inicialmente son identificados y se les debe pedir una evaluación de impacto con el fin de determinar si es requerida su participación y seguimiento en el proyecto debido al impacto y considerar en el diseño de la solución la correspondiente a la mitigación del impacto o que el participante impactado tome las debidas precauciones y acciones. Los grupos de trabajo involucrados terceros inclusive. A continuación se hace mención de aquellos grupos de trabajo que mínimamente deben participar en el proyecto. Grupo de Trabajo Roles Actividades Desarrollo de Proyectos Tecnológicos Gerente TI Analista TI Administrador de TI Análisis y Administración de proyectos TI. Tecnologías Arquitecto de Tecnologías de Análisis técnico, Análisis de costos tecnológicos, Planeación tecnológica, 109

114 la Información Documentación Técnica, Certificaciones Procesos de Evaluación, Diseño de la Arquitectura de la Solución TI. Infraestructura Ingeniero de infraestructura Construcción de ambientes de pruebas y producción, servidores, configuración, balanceadores, solicitudes de servicios técnicos. Comunicaciones Redes y Seguridad Equipo Técnico Sistema Principal Bancario y SPEI Estándares y Protocolos de TI Ingeniero de Comunicaciones Redes y Seguridad Analista Desarrollador Analista y Diseñador Configuración de la Red, registro de nodos, servidores, balanceadores, mapeo de accesos de red. Análisis de requerimientos y diseño de la solución tecnológico así como el desarrollo de dicha solución en el sistema principal bancario. Análisis de requerimientos de comunicación entre sistemas y diseño del protocolo de comunicación con base en estándares corporativos. Calidad y Pruebas Recursos de Calidad y Pruebas Gestión, planeación y ejercicio de evaluación de requerimientos, casos de prueba, riesgos, controles de mitigación asegurando Negocio Analista y Experto de procesos Validador Seguimiento y validación de la solución en relación al cumplimiento de los objetivos del proceso del negocio Tabla Principales participantes del proyecto, detalle Proveedores. Aquellos participantes que con anticipación deben ser contactados y solicitados los servicios y/o productos que el proyecto va a necesitar, deben contactarse con anticipación planeada con el fin de evitar retrasos por entrega de servicios y/o productos como servidores, balanceadores de carga, switches, paquetes de software, otros. Usuarios. Aquellos participantes que llevarán a cabo las pruebas de usuario en el correspondiente ambiente de pruebas justo antes de pasar a producción las mejoras desarrolladas. Estos usuarios por lo general son los expertos en el proceso o sistema usado para la operación de pagos electrónicos interbancarios, son asignados por el representante del área del negocio impactada. 110

115 Propuesta de Implementación Responsables del proyecto como un todo. Aquellos participantes del proyecto que de inicio a fin están involucrados en el proyecto, en todas las fases tienen tareas asignadas, responsabilidades y son elementos clave para el cumplimiento y éxito del proyecto en tiempo y forma Alcance del Proyecto Dentro del Alcance Alcance del Proyecto Sistematizar y Automatizar procesos manuales Reducir tiempos de procesos del negocio Seguridad y optimización de transaccionalidad Proveer una ventaja competitiva al negocio Alcance Organizacional Desarrollo de Proyectos TI Arquitectura TI Negocio Área del banco operacional Negocio Área del banco servicios al cliente Negocio Área de regulaciones legales Proveedores Alcance Funcional Envío y Recepción de Pagos electrónicos interbancarios totalmente en línea, automático, seguro y persistente entre los sistemas principales: Sistema Principal Bancario y SPEI Decomiso de sistemas y procesos no necesarios y de alto coste para el negocio como consecuencia de la implementación del proyecto Línea de Tiempo Todo proyecto tiene una fecha de inicio y una de fin, para fines genéricos y ejemplificativos se tomara proporcionara un estimado de tiempo para un proyecto de esta índole, de acuerdo a cada empresa y sus procesos internos de aprobaciones, asignación de recursos y solicitudes de servicios los tiempos pueden variar. Considerando meses de 30 días a continuación se tiene: 111

116 Fase Estimación Fecha Inicial Estimación Fecha Final Conceptualización Mes 1 día 1 año 1 Mes 1 día 10 año 1 Definición Mes 1 día 11 año 1 Mes 1 día 26 año 1 Análisis Mes 1 día 27 año 1 Mes 2 día 30 año 1 Diseño Mes 3 día 1 año 1 Mes 3 día 20 año 1 Construcción Mes 3 día 21 año 1 Mes 4 día 1 año 1 Pruebas Mes 4 día 2 año 1 Mes 4 día 22 año 1 Capacitación a Usuarios Mes 4 día 23 año 1 Mes 4 día 30 año 1 Capacitación a Soporte Técnico Mes 4 día 23 año 1 Mes 4 día 30 año 1 Pase a producción Mes 5 día 1 año 1 Mes 5 día 3 año 1 90 Días de Garantía Mes 5 día 1 año 1 Mes 8 día 30 año 1 Tiempo Inicio - Fin Mes 1 día 1 año 1 Mes 5 día 3 año 1 Tabla Línea de Tiempo Costo Beneficio El costo beneficio presentado a continuación se encuentra en una forma de ejemplo por lo cual no se consideraran términos monetarios específicos. Costo Invertir una suma importante de dinero en el desarrollo requerido en los sistemas involucrados. Beneficio El hecho de no estar conectados en línea los dos principales sistemas involucrados en el proceso de pagos electrónicos interbancarios, implica requerir el uso de sistemas de transferencia de archivos, un sistema intermediario que procese la información del Sistema 1 para generar una salida procesable para el Sistema 2, así como la aportación correspondiente ya sea anual o 112

117 Propuesta de Implementación mensual del costo por mantenimiento de estos sistemas adicionales. El Beneficio de la inversión es que hoy se invierte por ejemplo 1 año de costos de proceso y mantenimiento y partir del inicio del segundo año aproximadamente se estarían recibiendo los resultados del proyecto, ahorro en mantenimiento, ahorro en recursos dedicados a la conciliación y monitoreo de los diferentes puntos de vulnerabilidad y más demanda del servicios de pagos electrónicos interbancarios por parte de los clientes lo que significa mayor ingreso por comisión. Un ahorro en futuros requerimientos regulatorios (por ley) debido a la fácil escalabilidad de la arquitectura de las solución, colocación competitiva en el mercado debido a que la mayoría de la banca ya cuenta con una solución en línea, posibilidad de buscar otros servicios tecnológicos al cliente que generen ingresos a la empresa. Se reducen riesgos innecesarios, los procesos manuales estarían prácticamente decomisados, el proceso de conciliación y obtención de información sería al instante que se requiera dando la facilidad de reacción oportuna y rápida ante eventualidades. Invertir en profesionales especializados como Administración de Proyectos, Analistas y Arquitectos de TI El beneficio de requerir los servicios profesionales especializados radica en el alto porcentaje de éxito en el proyecto, gente con experiencia y vasto conocimiento en su área permitirá darle fluidez a la correcta toma de decisiones durante las diversas fases del proyecto, desde la definición puntual de los requerimientos, un análisis estructurado, segmentado, claro y amplio sobre el proyecto, un diseño eficaz, optimo, seguro, escalable y económico hasta el pase a producción preciso garantizando el inicio operacional con la mínima posibilidad de presentar defectos. Tabla Costo Beneficio 113

118 4.3.5 Requerimientos Puntuales El presente trabajo se enfoca en el diseño de la solución que cubra los siguientes requerimientos a alto nivel. No. Requerimiento del Negocio Prioridad 1 Habilidad de los sistemas: Sistema Principal Bancario, Sistema SPEI de establecer una interfaz de comunicación con la cual puedan enviar y recibir mensajes seguros entre los dos con la capacidad de identificar cada mensaje procesado. 2 Habilidad del Sistema principal Bancario de enviar pagos electrónicos interbancarios de salida (retiros y devoluciones de pagos de entrada inválidos) sin la intervención de un sistema intermediario, middleware estableciendo comunicación directa con el sistema SPEI el envío de pagos electrónicos bancarios desde el Sistema principal bancario hasta su procesamiento en el sistema SPEI debe ser menor a los 30 segundos, efectuando las correspondientes validaciones. 3 Habilidad del Sistema SPEI de enviar pagos electrónicos interbancarios de entrada (depósitos y devoluciones de pagos de salida inválidos) al sistema principal bancario en línea y sin intervención manual, así como el sistema principal bancario ser capaz de efectuar dicho depósito automáticamente y con las respectivas validaciones. 4 Habilidad de ambos sistemas de manejar diferentes estados de la transacción correspondiente a los pagos electrónicos interbancarios ya sea de salida o de entrada, por ejemplo: pendiente, completada, confirmada, rechazada, error y descripción. 5 Habilidad del Sistema principal bancario y SPEI de proporcionar en línea un reporte de conciliación y seguimiento de las transacciones llevadas a cabo durante el día así como la posibilidad de obtener un reporte histórico. 6 Habilidad del Sistema principal bancario y SPEI de trabajar en un esquema de alta disponibilidad con base en la implementación de un balanceador de cargas. Alta Alta Alto Alto Medio Medio Tabla Requerimientos Puntuales 114

119 Propuesta de Implementación 4.4 Arquitectura SOA. Como se menciono en el Capítulo 2 sección 2 los sistemas distribuidos tienen diversos desafíos: heterogeneidad, extensibilidad, seguridad, escalabilidad, tratamiento de fallos, concurrencia, transparencia, independencia de locación, balance de cargas computacionales e implementación. A continuación se presentará la propuesta de la Arquitectura de nuestro Sistema Distribuido para nuestro objeto de estudio. Como se ha analizado el banco en estudio busca poder tener un servicio de pagos electrónicos inter bancarios más abierto y automático, altamente escalable, por lo cual la arquitectura que mejor se adecua es la orientada a servicios SOA. Algunos racionales que fundamentan esta elección son que SOA permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros Análisis de Software y Hardware Entrando de lleno en el estudio de la solución al establecimiento de la comunicación directa entre el Sistema Principal Bancario y el Sistema SPEI tenemos los siguientes datos: Haciendo referencia al punto del presente trabajo las Capas del Software son: Sistema Principal Bancario Cuenta con dos servidores en ambiente de producción y ambiente de pruebas se encuentra en un determinado segmento de red que llamaremos A. Sistema SPEI Cuenta con un solo servidor en ambiente de producción y un servidor en ambiente de pruebas, se encuentra en el segmento de red que llamaremos B. Sistema Operativo Windows Server 2003 Sistema Operativo Windows Server 2003 Su Middleware es un sistema MQ series de IBM, se usa de forma local. Aplicación de Servicios, actualmente no tiene una interfaz directa con el sistema SPEI por lo cual el proceso es manual. Software desarrollado en Microsoft.Net Motor de Base de Datos MSSQL Utiliza una herramienta llamada Tuxedo (Transactions for Unix, Extended for Distributed Operations) se utiliza para enviar transacciones al Banco Central. Aplicación de Servicios, actualmente no tiene una interfaz directa con el sistema el Sistema Principal Bancario por lo cual el proceso es manual. Software desarrollado en J2EE Motor de Base de Datos MSSQL Tabla Arquitectura y Tecnología de Sistemas Principal Bancario y SPEI 115

120 Durante la definición de una nueva arquitectura, en la vida real es necesario consultar y respetar los estándares de la organización, en este caso dependiendo la tecnología empleada el entorno debe ser acorde, por recomendaciones, mejores prácticas y compatibilidad, la que mejor encaje. Estándares de acuerdo al banco de estudio por sistema: Sistema Principal Bancario Estándar Sistema SPEI Estándar Microsoft.Net Si J2EE Sí Windows Server 2003 Si Windows Server 2003 No es estándar con J2EE, se debe utilizar Linux. Motor de Base de Datos MSSQL Middleware MQ Series Aplicación Cliente Desktop Si Motor de Base de Datos MSSQL No es estándar con J2EE, se debe utilizar Mainframe DB2 Si Middleware Tuxedo No es estándar se puede usar MQ Series o Web Services Si Servidor Web, Weblogic 8 No es estándar debe usarse Weblogic 10 Tabla Estándares de acuerdo al banco de estudio por sistema Con base en los estándares mencionados el sistema SPEI es el único que tiene observaciones, el punto de arribo quedaría así: Sistema Principal Bancario Microsoft.Net Windows Server 2003 Motor de Base de Datos MSSQL Web Services SOAP Sistema SPEI J2EE Linux Red Hat Mainframe DB2 Web Services SOAP Aplicación Cliente Desktop Servidor Web, Weblogic 10 Tabla Estándares de acuerdo al banco, observaciones Un punto sobresaliente ahora es el hecho de utilizar Web Services SOAP, los otros cambios llevados requeridos en el sistema SPEI principalmente no son mayor problema ya que solo es cuestión de: 116

121 Propuesta de Implementación SPEI en J2EE es una solución multiplataforma y que su instalación es transparente para el proveedor si es en un determinado sistema operativo u otro. El motor de base de datos es más robusto, mejor contención ante la demanda y de hecho las especificaciones del sistema SPEI por parte del proveedor indican que puede trabajar con Mainframe DB2 sin inconvenientes. La actualización del servidor web proporciona mejor estabilidad y servicios al sistema SPEI, la instalación y configuración debe ajustarse a la nueva plataforma esta actualización se tendría que hacer de forma obligatoria debido a que la versión previa ya no es soportada por el fabricante. Regresando a la observación de la implementación de SOAP, se propone esta tecnología por las siguientes razones: Cuando se hace uso de mensajes encolados como lo es RabbitMQ, ActiveMQ, IBM MQ Series, Tuxedo se esperan ciertos escenarios: Si el servidor llegara a fallar la cola persiste el mensaje (opcionalmente, incluso si la maquina se apaga). Cuando el servidor trabaja de nuevo, recibe los mensajes pendientes. Si el servidor proporciona una respuesta a una llamada de un cliente y este falla (el cliente), si el cliente no respondió el acuso de recibo el mensaje persiste. Con esta tecnología la contención es robusta, uno puede decidir cuantas peticiones son manejadas por el servidor. No se espera una respuesta síncrona. Cuando se hace uso de Servicios Web: Si el servidor falla el cliente tiene la responsabilidad de manejar el error. Cuando el servidor trabaja de nuevo, el cliente es responsable de reenviar el mensaje. Si el servidor da respuesta a una llamada de un cliente y si este falla, la operación se pierde. No se tiene mucha contención, si miles de clientes llaman al servicio expuesto en el servidor en un segundo, es muy probable que el servidor tenga problemas. Se puede esperar una respuesta inmediata desde el servidor. Dependiendo las necesidades de cada proyecto tanto uno como el otro son los convenientes, en este caso se propone servicios web, SOAP, con base en lo siguiente: Se cuenta con un catalogo de errores que el cliente puede manejar en este caso el sistema SPEI y el sistema Bancario debe adoptar. Con base en el punto anterior el cliente debe reenviar el mensaje. 117

122 No se precisa de mucha contención debido a que las llamadas no pasaran de 10 por segundo en peticiones multi hilo en ambos sentidos, son dos puntos de comunicación controlados, el sistema SPEI y el sistema principal bancario. Se necesita de una respuesta inmediata, una gran desventaja de la tecnología basada en colas es que el tiempo de respuesta por transacción es indefinido, y el tema central de este proyecto es tener control puntual de los tiempos de procesamiento de cada simple transacción, adicionalmente los volúmenes operados no sobrepasan las 500 transacciones diarias durante 12 hrs continuas. lo que nos permite explotar al máximo la característica de comunicación síncrona de los servicios web. La tecnología de servicios web no es tan compleja y robusta en términos de licencia y costos por lo que su implementación además de adaptarse técnicamente a las necesidades del proyecto se adapta a un ahorro en el presupuesto. Fácil de implementar y de escalar otra gran ventaja, adicionalmente otros participantes o interesados en los servicios web pueden consumir estos fácilmente con tan solo conocer la definición del mismo lo cual potencializa el servicio SPEI no solo a los clientes del banco si no también puede usarse para procesos de pagos internos, pagos a proveedores, servicios, etc Implementación SOA El sistema que se va a implementar está basado en la arquitectura SOA la cual esta orienta a servicios, en nuestro proyecto el servicio principal que se desea ofrecer es el pagos electrónicos interbancarios, nuestra implementación SOA considera todos los componentes que en conjunto proporcionan el servicio de envío y recepción de pagos electrónicos interbancarios al Banco en Estudio, a continuación se irá construyendo la arquitectura de nuestro sistema distribuido de lo general a lo particular. Implementación SOA - SPEI Figura Paquete Implementación SOA - SPEI Nuestra implementación para poder ser capaz de ofrecer dichos servicios necesita de la participación de dos sistemas: El Sistema Principal Bancario, encargado de la gestión de cuentas y productos del banco en estudio. 118

123 Propuesta de Implementación El Sistema SPEI, encargado de enviar y recibir pagos electrónicos interbancarios al Banco Central. Implementación SOA - SPEI Sistema Principal Bancario Sistema SPEI Figura Sub paquetes: Sistema Principal Bancario y Sistema SPEI En el Sistema Principal Bancario se encuentran los clientes a los cuales se les proporciona el servicio de pagos electrónicos interbancarios, los clientes cuentan con productos en los cuales se administra y controla sus recursos económicos. El SPEI tiene la funcionalidad de procesar pagos electrónicos de envío y recepción de acuerdo a las reglas de operación del Banco Central, sin embargo; necesita de los datos del cliente y producto a quien se le abonaran los recursos económicos o se le retiraran recursos económicos para poder llevar a cabo el pago electrónico interbancario. El Sistema Principal Bancario le indicará al Sistema SPEI: Envío: el cliente, la cuenta, el monto, el concepto de pago y la clave de rastreo principalmente. Recepción: si el cliente, la cuenta, el monto, el concepto de pago y la clave de rastreo son válidos y el proceso de abono es correcto. De lo anterior se identifica que es necesario establecer comunicación entre ambos sistemas, para poder establecer comunicación los siguientes elementos son necesarios: Fuente Emisor Receptor Código Mensaje Canal de Comunicación Iremos integrando cada uno de ellos paso a paso. Dependiendo de la situación el emisor puede ser el Sistema Principal Bancario y el receptor el Sistema SPEI y viceversa. La situación se define por el flujo del pago, si es envío el emisor será el Sistema Principal Bancario y el receptor el Sistema SPEI, si es recepción el emisor será el Sistema SPEI y el receptor el Sistema Principal Bancario. 119

124 4.4.3 Comunicación Sistema Principal Bancario Implementación SOA - SPEI Comunicación Sistema SPEI Figura Sub paquetes: Sistema Principal Bancario, Sistema SPEI y Comunicación Independientemente de la situación la comunicación entre emisor y receptor precisa primeramente de un código. El código es el conjunto de reglas propias de cada sistema de signos y símbolos de un lenguaje que el emisor utilizará para transmitir su mensaje, en nuestro caso el código que se propone es el protocolo SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar que define como dos objetos, Sistema Principal Bancario y Sistema SPEI; en diferentes procesos pueden comunicarse por medio de intercambio de datos XML, a diferencia de otros estándares de comunicación por mensajes (CORBA, RMI) se basa en documentos XML, por lo que resulta independiente de la tecnología y la plataforma (lenguaje, sistema operativo) subyacente, a continuación se integra la estructura SOAP. Servicio de Pagos Electrónicos Interbancarios COMUNICACIÓN Sistema Principal Bancario Sobre SOAP -Encabezado - Cuerpo Sistema SPEI Figura Sub Paquete Sobre SOAP anidado a Sub Paquete Comunicación A continuación se detalla la estructura de nuestro sobre SOAP explicando sección por sección, llevando a cabo la formación de nuestro mensaje. El mensaje SOAP se caracterizará por incluir namespaces que ayudarán a manejar las etiquetas de nuestra particular estructura XML, dependiendo de la empresa y si cuenta con un servicio de nombres de espacios se puede aprovechar para facilitar la generación e interpretación de los elementos de nuestro mensaje SOAP. Encabezado <SecurityHeader actor="next" mustunderstand="1" name="stdsecurityblk" majorversion="1" minorversion="0" xsi:schemalocation="http://www.bancodeestudio.com/spei/security/v10/types 120

125 Propuesta de Implementación WSSecurityHeaderV1.0.xsd" xmlns="http://www.bancodeestudio.com/spei/security/v10/types" xmlns:xsi="http://www.w2.org/2001/xmlschema-instance"> xsi:schemalocation: proporciona información de la ubicación de varios documentos XML, en nuestro caso nos proporciona la ubicación de un documento de definición de nuestro esquema. xmlns: espacios de nombre que son usados para proveer de forma única nombres de elementos y atributos para nuestro documento xml El encabezado en SOAP es opcional y contiene información específica del mensaje SOAP como autenticación, actores y espacios de espacios de contexto. Si el encabezado es usado debe ser el primer elemento hijo del sobre SOAP. Actor: el mensaje SOAP debe viajar de un remitente a un receptor pasando por diferentes puntos a lo largo de la ruta del mensaje, sin embargo; no todas las partes del mensaje SOAP son intencionados para todos los puntos, pueden ser para uno o más de los puntos a lo largo de la ruta del mensaje. El Actor SOAP es usado para direccionar el elemento del encabezado al punto especifico, en nuestro caso solo es un punto en particular y la información completa es intencionada a dicho punto por lo que el valor Next es el que usaremos, significando que el mensaje va dirigido al próximo punto. mustunderstand: este atributo puede ser usado para indicar si la entrada del encabezado es obligatoria u opcional para el receptor del proceso, si se especifica el valor 1 indica que el elemento debe ser reconocido por el receptor si este no lo reconoce fallara el procesamiento del elemento del encabezado. A continuación mostramos el cuerpo para ambos casos, la petición Request y su respuesta Response Cuerpo Request <ExecProcessSPEITransferWSRequest> Nodo principal del cuerpo de nuestro request. Encabezado de nuestro servicio para controlar el mensaje. <ServiceHeader> <OriginatorNm></OriginatorNm> Nombre del originador del mensaje ya sea el Sistema Principal Bancario o el Sistema SPEI. Nombre del servicio, ProcessSPEITransfer 121

126 <ServiceNm></ServiceNm> Versión mayor del servicio, 1. Versión menor del servicio, 0. > <SrvcMajVersionNbr></SrvcMajVersionNbr Flujo del mensaje colocaremos RR, request and response. > <SrvcMinVersionNbr></SrvcMinVersionNbr Referencia única de la petición útil para revisar problemas en producción. <MsgPatternTypeCd></MsgPatternTypeCd> Cuerpo del Request Tipo de solicitud útil para identificar el flujo: <ProcessControlId></ProcessControlId> </ServiceHeader> Del Sistema Principal Bancario al SPEI: TS - Transferencia de Salida <Request> <ReqType></ReqType> Del SPEI al Sistema Principal Bancario: AB - Acuse Banco Central RB - Rechazo Banco Central RP - Rechazo Participante TE - Transferencia de Entrada Control del mercado Mexico Fecha de Operación SOAP Clave de Rastreo 122

127 Propuesta de Implementación Código del Banco Emisor Código del Banco Receptor Tipo de pago SPEI Tipo de operación SPEI Importe IVA <MktCd></MktCd> <OperationDt></OperationDt> <TrackCd></TrackCd> <SendBankCd></SendBankCd> <ReceiverBankCd></ReceiverBankCd> <PayTypeCd></PayTypeCd> <OperationTypeCd></OperationTypeCd> <Amt></Amt> <ValAddedTax></ValAddedTax> Llave para cobro del Pago, válido para ciertos pagos SPEI donde el beneficiado necesita saber esta llave para hacer válido su pago. Referencia Numérica Código de Rechazo si aplica Descripción del Rechazo Tipo de Autorización usado por el SPEI para tener un control del flujo, si se envía inmediatamente al Banco Central o precisa de una autorización. Topología del Pago Prioridad del Pago <PayKey></PayKey> Detalles del emisor del Pago Nombre del emisor Tipo de cuenta del emisor Número de cuenta del emisor <NumericRef></NumericRef> RFC del emisor <RejectionCd></RejectionCd> <RejectionDesc></RejectionDesc> <AuthorizationType></AuthorizationType> Detalles del receptor Nombre del receptor Tipo de cuenta del receptor Número de cuenta del receptor 123

128 RFC del receptor Concepto del Pago <TopologyCode></TopologyCode> <PriorityCode></PriorityCode> <SendDtls> <SendNm></SendNm> <SendAcctTypeCd></SendAcctTypeCd> <SendAcctNbr></SendAcctNbr> </SendDtls> <SendNatId></SendNatId> <ReceiverDtls> <ReceiverNm></ReceiverNm> d> <ReceiverAcctTypeCd></ReceiverAcctTypeC <ReceiverAcctNbr></ReceiverAcctNbr> <ReceiverNatId></ReceiverNatId> </ReceiverDtls> <PayConcept></PayConcept> </Request> </ExecProcessSPEITransferWSRequest> 124

129 Propuesta de Implementación <ExecProcessSPEITransferWSResponse> Nodo principal de nuestro Response <ServiceHeader> Encabezado de nuestro servicio para controlar el mensaje. <OriginatorNm></OriginatorNm> Nombre del originador del mensaje ya sea el Sistema Principal Bancario o el Sistema SPEI. Nombre del servicio, ProcessSPEITransfer <ServiceNm></ServiceNm> Versión mayor del servicio, 1. Versión menor del servicio, 0. > <SrvcMajVersionNbr></SrvcMajVersionNbr Flujo del mensaje colocaremos RR, request and response. > <SrvcMinVersionNbr></SrvcMinVersionNbr Referencia única de la petición útil para revisar problemas en producción. <MsgPatternTypeCd></MsgPatternTypeCd> <ProcessControlId></ProcessControlId> </ServiceHeader> <Response> Cuerpo del Response Fecha de Operación SOAP Resultado después de que el proveedor del servicio proceso el mensaje: 0 Proceso exitoso 1 Proceso fallido Descripción del resultado: 0 Success 125

130 1 Failure <OperationDt></OperationDt> <StatusCd></StatusCd> Código de Error en caso de Falla y su descripción <StatusDesc></StatusDesc> <ErrorCd></ErrorCd> <ErrorDesc></ErrorDesc> </Response> </ExecProcessSPEITransferWSResponse> Tabla Estructura XML de Petición y Respuesta Servicio Web Para que este mensaje sea independiente de las partes hay que recordar la arquitectura que se está empleando la cual es una arquitectura SOA que está orientada a servicios, el código que queremos implementar debe ser entendido independientemente del lenguaje, sistema operativo, infraestructura de comunicaciones, etc. (desacoplamiento entre las partes) para lograr esto necesitamos de un estándar que ayude a describir el servicio, este estándar es el WSDL Web Services Definition Language es un lenguaje XML que permite caracterizar cuatro aspectos fundamentales de todo servicio: Conjunto de operaciones publicas que ofrece Información sobre los tipos de datos empleados Información sobre los protocolos de comunicación para acceso Localización física del servicio 126

131 Propuesta de Implementación SERVICIO - WSDL Implementación SOA - SPEI Sistema Principal Bancario Comunicación Sobre SOAP Encabezado Cuerpo Sistema SPEI Figura Delimitación Servicio Web A continuación se muestra el WSDL que será utilizado por nuestra arquitectura SOA. Definición de namespaces, como se menciono son útiles para identificar de forma única los elementos de nuestra estructura XML. <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions targetnamespace="http://www.americanexpress.com/spei/processspeitransfer/v10" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://www.bancodeestudio.com/spei/processspeitransfer/v10" xmlns:intf="http://www.bancodeestudio.com/spei/processspeitransfer/v10" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w2.org/2001/xmlschema"> Sección donde se definen los tipos de datos de nuestra descripción del servicio web. Esta sección define los tipos de datos usados en los mensajes. Se utilizan los tipos definidos en la especificación de esquemas XML, en nuestro caso se incluirá en un XSD, XML Schema Definition, que nos muestra la definición de los elementos requeridos por el mensaje SOAP tanto para el Request como para el Response. En esta sección se abarcan los elementos del cuerpo SOAP que se detallaron anteriormente. <wsdl:types> <schema targetnamespace="http://www.americanexpress.com/spei/processspeitransfer/v10" xmlns="http://www.w2.org/2001/xmlschema"> <element name="execprocessspeitransfer"> <complextype> 127

132 <sequence> <element name="execprocessspeitransferwsrequest" type="xsd:string"/> </sequence> </complextype> </element> <element name="execprocessspeitransferresponse"> <complextype> <sequence> <element name="execprocessspeitransferwsresponse" type="xsd:string"/> </sequence> </complextype> </element> </schema> </wsdl:types> En la sección de mensaje, message ; definimos los elementos de mensaje. Cada mensaje puede consistir en una serie de partes lógicas. Las partes pueden ser de cualquiera de los tipos definidos en la sección anterior. En nuestro caso tenemos la parte de petición: ExecProcessSPEITransferRequest y parte de respuesta: ExecProcessSPEITransferResponse <wsdl:message name="execprocessspeitransferresponse"> name="parameters"> <wsdl:part element="impl:execprocessspeitransferresponse" </wsdl:part> </wsdl:message> <wsdl:message name="execprocessspeitransferrequest"> <wsdl:part element="impl:execprocessspeitransfer" name="parameters"> </wsdl:part> </wsdl:message> 128

133 Propuesta de Implementación En el siguiente apartado porttype definimos las operaciones permitidas y los mensajes intercambiados en el Servicio. Nosotros tenemos el mensaje de petición: ExecProcessSPEITransferRequest y el mensaje de respuesta: ExecProcessSPEITransferResponse así como la operación que gestionará dichos mensajes: ExecProcessSPEITransfer también definida en nuestra estructura SOAP. <wsdl:porttype name="iprocessspeitransfer"> <wsdl:operation name="execprocessspeitransfer"> <wsdl:input message="impl:execprocessspeitransferrequest" name="execprocessspeitransferrequest"> </wsdl:input> <wsdl:output message="impl:execprocessspeitransferresponse" name="execprocessspeitransferresponse"> </wsdl:operation> </wsdl:porttype> </wsdl:output> Especificamos los protocolos de comunicación usados, tendremos un estilo de mensaje SOAP del tipo documento el cual nos permite validar el mensaje con cualquier validador XML, todo lo que está dentro del cuerpo SOAP (soap:body) está definido en nuestro esquema que presentaremos a continuación, algunas características de este estilo son: el mensaje tiene una simple parte lógica, esta parte lógica contiene un elemento, el elemento tiene tipos de datos complejos y los tipos de datos por elemento se describen en el esquema de definición XML. <wsdl:binding name="processspeitransferportsoapbinding" type="impl:iprocessspeitransfer"> <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="execprocessspeitransfer"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="execprocessspeitransferrequest"> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output name="execprocessspeitransferresponse"> <wsdlsoap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> 129

134 En la sección de servicio, service ; tenemos el conjunto de puertos y dirección de los mismos. Esta parte final hace referencia a lo aportado por las secciones anteriores. Esta sección es útil para definir la dirección puntual del servicio expuesto. <wsdl:service name="processspeitransfer"> <wsdl:port binding="impl:processspeitransferportsoapbinding" name="processspeitransferport"> <wsdlsoap:address location="https://central681.gso.aexp.com:7004/appspeihostws/services/processspeitransferport"/> </wsdl:port> </wsdl:service> </wsdl:definitions> Finalmente para tener la descripción de nuestro servicio web completa hace falta integrar la definición del esquema XML del mensaje SOAP, esta descripción es útil para que cualquier interesado en consumir los servicios expuestos de pagos electrónicos interbancarios pueda saber cómo está formado el mensaje SOAP, la operación principal sus mensajes y sus datos involucrados, de aquí que se integra el siguiente XSD. Implementación SOA - SPEI Sistema Principal Bancario SERVICIO - WSDL XSD Comunicación Sobre SOAP Encabezado Cuerpo Sistema SPEI Figura Delimitación Servicio Web, WSDL y XSD A continuación se muestra la estructura de nuestro documento que define el esquema de datos XML. Versión del documento <?xml version="1.0" encoding="utf-8"?> Esquemas y namespaces <s:schema xmlns:s="http://www.w2.org/2001/xmlschema" xmlns:tns="http://www.americanexpress.com/spei/processspeitransfer/v10/types" 130

135 Propuesta de Implementación targetnamespace="http://www.americanexpress.com/spei/processspeitransfer/v10/types" elementformdefault="qualified"> Elemento de Petición del WSDL ExecProcessSPEITransferWSRequest se detallan los elementos requeridos por SOAP y sus tipos de datos, los elementos se pueden conciliar con el mensaje SOAP que se armó previamente. En nuestro esquema tenemos el elemento del mensaje SOAP ExecProcessSPEITransferWSRequest que se define en el mismo namespace por el tipo complejo tns:execprocessspeitransferwsrequesttype. <s:element name="execprocessspeitransferwsrequest" type="tns:execprocessspeitransferwsrequesttype"/> A continuación se muestra el detalle del tipo complejo tns:execprocessspeitransferwsrequesttype como se puede observar el tipo complejo tiene una secuencia de elementos que corresponden al encabezado y la petición de nuestro mensaje SOAP, estos elementos son complejos también. <s:complextype name="execprocessspeitransferwsrequesttype"> <s:sequence> <s:element ref="tns:serviceheader"/> <s:element ref="tns:request"/> </s:sequence> </s:complextype> De forma similar se detallan los elementos incluidos en el tipo de dato complejo del elemento referente a la petición de nuestro mensaje SOAP que a su vez se detallan en otro tipo de dato complejo adjunto también. Encabezado <s:element name="serviceheader" type="tns:serviceheadertype"/> <s:complextype name="serviceheadertype"> <s:sequence> 131

136 <s:element name="originatornm" type="s:string"/> <s:element name="servicenm" type="s:string"/> <s:element name="srvcmajversionnbr" type="s:string"/> <s:element name="srvcminversionnbr" type="s:string"/> <s:element name="msgpatterntypecd" type="s:string" minoccurs="0"/> <s:element name="processcontrolid" type="s:string" minoccurs="0"/> </s:sequence> </s:complextype> Petición <s:element name="request" type="tns:requesttype"/> <s:complextype name="requesttype"> <s:sequence> <s:element name="reqtype" type="s:string" minoccurs="0"/> <s:element name="mktcd" type="s:string" minoccurs="0"/> <s:element name="operationdt" type="s:string"/> <s:element name="trackcd" type="s:string"/> <s:element name="sendbankcd" type="s:string"/> <s:element name="receiverbankcd" type="s:string"/> <s:element name="paytypecd" type="s:string" minoccurs="0"/> <s:element name="operationtypecd" type="s:string" minoccurs="0"/> <s:element name="amt" type="s:string"/> <s:element name="valaddedtax" type="s:string" minoccurs="0"/> <s:element name="paykey" type="s:string" minoccurs="0"/> <s:element name="numericref" type="s:string"/> <s:element name="collectionref" type="s:string" minoccurs="0"/> <s:element name="rejectioncd" type="s:string"/> 132

137 Propuesta de Implementación <s:element name="rejectiondesc" type="s:string"/> <s:element name="authorizationtype" type="s:string" minoccurs="0"/> <s:element name="topologycode" type="s:string" minoccurs="0"/> <s:element name="prioritycode" type="s:string" minoccurs="0"/> <s:element name="senddtls" type="tns:senddtlstype"/> <s:element name="receiverdtls" type="tns:receiverdtlstype"/> </s:sequence> </s:complextype> Al observar a detalle en la secuencia de elementos que integran la petición hay dos elementos con tipos de datos complejos, SendDtls y ReceiverDtls. <s:complextype name="senddtlstype"> <s:sequence> <s:element name="sendnm" type="s:string"/> maxoccurs="unbounded"/> <s:element name="sendaccttypecd" type="s:string" <s:element name="sendacctnbr" type="s:string"/> <s:element name="sendnatid" type="s:string"/> </s:sequence> </s:complextype> <s:complextype name="receiverdtlstype"> <s:sequence> <s:element name="receivernm" type="s:string"/> <s:element name="receiveraccttypecd" type="s:string"/> <s:element name="receiveracctnbr" type="s:string"/> <s:element name="receivernatid" type="s:string"/> <s:element name="payconcept" type="s:string"/> </s:sequence> 133

138 </s:complextype> Elemento de Respuesta del WSDL ExecProcessSPEITransferWSResponse se detallan los elementos requeridos por SOAP y sus tipos de datos, los elementos se pueden conciliar con el mensaje SOAP que se armó previamente. En nuestro esquema tenemos el elemento del mensaje SOAP ExecProcessSPEITransferWSResponse que se define en el mismo namespace por el tipo complejo tns:execprocessspeitransferwsresponsetype. <s:element name="execprocessspeitransferwsresponse" type="tns:execprocessspeitransferwsresponsetype"/> A continuación se muestra el detalle del tipo complejo tns:execprocessspeitransferwsresponsetype como se puede observar el tipo complejo tiene una secuencia de elementos que corresponden a la respuesta de nuestro mensaje SOAP, estos elementos son complejos también, como observación el encabezado al ser del mismo tipo no es necesario crear otro, se reutiliza el ya definido. <s:complextype name="execprocessspeitransferwsresponsetype"> <s:sequence> <s:element ref="tns:serviceheader"/> <s:element name="response" type="tns:processspeitransferwsresponsepart" minoccurs="0"/> </s:complextype> </s:sequence> De forma similar se detallan los elementos incluidos en el tipo de dato complejo del elemento referente a la respuesta de nuestro mensaje SOAP. <s:complextype name="processspeitransferwsresponsepart"> <s:sequence> <s:element name="operationdt" type="s:string"/> <s:element name="statuscd" type="s:string"/> 134

139 Propuesta de Implementación <s:element name="statusdesc" type="s:string"/> <s:element name="errorcd" type="s:string" minoccurs="0"/> <s:element name="errordesc" type="s:string" minoccurs="0"/> </s:sequence> </s:complextype> Finalmente cerramos nuestra definición del esquema XML. </s:schema> Esquema de Seguridad Tenemos hasta este punto el emisor, el receptor, el código, la estructura del mensaje y la descripción del servicio ofrecido mediante esta comunicación así como la definición de nuestro esquema de datos, el siguiente paso es determinar el canal de comunicación, el canal de comunicación es el medio de transmisión por el que viajará el mensaje portador de la información. En nuestro caso como se podrá ir asumiendo debido a la definición de nuestro código SOAP, el canal de comunicación será el protocolo HTTPS, el sistema HTTPS utiliza un cifrado basado en SSL/TLS para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP. De este modo se consigue que la información sensible (usuario y claves de paso normalmente) no pueda ser usada por un atacante que haya conseguido interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá será un flujo de datos cifrados que le resultará imposible de descifrar. Para preparar un servidor web que acepte conexiones HTTPS, el administrador debe crear un Certificado de clave pública para el servidor web. Este certificado debe estar firmado por una Autoridad de certificación para que el navegador web lo acepte. La autoridad certifica que el titular del certificado es quien dice ser. El administrador del servidor de cada sistema es responsable de adquirir el certificado que se utilizará para asegurar el canal de comunicación y distribuirlo a la contra parte. Aquí se identifican acciones importantes para el equipo de infraestructura: El equipo de infraestructura debe instalar el certificado que identifica así mismo el servidor del Sistema Principal Bancario. El equipo de infraestructura debe instalar el certificado que identifica al servidor del Sistema SPEI El equipo de infraestructura debe instalar el certificado que identifica así mismo el servidor del Sistema SPEI. 135

140 El equipo de infraestructura debe instalar el certificado que identifica al servidor del Sistema Principal Bancario. Si alguna de las acciones anteriores no se hace, la comunicación y por ende consumo del servicio no se llevará a cabo. Implementación SOA - SPEI SERVICIO - WSDL XSD Sistema Principal Bancario Comunicación Sobre SOAP Encabezado Cuerpo Sistema SPEI Figura Seguridad Integrada en Sub Paquetes Hasta este punto ya tenemos definida como se dará la interacción entro nuestros dos sistemas, cada uno de ellos ya sabe cuáles son los datos requeridos, el código que se utilizará, la estructura del mensaje y su canal de comunicación definiendo su correspondiente seguridad cubriendo la confianza requerida por SOA Balance de Carga, alta disponibilidad El siguiente paso es proveer esa efectividad que nuestra arquitectura SOA sugiere en todo servicio provisto, esto se puede cubrir implementando un esquema de alta disponibilidad para nuestro servicio. La disponibilidad es el grado en que una aplicación o servicio está disponible cuándo y cómo los usuarios esperan. La disponibilidad se mide por la percepción de una aplicación del usuario final. Los usuarios finales experimentan frustración cuando sus datos no están disponibles, y ellos no entienden o son capaces de diferenciar los complejos componentes de una solución global. La importancia de la alta disponibilidad varía dependiendo de las aplicaciones. Sin embargo, la necesidad de aumentar los niveles de disponibilidad continúa acelerándose tanto como las empresas rediseñan sus soluciones para conseguir una ventaja más competitiva. La mayoría de las veces estas 136

141 Propuesta de Implementación nuevas soluciones se basan en el acceso inmediato a datos críticos para el negocio. Cuando los datos no están disponibles, la aplicación puede dejar de funcionar. El tiempo de inactividad o caída del sistema, puede conducir a pérdida de productividad, pérdida de ingresos, dañando las relaciones con los clientes, la mala publicidad, y pleitos. Si una aplicación con tarea crítica no está disponible, entonces la empresa se encuentra en peligro. La alta disponibilidad que se propone para el banco en estudio es la implementación de una réplica de servicios los cuales se podrán evaluar implementando un balanceador de cargas. Actualmente el Sistema Principal Bancario ya cuenta con un esquema de replicación de servicios de aplicación, el sistema SPEI por su lado no lo cuenta, por lo que se requiere un servidor que sirva de réplica en el cual se instalaran los servicios expuestos. El balanceador de cargas determina a que nodo se deben enviar los mensajes dependiendo de la respuesta de cada nodo a la pregunta estás vivo? Are you alive? por defecto se determinará al nodo 1 como el nodo maestro en ambos casos. Implementación SOA - SPEI Sistema Principal Bancario Nodo1 SERVICIO - WSDL XSD Comunicación Sobre SOAP Encabezado Cuerpo Sistema SPEI Nodo 1 Sistema Principal Bancario Nodo 2 Sistema SPEI Nodo 2 Figura Implementación de Balanceadores El balanceador de cargas debe ser configurado por el equipo tecnológico correspondiente por ejemplo el de infraestructura, los esquemas de alta disponibilidad pueden ser de las siguientes formas: Replicación Pasiva o Activo/Pasivo. En este esquema cada instante existe un único gestor de réplicas primario y uno o más gestores de réplicas secundarios (respaldos o esclavos). Replicación Activa o Activo/Activo. Los gestores son máquinas de estado que desempeñan papeles equivalentes y se organizan como un grupo. Los frontales multi-difunden sus peticiones al grupo de gestores de replicas y todos los gestores de replicas procesan la petición de forma independiente, pero idéntica, y responden. Si cae cualquier gestor de replicas, no tiene necesariamente impacto en las prestaciones del servicio, puesto que los restantes gestores de replicas continúan respondiendo de la forma habitual. 137

142 En nuestra propuesta trabajaremos con una Replicación Pasiva, en la cual cuando un cliente solicita que se realice una operación la secuencia de eventos es la siguiente: Petición: el frontal lanza la petición, que contiene un identificador único, al gestor de réplicas primario. Coordinación: el primario acepta cada petición de forma atómica, en el orden en que las recibe. Comprueba el identificador único y, en el caso en el que ya hubiera ejecutado la petición, simplemente reenvía la respuesta. Ejecución: el primario ejecuta la petición y guarda la respuesta. Acuerdo: si la petición es una actualización, entonces el primario envía a todas las copias de seguridad el estado actualizado, la respuesta y el identificador único. Los respaldos envían, a su vez, un acuse de recibo. Respuesta: el primario responde al frontal, que proporciona la respuesta de vuelta al cliente. El equipo de infraestructura debe solicitar que el balanceador de cargas tenga registrado a los dos nodos del sistema principal bancario y que además el puerto en el cual estarán publicados los servicios web estén habilitados de tal forma que no existan problemas de comunicación por la red de trabajo. Se recomienda que el monitoreo de Are you alive? se lleve a cabo cada 30 segundos. En caso de que el nodo 1 llegará a presentar alguna falla técnica el balanceador de carga no recibirá respuesta al Are you alive? por lo cual pasará la información al nodo 2, este movimiento o re direccionamiento de datos será transparente tanto para el sistema principal bancario que consumirá los servicios web como para el usuario del sistema SPEI. 138

143 Propuesta de Implementación Integración de Participantes e Interesados El servicio que se está ofreciendo principalmente es el de realizar pagos electrónicos interbancarios en línea, se han mencionado los elementos técnicos requeridos así como su configuración, lo que ahora hace falta es integrar a las partes interesadas y beneficiadas por estos servicios, los consumidores finales, el cliente. Para fines prácticos encapsularemos el servicio de pagos electrónicos interbancarios: Implementación SOA - SPEI Sistema Principal Bancario Nodo1 SERVICIO - WSDL XSD Comunicación Sobre SOAP Encabezado Cuerpo Sistema SPEI Nodo 1 Sistema Principal Bancario Nodo 2 Sistema SPEI Nodo 2 Implementación SOA - SPEI Servicios de Pagos Electrónicos Interbancarios Figura Encapsulamiento Servicios de Pagos Electrónicos Interbancarios 139

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

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com Modelos de los sistemas distribuidos Jorge Iván Meza Martínez jimezam@gmail.com Especialización en Gestión de Redes de Datos Universidad Nacional de Colombia Sede Manizales 1/36 Contenidos Modelo arquitectónico

Más detalles

Sistemas Distribuidos. Sistemas Distribuidos. Definiciones. Definición

Sistemas Distribuidos. Sistemas Distribuidos. Definiciones. Definición Sistemas Distribuidos Sistemas Distribuidos Por: Mariela Curiel Basado en los textos: Sistemas Distribuidos Conceptos y Diseño G. Coulouris, J. Dollimore, TimKinberg Definiciones Ejemplos Desafíos en el

Más detalles

Tema 1: Introducción a la gestión y planificación de redes

Tema 1: Introducción a la gestión y planificación de redes Tema 1: Introducción a la gestión y planificación de redes 1. Introducción general 2. Objetivos de la gestión de redes 3. Objetivos de la planificación de redes 4. Sistemas de gestión de red Gestión de

Más detalles

Unidad I Fundamentos de Sistemas Distribuidos. M.C. Juan Carlos Olivares Rojas

Unidad I Fundamentos de Sistemas Distribuidos. M.C. Juan Carlos Olivares Rojas Unidad I Fundamentos de Sistemas Distribuidos M.C. Juan Carlos Olivares Rojas Temario 1.1. Características de un sistema distribuido 1.2. Objetivos de los sistemas distribuidos 1.3. Ventajas y desventajas

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

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles

UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS MODELO DE GESTION WBEM PARA ADMINISTRACION DE REDES

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

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

1. Introducción 2. Historia 3. Características clave 4. Cuestiones de diseño

1. Introducción 2. Historia 3. Características clave 4. Cuestiones de diseño Tema 1. Introducción a los sistemas distribuidos 1. Introducción 2. Historia 3. Características clave 4. Cuestiones de diseño Tema 1 Introducción a los Sistemas Distribuidos 1 Introducción y objetivos

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

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

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción Dato: Hecho o valor a partir del cual se puede inferir una conclusión.

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

Coordinador general: José Luis Gordillo Ruiz. Informe Técnico Final.

Coordinador general: José Luis Gordillo Ruiz. Informe Técnico Final. Construcción de una Grid Interinstitucional en México. Instituciones participantes: - Universidad Nacional Autónoma de México (UNAM) - Centro de Investigación Científica y de Educación Superior de Ensenada

Más detalles

Simulador de Protocolos de Red a tráves de WEB

Simulador de Protocolos de Red a tráves de WEB Simulador de Protocolos de Red a tráves de WEB Propuesta de Estudio 20071608 Director Ing. Francisco Antonio Polanco Montelongo Resumen Introducción Actualmente, el desarrollo tecnológico a alcanzado niveles

Más detalles

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la Servicios web Introducción Un servicio web es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes

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

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

CENTRO DE RESGUARDO ARQUITECTURA AVANZADA PROF.: JUAN JOSÉ MUÑOZ BUSSI AUTOR: MARIANA FERRETTO

CENTRO DE RESGUARDO ARQUITECTURA AVANZADA PROF.: JUAN JOSÉ MUÑOZ BUSSI AUTOR: MARIANA FERRETTO CENTRO DE RESGUARDO ARQUITECTURA AVANZADA PROF.: JUAN JOSÉ MUÑOZ BUSSI AUTOR: MARIANA FERRETTO CENTRO DE RESGUARDO Centro de Cómputos de Resguardo Sitio para reubicarse luego de un desastre Sitio manejado

Más detalles

Programación en Capas.

Programación en Capas. Programación en Capas. Ricardo J. Vargas Del Valle Universidad de Costa Rica, Ciencias de Computación e Informática, San José, Costa Rica, 506 ricvargas@gmail.com Juan P. Maltés Granados Universidad de

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

Concepto de Procesamiento Distribuido y Centralizado

Concepto de Procesamiento Distribuido y Centralizado Concepto de Procesamiento Distribuido y Centralizado Procesamiento Centralizado: En la década de los años 50 s las computadoras eran máquinas del tamaño de todo un cuarto con las siguientes características:

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

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

UNIVERSIDAD ESTATAL DE MILAGRO

UNIVERSIDAD ESTATAL DE MILAGRO UNIVERSIDAD ESTATAL DE MILAGRO TRABAJO DE INVESTIGACION DE BASE DE DATOS TEMA: SISTEMAS DISTRIBUIDOS NOMBRE: ANGEL SAUL NOBOA BARRENO PROFESOR: ING. RICHARD RAMIREZ CURSO: 6 To SEMESTRE C SISTEMAS DISTRIBUIDOS

Más detalles

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

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

Grado en Ingeniería del Software

Grado en Ingeniería del Software Grado en Ingeniería del Software Descripción de los módulos o materias FUNDAMENTOS CIENTÍFICOS PARA LA INGENIERÍA Bases científicas necesarias para cualquier ingeniero informático: Física, Álgebra, Análisis

Más detalles

Introducción. Campos de Aplicación SGBD. Índice. Aplicaciones Representativas. Aplicaciones Representativas

Introducción. Campos de Aplicación SGBD. Índice. Aplicaciones Representativas. Aplicaciones Representativas SGBD Base de Un Sistema Gestor de consiste en: Datos Una colección de datos interrelacionados Un conjunto de programas para acceder a los datos Objetivo Principal de un SGBD: Proporcionar una forma práctica

Más detalles

Presentación Comercial IXAYA Crédito

Presentación Comercial IXAYA Crédito Presentación Comercial IXAYA Crédito Versión: 2.0.1 Fecha: 21/04/2014 Elaboró: División Consultoría Contenido 1. Descripción de la solución....3 1.1. Beneficios....4 1.2. Modelo operativo....5 1.3. Arquitectura

Más detalles

Arquitectura cliente/servidor

Arquitectura cliente/servidor Departamento de Lenguajes y Sistemas Informáticos Arquitectura cliente/servidor Programación en Internet Curso 2007-2008 Índice Introducción Tipos de servidores Ventajas Desventajas Arquitectura de una

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

Avances en el Área de Redes y Sistemas Distribuidos de la Universidad Tecnológica de la Mixteca

Avances en el Área de Redes y Sistemas Distribuidos de la Universidad Tecnológica de la Mixteca Avances en el Área de Redes y Sistemas Distribuidos de la Universidad Tecnológica de la Mixteca Gabriel Gerónimo Castillo 1 Cuerpo Académico de Redes y Sistemas Distribuidos 2 Instituto de Electrónica

Más detalles

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx Contenido Middleware: Introducción Definición Genealogía Aplicaciones actuales: Servicios Web Computación

Más detalles

Nombre del documento: Programa de Estudio de asignatura de Especialidad. Nombre de la asignatura: Arquitectura Cliente Servidor

Nombre del documento: Programa de Estudio de asignatura de Especialidad. Nombre de la asignatura: Arquitectura Cliente Servidor 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Arquitectura Cliente Servidor Carrera: Ingeniería en Sistemas Computacionales Clave de la asignatura: SIF-1204 (Créditos) SATCA: 3-2-5 2.- PRESENTACIÓN

Más detalles

Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web

Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web Servicio Web Un servicio web (en inglés, Web services) es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones

Más detalles

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

Memoria Compartida Distribuida (DSM) Sistema de Archivos

Memoria Compartida Distribuida (DSM) Sistema de Archivos Memoria Compartida Distribuida (DSM) La memoria compartida distribuida es una abstracción que se propone como alternativa a la comunicación por mensajes. Memoria compartida basada en páginas: este esquema

Más detalles

Marco Teórico MARCO TEÓRICO. AGNI GERMÁN ANDRACA GUTIERREZ

Marco Teórico MARCO TEÓRICO. AGNI GERMÁN ANDRACA GUTIERREZ MARCO TEÓRICO. 13 14 Virtualización Hablar de virtualización es hablar de un concepto que describe la posibilidad de tener varios sistemas operativos funcionando al mismo tiempo en un mismo equipo físico.

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

Sistemas Distribuidos. (Arquitecturas)

Sistemas Distribuidos. (Arquitecturas) (Arquitecturas) Dr. Víctor J. Sosa Sosa vjsosa@cinvestav.mx II-1 Arquitecturas Los SD son los sistemas de software más complejos Nortel Networks crea switches los cuales pueden contener entre 25-30 millones

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

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA

MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA MANUAL DE ORGANIZACIÓN Y FUNCIONES GERENCIA DE INFORMÁTICA Aprobando mediante Resolución de Gerencia General N 052-2015 de fecha 26 Junio 2015 ELABORADO POR: APROBADO POR: 1 de 82 ÍNDICE 1 INTRODUCCIÓN...

Más detalles

Monitoreo de Nubes Privadas

Monitoreo de Nubes Privadas Monitoreo de Nubes Privadas Whitepaper Autores: Dirk Paessler, CEO de Paessler AG Gerald Schoch, Editor Técnico de Paessler AG Publicado: Mayo 2011 Ultima Actualización: Febrero 2015 PÁGINA 1 DE 7 Contenido

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

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

Facultad de Ingeniería ISSN: 0121-1129 revista.ingenieria@uptc.edu.co. Universidad Pedagógica y Tecnológica de Colombia. Colombia

Facultad de Ingeniería ISSN: 0121-1129 revista.ingenieria@uptc.edu.co. Universidad Pedagógica y Tecnológica de Colombia. Colombia Facultad de Ingeniería ISSN: 0121-1129 revista.ingenieria@uptc.edu.co Universidad Pedagógica y Tecnológica de Colombia Colombia Amézquita-Mesa, Diego Germán; Amézquita-Becerra, Germán; Galindo-Parra, Omaira

Más detalles

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Base de Datos ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Una base de datos es un conjunto de elementos de datos que se describe a sí mismo, con relaciones entre esos elementos, que presenta

Más detalles

LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK

LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK 1 LA COLABORACIÓN, UNA REALIDAD GRACIAS A LA ARQUITECTURA TECNOLÓGICA HP EGOVERNMENT FRAMEWORK Miguel Angel Abellán Juliá Gerente de Soluciones para Administraciones Públicas. Hewlett-Packard Española,

Más detalles

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software.

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. . TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. Índice 1 INTRODUCCIÓN 2 2 CARACTERÍSTICAS 2 2.1 Características del cliente...2 2.2 Características

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 1: Introducción: 1.1 Introducción: Qué es un sistema operativo?. 1.2 Conceptos clave de un sistema operativo. 1.3 El sistema operativo como administrador

Más detalles

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI.

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Ponencia para Evento de Redes. Autor: Rubén Rivera Rodríguez, Citmatel Resumen Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Las nuevas tendencias

Más detalles

Tema 2: EL MODELO CLIENTE/SERVIDOR

Tema 2: EL MODELO CLIENTE/SERVIDOR Tema 2: EL MODELO CLIENTE/SERVIDOR E. U. Informática en Segovia Departamento de Informática Universidad de Valladolid Definición de sistemas cliente/servidor (1) Clientes y servidores: entidades lógicas

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

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: EL PROCESO DE DISEÑO DE SISTEMAS DISTRIBUIDOS MANEJANDO LOS DATOS EN LOS SISTEMAS DISTRIBUIDOS DISEÑANDO SISTEMAS PARA REDES DE ÁREA LOCAL DISEÑANDO SISTEMAS PARA ARQUITECTURAS CLIENTE/SERVIDOR

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

BPM y BPEL como herramientas de administración de procesos de negocio

BPM y BPEL como herramientas de administración de procesos de negocio BPM y BPEL como herramientas de administración de procesos de negocio BPM and BPEL as business process management tools Alejandro León Mora* Sandra Bibiana Zárate Zárate** Resumen Este artículo trata sobre

Más detalles

5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES

5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES SISTEMAS DISTRIBUIDOS DE REDES 5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES Programación remota: Introducción y generalidades INTRODUCCIÓN Debido a la dificultad de la arquitectura actual

Más detalles

Módulo 2 Comunicación

Módulo 2 Comunicación Sistemas Distribuidos Módulo 2 Comunicación Facultad de Ingeniería Departamento de Informática Universidad Nacional de la Patagonia San Juan Bosco Comunicación en Sistemas Distribuidos Modelos de Comunicaciones

Más detalles

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados

Más detalles

El monitoreo de una variable física requiere supervisión permanente de señales que

El monitoreo de una variable física requiere supervisión permanente de señales que Capítulo 1 Marco Contextual 1.1. Formulación del problema 1.1.1. Definición del problema El monitoreo de una variable física requiere supervisión permanente de señales que varían con el tiempo. Tal información,

Más detalles

Tecnologías Grid Estándares grid

Tecnologías Grid Estándares grid Tecnologías Grid Estándares grid Master en Sistemas y Servicios Informáticos para Internet Universidad de Oviedo Estándares grid Introducción Introducción Justificación El grid se construye a base de diversos

Más detalles

puede asegurar a sus clientes la calidad y disponibilidad de los servicios empresariales?

puede asegurar a sus clientes la calidad y disponibilidad de los servicios empresariales? RESUMEN DE LA SOLUCIÓN Service Operations Management puede asegurar a sus clientes la calidad y disponibilidad de los servicios empresariales? agility made possible (SOM) de CA Technologies es una solución

Más detalles

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

MACROPROCESO GESTIÓN TECNOLÓGICA

MACROPROCESO GESTIÓN TECNOLÓGICA Versión 1.0 Página 1 de 5 1. OBJETIVO Suministrar las fases para la puesta en producción de aplicaciones y sistemas de información desarrollados o adquiridos por el Instituto Colombiano de Bienestar Familiar

Más detalles

LINEAMIENTOS DE MONITOREO Y CONTROL

LINEAMIENTOS DE MONITOREO Y CONTROL Bogotá D.C., Agosto de 2014 TABLA DE CONTENIDO INTRODUCCIÓN ------------------------------------------------------------------------------------------- --3 1. OBJETIVO --------------------------------------------------------------------------------------------

Más detalles

Comunicación entre procesos

Comunicación entre procesos Comunicación entre procesos Patrones de comunicación Comunicación cliente-servidor En la que los mensajes de petición y respuesta proporcionan la base para la invocación remota de métodos o de procedimientos.

Más detalles

Denominación de la materia. créditos ECTS = 36 carácter = OBLIGATORIA SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES

Denominación de la materia. créditos ECTS = 36 carácter = OBLIGATORIA SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES Denominación de la materia SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES créditos ECTS = 36 carácter = OBLIGATORIA Ubicación dentro del plan de estudios y duración La materia está formada por 6 asignaturas

Más detalles

Las ventajas de cloud computing se hacen cada día más evidentes.

Las ventajas de cloud computing se hacen cada día más evidentes. Resumen ejecutivo Las ventajas de cloud computing se hacen cada día más evidentes. La informática en la nube, o cloud computing, es un tema de gran actualidad y por buenos motivos. Con este tipo de solución,

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R índice Módulo A Unidad didáctica 1: Introducción a las Bases de Datos Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos 3 19 Módulo B Unidad didáctica 1: Fase de análisis de requisitos Modelo

Más detalles

INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA (GATEWAY)

INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA (GATEWAY) UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIA Y TECNOLOGIA MAESTRIA CIENCIA DE LA COMPUTACION MENCION REDES DE COMPUTADORAS INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA

Más detalles

Bases de Datos Distribuidas: Arquitectura Cliente/Servidor

Bases de Datos Distribuidas: Arquitectura Cliente/Servidor Bases de Datos Distribuidas: Arquitectura Cliente/Servidor Instituto Tecnológico Superior de los Ríos Ing. en Sistemas Computacionales 30 de enero de 2012 Bases de Datos Distribuidas:Arquitectura Cliente/Servidor

Más detalles

INFORME DE PERCEPCIÓN DE PROVEEDORES DE CLOUD COMPUTING. Características Técnicas y de Seguridad

INFORME DE PERCEPCIÓN DE PROVEEDORES DE CLOUD COMPUTING. Características Técnicas y de Seguridad INFORME DE PERCEPCIÓN DE PROVEEDORES DE CLOUD COMPUTING OCTOBER 13, 215 215 Índice Objetivo y metodología... 2 Resumen Ejecutivo... 2 Resultados (Seguridad)... 3 Nivel de Madurez (Seguridad)... 7 Resultados

Más detalles

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V Bibliografía Tema V Tecnología de objetos distribuidos y arquitectura de componentes. Szyperski, C. 1998. Component Software. Addison-Wesley. Ruiz Cortés, 1998. A. CORBA: Una visión general. http://www.lsi.us.es/~aruiz

Más detalles

SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB]

SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB] Gobierno Municipal del Cantón Bolívar. SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB] Visión Universidad Técnica del Norte Histórico de Revisiones

Más detalles

Universidad Autónoma Metropolitana

Universidad Autónoma Metropolitana Universidad Autónoma Metropolitana Unidad Azcapotzalco División de Ciencias Básicas e Ingeniería Licenciatura en Ingeniería en Computación Propuesta de Proyecto Terminal Composición de servicios web para

Más detalles

Nombre del documento: Programa de Estudio de asignatura de Especialidad. Referencia a la Norma ISO 9001:2008 7.3 Página 1 de 6

Nombre del documento: Programa de Estudio de asignatura de Especialidad. Referencia a la Norma ISO 9001:2008 7.3 Página 1 de 6 Referencia a la Norma ISO 9001:2008 7.3 Página 1 de 6 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura : Sistemas Distribuidos I Carrera: Ing. en Sistemas Computacionales Clave de la asignatura: RSD-1203

Más detalles

ASEGURAR LA CONFIDENCIALIDAD, INTEGRIDAD Y DISPONIBILIDAD DE LA INFORMACIÓN DE LAS ORGANIZACIONES ES NUESTRO OBJETIVO.

ASEGURAR LA CONFIDENCIALIDAD, INTEGRIDAD Y DISPONIBILIDAD DE LA INFORMACIÓN DE LAS ORGANIZACIONES ES NUESTRO OBJETIVO. SEGURIDAD DE LA INFORMACIÓN ASEGURAR LA CONFIDENCIALIDAD, INTEGRIDAD Y DISPONIBILIDAD DE LA INFORMACIÓN DE LAS ORGANIZACIONES ES NUESTRO OBJETIVO. La mayoría de las organizaciones tiene sus procesos críticos

Más detalles

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1 Sinopsis de la gestión de s de acuerdo con el estándar del Project Management Institute Conceptos básicos Qué es un? Es un grupo de proyectos gestionados de modo coordinado para obtener beneficios y el

Más detalles

Monitoreo de Nubes Privadas

Monitoreo de Nubes Privadas White Paper Monitoreo de Nubes Privadas Whitepaper Autores: Dirk Paessler, CEO de Paessler AG Dorte Winkler, Editor Técnico de Paessler AG Publicado: Mayo 2011 Ultima Actualización: Febrero 2012 Contenido

Más detalles

Uso de firmas digitales en MEA de EVA R-GRID?

Uso de firmas digitales en MEA de EVA R-GRID? Uso de firmas digitales en MEA de EVA R-GRID? Daniel Burbano Gustavo Andrés Jiménez Lesmes Resumen El presente artículo establece la necesidad de integrar firmas digitales en el funcionamiento e interacción

Más detalles

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar

Más detalles

Planificación y Explotación de Sistemas Informáticos Curso 06/07. TEMA 2 ITIL para la gestión de servicios informáticos

Planificación y Explotación de Sistemas Informáticos Curso 06/07. TEMA 2 ITIL para la gestión de servicios informáticos Planificación y Explotación de Sistemas Informáticos Curso 06/07 TEMA 2 ITIL para la gestión de servicios informáticos 1 Índice Introducción Modelo de servicios Soporte de servicios Entrega de servicios

Más detalles

Antes de imprimir este documento piense en el medio ambiente!

Antes de imprimir este documento piense en el medio ambiente! Versión 1.0 Página 1 de 14 1. OBJETIVO: Suministrar la metodología que se aplicará para la estimación de esfuerzo para los desarrollos nuevos en el ICBF, para lo cual se detallan los aspectos a tener en

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

Carrera: SCD-1027 SATCA 1 2-3-5

Carrera: SCD-1027 SATCA 1 2-3-5 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Tópicos Avanzados de Programación Ingeniería en Sistemas Computacionales Clave de la asignatura: SATCA 1 SCD-1027 2-3-5 2.- PRESENTACIÓN Caracterización

Más detalles

Capítulo I. Marco Teórico

Capítulo I. Marco Teórico 1 Capítulo I. Marco Teórico 1. Justificación Hoy en día existe una gran diversidad de aplicaciones que corren sobre la World Wide Web (WWW o Web), y cada una orientada a un fin en particular, el cuál depende

Más detalles

POLÍTICA DE TECNOLOGÍA DE INFORMACIÓN

POLÍTICA DE TECNOLOGÍA DE INFORMACIÓN TABLA DE CONTENIDO 1. OBJETIVO... 1 2. ALCANCE... 1 3. CONTENIDO DE LA POLÍTICA... 1 3.1 Premisas generales para el cumplimiento de la política... 2 3.2 Contenido de la política... 3 3.2.1 Responsabilidades

Más detalles

Soluciones Informáticas para gestionar su empresa Presentación de empresa la Compañía La Compañía NEO GRUP Management, es un proyecto definido y creado para proporcionar a nuestros clientes, trabajando

Más detalles

II MARCO CONCEPTUAL. 2.1 Auditorías. 2.1.1 Proceso de Auditorías

II MARCO CONCEPTUAL. 2.1 Auditorías. 2.1.1 Proceso de Auditorías II MARCO CONCEPTUAL 2.1 Auditorías En general podemos considerar una auditoría como un proceso sistemático y formal en el que se determina hasta qué punto una organización está cumpliendo los objetivos

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

Sistemas Distribuidos

Sistemas Distribuidos Objetivos del curso Sistemas Distribuidos Presentar una visión global del estado del arte y los aspectos más novedosos del diseño y construcción de sistemas distribuidos. Desarrollar ejemplos prácticos

Más detalles

Service Oriented Architecture

Service Oriented Architecture Programación Concurrente y Distribuida Ingeniería en Informática Service Oriented Architecture José Carlos Cortizo Pérez josecarlos.cortizo@uem.es http://www.esp.uem.es/jccortizo D. Sistemas Informáticos

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