Tema V
Tecnología de objetos distribuidos y arquitectura de componentes. 1
Bibliografía •
•
Szyperski, C. 1998. Component Software. Addison-Wesley. Addison-Wesley. Ruiz Cortés, 1998. A. CORBA: Una visión general. http://www.lsi.us.es/~aruiz
•
Sevilla Ruiz, D. 2000. CORBA & Components. http://www.ditec.um.es/~dse http://www.ditec .um.es/~dsevilla/ccm/ villa/ccm/. .
•
Object Management Group. 1995. CORBA Overview. http://www.infosys.tuwien.ac.at/Research/Corba/OMG
•
Bernabéu Aubán, Aubán, J.M. 1999. Sistemas de Objetos Distribuidos: El estándar CORBA. http://www.iti.upv.es/~josep/docencia/sdb/CORBA/CORBA.html
•
Schmidt, D.C. 2000. Overview of CORBA. http://www.cs.wustl.edu/~schmidt/corba.html
2
Índice 1. Introducción. 2. OMA (Object Management Architecture). 3. CORBA (Common Object Request Broker Architecture). 4. Conclusiones.
3
Introducción Evolución de la arquitectura de los sistemas informáticos C/S 2 capas Sistemas monolíticos
Presentación Negocio
C/S 3 capas Presentación
Presentación Negocio Datos
Negocio
Negocio
Datos Datos
BD 4
Arquitectura multicapa subcapas
Presentación Negocio Datos
BD 5
Arquitectura de componentes (I) (multicapa y 3-tier) 3:Component system
2:Component frameworks
1:Components
( tier grada ) •
•
•
Tier 1: Arquitectura de componentes individuales. Tier 2: Arquitectura de los marcos de componentes. Macrocomponentes definidos para realizar una función de negocio concreta. Tier 3: Arquitectura del sistema de componentes. Super-componente que define todo el sistema. 6
Arquitectura de componentes (II) •
•
Cada componente del tier 3 se define con un conjunto de componentes del tier 2, y cada uno del tier 2 por un conjunto del tier 1. COMPONENTE = módulo + conjunto de recursos –
–
•
Módulo = conjunto de clases y puede que elementos de proceso no orientados a objeto (procedimientos y funciones). Conjunto de recursos = múltiples interfaces que cada uno representa un servicio ofrecido por el componente.
COMPONENTE OBJETO 7
Arquitectura de componentes (III) •
Problemas: –
–
•
No basta una modelización correcta de jerarquía de clases e interacciones, se necesita una infraestructura (nivel de transporte) de comunicación que permita el flujo transparente de mensajes entre objetos de distintas aplicaciones en distintas máquinas Se debe evitar el crecimiento exponencial de interfaces
Solución: –
Middleware de componentes
8
Arquitectura de componentes (IV) •
Alternativas: –
Sockets. •
–
Remote Procedure Calls ( RPC). •
–
Implementación costosa. No soporta objetos explícitamente.
Microsoft Distributed Component Object Model ( DCOM) Menos maduro, menos portable y además propietario. Java Remote Method Invocation ( RMI) Solo para JAVA. Common Object Request Broker Architecture ( CORBA) Multiplataforma, multilenguaje, ... •
–
•
–
•
9
OMA (Object Management Architecture) •
OMG: Object Management Group, Inc.
http://www.omg.org –
–
–
–
Fundado en 1989. Objetivo: Desarrollo de estándares para la reutilización, portabilidad e interoperabilidad de software orientado a objetos en entornos heterogéneos y distribuidos. Solución: Definen OMA (Object Management Architecture) de la cual CORBA es una parte. Historia: •
•
•
•
1991: CORBA 1.1 1995: CORBA 2.0 (Modelo de Referencia) 2000: CORBA 2.4 (actual) 2000-2001: CORBA 3.0 (Modelo de Componentes) (en desarrollo) 10
OMA: Objetivos técnicos •
•
•
•
•
•
•
•
Transparencia distribución Rendimiento local y remoto Comportamiento dinámico Sistema de nombrado Consultas: nombre, atributos, relaciones Control de la concurrencia Transacciones Robustez, disponibilidad
•
•
•
•
•
•
•
Mantenimiento de versiones Notificación de eventos Semántica de Relaciones entre objetos API en C para todas las operaciones Administración y gestión Internacionalización Estandarización 11
Arquitectura del modelo de referencia OMA Application objects
CORBA facilities
CORBA 2.0 Object Request Broker (ORB)
Object services (CORBAservices)
12
Object services (CORBAservices) (I) •
Definen 16 servicios comunes ofrecidos a los objetos: –
–
–
–
–
–
–
–
–
–
Naming service : Identificación de objetos
Object security service : Servicio de seguridad Object trader service : Mercader de objetos. Los ofrece a los clientes.
: Permite transacciones con commit-rollback Change management service : Gestor de versiones de implementación. Object transaction service
: Gestión de bloqueos para permitir concurrencia Event notification service : Objetos que son mensajes de eventos Concurrency service
Externalization service : Permite copiar objetos por valor Licensing service : Permite obtener licencias de uso de un objeto Lifecycle service : Crea, copia, mueve y borra objetos y grupos de
objetos relacionados
13
Object services (CORBAservices) (II) –
Object collections service : Crea colecciones de objetos (basado en
SMALLTALK) (árboles, listas, colas, conjuntos,...) –
Object query service : Permite localizar los objetos por el valor de
sus atributos (parecido al Trader, pero en lugar de servicios ofrece atributos) –
–
: Permite al objeto sobrevivir a la terminación del programa que lo creó Persistent object service
Properties service : Asocia propiedades al objeto
(modificable,
borrable o sólo lectura) –
–
Relationship service : Permite relaciones entre objetos Time service : Soluciona el problema del reloj asíncrono en los
SID. Usa time-stamping. 14
CORBAfacilities •
Definen servicios comunes ofrecidos a las aplicaciones: –
Horizontales: define colecciones de objetos prefabricados •
•
•
•
–
Interfaz de usuario Gestión de la información Gestión de sistemas Gestión de tareas
Verticales: define servicios comunes para un dominio completo (framework tier) •
•
•
•
•
•
Objetos de negocio Comercio electrónico Finanzas Manufacturación Medicina Telecomunicaciones 15
Application objects
•
•
Definen servicios específicos de un determinado negocio o aplicación. Suponen el nivel más alto de los servicios soportados por la arquitectura OMA
16
CORBA (Common Object Request Broker Architecture) •
•
•
•
•
CORBA es un middleware orientado a objetos / componentes. Los objetos cliente solicitan servicios a los objetos servidor mediante invocación de método Separa interfaz e implementación Es independiente del lenguaje: los objetos clientes y servidores se implementan en cualquier lenguaje (de los soportados) Crea transparencia de localización a través del ORB : –
–
–
–
de objetos: la invocación siempre se hace en local de red: el ORB la gestiona de activación: los servidores se activan automáticamente de estado persistente: permite que el servidor guarde persistencia y es transparente al cliente 17
IDL (Interface Definition Language) •
•
•
•
CORBA incorpora un lenguaje de definición de interfaces (IDL) Independiente del lenguaje de implementación. Mapea hacia los lenguajes de programación habituales. Los ORBs llevan incorporados su traductor de IDL a los lenguajes de implementación soportados C
C++
Java Delphi Ada SmallTalk IDL
Object Request Broker (ORB) 18
Comunicación C/S en CORBA
Cliente
Invocation Interface
Servidor
Object Adapter
Object Request Broker (ORB) 19
Arquitectura de CORBA Interface Repository
IDL COMPILER
Implementation Repository
operación(args) Client
Dynamic Invocation Interface
OBJ REF
IDL Stubs
Object resultado(args)
ORB Interface
(Servant)
IDL Dynamic Static Skeleton Skeletons Interface
Object Adapter
Object Request Broker (ORB) 20
Componentes primarios en CORBA (I) •
Object : –
–
•
Servant (sirviente) : –
–
•
Implementación de una entidad en un lenguaje de programación (en cualquiera de los soportados). Define las operaciones que soporta un determinado interfaz CORBA IDL.
Client : –
–
•
Entidad de programación CORBA. Tiene una identidad, una interfaz, y una implementación (conocida como Servant).
Entidad de programa que invoca una operación a una implementación de objeto. Idealmente será tan simple como una invocación a un método.
Object Request Broker (ORB) (corredor de peticiones a objetos) : –
–
–
–
Núcleo de la arquitectura CORBA. Proporciona transparencia entre los clientes y las implementaciones de los objetos. Cuando un cliente invoca una operación, ORB busca la implementación del objeto, lo activa si es necesario, transmite la petición y devuelve la respuesta. 21 Permite conexión con otros ORBs.
Componentes primarios en CORBA (II) •
ORB Interface : –
•
IDL stubs (cabos) : –
–
–
–
–
–
•
Interfaz de comunicación con el ORB para solicitarle servicios al propio ORB: conversión de referencias de objetos a cadenas, ... El stub es la interfaz que ve el cliente Representante del servidor en el lado cliente (proxy) Realiza invocación remota Define rutinas específicas para operaciones particulares en objetos particulares Definido en IDL y se transforma al lenguaje de programación del Cliente La transformación entre CORBA IDL y el lenguaje de programación se realiza automáticamente por el IDL compiler
IDL skeletons (esqueletos) : –
–
Ofrece una interfaz estática a cada servicio del objeto Definido en IDL y se transforma al lenguaje de programación del Servant 22
Componentes primarios en CORBA (III) •
Dynamic Invocation Interface : –
–
–
•
Permite la construcción dinámica de invocaciones a objetos. No llama a una rutina específica para una operación particular en un objeto particular. El cliente especifica el objeto a ser invocado, la operación y el conjunto de parámetros (esto lo obtiene del Interface Repository)
Dynamic Skeleton Interface : –
–
–
Permite el manejo dinámico de las invocaciones a objetos. No es accedido por un esqueleto específico para una operación determinada. Se proporciona acceso a través de un nombre de operación y parámetros.
23
Componentes primarios en CORBA (IV) •
Object Adapter : –
Conecta al ORB con la implementación del objeto para realizar los servicios que el ORB proporciona (a otros objetos y clientes): •
•
•
•
•
•
generación e interpretación de referencias a objetos invocación de métodos seguridad de las interacciones activación y desactivación del objeto y su implementación mapeo de las referencias de los objetos a sus implementaciones registro de implementaciones.
24
Componentes primarios en CORBA (V) •
Interface Repository : –
–
Almacena información relativa a las interfaces IDL definidas en el Sistema Distribuido. El ORB solicita los servicios al IR para: •
•
•
–
Los clientes solicitan los servicios al IR para: •
•
–
•
comunicarse con otros ORB de distinta implementación. verificar los parámetros de la petición verificar la existencia de ciclos en los grafos de herencia navegar por la lista de interfaces facilitar la instalación y distribución de objetos
Un ORB puede tener varios IR según la necesidad (prueba, release, externos, ...
Implementation Repository : –
Almacena información de administración de cada uno de los objetos: cuáles están instanciados, como activarlos, permisos, etc. 25
Conclusiones •
•
•
•
•
•
•
Independiente del Sistema Operativo y del lenguaje de programación Intenta hacer transparente a los programadores todos los aspectos que sea posible. Facilita la reutilización de software, incluso cuando no esté implementado en un OOL. Incorpora mecanismos de seguridad: autentificación, encriptación,... Tecnología OO. Estándar comercial y abierto. CORBA 3.0 Modelo de componentes (CCM) 26
