Universidad Austral de Chile

Transcripción

1 Universidad Austral de Chile Facultad de Ciencias de la Ingeniería Escuela de Ingeniería Civil en Informática DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE ADMINISTRACIÓN Y MONITOREO EN TIEMPO REAL UTILIZANDO WEBSPHERE MQ LOW LATENCY MESSAGING DE IBM Tesis para optar al Título de: Ingeniero Civil en Informática Profesor Patrocinante: Sr. Jaime Duarte Pino Ingeniero en Informática Magíster en Dirección Financiera Profesor Co-Patrocinante: Sr. Juan Pablo Salazar Fernández Ingeniero Civil en Informática. Licenciado en Ciencias de la Ingeniería Magíster en Administración de Empresas Profesor Informante: Sr. Jorge Morales Vilugrón Ingeniero Electrónico Diplomado en Ciencias de la Ingeniería Magíster en Administración de Empresas MANUEL ALEJANDRO ARANEDA ALARCÓN VALDIVIA - CHILE 2011

2

3

4

5 AGRADECIMIENTOS En primer agradecer a mis padres y hermano por entregarme, valores, principios, educación, pero principalmente por darme todo su amor, esfuerzo y apoyo incondicional para que cada día sea un nuevo comienzo. Incluso privando sus intereses por sobre los nuestros. A mi Anto por su amor, cariño y motivación en todos nuestros años universitarios, por estar incondicionalmente siempre a mi lado en los momentos buenos y malos de la vida. A mis pocos pero buenos amigos: Francisco Ulloa, Humberto Padget, Jorge Trapp, Maikel Miquel, Jonathan Makuc. Por su ayuda y colaboraron intelectual en este proyecto de tesis y por entregarme su cariño y afecto en momentos importantes de mi transcurso universitario y laboral. Una mención especial para Jaime Duarte por haber confiado en mí cuando recién estaba ingresando al mundo laboral, por estar presente en el día a día, entregándome consejos para seguir creciendo como profesional, pero principalmente para seguir creciendo como persona y como colega. A mis compañeros de la Bolsa de Comercio de Santiago, digo compañeros porque son más que colegas: Humberto Padget, Alexander Abarca, Jorge Trapp, Eugenio Contreras, Daniel Meneses, Alvaro Pizarro, Alberto Hormazabal, Ricardo Nuñez, Claudio Beiza, Jose Luis Flores, Luis Felipe Álvarez, Livio Carrasco e Isabel Vargas. Por su motivación constante y buena vibras durante este largo proceso. A los funcionarios del Instituto como Carlitos, Sra. Juanita, Verito, Marianne, Erwin y Jorge Cid por estar siempre dispuestos a ayudar. También a los Guardias del Campus Miraflores como: Pedro Henríquez, Félix Jaramillo, Osvaldo Jaramillo, Hugo López, José Pérez, Iván Rivera, Nolberto Sanzana y Domingo Torres porque sin su apoyo no hubiera podido finalizar esta tesis. Para concluir agradezco a todos mis compañeros con los que pude compartir durante el paso por esta Universidad, los cuales han dejado un lindo recuerdo. 1

6 ÍNDICE DE CONTENIDO ÍNDICE DE CONTENIDO... i ÍNDICE DE TABLAS... iv ÍNDICE DE FIGURAS... v RESUMEN... vii Capítulo I INTRODUCCIÓN ANTECEDENTES GENERALES CONTRIBUCIÓN DEL PROYECTO DE TÍTULO RELEVANCIA E IMPACTO DEL ESTUDIO OBJETIVOS GENERALES Y ESPECÍFICOS Objetivos Generales Objetivos Específicos ORGANIZACIÓN DEL PROYECTO DE TÍTULO NOMENCLATURA... 6 Capítulo II MARCO TEÓRICO MARCO EN EL CUAL SE DESENVUELVE EL PROYECTO SISTEMAS EN TIEMPO REAL (STR) Características de los sistemas en tiempo real Cuando se Utilizan los STR? Sistemas en tiempo real en la actualidad DESCRIPCIÓN DE ESTÁNDARES Y PROTOCOLOS DE COMUNICACIÓN Modelo OSI Modelo TCP/IP Modelo UDP Diferencias entre el protocolo TCP Y UDP Capítulo III WEBSPHERE MQ LOW LATENCY MESSAGING MESSAGE QUEUING Y MQ SERIES MESSAGING QUÉ ES WEBSPHERE MQ LOW LATENCY MESSAGING (WLLM)? DIFERENCIAS ENTRE WEBSPHERE MQ Y WEBSPHERE MQ - LLM RED Y MENSAJERÍA PARA WLLM Patrones lógicos de Mensajería Protocolos de red Soportados DISEÑO GENÉRICO WLLM PRINCIPALES CARACTERÍSTICAS DE WLLM Fiabilidad Disponibilidad Filtros Administración de Congestión Monitoreo Seguridad RELIABLE AND CONSISTENT MESSAGE STREAMING (RCMS) Tier i

