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.


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.


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.


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.


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.


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.


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.

reyes maza

Documents