1 / 37

SISTEMAS EN TIEMPO REAL Y DISTRIBUIDOS CAPITULO 1

SISTEMAS EN TIEMPO REAL Y DISTRIBUIDOS CAPITULO 1. INF-317. 1. INTRODUCCIÓN.

teague
Download Presentation

SISTEMAS EN TIEMPO REAL Y DISTRIBUIDOS CAPITULO 1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SISTEMAS EN TIEMPO REAL Y DISTRIBUIDOS CAPITULO 1 INF-317

  2. 1. INTRODUCCIÓN • Este tipo de sistemas se caracterizan por su correcto funcionamiento, depende no sólo de las entradas y salidas del mismo, sino porque además se debe dar respuesta a los diferentes eventos en el momento adecuado, pudiendo ser fatal cualquier retraso

  3. 1.1.SISTEMAS DISTRIBUIDOS DE TIEMPO REAL • La capacidad de procesamiento está distribuida entre varios computadores interconectados. • Las actividades del sistema tienen requisitos de tiempo. • Necesidad de sistemas distribuidos: • Requisitos de procesamiento. • Distribución física del sistema. • Fiabilidad: Tolerancia a fallos. • Los sistemas distribuidos de tiempo real (SDTR) son complicados de realizar. • Se consideran sistemas débilmente acoplados. • Comunicación mediante mensajes • Se consideran, fundamentalmente, sistemas críticos

  4. 1.1.1.DEFINICIÓN DE SISTEMAS DISTRIBUIDOS • Un sistema distribuido se define como: una colección de computadoras separadas físicamente y conectadas entre sí por una red de comunicaciones distribuida; cada máquina posee sus componentes de hardware y software que el usuario percibe como un solo sistema. • El tamaño de un sistema distribuido puede ser muy variado, ya sean decenas de hosts (red de área local), centenas de hosts (red de área metropolitana), y miles o millones de hosts (Internet); esto se denomina escalabilidad

  5. 1.1.2.PROGRAMACIÓN EN SISTEMAS DISTRIBUIDOS • Tenemos: • librerías de bajo nivel • procedimientos remotos • objetos distribuidos.

  6. 1.1.3.PLANIFICACIÓN EN SISTEMAS DISTRIBUIDOS

  7. 1.1.4 EL MEDIO DE COMUNICACION

  8. EL PARADIGMA DE PROGRAMACIÓN BASADO EN COMPONENTES • A pesar del éxito de la P.O.O surgieron nuevos problemas. • En lenguajes como C++, se utiliza la herencia de implementación, • En el campo de tiempo real, se han usado fundamentalmente lenguajes como Ada, C,

  9. La plataforma .NET • Recientemente Microsoft ha dirigido todos sus esfuerzos hacia la tecnología .NET • Se pueden tener dos visiones de .NET -Librería para el desarrollo de aplicaciones • - Entorno de ejecución en q los programas se van a ejecutar, proporcionando un nivel de abstracción sobre el S.O.

  10. Los componentes de .NET • Los componentes van a estar cont. en ensamblados. • .NET no esta diseñado para tiempo real El modelo de componentes de java • JavaBeans presenta un modelo de componentes Independiente de la plataforma, • Las principales características de la interfaz de JavaBeans son: • -Propiedades -Eventos • -Introspección

  11. BEANS Y TIEMPO REAL • No es adecuado para el desarrollo de aplicaciones de tiempo real. • Modificando el propio lenguaje, podría desarrollarse un modelo que incorporara características de tiempo real: • Introspección para obtener información de los componentes. • Usando una terminología adecuada, se podrían indicar distintas calidades de servicio (QoS) que el entorno podría detectar y utilizar. • El modelo de eventos sería adecuado, si permitiera la incorporación de tiempo o prioridades. • Las características de multicastserán útiles para la implementación de canales de tiempo real con múltiples consumidores. • Los contenedores, que controlan aspectos como la concurrencia, pueden extenderse para controlar planificación o la gestión de eventos. • Este modelo de contenedores/niveles permite realizar un estudio más sencillo de planificabilidad adecuado para sistemas dinámicos.

  12. El modelo de componentes CCM (CorbaComponentModel) Intenta solventar las dificultades que dan al combinar las numerosas políticas POA. Utilizando un subconjunto de combinaciones para un mejor desarrollo de aplicaciones en la parte del servidor. Los conceptos que forman el modelo de programación para servidores son: • Los componentes, • Marco de Trabajo de Implementación de Componentes. • ElModelo de Programación de Componente Contenedor. • Integración con persistencia, transacciones y eventos. • •Empaquetamiento de componentes y su despliegue. • •Interconexión con EJB 1.1. • •Modelo de Metadatos de Componentes (repositorio de interfaces).

  13. Los componentes de CCM Es un nuevo meta-tipo en CORBA y se declararán con la palabra component. Los diversos stubsy skeletons que soportan son los ports: • Facetas (Facets): interfaces que un componente ofrece. • Receptáculos (Receptacles): stubsclientes que invocan a otros componentes. • Fuentes de eventos (Eventsources):puntos de conexión que emiten eventos. • Sumideros de eventos (Eventsinks): conexiones en las que los eventos de un tipo específico deben ser puestos por un suministrador o un canal. Otras características del modelo incluyen: • Claves primarias, Atributos y configuración e Interfaces Home.

  14. El marco de trabajo para implementación de componentes • Proporciona interfaces para soportar la estructura y funcionalidad de los componentes. • Define un lenguaje declarativo, CIDL (ComponentImplementationDefinitionLanguage) que permite describir implementaciones y estados persistentes de los componentes. • ElCORBA CIF (ComponentImplementation Framework) está diseñado para desarrollar tareas como la gestión del ciclo de vida y estados de los componentes. • CIF usa las descripciones CIDL para generar código que automatiza comportamientos de los componentes.

  15. El modelo de programación basado en contenedores • Un contenedor es el entorno de ejecución que es ofrecido por CCM a los componentes. • Encapsulan la implementación y usan un conjunto de APIs para acceder al entorno de ejecución, facilitando el desarrollo y/o configuración de aplicaciones CORBA. • Activación/Desactivación de implementaciones para preservar recursos limitados del sistema. • Proporcionar un nivel de adaptación para cuatro servicios: Transacciones, Persistencia, Seguridad y Notificación. • •Nivel de adaptación para callbacksque el contenedor y el ORB utilizan para informar al componente sobre eventos. • •Gestión de las políticas POA, determinan la creación de referencias a los componentes

  16. CCM y tiempo real • No tiene la posibilidad de indicar restricciones temporales ni permite acotar el tiempo de ejecución de una invocación remota. • Múltiples interfaces funcionales y especiales para tiempo real, mediante las facetas. • Posibilidad de implementar un mecanismo de reconfiguración dinámica. • Modelo basado en eventos con fuentes y sumideros, podrían incorporar restricciones temporales y/o prioridades en la transmisión y recepción de los eventos. • La activación/desactivación puede usarse para tener implementaciones degradadas de los componentes. • Suministran niveles de adaptación para cuatro servicios usados. • Debería incorporarse un 5° nivel de adaptación que facilite el desarrollo de aplicaciones con CCM y tiempo real.

  17. TENDENCIAS ACTUALES SOBRE COMPONENTES Y TIEMPO REAL Existen algunos trabajos intentando relacionar los componentes con el tiempo real. • Hooman y Van Roosmalen, 2000: propone un modelo para el desarrollo de aplicaciones de tiempo real independiente de la plataforma y basándose en el concepto de compontes. • Hooman: propone un modelo de programación en tiempo real, con un método de verificación formal de programas con anotaciones de tiempo. • Henzinger: se describe un modelo formal, de forma estructurada para el desarrollo de hardware y software interactuando a través de componentes en tiempo real. En el ámbito de lo sistemas distribuidos, aparecen los primeros resultados para los componentes de tiempo real: herramientas, entornos de ejecución, métodos para expresar restricciones.

  18. Los trabajos estudiados se dividen en tres grupos: • Plataformas de ejecución con componentes u objetos • Estudios sobre planeación e indicación de restricciones • Estudios sobre estándares como ser Java o CORBA Villela et al : presenta un marco de trabajo con un conjunto de herramientas para el desarrollo de componentes distribuidos en tiempo real. Herramientas: • Plantillas de componentes • Diagramas de despliegue para la configuración de la aplicación en los distintos nodos que forman el sistema • Generadores de código • Un repositorio de componentes.

  19. Hsiung et al: fue presentado VERTAF, es un marco de trabajo para aplicaciones orientadas a objetos en sistemas empotrados de tiempo real. Dispone de 5 herramientas: • Implementador • Modelador • Planificador • Verificador • Generador Yen et al: propone un mecanismo integrado basado en componentes para el desarrollo de software empotrado. Para diseñar sistemas distribuidos de tiempo real predecibles se requiere: • especificación de los componentes en el dominio del tiempo. • interfaces funcionales. Para el desarrollo de los sistemas distribuidos se usa estándares de componentes como ser Java y CORBA.

  20. CORBA(Common Object Request Broker Architecture) y RT-CORBA (Real-time CORBA) • CORBA es ofrecer una capa homogénea para el desarrollo de aplicaciones que se ejecutan en sistemas distribuidos heterogéneos. • RT-CORBA • • Recursos del procesador • • Recursos de comunicación • • Recursos de memoria • Fundamentos de CORBA

  21. Arquitectura OMA (Object Management Architecture) • Invocación de operaciones

  22. Tipos de invocaciones • Invocación estática • Invocación dinámica • Una segunda clasificación de las invocaciones atendiendo a la sincronización: • Peticiones síncronas • Peticiones asíncronas diferidas • Peticiones oneway • Lenguaje de Definición de Interfaces: IDL Lenguaje Declarativo • Definir las interfaces de los objetos de forma independiente a un lenguaje de programación. • IDL establece el contrato entre el cliente y el servidor, describiendo los tipos e interfaces de objeto utilizados en una aplicación.

  23. ADAPTADORES DE OBJETOS INTERFAZ DE UN OBJETO A UNA INTERFAZ DIFERENTE SIRVIENTES ORB CLIENTE ENLAZA ADAPTA FUNCIONES • CREAR LAS REFERENCIAS A LOS OBJETOS • ASEGURAR QUE CADA OBJETO DESTINO ESTÁ REPRESENTADO POR UN SIRVIENTE Y RECIBIR LAS INVOCACIONES CURSADAS POR EL ORB EN EL LADO DEL SERVIDOR • DIRIGIRLAS A LOS SIRVIENTES QUE ENCARNAN A LOS OBJETOS DESTINO

  24. SERVICIOS EN ORB • Servicio de Nombres • Servicio de Eventos • Servicio de Notificación • Servicio de Trading • Servicio de Transacciones • Servicio de Ciclo De Vida • Servicio de Concurrencia

  25. DESARROLLO DE UNA APLICACIÓN CORBA

  26. GESTION DE PRIORIDADES

  27. FUNDAMENTOS DE SDL

  28. COMUNICACIÓN ENTRE PROCESOS

  29. Extensión de tiempo real para SDL Extensiones que permitirán solucionar las limitaciones con restricciones temporales:

More Related