7 3.7.2 Comunicación Intra-Tier Capítulo IV SELECCIÓN DE HERRAMIENTAS DE DESARROLLO EVALUACIÓN DE APIS GRÁFICAS JAVA Matriz de Evaluación Laboratorio y Resultados sobre Jide SERVIDOR DE APLICACIONES BASE DE DATOS Hardware y Software Construcción Laboratorios Resultados Conclusiones Capítulo V DEFINICION Y ESPECIFICACION RATIONAL UNIFIED PROCESS (RUP) ANÁLISIS DE REQUERIMIENTOS Requerimientos Funcionales del Cliente Requerimientos Funcionales del Servidor Requisitos No Funcionales ESPECIFICACIÓN Modelo de Procesos Actores y Casos de Uso DISEÑO Restricciones del Diseño Diagrama de Topología Diagrama de diseño Diagrama WLLM Modelo de Datos Capítulo VI : CONTRUCCION DEL PROTOTIPO CONSTRUCCIÓN Primera Iteración Segunda Iteración Tercera Iteración PRESENTACIÓN DEL PROTOTIPO Inicio del Sistema Enviar comandos Paleta de Servidores Paleta de Conexiones Alarmas Contactos Log de Conexiones PLAN DE VALIDACIÓN Capítulo VII RESULTADOS Y BENEFICIOS OBTENIDOS RESULTADOS Requerimientos ii

8 Requerimientos Funcionales Requerimientos No Funcionales Beneficios Obtenidos Capítulo VIII CONCLUSIONES Y TRABAJO FUTURO CONCLUSIONES MEJORAS A LA SOLUCIÓN Capítulo IX REFERENCIAS BIBLIOGRÁFICAS ANEXOS ANEXO A: ARCHIVOS DE CONFIGURACIÓN WLLM A.1 WLLM Driver A.2 WLLM Topic ANEXO B: SCRIPT DE CREACIÓN DE TABLAS ANEXO C: TABLA DE RESULTADOS EVALUACIÓN DE APIS GRÁFICAS ANEXO D: DIAGRAMAS DE REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES iii

9 ÍNDICE DE TABLAS Tabla Nº 1: Cuadro de Características de los STR... 9 Tabla Nº 2: Cuadro Comparativo entre WMQ y WMQ-LLM [DEV09] Tabla Nº 3: Cuadro de ponderaciones para APIs gráficas Tabla Nº 4: Cuadro resultado laboratorios API Jide Tabla Nº 5: Cuadro comparativo de Application Servers Tabla Nº 6: Modalidad auto-commit sobre tabla Test Tabla Nº 7: Modalidad batch sobre tabla Test utilizando SP Tabla Nº 8: Modalidad batch sobre tabla Test utilizando inserción directa Tabla Nº 9: Modalidad batch sobre tabla Test2 utilizando SP Tabla Nº 10: Modalidad batch sobre tabla Test2 utilizando inserción directa Tabla Nº 11: Requerimientos funcionales del cliente Tabla Nº 12: Requerimientos funcionales del servidor Tabla Nº 13: Requerimientos No funcionales Tabla Nº 14: Cuadro de Cumplimiento de FQR para aplicación cliente Tabla Nº 15: Cuadro de Cumplimiento de FQR para aplicación servidor Tabla Nº 16: Cuadro de Cumplimiento de NFQR Tabla Nº 17: Cuadro de resultados para APIs gráfica iv

