Reyes Maza
description
Transcript of Reyes Maza
UNIVERSIDAD VERACRUZANA
Facultad de Contaduría y Administración
“Java Real Time: Un Enfoque de Desarrollo de los
Sistemas Distribuidos en Tiempo Real”.
M O N O G R A F Í A
Qué para obtener el Título de:
Licenciado en Sistemas Computacionales Administrativos
Presenta:
Luis Alberto Reyes Maza
Asesor:
M.R. y T. Alma Delia Otero Escobar
Xalapa-Enríquez, Veracruz Septiembre 2007
II
DEDICATORIA
A mi madre…
A ti por ser tan especial en mi vida, por que se que me amas, me brindaste tu apoyo
incondicional para lograr este sueño; siempre viviré agradecido con Dios por haberme
dado el privilegio de ser tu hijo.
III
AGRADECIMIENTOS
A mi familia…
A cada uno de los miembros de mi familia, mis hermanitos Hugo y Roger, a mi Tía Noemí,
gracias por tu apoyo todo este tiempo, Abue, gracias por todo, a mis primos, primas,
cuñadas, tíos y tías quiero que sepan que los quiero mucho.
A mis amigos…
Bely, Mar, Alfredo, Abe, Toño, Marco, no tengo palabras para agradecerles el hecho que
me hayan permitido ser su amigo. Rosita, gracias por todo, y a todos ustedes que aunque
no estén aquí siempre estarán en mi corazón.
A mi asesora y sinodales…
Gracias por su apoyo para la realización de esta monografía, por sus comentarios y
correcciones para que todo quedara muy bien.
A ti Jesús…
Que no por ser menos importante, sino al contrario, te agradezco por todo y en cada uno
de los momentos de mi vida, que se sin duda alguna tu me has guardado, gracias por
haberme dado el privilegio de tener el regalo de la salvación.
IV
INDICE
INTRODUCCIÓN. ................................................................................................ 1
CAPITULO I ....................................................................................................... 5
SISTEMAS DISTRIBUIDOS............................................................................... 5
INTRODUCCIÓN. ................................................................................................ 6
1.1 CATEGORÍAS DE LOS SISTEMAS DISTRIBUIDOS. .............................................. 7
1.1.1 Modelo de Mini computadoras. .......................................................... 7
1.1.2 Modelo de Estación de Trabajo.......................................................... 8
1.1.3 Modelo microprocesadores en Pooling. ............................................. 8
1.2 CARACTERÍSTICAS CLAVE DE LOS SISTEMAS DISTRIBUIDOS.............................. 9
1.2.1 Compartición de Recursos. ................................................................ 9
1.2.2 Apertura (opennesss)....................................................................... 11
1.2.3 Concurrencia. ................................................................................... 12
1.2.4 Escalabilidad. ................................................................................... 13
1.2.5 Tolerancia a Fallos. .......................................................................... 14
1.2.6 Transparencia. ................................................................................. 15
1.2.7 El Modelo Cliente Servidor............................................................... 16
1.2.8 Middleware. ...................................................................................... 18
1.2.9 Middleware para sistemas cliente-servidor: RPC. ............................ 19
1.2.10 Servidores Pesados vs. Clientes Pesados..................................... 22
1.2.11 Sistemas N-Tiered.......................................................................... 23
1.2.12 Ventajas de los sistemas cliente-servidor. ..................................... 23
1.3 VENTAJAS Y DESVENTAJAS DE LOS SD. ...................................................... 24
1.3.1 Ventajas de los SD........................................................................... 25
1.3.2 Desventajas de los SD. .................................................................... 26
CAPITULO II .................................................................................................... 27
SISTEMAS DISTRIBUIDOS EN TIEMPO REAL.............................................. 27
INTRODUCCIÓN. .............................................................................................. 28
V
2.1 CARACTERÍSTICAS DE LOS SDTR. .............................................................. 30
2.2 CLASIFICACIÓN.......................................................................................... 33
2.2.1 Atributos Temporales. ...................................................................... 34
2.2.2 Tipos de Requisitos Temporales. ..................................................... 34
2.3 ARQUITECTURA DE UN SISTEMA OPERATIVO DE TIEMPO REAL. ....................... 35
2.4 ACTIVACIÓN DE LOS STR. .......................................................................... 42
CAPITULO III ................................................................................................... 44
ESPECIFICACION DE JAVA REAL TIME ....................................................... 44
INTRODUCCIÓN. .............................................................................................. 45
3.1 PRINCIPIOS GUÍA....................................................................................... 46
3.1.1 Aplicación para Ambientes particulares de Java. ............................. 46
3.1.2 Compatibilidad inversa. .................................................................... 46
3.1.3 Escrito una vez, Corre donde sea. ................................................... 46
3.1.4 Practica Actual vs. Presentaciones Avanzadas. .............................. 46
3.1.5 Ejecución Portable. .......................................................................... 47
3.1.6 No Extensión Sintáctica. .................................................................. 47
3.1.7 Permite Variación en Decisiones de Implementación. ..................... 47
3.2 RESUMEN DE LAS SIETE ÁREAS MEJORADAS. .............................................. 48
3.2.1 Hilos Programables y Enviables....................................................... 48
3.2.2 Administración de Memoria.............................................................. 49
3.2.3 Sincronización y Recurso Compartido. ............................................ 49
3.2.4 Manejo de Eventos asíncronos. ....................................................... 50
3.2.5 Control de transferencia Asíncrona. ................................................. 50
3.2.6 Terminación de Hilos Asíncronos..................................................... 51
3.2.7 Acceso a la Memoria Física. ............................................................ 51
3.3 PLANIFICACIÓN.......................................................................................... 51
3.4 GESTIÓN DE MEMORIA................................................................................ 53
3.4.1 Áreas de memoria. ........................................................................... 54
3.5 SINCRONIZACIÓN. ...................................................................................... 54
3.5.1 Colas de espera. .............................................................................. 55
VI
3.5.2 Prevención de la inversión de prioridades........................................ 55
3.5.3 Determinismo. .................................................................................. 55
3.6 MANEJO DE EVENTOS ASÍNCRONOS............................................................. 55
3.7 TRANSFERENCIA ASÍNCRONA DEL CONTROL. ................................................ 57
3.7.1 Principios Metodológicos.................................................................. 57
3.7.2 Principios de expresibilidad. ............................................................. 58
3.7.3 Principios semánticos....................................................................... 58
3.7.4 Principios Prácticos. ......................................................................... 59
3.8 TERMINACIÓN ASÍNCRONA DE HILOS DE TIEMPO REAL.................................... 59
3.9 ACCESO A MEMORIA FÍSICA......................................................................... 60
3.9.1 Acceso a memoria “en crudo”. ......................................................... 61
3.9.2 Áreas de memoria física................................................................... 61
CAPITULO IV ................................................................................................... 62
EJEMPLOS DE APLICACIÓN DE JAVA REAL TIME...................................... 62
4.1 JSTAMP.................................................................................................... 63
4.1.1 Ejecución normal de Java con soporte de Java Real Time.............. 63
4.1.2 Memoria. .......................................................................................... 64
4.1.3 Beneficios y Casos de Éxito. ............................................................ 64
4.2 IBM/APOGEE APHELION............................................................................. 65
4.3 WEBLOGIC REAL TIME 2.0 ......................................................................... 68
4.4 WEBSPHERE REAL TIME. ........................................................................... 69
CONCLUSIONES. ............................................................................................. 71
BIBLIOGRAFÍA. ................................................................................................ 76
DIRECCIONES DE INTERNET.............................................................................. 77
GLOSARIO. ..................................................................................................... 80
VII
INDICE DE FIGURAS
Figura 1.1 Ejemplo de un sistema distribuido..................................................... 6
Figura 1.2 Modelo de Mini-computadoras. ......................................................... 7
Figura 1.3 Modelo de estación de trabajo. ......................................................... 8
Figura 1.4 Modelo microprocesadores en Pooling. ............................................ 9
Figura 2.1 Ejemplificación de la atención prioritaria del kernel estándar.......... 36
Figura 2.2 Ejemplificación del HAL................................................................... 39
Figura 2.3 Utilización del Nano Kernel. ............................................................ 40
Figura 2.4 Recurso Kernel................................................................................ 41
Figura 2.5 Activación de un STR...................................................................... 43
Figura 4.1 Microprocesador JStamp. ............................................................... 64
INDICE DE TABLAS
Tabla 2.1 Beneficios y limitaciones del kernel preemtable. .............................. 37
Tabla 2.2 Beneficios y limitaciones de la estrategia de kernel dual.................. 38
1
INTRODUCCION
2
La siguiente monografía trata acerca de los Sistemas Distribuidos en
Tiempo Real (SDTR) y específicamente de la propuesta de Java para estos
sistemas. Hoy en día la información actualizada es de gran importancia en
cualquier entidad, llámese Empresa Comercial, Escuela, Instituto o Dependencia
Gubernamental, es por eso que los Sistemas Distribuidos (SD) presentan una
nueva faceta, los SDTR, ahora no solo es importante mantener la información,
recursos y equipos compartidos trabajando al unísono, sino que ahora contar con
la información mas actualizada y que interactué con el medio en que se mueve en
el momento exacto, se ha convertido en el punto mas importante de cualquier
entidad.
Con el surgimiento de los SDTR, se cuenta ahora con información valiosa
en el momento que se requiere, por ejemplo ahora los inversionistas saben como
esta el movimiento de la bolsa con tan solo abrir una nueva ventana en su
computadora, podemos saber como estará el clima con tan solo visitar la pagina
del pronostico del clima, toda esta información viaja por Internet a gran velocidad y
con demasiada demanda, pero no solo pasa esto en Internet, esto sucede en
cualquier entidad, hoy los gerentes necesitan saber cuanto esta vendiendo cada
sucursal de un grupo de tiendas, esta información es crucial para, cerrar trato,
solicitar financiamientos, surtimiento de bodegas, control de inventarios, etc., es
por eso que los SDTR juegan un papel importante en estos días.
Java como le lenguaje de programación vino a mejorar el desarrollo de sistemas,
trayendo consigo el paradigma de orientación a objetos hizo mas fácil que los
programadores pudieran reutilizar el código fuente. Cada una de las
características de dicho paradigma se ha vuelto una gran herramienta para poder
desarrollar sistemas mas estables y sin menos líneas de código, lo que nos da
como resultado el ahorro de recursos, como la memoria, lo cual es una parte
fundamental para un buen funcionamiento de los sistemas.
3
Hoy en día Java se ha vuelto la mejor opción para el desarrollo de sistemas,
y debido a la necesidad de tenerla de forma mas oportuna, aparece JRT, es por
eso que se ha tratado de reunir la información en esta monografía para poder
compartir lo que esta pasando en el mundo de los SDTR.
Debido a lo mencionado anteriormente, Sun microsystems se da a la tarea
de crear una nueva especificación del lenguaje Java, ahora aparece Java Real
Time (JRT) o Java para Tiempo Real, en español, contando con las bondades del
lenguaje Java, y las ya conocidas características de la Maquina Virtual de Java
(JVM), es por eso que JRT se convierte en la mejor alternativa para la creación de
SDTR, la implementación de esta nueva especificación, da como resultados SDTR
con el mayor respaldo y seguridad que se pueda obtener, esta especificación
ofrece los beneficios del lenguaje de Java al igual que los de la JVM.
Los expertos de la JRTS siguen trabajando para hacerla cada día mas
eficiente por lo cual se encuentra ya disponible la versión 1.0.2, información que
se ha recopilado para presentarla en este trabajo, con lo que se espera se pueda
tener el conocimiento de dicha especificación.
Se presentan las principales características de La JRTS, las cuales dan a
conocer sus principales fortalezas y que lo hace la principal atracción de los
desarrolladores y así implementarla en sus proyectos, los cuales necesitan de una
plataforma que de el respaldo necesario para la ejecución de un sistema en
tiempo real.
Uno de varios ejemplos que se presentan en esta monografía el JStamp, un
microprocesador diseñado especificadamente para la ejecución mas efectiva de
los sistemas creados bajo el lenguaje de Java y soportando JRT.
Dicho procesador es sin duda una de los mejores ejemplos de aplicación,
ya que este como se describe en este trabajo, realiza operaciones que hasta
4
ahora los procesadores convencionales no lo hacen, este ha sido diseñado para
aplicaciones desarrolladas exclusivamente bajo Java, y mejor aun dando soporte
para aplicaciones en tiempo real.
Por su parte IBM lanza WebSphere una plataforma para desarrollo de
sistemas en tiempo real, el cual esta basado en Java estándar y que cuenta con el
soporte de aplicaciones en tiempo real, el cual utiliza la JRTS. Dicha plataforma
presenta las bondades y beneficios que brinda.
Otro ejemplo mas que se presenta es Weblogic Real time, creado por BEA,
el cual es un motor de alto rendimiento que refuerza SOA orientando a evento, al
igual que WebSphere su tiempo de ejecución es en milisegundos, característica
importante para los sistemas en tiempo real, ya que la información se encuentra
actualizada y disponible en el momento que se necesita.
Aphelion es un ejemplo mas de aplicación, el cual ha sido lanzado por
Apogee Software, toma su base de WebSphere, y el cual esta diseñado para
ambientes micro, como por ejemplo celulares, PDAs, etc., este ha sido diseñado
bajo la especificación de Java Real Time y al igual que los demás ejemplos que se
presentan, Apehelion parece ser una buena alternativa, ya que cumple los
estandares necesarios para soportar aplicaciones en tiempo real, trabaja con Java
estandar y Java Micro Edition.
Se ha tratado de presentar la información más importante de cada uno de
los temas en esta monografía, si bien usted puede ahondar en cada uno de los
temas en la bibliografía que se presenta o en las páginas web consultadas
Se espera que la información aquí presentada sea de utilidad para aquellos
que estén o estarán trabajando sobre este tema, esto puede ser quizá el principio
de lo mucho que puede pasar con los SDTR.
5
CAPITULO I
SISTEMAS DISTRIBUIDOS
6
Introducción.
Un sistema distribuido (SD) se define como una colección de computadoras
autónomas conectadas por una red, y con el software distribuido adecuado para
que el sistema sea visto por los usuarios como una única entidad capaz de
proporcionar facilidades de computación, ver figura 1.1.
Figura 1.1 Ejemplo de un sistema distribuido.
Fuente: Adaptado de Instituto Tecnológico La Paz, Departamento de Sistemas y Computación,
(n.d.)
El desarrollo de los sistemas distribuidos vino de la mano de las redes
locales de alta velocidad a principios de 1970. Recientemente, la disponibilidad de
computadoras personales de altas prestaciones, estaciones de trabajo y
ordenadores servidores ha resultado en un mayor desplazamiento hacia los
sistemas distribuidos en detrimento de las computadoras centralizadas
multiusuario. Esta tendencia se ha acelerado por el desarrollo de software para
sistemas distribuidos, diseñado para soportar el desarrollo de aplicaciones
distribuidas. Este software permite a las computadoras coordinar sus actividades y
compartir los recursos del sistema - hardware, software y datos.
Los sistemas distribuidos se implementan en diversas plataformas
hardware, desde unas pocas estaciones de trabajo conectadas por una red de
7
área local, hasta Internet, una colección de redes de área local y de área extensa
interconectados, que en lazan millones de computadoras.
Las aplicaciones de los sistemas distribuidos varían desde la provisión de
capacidad de cómputo a grupos de usuarios, hasta sistemas bancarios,
comunicaciones multimedia y abarcan prácticamente todas las aplicaciones
comerciales y técnicas de los ordenadores. Los requisitos de dichas aplicaciones
incluyen un alto nivel de fiabilidad, seguridad contra interferencias externas y
privacidad de la información que el sistema mantiene. Se deben proveer accesos
concurrentes a bases de datos por parte de muchos usuarios, garantizar tiempos
de respuesta, proveer puntos de acceso al servicio que están distribuidos
geográficamente, potencial para el crecimiento del sistema para acomodar la
expansión del negocio y un marco para la integración de sistema usados por
diferentes compañías y organizaciones de usuarios.
1.1 Categorías de los sistemas Distribuidos.
1.1.1 Modelo de Mini computadoras.
Varias computadoras que soportan diferentes usuarios cada una y provee
acceso a recursos remotos.
Figura 1.2 Modelo de Mini-computadoras.
Fuente: Instituto Tecnológico La Paz, Departamento de Sistemas y Computación, (n.d.)
8
• Por lo menos un usuario por cada computadora (CPU < Usuarios).
1.1.2 Modelo de Estación de Trabajo.
Varias estaciones (por lo general cientos), donde cada usuario cuenta con una
estación de trabajo (ET) y realiza en ella todo su trabajo. Requiere de un Sistema
Operativo que soporte funciones de acceso y control remoto, ver figura 1.2
• Un microprocesador por cada usuario (CPU = Usuarios).
• Las estaciones de trabajo cuentan con Interfaces Gráficas, CPU potentes y
Memorias propias.
Figura 1.3 Modelo de estación de trabajo.
Fuente: Instituto Tecnológico La Paz, Departamento de Sistemas y Computación, (n.d.)
1.1.3 Modelo microprocesadores en Pooling.
Trata de utilizar uno o más microprocesadores dependiendo de las
necesidades de los usuarios.
9
Primero los procesadores completan su tarea y posteriormente regresan a esperar
una nueva asignación.
• El número de microprocesadores normalmente es mayor a uno por usuario
(CPU > Usuarios).[1]
Figura 1.4 Modelo microprocesadores en Pooling.
Fuente: Instituto Tecnológico La Paz, Departamento de Sistemas y Computación, (n.d.)
1.2 Características clave de los sistemas distribuidos.
[Coulouris, 1994], (citado en Oscar J. Rojo, 2003) establece que son seis
las características principales responsables de la utilidad de los sistemas
distribuidos. Se trata de comparición de recursos, apertura (openness),
concurrencia, escalabilidad, tolerancia a fallos y transparencia. En las siguientes
líneas se trata de abordar cada una de ellas. [2]
1.2.1 Compartición de Recursos.
El término 'recurso' es bastante abstracto, pero es el que mejor caracteriza
el abanico de entidades que pueden compartirse en un sistema distribuido. El
10
abanico se extiende desde componentes hardware como discos e impresoras
hasta elementos software como ficheros, ventanas, bases de datos y otros objetos
de datos.
La idea de compartir recursos no es nueva ni aparece en el marco de los
sistemas distribuidos. Los sistemas multiusuario clásicos desde siempre han
provisto entre sus usuarios el compartir recursos. Sin embargo, los recursos de
una computadora multiusuario se comparten de manera natural entre todos sus
usuarios. Por el contrario, los usuarios de estaciones de trabajo monousuario o
computadoras personales dentro de un sistema distribuido no obtienen
automáticamente los beneficios de compartir recursos.
Los recursos en un sistema distribuido están físicamente encapsulados en
una de las computadoras y sólo pueden ser accedidos por otras computadoras
mediante las comunicaciones (la red). Para que la compartición de recursos sea
efectiva, ésta debe ser manejada por un programa que ofrezca un interfaz de
comunicación permitiendo que el recurso sea accedido, manipulado y actualizado
de una manera fiable y consistente. Surge el término genérico de gestor de
recursos.
Un gestor de recursos es un modulo software que maneja un conjunto de
recursos de un tipo en particular. Cada tipo de recurso requiere algunas políticas y
métodos específicos junto con requisitos comunes para todos ellos. Éstos incluyen
la provisión de un esquema de nombres para cada clase de recurso, permitir que
los recursos individuales sean accedidos desde cualquier localización; la traslación
de nombre de recurso a direcciones de comunicación y la coordinación de los
accesos concurrentes que cambian el estado de los recursos compartidos para
mantener la consistencia.
Un sistema distribuido puede verse de manera abstracta como un conjunto
de gestores de recursos y un conjunto de programas que usan los recursos. Los
11
usuarios de los recursos se comunican con los gestores de los recursos para
acceder a los recursos compartidos del sistema. Esta perspectiva nos lleva a dos
modelos de sistemas distribuidos: el modelo cliente-servidor y el modelo basado
en objetos.
1.2.2 Apertura (opennesss).
Un sistema informático es abierto si el sistema puede ser extendido de
diversas maneras. Un sistema puede ser abierto o cerrado con respecto a
extensiones hardware (añadir periféricos, memoria o interfaces de comunicación,
etc.) o con respecto a las extensiones software (añadir características al sistema
operativo, protocolos de comunicación y servicios de compartición de recursos,
etc.). La apertura de los sistemas distribuidos se determina primariamente por el
grado hacia el que nuevos servicios de compartición de recursos se pueden añadir
sin perjudicar ni duplicar a los ya existentes.
Básicamente los sistemas distribuidos cumplen una serie de características:
• Los interfaces software clave del sistema están claramente especificados y
se ponen a disposición de los desarrolladores. En una palabra, los
interfaces se hacen públicos.
• Los sistemas distribuidos abiertos se basan en la provisión de un
mecanismo uniforme de comunicación entre procesos e interfaces
publicados para acceder a recursos compartidos.
• Los sistemas distribuidos abiertos pueden construirse a partir de hardware y
software heterogéneo, posiblemente proveniente de vendedores diferentes.
Pero la conformidad de cada componente con el estándar publicado debe
ser cuidadosamente comprobada y certificada si se quiere evitar tener
problemas de integración.
12
1.2.3 Concurrencia.
Cuando existen varios procesos en una única maquina decimos que se
están ejecutando concurrentemente. Si el ordenador esta equipado con un único
procesador central, la concurrencia tiene lugar entrelazando la ejecución de los
distintos procesos. Si la computadora tiene N procesadores, entonces se pueden
estar ejecutando estrictamente a la vez hasta N procesos.
En los sistemas distribuidos hay muchas maquinas, cada una con uno o
mas procesadores centrales. Es decir, si hay N computadoras en un sistema
distribuido con un procesador central cada una entonces hasta N procesos estar
ejecutándose en paralelo.
En un sistema distribuido que esta basado en el modelo de compartición de
recursos, la posibilidad de ejecución paralela ocurre por dos razones:
• Muchos usuarios interactúan simultáneamente con programas de
aplicación.
• Muchos procesos servidores se ejecutan concurrentemente, cada uno
respondiendo a diferentes peticiones de los procesos clientes.
El caso (1) es menos conflictivo, ya que normalmente las aplicaciones de
interacción se ejecutan aisladamente en la estación de trabajo del usuario y no
entran en conflicto con las aplicaciones ejecutadas en las estaciones de trabajo de
otros usuarios.
El caso (2) surge debido a la existencia de uno o más procesos servidores para
cada tipo de recurso. Estos procesos se ejecutan en distintas maquinas, de
manera que se están ejecutando en paralelo diversos servidores, junto con
diversos programas de aplicación. Las peticiones para acceder a los recursos de
un servidor dado pueden ser encoladas en el servidor y ser procesadas
13
secuencialmente o bien pueden ser procesadas varias concurrentemente por
múltiples instancias del proceso gestor de recursos. Cuando esto ocurre los
procesos servidores deben sincronizar sus acciones para asegurarse de que no
existen conflictos. La sincronización debe ser cuidadosamente planeada para
asegurar que no se pierden los beneficios de la concurrencia.
1.2.4 Escalabilidad.
Los sistemas distribuidos operan de manera efectiva y eficiente a muchas
escalas diferentes. La escala más pequeña consiste en dos estaciones de trabajo
y un servidor de ficheros, mientras que un sistema distribuido construido alrededor
de una red de área local simple podría contener varios cientos de estaciones de
trabajo, varios servidores de ficheros, servidores de impresión y otros servidores
de propósito específico. A menudo se conectan varias redes de área local para
formar internetworks, y éstas podrían contener muchos miles de ordenadores que
forman un único sistema distribuido, permitiendo que los recursos sean
compartidos entre todos ellos.
Tanto el software de sistema como el de aplicación no deberían cambiar
cuando la escala del sistema se incrementa. La necesidad de escalabilidad no es
solo un problema de prestaciones de red o de hardware, sino que esta
íntimamente ligada con todos los aspectos del diseño de los sistemas distribuidos.
El diseño del sistema debe reconocer explícitamente la necesidad de escalabilidad
o de lo contrario aparecerán serias limitaciones.
La demanda de escalabilidad en los sistemas distribuidos ha conducido a
una filosofía de diseño en que cualquier recurso simple -hardware o software-
puede extenderse para proporcionar servicio a tantos usuarios como se quiera.
Esto es, si la demanda de un recurso crece, debería ser posible extender el
sistema para darla servicio. Por ejemplo, la frecuencia con la que se accede a los
14
ficheros crece cuando se incrementa el número de usuarios y estaciones de
trabajo en un sistema distribuido. Entonces, debe ser posible añadir ordenadores
servidores para evitar el cuello de botella que se produciría si un solo servidor de
ficheros tuviera que manejar todas las peticiones de acceso a los ficheros. En este
caso el sistema deberá estar diseñado de manera que permita trabajar con
ficheros replicados en distintos servidores, con las consideraciones de
consistencias que ello conlleva.
Cuando el tamaño y complejidad de las redes de ordenadores crece, es un
objetivo primordial diseñar software de sistema distribuido que seguirá siendo
eficiente y útil con esas nuevas configuraciones de la red. Resumiendo, el trabajo
necesario para procesar una petición simple para acceder a un recurso compartido
debería ser prácticamente independiente del tamaño de la red. Las técnicas
necesarias para conseguir estos objetivos incluyen el uso de datos replicados, la
técnica asociada de caching, y el uso de múltiples servidores para manejar ciertas
tareas, aprovechando la concurrencia para permitir una mayor productividad.
1.2.5 Tolerancia a Fallos.
Los sistemas informáticos a veces fallan. Cuando se producen fallos en el
software o en el hardware, los programas podrían producir resultados incorrectos
o podrían pararse antes de terminar la computación que estaban realizando. El
diseño de sistemas tolerantes a fallos se basa en dos cuestiones,
complementarias entre sí: Redundancia hardware (uso de componentes
redundantes) y recuperación del software (diseño de programas que sean capaces
de recuperarse de los fallos).
En los sistemas distribuidos la redundancia puede plantearse en un grano
mas fino que el hardware, pueden replicarse los servidores individuales que son
esenciales para la operación continuada de aplicaciones críticas.
15
La recuperación del software tiene relación con el diseño de software que sea
capaz de recuperar (roll-back) el estado de los datos permanentes antes de que
se produjera el fallo.
Los sistemas distribuidos también proveen un alto grado de disponibilidad
en la vertiente de fallos hardware. La disponibilidad de un sistema es una medida
de la proporción de tiempo que esta disponible para su uso. Un fallo simple en una
maquina multiusuario resulta en la no disponibilidad del sistema para todos los
usuarios. Cuando uno de los componentes de un sistema distribuidos falla, solo se
ve afectado el trabajo que estaba realizando el componente averiado. Un usuario
podría desplazarse a otra estación de trabajo; un proceso servidor podría
ejecutarse en otra maquina.
1.2.6 Transparencia.
La transparencia se define como la ocultación al usuario y al programador
de aplicaciones de la separación de los componentes de un sistema distribuido, de
manera que el sistema se percibe como un todo, en vez de una colección de
componentes independientes. La transparencia ejerce una gran influencia en el
diseño del software de sistema.
El manual de referencia RM-ODP [ISO-1996a]1 identifica ocho formas de
transparencia. Estas proveen un resumen útil de la motivación y metas de los
sistemas distribuidos. Las transparencias definidas son:
• Transparencia de Acceso: Permite el acceso a los objetos de información
remotos de la misma forma que a los objetos de información locales.
• Transparencia de Localización: Permite el acceso a los objetos de
información sin conocimiento de su localización. 1 Reynoso, Carlos B. (2004) Extraído el día 20 de Agosto de 2007 desde http://www.willydev.net/descargas/prev/IntroArq.pdf
16
• Transparencia de Concurrencia: Permite que varios procesos operen
concurrentemente utilizando objetos de información compartidos y de forma
que no exista interferencia entre ellos.
• Transparencia de Replicación: Permite utilizar múltiples instancias de los
objetos de información para incrementar la fiabilidad y las prestaciones sin
que los usuarios o los programas de aplicación tengan por que conoces la
existencia de las replicas.
• Transparencia de Fallos: Permite a los usuarios y programas de aplicación
completar sus tareas a pesar de la ocurrencia de fallos en el hardware o en
el software.
• Transparencia de Migración: Permite el movimiento de objetos de
información dentro de un sistema sin afectar a los usuarios o a los
programas de aplicación.
• Transparencia de Prestaciones. Permite que el sistema sea reconfigurado
para mejorar las prestaciones mientras la carga varia.
• Transparencia de Escalado: Permite la expansión del sistema y de las
aplicaciones sin cambiar la estructura del sistema o los algoritmos de la
aplicación.
Las dos más importantes son las transparencias de acceso y de localización;
su presencia o ausencia afecta fuertemente a la utilización de los recursos
distribuidos. A menudo se las denomina a ambas transparencias de red. La
transparencia de red provee un grado similar de anonimato en los recursos al que
se encuentra en los sistemas centralizados.
1.2.7 El Modelo Cliente Servidor.
El modelo cliente-servidor de un sistema distribuido es el modelo más
conocido y más ampliamente adoptado en la actualidad. Hay un conjunto de
procesos servidores, cada uno actuando como un gestor de recursos para una
17
colección de recursos de un tipo, y una colección de procesos clientes, cada uno
llevando a cabo una tarea que requiere acceso a algunos recursos hardware y
software compartidos. Los gestores de recursos a su vez podrían necesitar
acceder a recursos compartidos manejados por otros procesos, así que algunos
procesos son ambos clientes y servidores. En el modelo, cliente-servidor, todos
los recursos compartidos son mantenidos y manejados por los procesos
servidores. Los procesos clientes realizan peticiones a los servidores cuando
necesitan acceder a algún recurso. Si la petición es valida, entonces el servidor
lleva a cabo la acción requerida y envía una respuesta al proceso cliente.
El termino proceso se usa aquí en el sentido clásico de los sistemas
operativos. Un proceso es un programa en ejecución. Consiste en un entorno de
ejecución con al menos un hilo de control.
El modelo cliente-servidor nos da un enfoque efectivo y de propósito
general para la compartición de información y de recursos en los sistemas
distribuidos.
El modelo puede ser implementado en una gran variedad de entornos
software y hardware. Las computadoras que ejecuten los programas clientes y
servidores pueden ser de muchos tipos y no existe la necesidad de distinguir entre
ellas; los procesos cliente y servidor pueden incluso residir en la misma maquina.
En esta visión simple del modelo cliente-servidor, cada proceso servidor
podría ser visto como un proveedor centralizado de los recursos que maneja. La
provisión de recursos centralizada no es deseable en los sistemas distribuidos.
Es por esta razón por lo que se hace una distinción entre los servicios
proporcionados a los clientes y los servidores encargados de proveer dichos
servicios. Se considera un servicio como una entidad abstracta que puede ser
18
provista por varios procesos servidores ejecutándose en computadoras separadas
y cooperando vía red.
El modelo cliente-servidor se ha extendido y utilizado en los sistemas
actuales con servicios manejando muchos diferentes tipos de recursos
compartidos - correo electrónico y mensajes de noticias, ficheros, sincronización
de relojes, almacenamiento en disco, impresoras, comunicaciones de área
extensa, e incluso las interfaces gráficas de usuario. Pero no es posible que todos
los recursos que existen en un sistema distribuido sean manejados y compartidos
de esta manera; algunos tipos de recursos deben permanecer locales a cada
computadora de cara a una mayor eficiencia - RAM, procesador, interfaz de red
local -. Estos recursos clave son manejados separadamente por un sistema
operativo en cada maquina; solo podrían ser compartidos entre procesos
localizados en el mismo ordenador.
Aunque el modelo cliente-servidor no satisface todos los requisitos
necesarios para todas las aplicaciones distribuidos, es adecuado para muchas de
las aplicaciones actuales y provee una base efectiva para los sistemas operativos
distribuidos de propósito general.
1.2.8 Middleware.
El término middleware se discute en [Lewandosky, 1998, Citado en Oscar J.
Rojo, 2003]. El software distribuido requerido para facilitar las interacciones
cliente-servidor se denomina middleware. El acceso transparente a servicios y
recursos no locales distribuidos a través de una red se provee a través del
middleware, que sirve como marco para las comunicaciones entre las porciones
cliente y servidor de un sistema.
19
El middleware define: la API (Interfase de Programación de Aplicación) que
usan los clientes para pedir un servicio a un servidor, la transmisión física de la
petición vía red, y la devolución de resultados desde el servidor al cliente.
Ejemplos de middleware estándar para dominios específicos incluyen: ODBC,
para bases de datos, Lotus para groupware, HTTP y SSL para Internet y CORBA,
DCOM y JAVA RMI para objetos distribuidos.
El middleware fundamental o genérico es la base de los sistemas cliente-
servidor. Los servicios de autentificación en red, llamadas a procedimiento remoto,
sistemas de ficheros distribuidos y servicios de tiempo en red se consideran parte
del middleware genérico. Este tipo de middleware empieza a ser parte estándar de
los sistemas operativos modernos como Windows NT. En sistemas donde no se
disponga deberá recurrirse a middlware del tipo OSD DCE (Distributed Computing
Environment). El middleware específico para un dominio complementa al
middlware genérico de cara a aplicaciones mucho mas especificas.
El protocolo de comunicaciones mas usado por el middlware, tanto genérico
como específico, es TCP/IP. Esto se debe a su amplia difusión en todos los
sistemas operativos del mercado y en especial en los ordenadores personales.
1.2.9 Middleware para sistemas cliente-servidor: RPC.
Un servicio proporcionado por un servidor no es más que un conjunto de
operaciones disponibles para los clientes. El acceso al servicio se realiza mediante
un protocolo de peticiones respuesta con llamadas bloqueantes. Ejemplo: Un
servicio de ficheros. El servidor mantiene como recurso compartido los ficheros.
Sobre el recurso compartido se pueden realizar diversas operaciones: Crear, Abrir,
Leer, etc.
20
Los mecanismos RPC persiguen que los clientes se abstraigan e invoquen
procedimientos remotos (operaciones) para obtener servicios. Así, el
procedimiento llamado se ejecuta en otro proceso de otra maquina (servidor). El
objetivo de RPC es mantener la semántica de la llamada a procedimiento normal
en un entorno de implementación totalmente distinto. La ventaja esta en que el
desarrollador se preocupa de los interfaces que soporta el servidor. Para
especificar dichos interfaces se dispones de un IDL (lenguaje de definición de
interfaces).
Los sistemas RPC disponen de mecanismos de RPC integrados en un
lenguaje de programación particular que incluye además una notación para definir
interfaces entre clientes y servidores (IDL específico). Un IDL permite definir el
nombre de las operaciones soportadas por el servidor y sus parámetros (tipo y
dirección). También se deben proveer mecanismos para manejo de excepciones,
garantizar la ejecución de las operaciones, así como la detección de fallos. Todo
ello de la forma más transparente posible.
El software (middleware) que soporta RPC tiene tres tareas fundamentales:
• Procesamiento relacionado con los interfaces: Integrar RPC en el entorno
de programación, empaquetamiento (marshalling)/desempaquetamiento
(unmarshalling) y despachar las peticiones al procedimiento adecuado.
• Gestionar las comunicaciones.
• Enlazado (Binding): Localizar al servidor de un servicio.
La interfaz no es más que un número de procedimiento acordado entre cliente
y servidor. Este número viaja dentro del mensaje RPC transmitido por la red. En la
parte cliente existe un procedimiento de 'stub' encargado de
empaquetar/desempaquetar los argumentos de la llamada, convertir la llamada
local en una llamada remota. Esto supone enviar un mensaje, esperar la respuesta
y retornar los resultados. En la parte del servidor esta el despachador, junto con el
conjunto de procedimientos de stub de servidor, que tienen una misión similar a
21
los de la parte cliente. El despachador selecciona el procedimiento de stub
adecuado a partir del número de procedimiento requerido.
El compilador de IDL genera los procedimientos de stub de cliente y de
servidor, las operaciones de empaquetamiento y desempaquetamiento así como
los ficheros de cabecera necesarios.
Las peticiones de los clientes son con respecto a un nombre de servicio. En
última instancia deben ser dirigidas a un puerto en el servidor. En un sistema
distribuido un binder es un servicio separado que mantiene una tabla que contiene
correspondencias de nombres de servicios con puertos de servidor. Se trata, como
veremos más adelante, de un servicio de nombres. Importar un servicio es pedir al
binder que busque el nombre del interfaz y retorne el puerto del servidor. Exportar
un servicio es registrarlo de cara el binder. El binder deberá estar en un puerto
bien conocido o, al menos, se le podrá localizar.
Una implementación bastante habitual de RPC es la de SUN. Incorpora todo
un conjunto de primitivas para trabajar con RPC en lenguaje C. Dispone de una
representación neutral de los datos para su empaquetamiento, XDR (External
Data Representation). XDR también se denomina al IDL que se proporciona.
El compilador de IDL, que se denomina “rpcgen”, genera los procedimientos de
stub, el procedimiento principal del servidor y el despachador, el código de
conversión de los parámetros a XDR, así como los ficheros de cabecera
correspondientes.
El binder recibe el nombre de port mapper. Cuando se activa un servidor en
una máquina remota ésta se registra con el port mapper, obteniendo un puerto de
comunicación a través del cuál escuchar. Cuando se quiere acceder a un servicio
hay que contactar con el port mapper de la máquina remota, preguntándole por el
nombre de un determinado servicio, devolviéndose el puerto de comunicación en
22
el que está a la escucha el servidor correspondiente. Por tanto para acceder a una
determinada operación de un servicio hace falta la siguiente información:
[host:servicio:procedimiento].
1.2.10 Servidores Pesados vs. Clientes Pesados.
Los especialistas en sistemas de información califican como 'pesada' una
parte de un sistema con una cantidad de funcionalidad desproporcionada. Por el
contrario, una parte de sistema se considera ligera si tiene menos
responsabilidades.
En un sistema cliente-servidor la porción del servidor casi siempre mantiene
los datos, mientras que la porción del cliente es responsable de la interfaz de
usuario. El desplazamiento de la lógica de la aplicación constituye la distinción
entre clientes 'pesados' y servidores 'pesados'. Los sistemas servidores 'pesados'
delegan más responsabilidad de la lógica de la aplicación en los servidores,
mientras que los clientes 'pesados' dan al cliente mayor responsabilidad. Ejemplo
de servidor pesado es un servidor Web, mientras que muchos de los clientes en
sistemas de bases de datos constituyen clientes 'pesados'.
Aunque los sistemas basados en servidores 'pesados' han sido los más
utilizados en el pasado, en la actualidad muchos diseñadores prefieren sistemas
con clientes 'pesados', debido a que son más fáciles de implementar. Los clientes
'pesados' permiten a los usuarios crear aplicaciones y modificar los front-end del
sistema fácilmente, pero a costa de reducir la encapsulación de los datos; cuanta
más responsabilidad se coloque en un cliente, el cliente requerirá un conocimiento
más profundo de la organización de los datos del servidor.
Por otra parte, un servidor 'pesado' es más fácilmente explotable, esto es,
más fácil de explotar. Además este tipo de servidor asegura una mayor
23
compatibilidad entre clientes y servidores. Por ejemplo, una pagina Web diseñada
bajo este modelo supondría que no hay disponibilidad de applets de Java, plugins
o ActiveX's debido a que el usuario esta usando un cliente 'ligero', (un navegador
básico), y el servidor estaría restringido al estándar HTML 2.0. El uso de este
modelo de cliente 'ligero' asegura que todos los usuarios visualizan una página
"aceptable", aunque no se pueden proveer las características avanzadas
disponibles con un cliente 'pesado'.
1.2.11 Sistemas N-Tiered.
El modelo canónico cliente-servidor asume exactamente dos participantes
discretos en el sistema. Se denomina sistema 'two-tier'; la lógica de la aplicación
puede estar en el cliente, el servidor, o compartida entre los dos. También puede
darse el caso de tener la lógica de la aplicación separada de los datos y de la
interfaz de usuario, convirtiéndose el sistema en 'three-tiered'. En un sistema
'three-tiered' ideal toda la lógica de la aplicación reside en una capa separada.
Esto ocurre raramente en los sistemas actuales. Siempre hay ciertas partes que
permanecen o bien del lado del cliente o del lado del servidor.
Las aplicaciones Web estándar son un ejemplo clásico de sistemas 'three-
tiered'. Por un lado se tienen la interfaz de usuario, provista por la interpretación de
HTML, por un navegador. Los componentes embebidos visualizados por el
navegador residen en la capa media; pueden ser applets de Java, ActiveX's o
cualquier otra clase de entidad que provea lógica de aplicación para el sistema.
Por último se tienen los datos suministrados por el servidor Web.
1.2.12 Ventajas de los sistemas cliente-servidor.
24
La principal ventaja de los sistemas cliente-servidor está en la
correspondencia natural de las aplicaciones en el marco cliente-servidor. Un
ejemplo de esto es una agenda electrónica. Debido a que los datos son
relativamente estáticos y son vistos de manera uniforme por todos los usuarios del
sistema parece lógico colocarlos en un servidor que acepte peticiones sobre
dichos datos. Es más, en este caso la lógica de aplicación debería estar colocada
del lado del servidor, para proporcionar una mayor flexibilidad al sistema de
búsquedas (cambios en los algoritmos, etcétera.).
Como resultado de la disponibilidad de middleware compatible para
múltiples plataformas y de los avances recientes de la interoperabilidad binaria, los
sistemas cliente-servidor pueden conectar clientes ejecutándose en una
plataforma con servidores ejecutándose en otra plataforma completamente
distinta. Las tecnologías como Java y los ORBs (Object Request Brokers), de los
que trata en profundidad este trabajo, esperan proveer una total integración de
todas las plataformas en unos pocos años. Si las porciones de un sistema cliente-
servidor encapsulan una única función y siguen un interfaz perfectamente definido,
aquellas partes del sistema que proveen los servicios pueden ser intercambiadas
sin afectar a otras porciones del sistema. Esto permite a los usuarios,
desarrolladores y administradores adecuar el sistema con sus necesidades en
cada momento.
Otra ventaja es la posibilidad de ejecutar aplicaciones que hacen uso
intensivo de los recursos en plataformas hardware de bajo costo. También el
sistema es más escalable, pudiéndose añadir tanto nuevo clientes como nuevos
servidores.
1.3 Ventajas y Desventajas de los SD.
25
Los SD, al igual que cualquier otro tipo de sistema, presentan ventajas para
los usuarios de la misma manera que sus desventajas, a continuación se
mencionan algunas de ellas: [3]
1.3.1 Ventajas de los SD.
Estas son algunas de las ventajas importantes de los SD por lo cual se
señalan en esta monografía.
• Procesadores más poderosos y de menores costos.
Desarrollo de Estaciones con más capacidades.
Las estaciones satisfacen las necesidades de los usuarios.
Uso de nuevas interfaces.
• Avances en la Tecnología de Comunicaciones.
Disponibilidad de elementos de Comunicación.
Desarrollo de nuevas técnicas.
• Compartición de Recursos.
Dispositivos (Hardware).
Programas (Software).
• Eficiencia y Flexibilidad.
Respuesta Rápida.
Ejecución Concurrente de procesos (En varias computadoras).
Empleo de técnicas de procesamiento distribuido.
• Disponibilidad y Confiabilidad.
Sistema poco propenso a fallas (Si un componente no afecta a la disponibilidad
del sistema).
26
Mayores servicios que elevan la funcionalidad (Monitoreo, Telecontrol, Correo
Eléctrico, Etc.).
• Crecimiento Modular.
Es inherente al crecimiento.
Inclusión rápida de nuevos recursos.
Los recursos actuales no afectan.
1.3.2 Desventajas de los SD.
De la misma manera como se señalaron algunas ventajas de los SD,
ponemos sus desventajas.
• Requerimientos de mayores controles de procesamiento.
• Velocidad de propagación de información (Muy lenta a veces).
• Servicios de replicación de datos y servicios con posibilidades de fallas.
• Mayores controles de acceso y proceso (Commit).
• Administración más compleja.
• Costos.
27
CAPITULO II
SISTEMAS DISTRIBUIDOS EN TIEMPO REAL
28
Introducción.
Los Sistemas Distribuidos en Tiempo Real (SDTR) son sistemas
informáticos que se encuentran en multitud de aplicaciones, desde la electrónica
de consumo hasta el control de complejos procesos industriales, además que
interactúan con el mundo exterior donde el tiempo es un factor importante. Están
presentes en prácticamente todos los aspectos de nuestra sociedad como,
teléfonos móviles, automóviles, control de tráfico, ingenios espaciales, procesos
automáticos de fabricación, producción de energía, aeronaves, etc. Además, el
auge de los Sistemas de Tiempo Real está en constante aumento, ya que cada
vez más máquinas se fabrican incluyendo un número mayor de sistemas
controlados por computadoras. Un claro ejemplo es la industria del automóvil; un
turismo actual de gama media incluye alrededor de una docena de estas
automatizaciones (ABS, airbag, etc.). Otro claro ejemplo son los electrodomésticos
de nueva generación, que incluyen Sistemas de Tiempo Real para su control y
temporización. Hoy día son tantas las aplicaciones de estos sistemas que su
número duplica actualmente al de los sistemas informáticos "convencionales" o de
propósito general. Las previsiones son que esta diferencia vaya en constante
aumento, debido fundamentalmente el elevado crecimiento de la automatización
en casi todas las facetas de la vida cotidiana.
La característica que hace diferente a los Sistemas Distribuidos de Tiempo
Real es que sus acciones deben producirse dentro de unos intervalos de tiempo
determinados por la dinámica del sistema físico que supervisan o controlan,
además de distribuir sus recursos. Por poner un ejemplo, el sistema de control de
inyección de combustible en un motor alternativo (como los que están presentes
en los automóviles) debe realizar la inyección de la mezcla dentro del intervalo de
tiempo marcado por la rotación del motor, de otro modo el motor no funcionará
correctamente. En este caso, se trata de un sistema de tiempo real empotrado, es
29
decir, el sistema informático se encuentra físicamente incluido en un sistema de
ingeniería más complejo. La mayoría de los sistemas de tiempo real son sistemas
empotrados y suelen tener restricciones adicionales en cuanto al uso de recursos
computacionales con respecto a otros tipos de sistemas informáticos. Además,
suelen tener requisitos de seguridad y fiabilidad mas severos, ya que si el sistema
falla puede ocasionar pérdidas económicas (por ejemplo, avería del motor) o
incluso humanas (por ejemplo, si el motor fuera de una aeronave).
Además, las aplicaciones empotradas no son ni mucho menos pequeñas. Por
ejemplo; un simple teléfono móvil tenía medio millón de líneas de código en 1997,
y el número de líneas de código que vuelan embarcadas en los sistemas de
control de una aeronave moderna se cuentan por millones. El tamaño actual de
estas aplicaciones hace impensable su desarrollo sin utilizar la Ingeniería del
Software que es una disciplina fundamental y propia de los Ingenieros
Informáticos.
Cabe mencionar que un programa o un sistema operativo se consideran
como de tiempo real, si a pesar de las restricciones de tiempo se le permite
trabajar y funcionar correctamente; se distinguen las siguientes clases: Tiempo
real estricto (Hard Real Time), Tiempo real flexible (Soft Real Time), Tiempo real
firme (Firm Real Time), las cuales mencionamos detalladamente más adelante.
30
2.1 Características de los SDTR.
Algunas características importantes de los Sistemas Distribuidos en Tiempo
Real se citan a continuación [4]:
• Gran tamaño y complejidad.
– algunos STR tienen millones de líneas de código.
– la variedad de funciones aumenta la complejidad incluso en sistemas
relativamente pequeños.
• Simultaneidad de acciones (concurrencia).
– los dispositivos físicos controlados funcionan al mismo tiempo
– las tareas que los controlan actúan concurrentemente.
• Dispositivos de entrada y salida especiales.
– los manejadores de dispositivos forman parte del software de aplicación.
• Seguridad y fiabilidad.
– sistemas críticos: fallos con consecuencias graves.
» Pérdida de vidas humanas.
» Pérdidas económicas.
» Daños medioambientales.
La fiabilidad es normalmente mucho mas importante en sistemas en tiempo
real que en los que no lo son. Un fallo transitorio en un sistema que no sea en
tiempo real puede resolverse simplemente volviendo a reiniciar el sistema. Un fallo
de un procesador en un multiprocesador que no sea en tiempo real produce una
reducción del nivel de servicio hasta que se repara o sustituye el procesador
averiado. Pero un sistema en tiempo real responde y controla sucesos en tiempo
real. Las perdidas o degradaciones del rendimiento pueden tener consecuencias
catastróficas, que pueden ir desde perdida financieras hasta daños en equipo e
incluso perdida de vidas humanas.
31
• Determinismo temporal.
– Acciones en intervalos de tiempo determinados.
– Es fundamental que el comportamiento temporal de los STR sea
determinista o, al menos, previsible.
» No hay que confundirlo con la necesidad de que sea eficiente.
» El sistema debe responder correctamente en todas las situaciones.
» En los sistemas de tiempo real estricto hay que prever el
comportamiento en el peor caso posible.
Un sistema operativo es determinista si realiza las operaciones en instantes
fijos y predeterminados o en intervalos de tiempos predeterminados. Cuando
compiten varios procesos por los recursos y por el tiempo del procesador,
depende, en primer lugar, de la velocidad con la que pueda responder a las
interrupciones y en segundo lugar, de si el sistema posee suficiente capacidad
para gestionar todas las peticiones en el tiempo requerido.
Un sistema operativo para operar de forma determinista es el retardo
máximo que se produce de la llegada de la interrupción de un dispositivo de alta
prioridad hasta que comienza el servicio.
• Control del Usuario.
Es generalmente mucho mayor en un sistema operativo en tiempo real que
en un sistema operativo ordinario. En sistema operativo típico que no sea
en tiempo real, el usuario no tiene control sobre la función de planificación
del sistema operativo. En un sistema en tiempo real resulta esencial permitir
al usuario un control preciso sobre la prioridad de las tareas. El usuario
debe poder distinguir entre tareas rígidas y flexibles y especificar
prioridades relativas dentro de cada clase. Un sistema en tiempo real
también permitirá al usuario especificar características. Que procesos
32
deben estar siempre residente en la memoria principal.
• Tolerancia a Fallos.
Esta característica que hace referencia a la capacidad de un sistema de
conservar la máxima capacidad y los máximos datos posibles en caso de
fallos por Ej., un sistema UNIX clásico típico, cuando detecta datos
corruptos en el núcleo, genera un mensaje de error en la consola del
sistema, vuelca el contenido de la memoria en el disco para un análisis
posterior y finaliza la ejecución del sistema. Un sistema en tiempo real
intentara corregir el problema o minimizar sus efectos mientras prosigue
con la ejecución.
Un aspecto importante a la tolerancia a los fallos es la estabilidad. Un
sistema en tiempo real si, en los casos en los que es imposible cumplir todos los
plazos de ejecución de las tareas, el sistema cumple los plazos de las tareas mas
criticas y de mayor prioridad, incluso si no se cumple los de alguna tarea menos
critica.
Para cumplir los requisitos anteriores los sistemas operativos actuales en
tiempo real incluyen normalmente las siguientes características:
• Cambios rápidos de procesos o hilos.
• Pequeño tamaño (con una mínima funcionalidad asociada).
• Capacidad de responder rápidamente a interrupciones externas.
• Multitarea con herramientas de comunicación entre procesos, como
semáforos, señales y sucesos.
• Uso de archivos secuénciales especiales que puedan acumular datos a alta
velocidad.
• Planificación preferente basadas en prioridades.
• Reducción de intervalos en los que están inhabilitadas las interrupciones.
33
• Primitivas para demorar tareas durante un tiempo fijo y para detenerlas y
reanudarlas.
• Alarmas especiales y temporizadores.
El corazón de un sistema en tiempo real es el planificador de tares a corto
plazo. Lo que resulta importante es que todas las tareas rígidas de tiempo real
acaben (o comiencen) en su plazo y que también acaben (o comiencen) en su
plazo tantas tareas flexibles de tiempo real como sea posible.
La mayoría de los sistemas operativos actuales en tiempo real son
incapaces de trabajar directamente con plazos. En su lugar, se han diseñado para
ser tan sensibles como sea posible a las tareas de tiempo real, de forma que,
cuando se aproxima un plazo se pueda planificar rápidamente la traerá. Las
aplicaciones de tiempo real normalmente necesitan tiempos de respuesta
deterministas en un rango de varios milisegundos, las aplicaciones al límite, como
los simuladores de aviones militares, por ejemplo, presentan a menudo
restricciones en un rango de diez a cien microsegundos.
2.2 Clasificación.
Los sistemas de tiempo real se clasifican en general en dos tipos
dependiendo de lo serio de sus tiempos límite y de las consecuencias de omitir
uno de ellos, estos son:
Sistema de tiempo real suave.
Sistema de tiempo real duro.
El tiempo real suave significa que no existe problema si se rebasa un
tiempo límite. Un sistema de tiempo real duro es aquel en el que un tiempo límite
no cumplido puede resultar catastrófico.
34
2.2.1 Atributos Temporales.
• Activación.
– Periódica: a intervalos regulares.
– Aperiódica: cada vez que ocurre un suceso determinado.
» Esporádica: separación mínima entre activaciones.
» Estocástica, a rachas, irregular.
• Plazo de respuesta
– Absoluto: tiempo límite para terminar.
– Relativo: intervalo desde la activación.
• Plazo de respuesta.
– Absoluto: tiempo límite para terminar.
– Relativo: intervalo desde la activación.
2.2.2 Tipos de Requisitos Temporales.
• Tiempo real estricto (hard realtime).
o todas las acciones deben ocurrir dentro del plazo especificado.
» Ejemplo: control de frenado.
• Tiempo real flexible (soft realtime).
o Se pueden perder plazos de vez en cuando.
o El valor de la respuesta decrece con el tiempo.
» Ejemplo: adquisición de datos.
• Tiempo real firme (firm realtime).
o Se pueden perder plazos ocasionalmente.
o Una respuesta tardía no tiene valor.
» Ejemplo: sistemas multimedia.
35
2.3 Arquitectura de un sistema operativo de tiempo real.
El objetivo de un sistema operativo de tiempo real es reducir la latencia y el
jitter en las interrupciones, tanto internas como externas, al orden de
microsegundos [5].
Es decir, la parte fundamental para convertir un sistema operativo de
propósito general en un sistema operativo de tiempo real es el manejo de las
interrupciones.
El procesamiento de interrupciones en el kernel estándar esta divido en 2
tareas. Una tarea que se encarga de leer los datos del dispositivo físico y
escribirlos en un buffer, es lo que se conoce como manejador de interrupciones, y
una tarea que se encarga de pasar los datos del buffer a otro para que sean
accesibles por el kernel. Con este esquema, cuando el manejador esta
ejecutando, todas las interrupciones están inhibidas con el siguiente retardo
impredecible en el servicio de otras interrupciones que se puedan haber producido
y por tanto en los valores de latencia y jitter.
Para conseguir reducir la latencia y el jitter se han desarrollado distintas
alternativas que modifican el kernel de Linux en este aspecto fundamentalmente.
Actualmente hay dos corrientes de diseño:
• Atención prioritaria en el kernel estándar (Preemptable kernel),
esta metodología modifica el kernel en profundidad de forma que los
procesos de kernel ejecuten con máxima prioridad de forma que puedan
interrumpir a procesos de menor prioridad en el acceso a los recursos que
necesiten.
36
Esta metodología implica cambios en los manejadores de
interrupciones para que las interrupciones de alta prioridad no sean
bloqueadas por el manejador de interrupciones mientras esta manejando
otra de menor prioridad.
El resultado de esta metodología es una latencia y un jitter del orden
de 1 milisegundo en un Pentium a 100 Mhz.
A partir de la versión 2.5.4 del kernel de Linux se incorpora esta
metodología.
Como se puede observar en la figura la tarea de tiempo real esta
controlada por el planificador del kernel y es una más de las tareas que
controla el kernel. Esta tarea hace referencia a los procesos de tiempo real
en el espacio de usuario. El planificador sabe que las tareas de tiempo real
tienen mayor prioridad que las tareas que no son de tiempo real, ver figura
2.1.
Figura 2.1 Ejemplificación de la atención prioritaria del kernel estándar.
Fuente: Sánchez Moreno (2007).
37
Como se puede comprobar esta metodología es adecuada para
aplicaciones de audio y vídeo donde el periodo de interrupciones es del
orden de 1 milisegundo, pero inadecuado cuando ya hablamos de menos
de 1 milisegundo.
Beneficios y limitaciones de la estrategia de kernel preemptable, ver
tabla 2.1:
Tabla 2.1 Beneficios y limitaciones del kernel preemptable.
Fuente: Marquez (2005).
• Modificaciones sobre el kernel estándar (Patch).
Existen 4 estrategias de modificación del kernel de Linux para
proveer capacidades de tiempo real. Tres de ellas implican añadir un
segundo kernel (kernel dual) para manejar las tareas de tiempo real y el
cuarto implica modificar directamente el código del kernel para añadir
características de tiempo real.
Beneficios y limitaciones de la estrategia de kernel dual, ver en tabla 2.2:
38
Tabla 2.2 Beneficios y limitaciones de la estrategia de kernel dual.
Fuente: Sánchez Moreno (2007).
o Micro-kernel
Esta estrategia añade un segundo kernel que en realidad es
una capa interfaz entre el hardware y el kernel estándar, lo que se
llama tradicionalmente HAL (Hardware Abstraction Layer). Esta capa,
micro-kernel, controla la ejecución de las tareas de tiempo real y
ejecuta el kernel estándar como una tarea en background, es decir,
el kernel estándar sólo ejecuta cuando no hay tareas de tiempo real
pendientes, ver figura 2.2.
39
Figura 2.2 Ejemplificación del HAL.
Fuente: Sánchez Moreno (2007).
Este microkernel intercepta las interrupciones hardware y
asegura que las tareas de tiempo real ejecuten con la mayor
prioridad posible de forma que la latencia se minimice.
Ejemplo de implementación de esta metodología son RTLinux
y RTAI.
o Nano-kernel
Esta estrategia es similar a la primera, micro-kernel, pero
consigue evitar la patente que tienen algunos programadores sobre
ésta, de forma que este nano-kernel únicamente captura las
interrupciones hardware y permite la ejecución paralela de varios
sistemas operativos por encima de él.
40
En este sentido, esta estrategia no desemboca directamente
en un sistema operativo de tiempo real, sino que, simplemente es
una capa intermedia entre el hardware y un sistema operativo, que
puede ser de tiempo real ó no, ver figura 2.3.
Figura 2.3 Utilización del Nano Kernel.
Fuente: Sánchez Moreno (2007).
Una implementación de esta estrategia es ADEOS2. Los
desarrolladores de este proyecto fueron precisamente los que
pusieron el nombre de nano-kernel para diferenciarlo claramente de
la estrategia de micro-kernel patentado por algunos programadores.
o Extensión con un nuevo kernel de acceso a los recursos (Recurso-
kernel)
2 Yaghmour, Karim. (n.d.). Adaptive Domain Environmente for Operating Systems (ADEOS). Extraído el día 21 de julio del 2007 desde: http://www.opersys.com/ftp/pub/Adeos/adeos.pdf
41
Esta estrategia añade un kernel de forma que éste
proporciona una puerta de acceso a los recursos, tales como al
sistema de ficheros, al puerto paralelo, etc., tanto para el kernel
estándar como a los procesos de usuario.
El recurso kernel no sólo captura las interrupciones sino que
proporciona un mecanismo donde los programas de usuario pueden
requerir, reservar y garantizarse un porcentaje finito de los recursos
como pueden ser de CPU, memoria, etc. Ver figura 2.4.
Figura 2.4 Recurso Kernel.
Fuente: Sánchez Moreno (2007).
o Extensiones POSIX de tiempo real añadidas al kernel
Esta estrategia consiste en modificar directamente el kernel
estándar de Linux para añadir librerías que implementan las
extensiones de tiempo real de POSIX. El resultado es un kernel
conforme al estándar IEEE 1003.1d. No añade un segundo kernel.
42
Las modificaciones realizadas al kernel consisten en la
implementación de relojes, señales, semáforos, memoria compartida,
planificador por prioridades, etc., según lo especificado en IEEE
1003.1d.
Existen 2 aproximaciones diferentes para esta estrategia:
• KURT (The Kansas University Real Time Linux) que
únicamente implementa los relojes conforme al estándar IEEE
1003.1d.
• TimeSys Linux. Añade al "preemptable kernel" un planificador
de kernel que proporciona una latencia y un jitter menor de
100µs. El parche con el planificador no proporciona una alta
resolución en los relojes, que es necesaria para tareas de
tiempo real repetitivas.
2.4 Activación de los STR.
Los sistemas de tiempo real pueden ser activados por evento o por tiempo.
Se dice que un sistema es activado por evento cuando, al ocurrir un evento
externo, este es detectado por algún sensor, lo que entonces provoca que el CPU
conectado tenga una interrupción. Los sistemas activados por eventos están
controlados entonces por las interrupciones. Por otro lado, en los sistemas de
tiempo real activados por el tiempo, se verifican los sensores cada cierto tiempo,
para verificar si está ocurriendo algún evento externo. La desventaja es que se
pierde mucho tiempo de CPU si los eventos ocurren con poca frecuencia, ver
figura 2.5. [6]
43
Figura 2.5 Activación de un STR.
Fuente: Zamorano (n.d.)
44
CAPITULO III
ESPECIFICACION DE JAVA REAL TIME
45
Introducción.
El grupo de expertos de Java Real Time (RTJEG por sus siglas en ingles),
en común acuerdo con la Comunidad de Procesos de Java y el JSR-000001, le
fue dado la responsabilidad de producir una especificaron para la presentación de
La especificación del lenguaje Java y La especificación para la maquina virtual de
Java y de proveer una Interfase de Programación de Aplicación (API) que
permitirá la creación, verificación, análisis, ejecución y administración de los hilos
de Java los cuyas condiciones correctas incluyen restricciones de ejecución de
tiempo (conocidos también como hilos en tiempo real). [7]
Esta monografia describe los principios guía que el RTJEG creo y uso
durante sus trabajo, una descripción de los requerimientos de JRT desarrollados
bajo el auspicio de The Nacional Institute for Standard and Technology (NIST), así
como una breve descripción de alta tecnología de cada uno de las siete áreas
identificadas como mejoras requeridas para cumplir con las metas del grupo.
Una de los principales características que es de gran importancia tomar en
cuenta, es el ahorro de consumo de memoria, además de otros recursos, cada
característica nos hace ver porque los desarrolladores han decidido utilizar el
lenguaje de Java para el desarrollo de aplicaciones en tiempo real.
46
3.1 Principios Guía. Los principios guía son declaraciones que delimitan el rango de trabajo de
el RTJEG e introduce los requerimientos de compatibilidad para la Especificación
de Java Real Time (RTSJ). [8]
3.1.1 Aplicación para Ambientes particulares de Java.
La RTSJ no permitirá especificaciones que restrinjan su uso para ambientes
particulares de Java, tales como una versión específica del Kit de desarrollo de
Java, El ambiente de Aplicación Integrada de Java o la Micro Edición de JavaTM.
3.1.2 Compatibilidad inversa.
La RTSJ no prevendrá existencia, propiamente escrita en programas que
no sean de Java para tiempo real desde su ejecución en implementaciones de La
RTSJ.
3.1.3 Escrito una vez, Corre donde sea.
La RTSJ debe reconocer la importancia de “Escrito una vez, Corre donde
sea” (WORA), además de identificar la dificultad de lograr WORA para programas
de tiempo real y no intentar incrementar o mantener la portabilidad binaria en la
falta de previsibilidad.
3.1.4 Practica Actual vs. Presentaciones Avanzadas.
47
La RTSJ debe direccionar la práctica del sistema actual de tiempo real así
como permitir implementaciones futuras para incluir las presentaciones
avanzadas.
3.1.5 Ejecución Portable.
La RTSJ sostendrá la ejecución previsible como principal prioridad en todas
las transacciones, esto puede ser algunas veces en la falta de típicos propósitos
generales en estándares de computación.
3.1.6 No Extensión Sintáctica.
Para facilitar el trabajo de las herramientas de los desarrolladores, y por lo
tanto incrementar la probabilidad de las implementaciones a tiempo, la RTSJ no
introducirá nuevas palabras clave o hará otras extensiones sintácticas para el
lenguaje de Java.
3.1.7 Permite Variación en Decisiones de Implementación.
El RTJEG reconoce que las implementaciones de la RTSJ pueden variar en
un numero de decisiones de implementación, tales como el uso de algoritmos
eficientes o ineficientes, transacciones eficaces entre tiempo y espacio, la
inclusión de algoritmos programables no requeridos en la mínima implementación
y la variación en la longitud de la ruta del código para la ejecución de los
bytecodes. La RTSJ no ordenara a algoritmos constantes de tiempo especifico
para esto, pero requerirá que la semántica de la implementación se encuentren.
La RTSJ otorga implementar la flexibilidad para incrementar implementaciones
adaptadas para satisfacer los requerimientos de sus clientes.
48
3.2 Resumen de las Siete Áreas Mejoradas.
En cada una de las siete siguientes secciones se da una breve declaración
de dirección para cada área. Estas direcciones fueron definidas en la primera
reunión de los ocho primeros ingenieros en Mendocino, California a finales del
mes de Marzo del año de 1999 y revisadas más adelante en Septiembre del
mismo año.
3.2.1 Hilos Programables y Enviables.
A la luz de la diversidad significante en de programación, modelos de envío
y el reconocimiento de cada modelo tiene una aplicación amplia en la industria
diversa de los sistemas de tiempo real, se concluyo que la dirección tomada para
cada especificación de programación seria para permitir un mecanismo de
programación fundamental que será usado por los hilos de Java para tiempo real,
pero no se especifico por adelantado la naturaleza de todos (o un de un numero
de ellos) los mecanismos de programación posible. La especificación esta
construida para permitir implementaciones que provean algoritmos de
programación no anticipada. Las implementaciones permitirán tareas de
parámetros apropiados para los mecanismos de programación fundamentales, así
como proveer cualquier método necesario para la creación, administración,
admisión y terminación de los hilos de Java para tiempo real. Se espera también
que, por el momento, hilos particulares programables y mecanismos de envío
sean delimitados a una implementación. Sin embargo, se proveyó la flexibilidad
suficiente en el marco de los hilos de programación que permitirán en versiones
futuras de la especificación, construir en base a esta además de permitir la carga
dinámica de módulos de políticas de programación.
Para colocar la práctica actual de la RTSJ se requiere una base
programable en todas las implementaciones. La base requerida será familiar a los
49
programadores de sistemas en tiempo real. Esta es base prioritaria, preventiva y
debe tener al menos 28 prioridades únicas.
3.2.2 Administración de Memoria.
Se reconoce que la administración de memoria automática es una
presentación particularmente importante del ambiente de programación de Java, y
se busco una dirección que permitiría, tanto como fuese posible, el trabajo de la
administración de memoria para ser implementado automáticamente por los
sistemas fundamentales sin introducirse en las tareas de programación.
Adicionalmente, se ha entendido que muchos algoritmos de administración de
memoria, conocidos también como recolectores de basura (GC), existen y muchos
de estos se aplican para ciertas clases de sistemas y estilos de programación de
tiempo real. En este intento de colocar un grupo diverso de algoritmos GC, se
busco definir una locación de memoria y especificación de recuperación que:
• Seria independiente de cualquiera algoritmo GC.
• Permitiría que el programa caracterice precisamente un efecto de un
algoritmo GC implementado sobre el tiempo de ejecución, prevención y
envió de hilos de Java para tiempo real.
• Permitiría la locación y recuperación de objetos fuera de cualquier interfase
por un algoritmo GC.
3.2.3 Sincronización y Recurso Compartido.
Con frecuencia la lógica requiere de un acceso serial a los recursos. Los
sistemas de tiempo real introducen una adicional complejidad: inversión de control
prioritario. Se ha decidido que la última especificación intrusiva para la permisión
segura de sincronización en tiempo real se requiere que las implementaciones de
50
la palabra clave de Java synchronized incluye uno o más algoritmos que
previenen inversión prioritaria entre los hilos de Java real rime que comparte el
recurso seriado. Se observo que en algunos casos el uso de la palabra
synchronized implementando la inversión primaria del algoritmo requerido no es
suficiente para que ambos prevengan la inversión primaria y permitan al hilo tener
una ejecución elegiblemente lógica más alta que el recolector de basura. Se
provee un grupo libre de clases de colas de espera para ser usadas en dichas
situaciones.
3.2.4 Manejo de Eventos asíncronos.
Los sistemas de tiempo real comúnmente interactúan muy cercanamente
con el mundo real. Con respecto a la ejecución de la lógica, el mundo real es
asíncrono. Por lo tanto RTJEG se vio obligado a incluir mecanismos eficientes
para las disciplinas de programación que colocarían esta inherente asincronía. La
RTSJ generaliza el mecanismo del lenguaje Java del manejo de un evento
asíncrono. Las clases requeridas representas actos que suceden y la lógica se
ejecuta cuando estos suceden. Una presentación notable es cuando la ejecución
de la lógica es programada y enviada por un programador implementado.
3.2.5 Control de transferencia Asíncrona.
Algunas veces el mundo real cambia drásticamente (y de manera
asíncrona) que el punto actual de la ejecución lógica de ser transferida inmediata y
eficientemente a otra locación. La RTSJ incluye un mecanismo el cual permite el
manejo de excepción de Java permitir a las aplicaciones cambiar
programaticamente el lugar del control de otro hilo de Java. Es importante
observar que la RTSJ restringe esta transferencia asíncrona de control a la lógica
51
escrita específicamente con el acuerdo que su lugar de control puede cambiar de
manera asíncrona.
3.2.6 Terminación de Hilos Asíncronos.
Nuevamente, debido a que algunas veces los cambios asíncronos y
drásticos en el mundo real, la aplicación lógica puede necesitar arreglar para un
hilo de JRT, transferir expedita y seguramente su control a su punto más lejano del
rango y por lo cual termina de una manera normal. Se observa que probablemente
el mecanismo de Java tradicional, inseguro y desaprobado mecanismo de Java
para detener hilos, el mecanismo de la RTSJ para el manejo y transferencia de
eventos asíncronos es seguro.
3.2.7 Acceso a la Memoria Física.
Aunque no es un problema directo de tiempo real, el acceso a la memoria
física es deseable por muchas de las aplicaciones que podrían hacer
productivamente el uso de una implementación de la RTSJ. Se define una clase
que permita a los desarrolladores un acceso de nivel byte a la memoria física, así
como otra que permita la construcción de objetos dentro de la misma.
3.3 Planificación.
Uno de los aspectos concernientes a la programación en tiempo real es
asegurar una ejecución de secuencias de instrucciones máquina que sean
correctas y predecibles en el tiempo. Los diferentes esquemas de planificación
llaman a estas secuencias de instrucciones de diferentes formas. Los nombres
típicamente usados incluyen los hilos, tareas, módulos y bloques. RTJS introduce
52
el concepto de objeto planificlable (schedulable object). Estos son objetos que
administran el planificador base, RealtimeThread y sus subclases junto a
AsyncEventHandler y sus subclases.
“Timely execution of schedulable objects” significa que el programador
puede determinar si los hilos completaran siempre su ejecución en base a unos
requisitos de tiempo dados mediante el análisis del programa, probando el
programa en implementaciones concretas, o haciendo ambas cosas. Ésta es la
esencia de la programación en tiempo real: la adición de requisitos temporales
para establecer las condiciones correctas de computación.
Se utiliza aquí el termino planificación (o algoritmo de planificación) como la
producción de un orden de ejecución para un conjunto de objetos planificables
(schedulable objects). Esta planificación trata de optimizar una métrica en
particular (una métrica que mida si se ajusta correctamente el sistema a los
requisitos temporales). Un análisis de viabilidad determina si una planificación
tiene un valor aceptable para dicha métrica.
Muchos sistemas utilizan la prioridad en los hilos para tratar de determinar
una planificación. La prioridad suele ser un entero asociado a un objeto
planificable, esta prioridad indica al sistema el orden en que deben ejecutarse los
hilos.
Generalizando el concepto de prioridad aparece el concepto de execution
elegibility. Utilizamos el término envío a ejecución para hablar de la parte del
sistema encargada de elegir el hilo con la mayor execution elegibility del conjunto
de hilos que están listos para ejecución. En los sistemas de tiempo real actuales la
asignación de prioridades suele estar bajo control del programador en oposición
de un control por parte del sistema. El planificador base de RJST también permite
al programador controlar la asignación de prioridades. Sin embargo, el planificador
53
base también hereda métodos de su superclase que deben ayudar a determinar la
viabilidad.
Para el planificador base, los métodos deben asumir un procesador
suficientemente rápido para completar cualquier carga propuesta en la
planificación. En RTSJ se espera que el planificador base sea utilizado como clase
padre en implementaciones particulares, y para estas implementaciones, los
métodos de viabilidad deben indicar correctamente la viabilidad real del sistema
según la planificación dada por la RTSJ requiere unas clases con el formato de
nombre <string>Paremeters (por ejemplo SchedulingParameters). Una
instancia de uno de estas clases 'parámetros' representa una demanda de
recursos para uno o más objetos planificables. Por ejemplo la subclase
PriorityParameters contiene la métrica execution elegibility del planificador
base, por ejemplo prioridad. En algún momento las instancias de estas clases
parámetros se ligan a un objeto planificable. Los objetos planificables asumen
entonces las características de los valores en el objeto parámetro.
RTSJ está hecho de forma que se pueden instalar otros algoritmos de
planificación y algoritmos de análisis de la viabilidad en una implementación de la
especificación. Esto se hace porque entendemos que los sistemas de tiempo real
existentes en la industria han tenido requisitos muy variados respecto a la
planificación. El uso de la plataforma Java ayuda a producir código fuente portable
(Write Once, Run anywhere). RTSJ contribuye a este objetivo por un lado y no lo
hace por otro, ya que también se permiten planificadores específicos de la
plataforma (que no son portables).
3.4 Gestión de memoria.
El colector de basura de memoria siempre ha sido considerado un
obstáculo para la programación en tiempo real, ya que introduce latencias
54
impredecibles. RTSJ proporciona varias extensiones al modelo de memoria, que
soporta una gestión de memoria que no interfiere con el código en tiempo-real.
Este objetivo se consigue permitiendo la ubicación de objetos fuera del montón
tanto para objetos short-lived y long-lived.
3.4.1 Áreas de memoria.
RTSJ introduce el concepto de área de memoria. Un área de memoria es
una porción de memoria que se debe usar para la ubicación de objetos. Algunas
áreas de memoria existen fuera del montón y restringen lo que el sistema y el
colector de basura pueden y deben hacer con los objetos ahí ubicados.
Algunos objetos en estas áreas de memoria nunca son tratados por el
colector, sin embargo el colector debe ser capaz de escanear estas áreas de
memoria en busca de referencias a objetos que estén en el grupo, para conservar
la integridad del mismo.
Hay cuatro tipos básicos de áreas de memoria:
1. Scoped memory que proporciona un mecanismo para la gestión de objetos
que tienen un tiempo de vida definido por su alcance.
2. Memoria física, permite la creación de objetos en regiones específicas de
memoria que tienen alguna característica importante (por ejemplo una
región que tiene un acceso más rápido).
3. Memoria inmortal; representa un área que contiene objetos que hacen
referencia desde objetos planificables sin excepciones ni retraso causado
por el colector de basura.
4. Montón (heap memory). RTSJ no cambia el tiempo de vida de los objetos
del montón. El tiempo de vida es todavía determinado por visibilidad.
3.5 Sincronización.
55
3.5.1 Colas de espera.
La espera de hilos y manejadores de eventos asíncronos para adquirir un
recurso debe ser liberada en el orden de preferencia de ejecución. Esto se aplica
tanto al procesador como a bloques de código donde se hace sincronía (secciones
críticas,…). Si existen varios objetos planificables con la misma preferencia de
ejecución se irá despertando a dichos objetos en orden de llegada (FIFO).
3.5.2 Prevención de la inversión de prioridades.
RTSJ provee una implementación de la primitiva synchronized con un
comportamiento por defecto que asegura que no exista una inversión de
prioridades ilimitada.
El protocolo de herencia de prioridades debe implementarse por defecto. La
especificación también proporciona un mecanismo para que el programador pueda
pasar por alto esta política, o sustituirla por la que a él le interese.
3.5.3 Determinismo.
La implementación debe ofrecer un límite superior en cuanto al tiempo de
espera necesario para que se libere un monitor o un cerrojo.
3.6 Manejo de eventos asíncronos.
Para el manejo de eventos asíncronos se tienen dos clases, AsyncEvent y
AsyncEventHandler. Un objeto AsyncEvent representa algo que puede
56
suceder, como puede ser una señal POSIX, una interrupción hardware o cualquier
otro evento.
Cuando ocurre uno de en estos eventos, las instancias de
AsyncEventHandler asociada a dichos eventos son programadas y se invoca el
evento handleAsyncEvent para que haga lo necesario en atención al evento.
AsyncEvent proporciona métodos para establecer los manejadores asociados al
evento.
Una instancia de AsyncEventHandler es similar a un hilo. Es un objeto
ejecutable (Runnable). Lo que distingue un AsyncEventHandler de los demás
objetos ejecutables es que éste tiene asociadas instancias de
ReleaseParameters, SchedulingParameters y MemoryParameters que
controlan la ejecución del manejador cuando se dispara el evento correspondiente.
Cuando ocurre un evento, los manejadores se ejecutan de forma asíncrona de
acuerdo a los parámetros establecidos de tal forma que parece que el manejador
tiene asignado su propio hilo. Se espera que el sistema sea capaz de manejar
correctamente un gran número de instancias de AsyncEvent y
AsyncEventHandler. El número de manejadores que se ejecuten se espera que
sea menor.
Una forma especializada de AsyncEvent es la clase Timer, que
representa un evento cuya activación está dirigida por el tiempo. Hay dos tipos de
timers: OneShotTimer y PeriodicTimer. Las instancias de OneShotTimer se
disparan una sola vez, las de PeriodicTimer se disparan inicialmente al tiempo
especificado y tras esta vez, se repiten periódicamente según el intervalo de
tiempo especificado.
Los timers son dirigidos por objetos del tipo Clock. Existe un tipo de reloj
que representa un reloj de tiempo real, se llama Clock.getRealtimeClock. La
clase Clock puede extenderse para representar otros relojes.
57
3.7 Transferencia asíncrona del control.
En muchas ocasiones un programador de tiempo real se encuentra con una
situación en la que el costo computacional de un algoritmo es muy variable, el
algoritmo es iterativo y produce resultados más refinados en cada iteración. Si el
sistema, antes de empezar la ejecución, puede determinar solo un límite de tiempo
de cuanto tardará la ejecución, entonces utilizará la transferencia de control
asíncrona para transmitir los resultados tras el límite de tiempo establecido puede
ser un modo de programación adecuado. RTSJ soporta este y otros estilos de
programación que harán uso de transferencia asíncrona del control.
La aproximación que RTSJ usa para conseguir la transferencia asíncrona
del control se basa en varios principios enumerados a continuación.
3.7.1 Principios Metodológicos.
• Aunque un método permita transferencia asíncrona del control, algunas
secciones de código deben ejecutarse hasta que se completen; en tal caso
transferencia asíncrona del control queda diferido. Estas secciones son
métodos de sincronización, inicializadores estáticos y sentencias
sincronizadas.
• El código que responde a la transferencia asíncrona del control no vuelve al
punto del objeto planificable donde se disparó el transferencia asíncrona del
control; esto es, transferencia asíncrona del control es una transferencia de
control sin condiciones.
58
3.7.2 Principios de expresibilidad.
• Un mecanismo que necesita de transferencia asíncrona del control puede
ser disparado explícitamente en un objeto planificable. Este lanzamiento
puede ser directo (desde un hilo a un objeto planificable) o indirecto (a
través de un manejador de eventos asíncrono).
• Debe ser posible lanzar una transferencia asíncrona del control basándose
en cualquier evento asíncrono.
• Utilizando transferencia asíncrona del control debe poderse abortar hilos de
tiempo real de una forma que no conlleve los riesgos de los métodos
stop() y destroy() de la clase Thread.
3.7.3 Principios semánticos.
● Si la transferencia asíncrona del control se modela sin manejo de
excepciones debe existir algún mecanismo que asegure que si ocurre una
excepción asíncrona, que esta sea capturada sólo por el manejador
especificado, y no por el resto de manejadores de propósito general que se
encuentran en el camino de propagación de las excepciones.
● Los transferencias anidadas no deben funcionar correctamente. Considere
por ejemplo dos timers anidados basados en transferencia asíncrona del
control, y suponga que el timeout del timer exterior es menor que el del
timer anidado. Si el timer exterior finaliza mientras el control se encuentra
en el código anidado, entonces el código anidado será abortado y el control
transferido a cláusula ctransferencia asíncrona del controlh apropiada para
el timer exterior. Una implementación que maneje el timeout exterior en el
código fuente o que espere al timer más largo es incorrecta.
59
3.7.4 Principios Prácticos.
● Deberían existir idiomas directos para los casos comunes como
manejadores de timers o terminación de hilos de tiempo real.
● Si un código con un timeout acaba antes de que expire el timer, éste debe
ser parado de forma automática, y sus recursos devueltos al sistema.
3.8 Terminación asíncrona de hilos de tiempo real.
Aunque esta cuestión no es un aspecto único de tiempo real, muchos
sistemas dirigidos por eventos que interactúan con el mundo real (con humanos,
máquinas, etc.) pueden requerir cambios en el comportamiento de su cómputo
como resultado de cambios significantes en el mundo real. Sería conveniente
programar hilos que terminan de forma anormal cuando el mundo cambia de
forma que el hilo deja de ser útil. Sin esta facilidad, un hilo o un conjunto de hilos
deben ser programados de forma que su comportamiento se anticipe a los
posibles cambios de estado del sistema externo. Es una tarea más sencilla
codificar hilos que cooperen solo para uno (o unos pocos) de los posibles estados
del sistema externo. Cuando el sistema externo cambia de estado, el cambio en el
comportamiento de la computación debe ser manejado por un 'oráculo' que se
encarga de finalizar el conjunto de hilos útiles en el estado anterior e invoque un
nuevo conjunto de hilos apropiado al nuevo estado del sistema externo. Puesto
que los posibles cambios de estado del sistema externo se codifican solamente en
el oráculo y no en cada hilo, el diseño del sistema resultante es más sencillo.
Versiones anteriores de Java proporcionaban mecanismos para conseguir
estos efectos: en particular los métodos stop() y destroy() de la clase
Thread. Sin embargo, puesto que stop() puede dejar los objetos compartidos
en un estado inconsistente, stop() se ha considerado obsoleto. El uso de
destroy() puede conducir a un estado erróneo si un hilo es destruido mientras
60
mantiene bloqueado un cerrojo. Uno de los objetivos de RTSJ era conseguir los
requerimientos de terminación asíncrona de hilos sin introducir peligros similares a
los que existen con los métodos stop() o destroy().
RTSJ consigue una terminación asíncrona de hilos en tiempo real de forma
segura utilizando una combinación de manejadores de eventos asíncronos y de la
transferencia de control asíncrona. Para crear un juego de hilos en tiempo real
considera los siguientes pasos:
1. Hace que todos los métodos del hilo en tiempo real puedan
interrumpirse.
2. Crea un oráculo que monitoriza el mundo externo a través de un número
de manejadores de eventos asíncronos.
3. Hacer que los manejadores de eventos interrumpan cada uno de los
hilos afectados por el cambio.
4. Tras la interrupción deben crear un nuevo conjunto de hilos apropiado al
estado del mundo externo.
3.9 Acceso a memoria física. RTSJ define clases para programadores que deseen acceder directamente
a memoria física desde código escrito en lenguaje Java. RawMemoryAccess
define métodos que permiten al programador construir un objeto que representa
un rango de memoria física.
El acceso a memoria física se consigue a través de los métodos
get[type]() y set[type](), donde type indica el tamaño de palabra ( byte,
short, int, long, float y double). Las clases VTPhysicalMemory,
LTPhysicalMemory e InmortalPhysicalMemory permiten construir un objeto
que representa un rango de direcciones de memoria física.
PhysicalMemoryManager es una clase disponible para su uso por varios
61
objetos que acceden a memoria física (VTPhysicalMemory,
LTPhysicalMemory, InmortalPhysicalMemory, RawMemoryAccess y
RawMemoryFloatAccess) para crear objetos del tipo correcto que se limitan a
áreas de memoria física con las características apropiadas.
3.9.1 Acceso a memoria “en crudo”.
La clase RawMemoryAccess modela un rango de memoria física como una
secuencia fija de bytes. Un complemento de los métodos de acceso permite
acceder a los contenidos del área física utilizando diferentes tamaños de palabra,
interpretando así los datos como byte, short, int, o long o como arreglos de estos
tipos.
La clase RawMemoryAccess permite implementar en un programa en
tiempo real, los controladores de dispositivos de entrada/salida a bajo nivel. Un
área de memoria de este tipo no puede contener referencias a objetos Java.
3.9.2 Áreas de memoria física.
En muchos casos la necesidad de que la ejecución sea predecible nos lleva
a necesitar diferentes tipos de acceso a memoria por motivos de rendimiento o por
otros motivos. Las clases VTPhysicalMemory, LTPhysicalMemory y
InmortalPhysicalMemory permiten esta flexibilidad. El programador construirá
un objeto de memoria física en la dirección ocupada por la RAM más rápida.
62
CAPITULO IV
EJEMPLOS DE APLICACIÓN DE JAVA REAL TIME
63
4.1 JStamp.
La compañía Systronix, ha creado un procesador de un tamaño de 1.0” x
2.0”, el cual ha sido diseñado específicamente para trabajar con Java, este puede
procesar 3 millones de bytecodes por segundo a una velocidad de 74Mhz, además
de contar con las bondades del lenguaje Java, también cuenta con el respaldo de
la ejecución de JRT, ver figura 1.10.
4.1.1 Ejecución normal de Java con soporte de Java Real Time.
El JStamp usa el poderoso procesador aJ-80 nativo de Java de los
sistemas aJile. Este provee eficiencia y rapidez en la ejecución de una instrucción
en Java, además de una impresión mas densa, 2 a 3 veces mas densa que el
código para 32-bit de RISC.
Incluye un administrador de hilo de JRT microprogramado con funciones
RTOS típicas incluidas. De la misma manera hilos primitivos implementados como
instrucciones atómicas, un programador de base prioritario y un contexto de
intercambio extremadamente rápido y de interrupción de respuesta.
JStamp es multitarea a través de múltiples maquinas virtuales de Java en
los cuales las aplicaciones se ejecutan en determinado espacio de tiempo
programable. Cada aplicación tiene su propio administrador de hilos y manejo de
eventos.
64
4.1.2 Memoria.
JStamp esta listo para trabajos reales con 512kb de SRAM y 512KB de
Flash (2 MB sobre JStamp+). El código puede ser ejecutado desde la flash o
SRAM debido a que la maquina virtual de Java esta dentro de un conductor de
silicón, toda la memoria esta disponible para su aplicación. Debido a su
conducción por medio del silicón no permitirá que la ejecución de cualquier
software sea lenta.
4.1.3 Beneficios y Casos de Éxito.
Algunos de los beneficios que podemos mencionar son los siguientes:
• Su precio estimado de USD $100, en cantidades moderadas.
• Utiliza en recolector de basura de Java.
• Trabaja con hilos.
• Se puede trabajar con cualquier herramienta estándar de Java para crear
sus propios programas de JStamp.
• Utilizado dentro del proyecto Sumo Robot dentro el festival Robonexus
2005.
• La Universidad de Utah ha incluido a JStamp dentro de sus proyectos de
investigación.
Figura 4.1 Microprocesador JStamp.
Fuente: Systronix Inc. (2007)
65
4.2 IBM/Apogee Aphelion
Aphelion esta comprendido en los ambientes de ejecución de Java (JREs
en ingles) y en los del desarrollo de Java (JDEs en ingles) basados en las
tecnologías de Java autorizadas por Apogee de IBM, que se aumentan con las
tecnologías obtenidas de proveedores de código abierto de Java software o
desarrolladas por Apogee según las necesidades de sus clientes.
Aphelion JREs se crea para las plataformas de RTOS/processor (por
ejemplo, la plataforma eLinux/x86 comprendida de un procesador de una base-x86
que funciona en una de las versiones empotradas de Linux) solicitadas por los
clientes de Apogee dirigidas hacia cada una de las plataformas de IBM
compatibles tales como J2ME, La Maquina virtual J9 (J9VM) y a las bibliotecas
comúnmente usadas de la clase de Java. Por lo cual, Apogee personaliza cada
JRE para requisitos particulares según las necesidades específicas de un cliente
dado, sintoniza el JRE para el alto funcionamiento de ejecución y la marca de
ejecución pequeña cuando se ejecutan las aplicaciones de los clientes en Java, y
hace una prueba a fondo al JRE con J2ME TCK (kit de compatibilidad de
tecnología) prueba de paquetes.
Por ejemplo, Apogee puede incluir en un JRE dado:
Implementaciones de paquetes de Java API definidos por varias peticiones
de la especificación de Java (JSRs), J2ME-specific , tales como soporte de
XML y paquetes de servicios web definido por JSR-172.
Ejecuciones Cliente-side para varios servicios de cliente-servidor, tales
como ejecución del OSGi de el Eclipse Equinos OSGi R4 Framework.
Paquetes de nivel-aplicación de IBM o de proveedores de código abierto de
Java software, por ejemplo servidor de mensaje de Java (JMS)
66
perteneciente a el Kit de herramientas de micro ambientes de IBM para
WebSphere Studio o Tomcat servlet container de apache.org.
Las tecnologías básicas de Java utilizadas en el Aphelion JREs, tales como
la CDC (configuración de dispositivo conectado) y CLDC (configuración de
dispositivo limitado conectado) compatibles con la JVM, las bibliotecas de las
clases de Java y las implementaciones de los paquetes de Java API definidos por
varios J2ME-specific de JSRs, provenientes de WebSphere Everyplace Micro
Environments (WEMEs) de IBM, compatibles con la plataforma J2ME de Sun. Las
tecnologías adicionales para JREs específicos provienen de WebSphere
Everyplace Custom Environments (WECEs) de IBM o de los proveedores de
código abierto de Java software. Apogee ha creado algunas tecnologías (por
ejemplo, una puesta en práctica de la API para Bluetooth definido por JSR-82).
Si un cliente hiciera una petición, cada aphelion JRE puede ser provisto con
un JDE correspondiente (dirigido a la misma plataforma de RTOS/processor) el
cual facilite el desarrollo eficaz, prueba, depuración de errores y la sintonía del
funcionamiento de los aplicaciones de Java dirigidos a el JRE.
El JDE de Aphelion se deriva del Workplace Client Technology, Micro
Edition (WCTME) de IBM, los productos relevantes de los cuales, WebSphere
Studio Device Developer (WSDD) y el Micro Environment Toolkit for WebSphere
Studio (METWS), están incluidos parcial o totalmente en cada JDE según las
necesidades de un cliente dado. Por ejemplo, cada JDE incluye el GUI de WSDD,
sistema de ficheros, encargado de proyecto, redactores, browsers, un recopilador
de Java--bytecode, depuración del bytecode, analizador y perfil de la ejecución,
SmartLinker (optimizador de AOT de la ejecución impresa), las herramientas, caja
de herramientas de ANT, etc.
Juntos, Apehlion, JREs y JDEs abarcan un ofrecimiento comprensivo del
software que permite el desarrollo y despliegue eficaces de los usos de Java
67
dirigidos en una amplia gama de los dispositivos basados en las plataformas de
RTOS/processor solicitados por los clientes de Apogee, tales como:
• Dispositivos de comunicación inalámbricos, incluyendo dispositivos
avanzados como GPS y sistemas telemáticos.
• Aplicaciones electrónicas del consumidor (PDAs, teléfonos inteligentes, PC
de bolsillo, set-top boxes, home gateways, etc.).
• Dispositivos industriales (monitores, reguladores de procesos, gateways,
etc.).
• Dispositivos usados en la automatización de plantas (fabricas) (robots,
sensores, etc.).
• Dispositivos de clientes usados en la administración de empresas y sistema
de monitoreo.
• Lectores de RFID, servidores "extremos" y servidores premisos.
• Terminales de punto de venta y otros dispositivos utilizados en ventas al por
menor.
• Dispositivos telemáticos y de infotainment.
El Aphelion JREs y JDEs también brinda a los desarrolladores de software
en Java para sistemas empotrados, la mayoría de las ventajas que hicieron la
plataforma de Java altamente exitosa en los sistemas empresariales y de
escritorio, por ejemplo:
• La creación de aplicaciones en Java más cortos y menos frecuentes en
ciclos de desarrollo comparados con la creación de aplicaciones
funcionalmente equivalentes usando otros lenguajes de programación.
• Despliegues de ejecución más simples y confiables de aplicaciones en Java
comparado con el despliegue de aplicaciones escritos en otros lenguajes de
programación.
• Menos ayuda técnica y mantenimiento costoso de usos desplegados,
especialmente en el caso de aplicaciones con largos life-spans.
• Fácil Migración de aplicaciones a otras plataformas destino.
68
4.3 WebLogic Real Time 2.0
WebLogic Real Time 2.0 es un motor de alto rendimiento que refuerza SOA
orientada a evento. [10]
BEA Systems, compañía global en software de infraestructura empresarial,
anuncia WebLogic Real Time 2.0, una tecnología basada en Java y la única
solución en tiempo real con un tiempo de pausa de microsegundo garantizado
para aplicaciones Java estándar, sin necesidad de una codificación específica.
BEA WebLogic Real Time 2.0 eleva la latencia y el rendimiento, ya que el
tiempo de pausa es de 10 milisegundos máximo y la media de pausa se encuentra
por debajo del milisegundo. Esta mejora en el rendimiento se alcanza gracias a la
optimización extrema y a las nuevas técnicas de latencia. En algunas aplicaciones
de un sector determinado y de misión crítica, un nivel de latencia garantizado por
debajo del segundo supone un gran incremento de beneficios.
El producto permite mejorar la productividad del desarrollador y la
estandarización más allá de los dominios, como es el caso del mercado financiero
y los sistemas de control que han sido programados tradicionalmente en C o C++.
Además de acercar Java a mercados con requerimientos en tiempo real, BEA fue
la primera compañía en introducir Java en el mercado de la virtualización y ahora
también en el mercado de la arquitectura orientada a eventos (SOA) con
WebLogic Event Server. WebLogic Real Time junto a WebLogic Event Server y
WebLogic Server – Virtual Edition proporcionan una base sólida imprescindible
para facilitar SOA orientada a evento y procesos de transacción extremos.
Otra nueva funcionalidad en WebLogic Real Time 2.0, es la herramienta de
análisis de latencia que proporciona a los desarrolladores la capacidad de analizar
69
e integrar fuentes de latencia en sus aplicaciones, garantizando un tiempo de
solución inferior al nanosegundo. La herramienta mejora de forma significativa la
productividad del desarrollador y también reduce la latencia para aplicaciones end-
to-end.
WebLogic Real Time está diseñado para permitir a los clientes rapidez en el
time-to-market para aplicaciones en tiempo real y generar un menor coste total de
propiedad.
4.4 WebSphere Real Time.
WebSphere Real Time permite a clientes construir aplicaciones
dependientes en un tiempo de respuesta preciso para tomar ventaja de la
tecnología de Java estándar; sin sacrificar el determinismo.[11]
WebSphere Real Time contiene un stand-alone de la edición V5 de Java
estándar basado en el ambiente de ejecución de Java (JRE) con el kit de
desarrollo de software (SDK):
Amplia la plataforma de Java para soportar aplicaciones en tiempo
real: Compila con la RTSJ.
Provee una alternativa realista para la programación en tiempo real:
Las aplicaciones pueden usar el modelo de programación de Java
estándar, en lugar de los lenguajes de bajo nivel como, Ada 95, C, o
C++.
Tiempo de respuesta medido en milisegundos: Cuando una
característica crítica de la aplicación requiere tiempo de respuesta en
sub-segundo.
70
Tecnología de recolección de basura para Tiempo Real única: Evita
pausas imprevisibles en las aplicaciones en Java para la colección
de la basura.
WebSphere Real Time contiene un stand-alone de la edición 5 de Java
estándar con ambiente de ejecución optimizado para correr sobre un sistema
operativo de Linux en tiempo real de código abierto. Funcionará solamente en el
Linux modificado para requisitos particulares. La ayuda para este ambiente de
Linux está disponible en IBM. A diferencia de WebSphere Application Server, este
no incluye servidor de aplicación de Java Enterprise Edition.
WebSphere Real Time V1.0 contiene un ambiente de ejecución de Java
(JRE) con el kit de desarrollo de software (SDK) que trae las siguientes
capacidades:
Colección de basura en tiempo real: Simplifica grandemente el
desarrollo de aplicaciones en tiempo real del usando la programación
estándar de Java.
Especificación en tiempo real para Java (RTSJ): IBM proporciona
una biblioteca de clases de RTSJ.
Compilación por adelantado (Ahead-of-Time): Pre-compilación de
código para alcanzar un mejor funcionamiento que la compilación
interpretada y más tiempos de respuesta predicibles que la
compilación en tiempo preciso (Just-in-Time).
Ayuda ejecutable de Java: Mejora funcionamiento con carga
dinámica de clases.
71
CONCLUSIONES
72
En el siglo XXI, se puede encontrar un sin fin de avances en la tecnología,
hoy se encuentran computadoras en cualquier parte de nuestro entorno, la
información que fluye a través de los medios es cada día mayor, son cientos y
cientos de bytes de información transmitiéndose por Internet; esto da por
consiguiente que se necesite tener a dicha información en el momento preciso y
fidedigna.
Con el surgimiento de los sistemas distribuidos se dio gran avance en el
compartimiento de información, pero aun así no era suficiente, se había dado un
gran paso, el poder tener la información que se encontraba en el edificio de
enfrente, o quizá en el departamento que se encontraba en el segundo piso, o en
la computadora de al lado, pero que pasaba, la información tenia que actualizar su
propietario cada vez que se necesitaba, ya que el que la solicitaba no tenia
acceso total, existían limitantes.
En la información aquí presentada, se muestra como los sistemas
distribuidos son de gran importancia en los diferentes sectores de la humanidad,
debido a la gran necesidad de la información.
Cuando los SDTR aparecen, ahora ya no solo se compartía la información,
sino que estaba actualizada y disponible en el momento que se necesita, esto vino
a ser posible en parte al Internet, la gran red que permite compartir la información
y hacer que los sistemas distribuyan sus recursos a través de.
Cada momento en el que se interactúa con un sistema de información se
genera información, la cual es importante para cada uno de quien la realiza, se
puede volver imprescindible, por ejemplo, un contacto, un cliente, proveedor,
agente de seguros, etc., cuando esta fuera de casa o de la oficina y no lleva
consigo su laptop, PDA o algún otro dispositivo que pueda portar dicha
información, es necesario acceder a ella por medio de otro equipo, compartir la
73
información que se genera es muy importante y es posible por los sistemas
distribuidos en los que hoy en día la herramienta mas utilizada, y que decir
aquellos en tiempo real, gracias a estos avances se puede obtener esa
información que se pudo a ver quedado olvidad en casa o la oficina, utilizando
escritorios remotos o servidores ftp por ejemplo.
El servicio de mensajería instantánea es otro ejemplo de trabajo en tiempo
real y que además se puede compartir información.
Se pueden mencionar un sin fin de ejemplos, con los cuales se ejemplifica
como se interactúa con los sistemas y como los sistemas interactúan con el medio
ambiente, lo cual los hace ser sistemas en tiempo real.
Algo que es importante aclarar es que tiempo real, no significa que sea mas
rápido, sino que los sistemas están en constante interacción con el medio
ambiente, por ejemplo, los sensores instalados en una carretera informan cuantos
vehículos están circulando por cierta calle a cierta hora, también muestran la
velocidad promedio en los que estos circulan, esto es un ejemplo de la interacción
de los sistemas y en tiempo real, se esta obteniendo la información que esta
pasando en cierto tiempo.
Hoy en día la toma de decisiones es algo muy importante, y una
herramienta crítica para realizar dicha actividad es la información, tenerla pues en
el momento exacto ayudara a que se tomen decisiones claves para cierta
institución o empresa.
Es por eso que los sistemas en tiempo real se han vuelto herramienta clave
en el éxito de las empresas, hoy en día la empresa que no comparte su
información la hace obsoleta y poco atractiva a la inversión.
74
Que decir de un país, que pasaría si México por ejemplo no compartiera su
información a través de la bolsa de valores, nadie sabría que se puede invertir o
dejar de invertir, los avances que pueda tener un país depende mucho de esto, es
donde aparece la necesidad de los SDTR.
Desarrollar aplicaciones confiables y seguras son una gran necesidad hoy
en día.
Java se presenta en este trabajo como una gran opción para los
desarrolladores, una de sus ventajas muy importante es que es libre y compatible
con diferentes plataformas.
Java se ha vuelto el favorito de los desarrolladores de código libre, en esta
monografía se puede encontrar varios ejemplos de aplicación, los cuales
proporcionan una vista del panorama de los SDTR basado en Java.
Así como es de gran necesidad contar con la información en el momento
preciso, también se debe de tomar en cuenta otros aspectos, como son, el ahorra
de mermaría, optimización de recursos y tiempo, desarrollar sistemas bajo la
plataforma de Java Real Time puede brindar soluciones a estas necesidades.
Cuando se desarrollan aplicaciones o sistemas enteros con Java, se realiza
con la tranquilidad que da el respaldo de un lenguaje bastante robusto,
multiplataforma, lo que nos garantiza una ejecución sin problemas.
Es importante tomar en cuenta que aun cuando un lenguaje de
programación, sea este Java o cualquier otro, brinden la característica de ser muy
seguros, hay que considerar las características de los equipos en los cuales se
han de montar los servicios, aplicaciones o sistemas, para poder tener un
funcionamiento idóneo.
75
La información que se ha reunido para presentar este trabajo, se espera
que sea de gran ayuda para quien desee saber mas de los sistemas en tiempo
real basados en Java.
Esta monografía puede ser el comienzo de muchos otros trabajos que
pueden ser un gran aporte para los cuerpos académicos y grupos de investigación
de la facultad de Sistemas Computacionales Administrativos
76
Bibliografía.
Dibble, P.C. (2002). Real-Time Java Platform Programming, E. U., Prentice-Hall
Coulouris G., Dollimore J., Kindberg T., (1994). Distributed Systems Concepts and
Design, E.U., Addison Wesley,
Andrew, S. Tanenbaum; tr. Oscar Alfredo Palmos Velasco, (1996). Sistemas
Operativos Distribuidos, México. Prentice Hall Hispanoamericano.
Bocardo Quezada, Alfredo. (1994). Desarrollo de Sistemas Distribuidos bajo el
modelo Cliente – Servidor, Tesis de licenciatura, Universidad Veracruzana,
Cornafion, Fracoise A.. (1987). Sistemas Informáticos Distribuidos, Barcelona.
Omega.
Alan, Burns; Andy Wellings; tr. Cesar Llamas [et al]. (2003). Sistemas de Tiempo
Real y Lenguajes de Programación (2da. Ed.). Madrid, Addison Wesley.
Tsai, Jeffrey J.P. (1996). Distributed real-time systems: Monitoring, Visualization,
Debugging and Analysis. New York. Wiley.
Laplante, Phillip A. (1993). Real- Time systems design and analysis: an engineer’s
handbook. New York. Institute of Electric and Electronics Engineers.
77
Direcciones de Internet.
Categorías de los Sistemas Distribuidos.
Instituto Tecnológico La Paz, Departamento de Sistemas y Computación,
Programa “elaboración de Tutoriales”, Tutorial de Sistemas Distribuidos, (n.d.).
Extraído el dia 13 de junio del 2007 desde:
http://sistemas.itlp.edu.mx/tutoriales/sistsdist1/u1parte3.htm
Características clave de los sistemas distribuidos.
Rojo, Oscar J. (2003). Introducción a los Sistemas Distribuidos. Extraído el día 19
de junio del 2007 desde:
[2] http://www.augcyl.org/?q=glol-intro-sistemas-distribuidos
Ventajas y desventajas de los sistemas distribuidos.
[3] López Posada, José A., (n.d.). Sistemas Distribuidos. Extraído el día 20 de
junio del 2007 desde:
http://www.itistmo.edu.mx/Pag%20Informatica/APUNTES_archivos/page0005.htm
Instituto Tecnológico La Paz, Departamento de Sistemas y Computación.
Programa “elaboración de Tutoriales”, (n.d.). Tutorial de Sistemas Distribuidos.
Extraído el día 28 de junio del 2007 desde:
http://sistemas.itlp.edu.mx/tutoriales/sistsdist1/u1parte2.htm
Características de los Sistemas Distribuidos en Tiempo Real.
[4] Martínez, David la Red, (2001). Sistemas Operativos: Planificación de
Multiprocesadores y en Tiempo Real. Extraído el día 15 de julio del 2007 desde:
http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/PLA
PRO02_archivos/caracteristicas_de_los_s.o._en_t.r..htm
Arquitectura de un sistema operativo de tiempo real.
78
[5] Sánchez, Moreno F. M. (2007). Arquitectura de un sistema operativo de tiempo
real. Extraído el día 18 de julio del 2007 desde:
http://www.ciclope.info/doc/rtos/rtos.php
Activación de los sistemas en tiempo real.
[6] Zamorano, Flores Juan, Francisco Manuel Sánchez Moreno, (n.d.). Sistemas
de Tiempo Real: curso 2006/2007. Extraído el día 20 de julio del 2007 desde:
http://laurel.datsi.fi.upm.es/~ssoo/STR/
Especificación de Java Real Time.
[7] Sun microsystems, Sun Developer Network, (n.d.). Java SE Real-Time.
Extraído el día 4 de agosto del 2007 desde:
http://java.sun.com/javase/technologies/realtime/index.jsp
Java Community Process (2006, 12 de Julio). JSR 1: Real-time specification for
Java. Extraído el día 5 de agosto del 2007 desde: http://jcp.org/en/whatsnew/jcp
Principios Guía de Java Real Time
[8] TimeSys Corporation (2006, Junio). JSR001 Real-time Specification for Java.
Extraído el día 10 de agosto del 2007 desde:
http://www.rtsj.org/specjavadoc/book_index.html
The Real-Time for JavaTM Expert Group, (2001, diciembre). The Real Time
Specification for Java. Extraído el día 13 de agosto del 2007 desde:
https://rtsj.dev.java.net/
Jstamp, Ejemplo de Aplicación de JRT.
[9] Systronix, Inc., (n.d.). JStamp Information: Datasheet. Extraído el día 18 de
agosto del 2007, desde:
http://jstamp.systronix.com/Resource/jstamp_datasheet.pdf
WebLogic Real Time 2.0
79
[10] CMS-Spain.com Noticias. (2007, Junio). BEA lanza WebLogic Real Time 2.0
para aplicaciones Java. Extraído el día 21 de agosto del 2007, desde:
http://www.ecm-spain.com/noticia.asp?IdItem=8127
[11] WebSphere Real Time
IBM. (n.d.). WebSphere Real Time – Product Overview. Extraído el día 22 de
agosto del 2007, desde: http://www-306.ibm.com/software/webservers/realtime/
80
GLOSARIO
81
Pooling. Agrupar, acción de formar grupos o reunir en conjunto varios elementos
para maximizar ventajas. Termino utilizado en muchas disciplinas.
Internetworks. Que va de una red de trabajo a otra.
RM-ODP. Modelo de referencia ISO para Ambientes Distribuidos Abiertos (Open
Distributed Environments).
Middleware. Software que funciona como traducción o una conversión. También
puede ser un consolidador o integrador. Su función especifica es la de lograr la
comunicación de una aplicación a otra, las cuales pueden estar siendo ejecutadas
en diferentes plataformas.
ODBC (Open DataBase Conectivity). Interfase de programación de base de
datos realizada por Microsoft, la cual provee una lenguaje de común para las
aplicaciones de Windows para acceder a bases de datos en una red.
HTTP (Hyper Text Transfer Protocol). Protocolo de comunicaciones utilizado
para conectar a los servidores en la Red. Su principal función es establecer la
conexión con un servidor web y transmitir paginas HTML a los navegadores de los
clientes y cualquier otros archivos requeridos por una aplicación HTML.
SSL (Secure Sockets Layer). Protocolo líder en Internet, desarrollado por
Netscape, SSL es ampliamente utilizado para realizar dos actividades: validar la
identidad de un sitio web y crear una conexión encriptada para el uso de tarjetas
de crédito y otros datos personales.
CORBA (Common Object Request Broker Architecture). Software basado en la
interfase del Administrador de Objetos en Grupo (OMG) que permite a módulos de
82
software (objetos) comunicarse entre si, sin importar donde estén localizados, ya
sea en una red privada o publica.
DCOM (Distributed Component Object Model). Tecnología de Microsoft para
objetos distribuidos. Basado en la arquitectura de componentes de software
creada por Microsoft también y que define la interfase de los objetos.
RMI (Remote Method Invocation). Estándar de Sun para objetos distribuidos
programados exclusivamente en Java.
OSD DCE (Open Source Code) (Distributed Computing Environment). Software libre que permite a las aplicaciones ser construidas en plataformas
heterogéneas en una red.
TCP/IP (Transmission Control Protocol/Internet Protocol). Protocolo de
comunicaciones desarrollado bajo contrato de la Defensa de los Estados Unidos
para sistemas diferentes en red.
RPC (Remote Procedure Call). Interfase de programación que permite a un
programa utilizar los servicios de otro en una maquina remota.
IDL (Interface Definition Language). Lenguaje utilizado para definir a la interfase
como una rutina o función.
Marshalling. Se refiere a ordenar una serie de objetos de acuerdo a su estructura
de datos.
Unmarshalling. Desordenar una serie de objetos.
Binding. Se refiere a la creación de una referencia simple de algo que es mucho
más grande y complicado. Binder.
83
Stub. Pequeña rutina de software colocada en un programa que provee una
función común. Por ejemplo, un stub puede ser instalado en una maquina cliente y
a su vez en un servidor, donde ambos solucionan un protocolo, llamada a un
proceso remoto u otro requerimiento de interoperabilidad.
XDR (External Data Representasion). Formato de dato desarrollado por Sun que
es parte de sus estándares de conexión de red.
Portmapper. Servidor que convierte los números de puertos del protocolo TCP/IP
en números de programas de RPC.
Front-end. Cabeza, punto de inicio o punto interno en un sistema.
Applets. Es una pequeña aplicacion, tal como un programa de utilirea o funcion
limitada de una hoja de calcula o procesador de textos. Los programas de Java
que son ejecutados desde un navegador son conocidos como applets.
Plugin. Programa auxiliar que trabaja con un paquete de software major para
mejorar su capacidad.
ActiveX. Anteriormente era incluido en la arquitectura COM, se utiliza para
habilitar la ejecución de programas en una página web.
N-Tier. “Tier” se refiere al número de elementos que pueden ser, servidores, cpus,
cluster, etc., n es el cualquier número de tiers al que se refiera, por ejemplo, 500
cpus (500-tiers)
ORB (Object Request Broker). Software que maneja la comunicación de los
mensajes de un programa cliente, en su envió y retorno.
Commit. Actualización de un registro.
84
Jitter. Se refiere al tiempo de fluctuación de una transmisión o muestra de una
imagen. Tiempo en que tardan en llegar los paquetes de comunicación.
Kernel. El núcleo de un sistema operativo. Puede activar el hardware
directamente o por medio de un software especial.
Preemptable. Significa que los recursos pueden ser solicitados de su propio
propietario y regresarlos, por ejemplo la memoria.
Patch. Arreglo a un programa.
HAL (Hardware Abstraction Layer). Se refiere a la optimización del kernel para
soportar un nuevo hardware tan eficientemente como sea posible.
Bytecode. Un lenguaje intermedio ejecutado por una rutina. Tanto el codigo del
programa de Java como Visual Basic son compilados en su tipo de bytecode, los
cuales después son ejecutados por sus respectivas rutinas, llamadas “maquinas
virtuales”.
Short-lived. De corta ejecución.
Long-lived. De larga ejecución.
Scoped memory. Termino utilizado por la RTSJ referente a la optimización de la
memoria.
POSIX (Portable Operating System Interface for UNIX). Estándar de la IEEE
1003.1 que define el lenguaje de la interfase entre las aplicaciones y el sistema
operativo UNIX.
Timer. Cronometro o temporizador.
85
Timeout. Tiempo que transcurrió en una comunicación y que al final fallo.
OSGi (Open Service Gateway initiative). Estándares abiertos de organización,
los cuales tienen un servicio de plataforma basado en java el cual puede ser
manipulado remotamente.
Set-top-box. Dispositivo que se conecta a la televisión o alguna fuente de señal
externa y que después regresa la señal a un contenedor y la despliega en la
pantalla.
PDA (Personal Digital Assistant). Computadora de mano para manejo de citas,
actividades y contactos.
Homegateway. Dispositivo que conecta a una línea de cable o DSL para el
acceso a Internet.
Infotainment. Se refiere a los servicios de información y de entretenimiento
entregados al hogar.
Life-span. Esperanza de vida.
SOA (Service Oriented Architecture). Arquitectura basada en el servicio, se trata
de no crear monolíticas aplicaciones sino que sean intercambiables entre ellos.
End to end. Termino utilizado en el e-commerce para las personas que desean
comprar y vender de manera directa.
Time-to-market. Tiempo que lleva a un producto desde que es concebido hasta
que esta disponible en el Mercado.
Stand-alone. Se refiere a que una aplicacion es auto ejecutable.