10 ÍNDICE DE FIGURAS Figura Nº 1: Estructura general para el monitoreo de redes LAN Figura Nº 2: Comparación Modelo OSI - TCP/IP Figura Nº 3: WMQ y WLLM típicamente usado en un Organización financiera [DEV09] Figura Nº 4: Arquitectura Genérica LLM [DEV09] Figura Nº 5: Comunicación RMM. [DEV09] Figura Nº 6: Comunicación RUM [DEV09] Figura Nº 7: Ordenamiento Total [DEV09] Figura Nº 8: RCMS Arquitectura Tier [DEV09] Figura Nº 9: Arquitectura Detallada WLLM [DEV09] Figura Nº 10: Gráfico modalidad auto-commit sobre tabla Test Figura Nº 11: Gráfico modalidad batch sobre tabla Test utilizando SP Figura Nº 12: Gráfico modalidad batch sobre tabla test utilizando inserción directa Figura Nº 13: Gráfico modalidad batch sobre tabla Test2 utilizando SP Figura Nº 14: Gráfico modalidad batch sobre tabla Test2 utilizando inserción directa. 36 Figura Nº 15: Esquema RUP Figura Nº 16: Diagrama de actividad de inicio y envío de comando Figura Nº 17: Casos de uso consola cliente Figura Nº 18: Mapa de la arquitectura general del Sistema Figura Nº 19: Diagrama general de topología Figura Nº 20: Diagrama parcial de componentes. Cliente y Servidor Figura Nº 21: Diagrama parcial de componentes Application Server Figura Nº 22: Diagrama parcial de componentes. Servidor de Base de Datos Figura Nº 23: Diagrama de diseño servidor de administración Figura Nº 24: Diagrama de diseño utilizando WLLM Figura Nº 25: Inicio Consola de administración Figura Nº 26: Envío de comandos a las distintas aplicaciones Figura Nº 27: Pantalla para deshabilitar una determinada acción Figura Nº 28: Paleta de Servidores Trading Engine Figura Nº 29: Pantalla de tiempos de respuesta por mensaje Figura Nº 30: Paleta Usuarios Figura Nº 31: Pantalla de información detalla por corredora Figura Nº 32: Pantalla de Porcentaje de Variación Figura Nº 33: Pantalla de Contactos v

11 Figura Nº 34: Pantalla de Conexiones Figura Nº 35: Plan de pruebas sistema de administración y monitoreo Parte I Figura Nº 36: Plan de pruebas sistema de administración y monitoreo Parte II Figura Nº 37: Diagrama generado en EA para los requerimientos funcionales cliente.. 84 Figura Nº 38: Diagrama generado en EA para los requerimientos funcionales servidor 85 Figura Nº 39: Diagrama generado en EA para los requerimientos no funcionales vi

12 RESUMEN Las necesidades de comunicación de las empresas han llegado al punto en el que se necesita saber de manera concreta el estado y funcionamiento de sus sistemas, equipos o maquinarias que integran los activos que posee la empresa. Esta necesidad junto con la viabilidad y disponibilidad de los servicios de comunicación a distancia se unen para crear una solución a las necesidades de monitoreo de sistemas. El tema de estudio se enfoca en el monitoreo en tiempo real de las distintas piezas que componen el sistema electrónico de negociación de acciones de la Bolsa de Comercio de Santiago, denominado Telepregón HT y los distintos usuarios que negocian a través de él. Por medio de un software desarrollado en Java, utilizando protocolo de transporte de alta disponibilidad llamado WebSphere Low Latency Messaging (WLLM). Se ha planteado una solución con dos módulos del tipo Cliente-Servidor. El módulo servidor procesa los mensaje de WLLM y almacena la información en memoria, en base de datos y levanta un socket TCP/IP, mientras que el módulo cliente escucha por medio del socket la data proveniente del servidor mostrando la información al usuario final. El sistema permite acceder a esta información a través de una computadora remota. El objetivo del estudio es la definición de un sistema de monitoreo en tiempo real y de alerta temprana ante fallas, teniendo un registro del funcionamiento histórico de las aplicaciones para poder realizar un mantenimiento preventivo basándose en la información de dichos registros. vii

13 ABSTRACT Communication needs of enterprises have reached the point where you need to know concretely the status and operation of its systems, equipment or machinery that make up the fleet of assets held by the company. This need, together with the feasibility and availability of distance communication services together to create a solution to the needs of monitoring systems. The subject of study focuses on real-time monitoring of various software pieces that make up the electronic trading of shares in the Santiago Stock Exchange, called Telepregón HT and individual users who trade through it using a software developed in Java that uses a high availability transport protocol called "WebSphere Low Latency Messaging (WLLM). A solution has been proposed with two modules based on the client-server model. The server module processes WLLM messages and stores information in memory, database and picks up a TCP/IP socket, while the client module listens for data, via the socket, that comes from the server, showing the information to the final user. The system allows access to this information through a remote computer. The study's objective is to have a real time monitoring system and early failure warning detection, having a record of historical performance of the applications to perform preventive maintenance based on information from such records. viii

14 Capítulo I INTRODUCCIÓN 1.1 Antecedentes Generales La palabra monitoreo no tiene una definición acabada, pero ha alcanzado un gran auge con la aparición de internet, sobre todo en el área de redes y de seguridad. Mucho se ha discutido sobre la definición de la palabra monitoreo, se han hecho estudios y discusiones sobre el tema, una muy buena definición que se enfoca al hecho de estudio es representa al proceso que evalúa la calidad del control en el tiempo y permite al sistema reaccionar en forma dinámica, cambiando cuando las circunstancias así lo requieran. [CGR98] Aunque la definición anterior no es extraída exactamente del área que nos compete, nos proporciona una visión en donde se puede extender más en una definición concreta para nuestra investigación. En el área de la informática y la inteligencia tecnológica, el concepto de monitoreo debe tener un enfoque más práctico. Por ejemplo, en materia de redes, todas las acciones que se realizan son activas y se necesita tener constante interacción con el sistema involucrado. Es por esto que el monitoreo y el concepto de inteligencia competitiva se encuentran íntimamente ligados, este último se define como: conocimiento generado a partir del análisis resultante de la integración de información sobre el entorno de la organización, que está disponible lícitamente [ESP] En base a este conocimiento, se pueden realizar acciones específicas y preventivas en el caso de que una infraestructura pueda tener algún tipo de problema, se puede decir que esta sería la diferencia entre un simple análisis de datos y el monitoreo de información. En caso del monitoreo, además de realizar un análisis minucioso, también se realizan tareas de supervisión para lograr reaccionar a tiempo sobre alguna contingencia. A grandes rasgos lo que se pretende en el proyecto de tesis, es verificar que la información que viaja a lo largo de toda la red, a través de diversos protocolos, llegue a su correspondiente destino en tiempos aceptables y mostrar de forma organizada la información contenida en los distintos mensajes. En conclusión, cada uno de los servidores del sistema, los cuales están encargados de cumplir con sus distintas funciones, se encuentra bajo análisis y se llevará una supervisión por si ocurren posibles errores a nivel de red, por mal funcionamiento de la misma o de algún programa en específico. 1

15 La estructura general para el monitoreo se muestra a continuación en la Figura Nº 1: Figura Nº 1: Estructura general para el monitoreo de redes LAN. Otro aspecto importante para resaltar es que al momento de mostrar un error, el administrador deberá tener una reacción a este acontecimiento, el cual es dar seguimiento, escalamiento y tomar las medidas correctivas del caso, es decir tener una respuesta a los eventos inesperados del sistema. En el mercado existen varias herramientas de software para la administración y monitoreo, destacándose productos como: Cognos y Netscout, herramientas de buen nivel y un amplio espectro de funcionalidades. Pero uno de los principales inconvenientes de trabajar con este tipo de software, es que son de propósito general y no cubren ciertas particularidades de los sistemas que posee la Bolsa de Comercio de Santiago. Es por esto que nace este proyecto de titulo, como un complemento a las distintas herramientas de monitoreo utilizadas en la empresa, así como para entregar una herramienta ad-hoc a la nueva plataforma de negociación electrónica que dispondrá la Bolsa de Comercio de Santiago a las distintas corredoras, bancos, AFP 1 s, etc., las cuales transan acciones en el mercado chileno. 1 Administradoras de Fondos de Pensiones 2

16 1.2 Contribución del Proyecto de Título En nuestro país existen tres bolsas de comercio, Bolsa de corredores de Valparaíso 2, Bolsa Electrónica de Chile 3 y la Bolsa de Comercio de Santiago. En la actualidad, la Bolsa de Comercio de Santiago, dado su carácter de empresa de innovación tecnológica en el rubro bursátil, está desarrollando un nuevo motor bursátil que reemplazará al actual sistema SEBRA y tendrá como objetivo principal aumentar el throughput 4 y disminuir la latencia 5. Se desarrollará además una herramienta de monitoreo que utiliza el protocolo de comunicación WLLM. Lo que busca la herramienta de administración y monitoreo es explotar al máximo las capacidades de la plataforma, optimizando el tiempo de respuesta ante alertas, junto con observar en tiempo real la actividad a la cual está sometido el sistema. 1.3 Relevancia e Impacto del estudio El producto en estudio entregará información relevante a las distintas áreas de la bolsa: Operaciones: Mejora en cuanto a la rapidez y certeza en la toma de decisiones, ante por ejemplo, una inminente caída masiva de sistemas, con el fin de lograr determinar si se suspende o se mantiene vigente un remate. Servicio al Cliente: Permitirá detectar tempranamente un problema de desconexión, siendo proactivos en la atención al cliente, ya que se podrá anticipar a los reclamos de los corredores e informar oportunamente la situación. Esto ayudará a mejorar los tiempos de atención de reportes, al disponer de más y mejor información, características y estado de sus conexiones. Por otro lado, el Servicio al Cliente podrá proveer de información a las distintas áreas de la Bolsa ante caídas masivas de terminales. Negocios: Permitirá identificar de manera más sencilla a los operadores que se encuentran conectados. Con esto, se espera reforzar el sistema de negociación, para lograr con esa información contactar de forma oportuna a los operadores que se encuentran off line cantidad de operaciones por segundo 5 tiempo de respuesta 3

17 Tecnología: Permitirá contar con un control sobre el sistema, saber con exactitud los terminales conectados y desconectados. Además, ante problemas de desconexión masiva se podría conocer rápidamente varios factores que son importantes al tomar una decisión, como por ejemplo, si se trata de un caso particular o de un tema generalizado, si es una falla interna o externa, estos datos nos permitirán detectar a tiempo la posible causa del problema (enlace, servidor, entre otros). 1.4 Objetivos generales y Específicos Objetivos Generales Desarrollo e Implementación de un Sistema de Administración y Monitoreo en Línea utilizando WebSphere MQ Low Latency Messaging de IBM Objetivos Específicos 1. Comprender y describir el estado del arte de la administración de reglas de negocio y las distintas herramientas que permiten su gestión. 2. Describir características y funcionalidades del protocolo de comunicación WLLM. 3. Analizar alternativas Java Swing comerciales y código abierto que se adapten a los requerimientos de la organización. 4. Diseñar y desarrollar una aplicación que administre y monitoree el nuevo sistema de negociación, que cumpla con las necesidades del proyecto Trading Engine Evaluar la solución mediante métricas de conectividad, tiempo de respuesta y proporción de reglas administradas en un ámbito determinado. 6 Trading Engine: Nuevo proyecto de negociación electrónica de la Bolsa de Comercio de Santiago 4

18 1.5 Organización del Proyecto de Título Está estructurado por ocho capítulos, los cuales están organizados de la siguiente forma: Capítulo I Introducción: Este capítulo, describe el contexto en el cual se desenvuelve este proyecto, el alcance, contribución e impacto, junto con la nomenclatura a utilizar en su desarrollo. Capítulo II Marco teórico: Este capítulo, describe el área de interés en la cual está inmerso el proyecto. Capítulo III Websphere MQ Low Latency Messaging: Este capítulo detalla en forma específica el protocolo de alta disponibilidad utilizado y sus principales características. Capítulo IV Selección de herramientas de desarrollo: Este capítulo, describe, analiza y explica el porqué de las razones por las cuales se utilizaron las distintas herramientas desarrollo mencionadas. A demás de mostrar los resultados de los benchmark 7 realizados. Capítulo V Definición y especificación: En este capítulo, se incluye la especificación de requisitos, análisis y diseño. Capítulo VI Construcción del prototipo: En este capítulo, describe la metodología utilizada y las distintas iteraciones que se llevaron a cabo en la evolución del proyecto, así como también el plan de validación desarrollado. Capítulo VII Resultados y beneficios obtenidos: En este capítulo, se comentan los resultados obtenidos y el beneficio de la implementación para el proyecto. Capítulo VIII Conclusiones y trabajo futuro: junto con dar a conocer las conclusiones obtenidas en la implementación. Además, se plantean posibles mejoras al sistema y trabajos futuros. Capítulo IX Referencias bibliográficas: En este capítulo, aparecen las referencias bibliográficas citadas en el documento. 7 técnica utilizada para medir el rendimiento de un sistema o componente del mismo 5

19 1.6 Nomenclatura En el desarrollo de este proyecto de titulo, aparecen términos en idiomas distintos al español, muchos de los cuales no se traducen debido a que son de uso frecuente en Informática, o debido a que es más complejo utilizar un término apropiado en español o simplemente no tienen una traducción a este idioma. Por este motivo, se escriben en su idioma original con formato de fuente cursiva. 6

20 Capítulo II MARCO TEÓRICO 2.1 Marco en el cual se desenvuelve el proyecto Los sistemas de negociación electrónicos desarrollados por la Bolsa de Comercio de Santiago, fueron diseñados para que los traders 8 de las Corredoras de Bolsa y de las Instituciones autorizadas como operadores directos pudiesen negociar los diferentes tipos de instrumentos financieros que se transan en Bolsa, a través de un terminal de negociación. Con el surgimiento de nuevas técnicas de negociación basadas en programas computacionales, denominados Algorithmic Trader 9, nació un nuevo desafío para los sistemas de negociación electrónica provistos por las Bolsas de Valores, ya que estos nuevos mecanismos exigen una alta capacidad de procesamiento y muy baja latencia en el proceso de las órdenes de compra y venta. La Bolsa de Comercio de Santiago ha decidido el desarrollo de una nueva plataforma de negociación electrónica, que tenga una capacidad de procesamiento de al menos órdenes por segundo y una disponibilidad mínima de 99,999% anual. Los sistemas a construir deben tener un diseño modular que permita configurar paramétricamente las diferentes modalidades de negociación de todos los mercados transados en la Bolsa. El principal objetivo del proyecto es construir una nueva familia de sistemas de negociación electrónicos, de alta capacidad de procesamiento y baja latencia, con el fin de satisfacer los requerimientos planteados por los sistemas de Algorithmic Trader. Como un complemento al aspecto funcional, será necesario desarrollar una herramienta de administración y monitoreo que sea capaz de controlar y manejar el software y ese es el objetivo de este proyecto de título en particular. 2.2 Sistemas en Tiempo Real (STR) Los Sistemas de Tiempo Real pueden llevar el control de eventos que ocurren en el mundo real, por lo tanto son sistemas que responden a un estímulo externo dentro de un tiempo especificado. Esto quiere decir que los STR interactúan con el entorno que se les 8 Traders, palabra usada en la jerga bursátil para referirse a los corredores. 9 Algoritmos que deciden sobre ciertos aspectos de la orden, tales como el momento de ingreso, el precio e incluso la cantidad final de la orden. 7

21 presente y pueden ejecutar acciones de respuesta para determinados estímulos de dicho entorno. Algunas definiciones de sistemas de tiempo real: 1. Tiempo real es la capacidad de un sistema operativo de proporcionar el nivel exigido de servicio en un tiempo de respuesta acotado [Nor]. 2. Cualquier sistema en el cual el instante en el que se produce la salida es significativo. Esto suele deberse a que la entrada corresponde a algún movimiento en el mundo físico y la salida tiene que estar relacionada con ese mismo movimiento. Para una puntualidad aceptable el lapso entre la entrada y la salida debe ser lo suficientemente pequeño [DAI06]. En conclusión, un STR es un sistema informático que tiene la facultad de ejecutar acciones o tareas en intervalos de tiempo bien determinados, estas tareas son ejecutadas de forma concurrente, con el objetivo de sincronizar el funcionamiento del sistema con el paralelismo de acciones que se presentan en el mundo físico. En los sistemas de tiempo real los intervalos de tiempo en que se ejecutan las tareas se definen por un esquema de activación y por un plazo de ejecución. En lo que respecta al esquema de activación puede ser periódico, es decir en intervalos regulares, o también puede ser aperiódico, es decir, en respuesta a sucesos externos que ocurren de forma irregular. La mayoría de los STR son requeridos cuando existen necesidades de tiempo muy rigurosas para las operaciones o en el flujo de datos. La eficiencia no solo depende de la precisión de los resultados, también depende del momento en que los entrega Características de los sistemas en tiempo real Determinismo: Este término es una parte esencial para este tipo de sistemas, por ser la capacidad de determinar con alta precisión, el resultado de una tarea basándose en la entrada de datos al Sistema. Latencia: Se basa en el tiempo que tarda una tarea en ejecutarse. Esta característica se enfoca principalmente en tres aspectos los cuales son: [ALA01] La cantidad de tiempo que tarda en procesar una petición. 8

22 La cantidad de tiempo que se necesita para responder las tareas que fueron solicitadas. Los efectos de peticiones concurrentes. Throughput: Volumen de trabajo o de información que fluye a través de un sistema, también se le llama al volumen de información que fluye en las redes de datos. Particularmente significativo en los sistemas de tiempo real, en los cuales el rendimiento es medido en cantidad de operaciones por segundo. Confiabilidad: La confiabilidad juega un papel muy determinante debido a que el sistema no debe presentar fallos, garantizando que la calidad del servicio que se ofrece no debe degradarse más allá de un límite especificado. El sistema debe tener la capacidad de seguir funcionando aunque se presenten grandes problemas o fallos en alguna pieza de hardware o software. Por lo general, una degradación en el servicio en un STR, lleva consecuencias considerables. Tolerancia a fallos: Cuando se habla de tolerancia a los fallos se refiere a que el sistema debe responder a una acción aún en el caso de existir una falla de algún componente. En caso de que el sistema no sea capaz de responder favorablemente ante este evento, el sistema debe contar con la mayor cantidad de datos posibles para que pueda retomar la acción hasta el momento de la falla. A continuación la Tabla N 1 entrega un resumen de las principales características que debe poseer un sistema en tiempo real. Característica primaria Característica Secundaria Procesamiento concurrente. Fiabilidad Interfaz hardware Re-configurabilidad Tiempo de reacción antes de los eventos Usabilidad Arquitectura distribuida Obligaciones Bases de datos Capacidad de evolución Tabla Nº 1: Cuadro de Características de los STR Cuando se Utilizan los STR? Entornos en donde deben ser aceptados y procesados una gran cantidad de eventos, con rápidos tiempos de respuesta. Cuando se necesita procesar grandes ráfagas de transacciones por segundo sin perder un solo suceso. 9

23 2.2.3 Sistemas en tiempo real en la actualidad Los sistemas de tiempo real pueden tener muchísimas aplicaciones y con el paso del tiempo y el desarrollo de nuevas tecnologías surgen nuevos campos de utilización para estos sistemas. Las áreas más comunes donde se aplican los servicios de un STR son: a. Las telecomunicaciones. b. Los sistemas multimedia. c. Sistemas de negociación electrónica. d. El control industrial. e. La robótica. f. Los sistemas de aviónica y espaciales. g. Los ferrocarriles. h. Automóviles. i. Electrodomésticos de nueva generación. j. Experimentos científicos. k. Sistemas médicos. 2.3 Descripción de estándares y protocolos de comunicación. La estructura física de la red la constituyen dos o más computadores que comparten recursos, pero una red es más que su estructura física ya que también la constituyen las personas que solicitan, proporcionan e intercambian información a través de los sistemas. Parece lógico que los computadores se comuniquen entre sí cuando exista una conexión, pero qué pasa si los equipos son de distintos fabricantes, distintos países?. Para solucionar este tipo de conflicto es que nace un estándar para mejorar la comunicación entre los distintos equipos, este estándar es el modelo OSI que se definirá a continuación. 10

24 Modelo OSI. El modelo OSI (Open System Interconnection) es utilizado prácticamente en las redes de todo el mundo. Creado por el ISO (International Standard Organization), consiste en siete niveles o capas las cuales definen las funciones de los protocolos y cómo estos intercambian información para lograr comunicar varios sistemas. Cada nivel, depende del anterior que está debajo de él y le proporciona a los demás niveles superiores alguna funcionalidad específica. La figura N 2 muestra y detalla los distintos niveles del modelo OSI. [CIE] Modelo TCP/IP. Modelo de 4 capas principales basado en el modelo OSI y que se ha convertido en un estándar a nivel mundial. OSI no tuvo éxito debido principalmente a las demoras en la definición del mismo, la tecnología existente en ese momento y las malas políticas e implementaciones por parte de los investigadores, pero es la combinación de ambos modelos la que permite las comunicaciones de hoy en día, ya que OSI es un buen modelo y TCP/IP es un buen conjunto de protocolos. En la Figura Nº4, se muestra una comparación entre los dos modelos [RFC973]. El TCP/IP (Transmission Communication Protocol/Internet Protocol) es hoy en día el protocolo más utilizado a nivel mundial por su independencia de Sistema Operativo y hardware. El TCP/IP no es un único protocolo, sino que son un conjunto de protocolos que cubren las cuatro capas de este modelo, donde los principales son los que le dan nombre al modelo el TCP y el IP. Las capas pertenecientes a este modelo se muestran a continuación. [YAL] Figura Nº 2: Comparación Modelo OSI - TCP/IP 11