Tecnologías Middleware

Tecnologías Middleware 1 Bibliografía y Evaluación The Essential Distributed Objects Survival Guide R. Orfali, D. Harkey, J. Edwards Wiley, 1996 Seguimiento clases teóricas. Seguimiento prácticas laboratorio. 2 1

Contenidos TEORIA (6 horas) Conceptos de Orientación a Objetos (1 hora) Introducción al Middleware (1 hora) CORBA (4 horas) LABORATORIO (6 horas) RMI (2 horas) CORBA (2 horas) EJERCICIOS (2 horas) 3 Conceptos de OO Introducción Concepto de objeto Clases Instanciación Envío de mensajes Herencia Polimorfismo 4 2

Introducción OO Hasta la aparición del primer lenguaje orientado a objetos (Simula 67) dentro de un programa subsistían como entidades separadas los datos y los procedimientos o funciones que manipulan esos datos: Programas = Algoritmos + Estructuras de Datos. Aparece el concepto de objeto: entidad de programación que encapsula datos y procedimientos que los manipulan. 5 Concepto de Objeto Entidad de programación con dos componentes: Parte estática: datos. Parte dinámica: métodos, procedimientos o funciones que manipulan en exclusividad esos datos. Cada objeto posee una interfase que contiene los servicios que ofrece al mundo exterior. Encapsulación I N T E R F A S E métodos (procedimientos o funciones) atributos (datos) Ocultación de información 6 3

Concepto de Objeto... En un lenguaje orientado a objetos, con ocultación de información, no se puede acceder libremente a los campos de un objeto. Los objetos modelan entidades o conceptos, reales o abstractos del dominio de discurso como facturas, coches, personas, colas de tareas, etc. Un objeto viene caracterizado por un número de operaciones y por un estado que recuerda el efecto de esas operaciones. 7 Concepto de Objeto... EMPLEADO EMPLEADO REGISTRO NOMBRE FEC_NAC DNI EMPLEO SUELDO ENDREGISTRO DATOS NOMBRE FEC_NAC DNI EMPLEO SUELDO MODIFICAR_EMPLEO MODIFICAR_SUELDO CALCULAR_EDAD OPERACIONES MODIFICAR_EMPLEO MODIFICAR_SUELDO CALCULAR_EDAD INTERFACE PROGRAMA PRINCIPAL PROGRAMA PRINCIPAL Acceso a los datos: lenguaje convencional vs lenguaje OO. 8 4

Concepto de Objeto... Estado compartido Función 1 Función 2 Función 3 Función 4 Función 5 Flujo de control Flujo de datos Los átomos de computación en los sistemas orientados a funciones son las funciones que operan sobre un estado compartido. 9 Concepto de Objeto... dibujar #1 insertar #2 imprimir atributos atributos actualizar eliminar insertar #3 limpiar #4 atributos atributos eliminar dibujar Flujo de control Flujo de datos El mecanismo de comunicación se llama paso o envío de mensajes. Un mensaje origina que un objeto lleve a cabo las oportunas operaciones. 10 5

Clases Muchos objetos similares pueden ser descritos por una misma definición o esquema general, a esta definición o descripción se le llama clase. Una clase es una definición, plantilla o molde que permite la creación de objetos, y contiene la descripción de las características comunes de esos objetos. Una clase, posee por tanto, dos componentes: Parte estática: Campos con nombres, atributos. Parte dinámica: Procedimientos o funciones, métodos. 11 Clases... Una definición de clase debe incluir como mínimo: El nombre de la clase. Las operaciones públicas, interfase de la misma. La representación interna de los atributos. La implementación de la interfase. 12 6

Instanciación Operación que permite la creación de representantes físicos de las clases, llamados instancias o ejemplares. Cada objeto o ejemplar es una instancia de una clase determinada. Las clases existen en tiempo de compilación mientras que los objetos existen en tiempo de ejecución. 13 Instanciación... Articulo 10156 camisa 4567.90 200 Instancia de referencia descripcion precio cantidad Inicializar preciototal preciotransporte Retirar Añadir 40256 TV porta. 35670 30 Instancia de Instanciación de la clase Artículo. 14 7

Instanciación... Atributos de clase: Compartidos por todas las instancias de esa clase. Aquellos atributos cuyo valor reside en la propia clase. Difieren de las variables globales en el alcance, sólo pueden ser utilizadas por las instancias. 15 Instanciación... 10156 camisa 4567.90 200 40256 TV porta. 35670 30 Articulo referencia descripcion precio cantidad 50 Inicializar preciototal preciotransporte Retirar Añadir clase Artículo... variable de clase CantidadMinima:Integer... fin Artículo Instanciación de la clase Artículo con atributos de clase. 16 8

Envío de mensajes A los objetos se puede acceder únicamente a través de su interfase pública: un objeto puede acceder a otro mediante el envío de un mensaje. Paso de mensajes: Proceso de presentar a un objeto una solicitud para realizar una acción específica. Contiene: destinatario del mismo, nombre de la operación a invocar y una posible lista de argumentos. MENSAJE OBJETO EMISOR NOMBRE Y ARGUMENTOS OBJETO RECEPTOR 17 Envío de mensajes... Para que un objeto pueda responder a un mensaje, éste debe ser parte de su interfase pública. Al conjunto de mensajes a los que puede responder un objeto dado se le llama comportamiento del objeto. Cuando el receptor recibe el mensaje, realiza la operación en la forma que él solo conoce (y que puede ser cualquiera, con tal de que haga lo establecido: el emisor nunca especifica cómo debe llevarse a cabo esa operación). 18 9

Herencia Relación transitiva entre clases que permite a una nueva clase utilizar los métodos y atributos definidos en otra clase como si fuesen propios. Mecanismo de reutilización de código. Permite a los programadores crear nuevas clases a partir de clases existentes. 19 Herencia... A Superclase A (Clase Padre) Hereda_de Hereda_de C Hereda_de Una subclase consta de dos partes: B Subclase (Clase descendiente) Parte derivada: Atributos o métodos que hereda directamente de su superclase. Parte emergente: Atributos o métodos que le son propios, creados especialmente para esa clase. B 20 10

Polimorfismo Un objeto polimórfico es una entidad (por ejemplo una variable) que puede contener valores de diferente tipo durante la ejecución de un programa. AD-HOC Sobrecarga Coerción UNIVERSAL Paramétrico o Genericidad Inclusión 21 Polimorfismo... Sobrecarga: utilizar el mismo símbolo para denotar operaciones con distinto significado. Coerción: Las operaciones pueden trabajar con tipos mezclados. Genericidad: Sustitución de argumentos dentro de un rango de tipos en la llamada a una función. Definición de clases paramétricas, que son aquellas que admiten uno o varios tipos como parámetro. Inclusión o controlado por herencia: Variables de un tipo determinado pueden referirse a instancias de clases descendientes. 22 11

Introducción al Middleware Motivación Software distribuido Evaluación de Middleware Componentes 23 Motivación Dos hechos El bajo precio de los servicios de las WAN (Wide Area Networks). El bajo precio de los s.o. válidos para red, multitarea, (OS/2, Windows, Linux, ). Cualquier máquina puede ser cliente y servidor en las autopistas de la información. 24 12

Software distribuido Rico en procesamiento de Transacciones Necesario transacciones anidadas a través de múltiples servidores, transacciones de larga duración, transacciones encoladas, Capacidad para manejar gran cantidad de información Documentos multimedia. Superservidores que almacenan y distribuyen la información. 25 Software distribuido Tecnología de agentes Todo tipo de agentes: gestión sistema, venta, estadísticas, Software inteligente Con s.o. baratos no podemos tener administradores de sistemas. El software debe saber cómo configurarse y gestionarse. 26 13

Software distribuido Middleware Software que reside en el cliente y en el servidor. Hay tres tipos: Protocolos de transporte (TCP/IP, AppleTalk,...) Sistema Operativo en Red (Netware, LANServer, ) Service-Specific: gestión de los mensajes entre procesos u objetos. 27 Middleware Cliente/Servidor Bases de Datos Relacionales Monitores Transaccionales Groupware Objetos Distribuidos 28 14

C/S con BDR Modelo más extendido. Lanzar sentencias SQL a través de la Red da bajas prestaciones. Solución: Almacenar en un procedimiento varias sentencias SQL, el procedimiento reside en el mismo servidor que la BD à stored procedures. Pero, El lenguaje para programar stored precedures varía de un fabricante a otro à no standard. También varía la forma de Administrar la BD, replicar los datos, etc. 29 C/S con BDR Ventaja Existen muchas GUI Tools que hacen fácil crear aplicaciones C/S à pero single vendor environments. Puentes con entornos visuales. Desventajas SQL es muy pobre manejando procesos. No existe Middleware SQL standard No hay protocolos estándar para intercambiar mensajes a trevés de la Red entre productos diferentes. SQL no es lo más adecuado para gestionar información rica Sí es interesante para tipos simples, pero NO para multimedia. Bases de Datos Federadas: entornos de BD heterogéneas. 30 15

C/S con Monitores Transac. Transaction Processing Monitors (Tuxedo, Encina, ) Gozan de buena reputación: robustos. Bancos/Mainframes, Se utilizan para aplicaciones que dan servicio a miles de clientes. Sistemas de gestión críticos. Gestión transacciones: balanceo de carga, levantándolas de posibles caídas, 31 C/S con Monitores Transac Utilizan arquitectura C/S de tres niveles: interfaz, proceso, datos. Futuro: matrimonio con los objetos distribuidos. 32 16

C/S con Groupware Conjunto de tecnologías que permite representar procesos complejos centrados alrededor de actividades humanas colaborativas. Ejemplo: Lotus Notes. Cinco tecnologías: Multimedia, e-mail, Conferencing, Scheduling, Workflow: se utiliza para dirigir automáticamente eventos de un programa al siguiente. Utiliza el concepto de documento para referirse a texto, imágenes, faxes, mail, (tabla en SQL). Un documento puede ser: mostrado, almacenado, replicado, enviado a través de la red. 33 C/S con Groupware Ventajas Es una tecnología flexible que se adapta a la forma en que la gente hace negocios. Desventajas Es propietario. No se adapta bien al mundo de las Transacciones. 34 17

C/S con Objetos Distribuidos Los objetos encapsulan información y comportamiento. Porqué objetos para C/S? Los objetos permiten dividir las aplicaciones en componentes, haciéndolas más manejables. Se puede modificar un objeto sin afectar al resto de componentes. Los objetos pueden viajar a través de la Red, diferentes máquinas, sistemas operativos, Construir aplicaciones C/S ensamblando componentes. Pero, necesitamos un estándar 35 Componentes Pieza de Sw lo suficientemente pequeña para ser creada y mantenida, lo suficientemente grande para ser vendida y soportada, y con interfaces definidos para comunicarse A diferencia de los objetos tradicionales pueden interoperar a través de lenguajes, herramientas, sistemas operativos y redes. Al igual que los objetos tradicionales soportan herencia, polimorfismo y encapsulación. Los componentes que no soportan herencia se les llama black box components (COM) 36 18

Componentes (características) Es una entidad que se puede vender Es una pieza de Sw binario. No es una aplicación completa Se diseña para que realice tareas en un Dominio de Aplicación. Combinando con otros componentes se obtienen aplicaciones completas. Se puede utilizar en combinaciones impredecibles El desarrollador del componente no sabe de qué aplicaciones finales formará parte. 37 Componentes (características) Tiene una interfaz bien definida Al igual que los objetos tradicionales los componentes sólo pueden ser manipulados a través de su interfaz. Es un objeto interoperable Es una entidad Sw independiente del sistema. Puede ser invocado a través de la red, desde cualquier sistema operativo, con cualquier lenguaje o herramienta. Pieza de Software autocontenida e independiente de cualquier aplicación. 38 19

Componentes y objetos distribuidos Los objetos distribuidos son por definición componentes. En los sistemas de objetos distribuidos la unidad de trabajo y distribución es el componente. Pero, no todos los componentes son objetos. Ni tampoco distribuidos. Ejemplo: un control OLE (OCX) es un componente que no es un objeto ni es distribuido. 39 Supercomponentes Seguridad Debe ser capaz de autentificarse ante sus clientes y viceversa. Manejo del ciclo de vida Debe gestionar su instanciación, destrucción y archivo. Soporte para paletas Drag and drop. Notificación de eventos Debe notificar cuándo le ha sucedido algo de interés. Gestión de configuración Debe proporcionar una interfaz para configurar sus propiedades 40 20

Supercomponentes Control de transacciones Debe proteger sus recursos transaccionalmente y cooperar con otros componentes. Persistencia Debe ser capaz de salvar su estado en un almacenamiento persistente y recuperarlo posteriormente. Relaciones Debe ser capaz de soportar asociaciones con otros componentes. Facilidad de uso, autoinstalable, versionado, 41 CORBA CORBA OMG OMA ORB 42 21

Qué es CORBA? Common Object Request Broker Architecture. Estándar para objetos distribuidos. Un estándar para interoperabilidad entre diferentes fabricantes de hardware y software: Una especificación para objetos remotos e interoperables. Las comunicaciones entre objetos utilizan un Object Request Broker. Puede ser soportado por cualquier plataforma. Los objetos se especifican en IDL. Cada fabricante implementa su propio producto CORBA compliant. 43 Qué es un objeto CORBA? Un objeto que puede vivir en cualquier lugar de una red. Un objeto empaquetado como un componente binario, de modo que cualquier cliente puede invocar sus métodos: No necesita saber dónde está el objeto servidor, ni sobre qué sistema operativo corre, ni cómo está implementado. Lo único que necesita conocer el objeto cliente es la interfaz del objeto servidor. Un objeto distribuido CORBA es un componente. 44 22

Existen otros estándares COM (Common Object Model): Es de Microsoft Es un estándar binario OpenDoc. RMI. 45 Qué es OMG? Object Management Group. Un comité responsable de especificar los estándares CORBA. Más de 600 compañías (IBM, HP, Sun, ). Muchas compañías en OMG también soportan COM. 46 23

Todo es IDL Lenguaje declarativo. Se utiliza para especificar componentes: Atributos, métodos, clases padre, La implementación de los métodos puede hacerse en cualquier lenguaje que tenga binding con IDL: La invocación a los métodos se hará en este lenguaje. IDL es independiente del sistema operativo y del lenguaje de programación. Permite que objetos clientes y servidores implementados en diferentes lenguajes y sistemas operativos puedan interoperar. 47 OMA OMG Management Architecture para C/S. Tres grandes segmentos: 1. Application Objects Componentes cercanos al usuario final. 2. System Oriented (ORB, Object Services) Se refiere a los aspectos de infraestructura de la computación distribuida. 3. Common Facilities 3.1. Horizontales. 3.2. Verticales (Domain Interfaces): objetos para dominios de aplicación específicos. 48 24

OMA Application Objects Domain Interfaces User Interface Common Facilities Information Management System Management Task Management Object Request Broker Naming Persistence Life Cycle Properties Concurrency Collections Security Trader Externalization Events Transactions Query Object Services Relationships Time Change Management Licensing 49 ORB Comercialmente CORBA. Permite a los objetos hacer peticiones (y recibir respuestas) de otros objetos. Invocación dinámica y estática de métodos. Peticiones transparentes (Local y Remota): ORB puede manejar llamadas entre objetos en un único proceso, en muchos procesos corriendo en la misma máquina, en muchos procesos corriendo en diferentes máquinas con diferentes sistemas operativos. 50 25

ORB Enlaces con lenguajes de alto nivel Permite invocar métodos de objetos servidores desde tu lenguaje de programación. Lenguajes soportados: C, C++, Cobol, Ada, Java Seguridad y Transacciones El ORB incluye en los mensajes información de contexto para manejar seguridad y transacciones. Mensajes polimórficos El ORB no sólo invoca una función remota sino que lo hace sobre un objeto determinado. Por tanto la misma función puede tener efectos diferentes (diferencia con RPC). 51 ORB Self-describing system CORBA proporciona metainformación en tiempo de ejecución para describir cualquier objeto servidor conocido por el sistema (Interface Repository). Interface Repository: contiene información describiendo las funciones (y sus parámetros) de los objetos servidores. Los clientes usan la metainformación en tiempo de ejecución para saber qué servicios pueden utilizar. La metainformación ha sido generada por el precompilador IDL o por el compilador del lenguaje. 52 26

Object Services Son componentes que proporcionan servicios, para los objetos, a nivel de sistema. Aumentan la funcionalidad del ORB. Se crean utilizando IDL. Naming Persistence Events Transactions Externalization Life Cycle Properties Query Concurrency Relationships Collections Time Security Change Management Trader Licensing 53 Object Services Persistence Proporciona una interfaz única para almacenar componentes en diferentes tipos de almacenamiento (RDB, ODB, ficheros, ). Naming Permite a los componentes localizar a otros por su nombre. Events Permite a los componentes registrarse o borrarse en eventos especificos. Transactions Proporciona un protocolo que permite a los componentes manejar transacciones normales y anidadas. 54 27

Object Services Externalization Proporciona una forma estándar (stream-like) de introducir y sacar información de los componentes. Life Cycle Define operaciones para crear, copiar, mover y borrar componentes en el ORB. Properties Proporciona operaciones que permiten poner propiedades al componente (fecha, hora, ). Query Permite operaciones de query a los componentes. Basado en SQL3 y en el OQL de OMG. 55 Object Services Concurrency Proporciona un manejador de bloqueos para transacciones. Relationships Permite crear dinámicamente asociaciones entre los componentes y recorrerlas. Licensing, Collections,Time,Security,Change Management,Trader. 56 28

Object Services Los Object Services permiten la creación de middleware bajo demanda El programador CORBA programa sin preocuparse de los Object Services. Ejem: el programador CORBA programa un componente y quiere que éste sea persistente y soporte transacciones. Cómo lo hace? Hace que su componente sea herencia múltiple de los componentes Persistence y Transaction. 57 Common Facilities (Horizont.) Comercialmente CORBAfacilities. Colecciones de componentes (definidos con IDL) que proporcionan servicios a los Application Objects. Ejemplos: utilidades de impresión, gestión de documentos, gestión de BD, correo electrónico. La estandarización de operaciones genéricas produce facilidad a los usuarios finales para configurar sus entornos de trabajo. 58 29

Common Facilities (Horizont.) Tipos: User Interface. Information Management. Ejem: gestión de documentos System Management. Ejem: configuración, instalación de objetos distribuidos Task Management. Ejem: correo electrónico 59 Common Facilities (Verticales) Domain Interfaces. Combinan las Common Facilities y los Object Services pero dirigidos a un mercado vertical. OMG ha estandarizado interfaces para Telecomunicaciones, Mercados Financieros y Servicios Médicos. 60 30

Application Objects Componentes específicos para aplicaciones finales. Se crean utilizando IDL. Se construyen utilizando los servicios del ORB, Object Services, Common Facilities y Domain Interfaces. No estandarizados por OMG. No son aplicaciones finales. 61 ORB Características Middleware que establece mecanismos básicos para comunicar objetos de forma transparente. Transparente ya que el objeto cliente invoca métodos del objeto servidor sin preocuparse de dónde está, en qué lenguaje ha sido implementado, El ORB intercepta la llamada, busca un objeto con un método que la pueda resolver, le pasa los parámetros y devuelve los resultados. ORB permite que la invocación de métodos sea estática o dinámica. 62 31

Arquitectura del ORB Cliente Object Implementation Almacen de Interfaces Interfaz para la Esquemas invocación IDL para el dinámica Cliente Interfaz del ORB Esquemas Estáticos Invocación Esquemas Dinámicos Adaptador de objetos Almacen de Implementaciones ORB Core 63 Parte Cliente Esquemas IDL para el Cliente Son esquemas compilados que definen cómo los objetos cliente invocan los servicios de los objetos servidores. El esquema actúa como una llamada local. Un esquema por interfaz. 64 32

Parte Cliente Interfaz para la invocación dinámica Permite descubrir el método a invocar en tiempo de ejecución. CORBA define APIs estándar (API de Invocación Dinámica) para: Buscar (en el AI) la metainformación que describe la interfaz del objeto servidor. Generar los parámetros. Lanzar la llamada remota. Conseguir los resultados. 65 Parte Cliente Almacén de Interfaces Es una Base de Datos en tiempo de ejecución que contiene las interfaces IDL de los objetos servidores. APIs del Almacén de Interfaces Permiten obtener y modificar las interfaces (métodos y sus parámetros) de todos los objetos registrados. 66 33

Parte Cliente y Servidora Interfaz del ORB APIs para servicios locales que pueden ser de interés a una aplicación. Ejemplos: Convertir una referencia a un objeto en un string y viceversa (string_to_object, object_to_string). Connect, disconnect, init,.. Las llamadas no son parte del mecanismo de invocación C/S. 67 Parte Servidora Esquemas IDL estáticos para el servidor Se generan utilizando el compilador de IDL. Proporcionan interfaces estáticas para cada servicio exportado por el servidor. Son el equivalente en la parte servidora a los Esquemas IDL para el Cliente. 68 34

Parte Servidora Invocación de Esquemas dinámicos Proporciona un mecanismo de enlazado en tiempo de ejecución para manejar llamadas a métodos que no tienen esquemas IDL compilados. Mira los valores de los parámetros en el mensaje recibido para descubrir el objeto y el método al que va destinado. Son útiles para implementar puentes entre ORBs. Es análogo al Interfaz de Invocación Dinámica en la parte cliente. 69 Parte Servidora Adaptador de Objetos Interfaz con los servicios de comunicación que ofrece el ORB Core. Acepta peticiones sobre los métodos de los objetos servidores. Proporciona un entorno en tiempo de ejecución para instanciar objetos servidores, asignarles referencias y pasarles peticiones de servicios. 70 35

Parte Servidora Adaptador de Objetos Registra las clases que soporta y sus objetos en tiempo de ejecución en el Almacen de Implementaciones. CORBA especifica que cada ORB debe soportar un adaptador estándar, llamado Adaptador Básico de Objetos. 71 Parte Servidora Almacén de Implementaciones Es un almacén de información sobre: Las clases que soporta el servidor. Los objetos que están instanciados y sus identificadores. Información adicional asociada con la implementación de ORBs. Ejem: seguridad, auditorias,... 72 36

CORBA... Invocación Estática vs. Dinámica. Adaptador de Objetos. Adaptador de Objetos Básico. Inicialización de un objeto en un ORB. Interoperabilidad de ORBs. 73 Invocación Dinámica/Estática Invocación estática Generada en forma de esqueletos por el compilador de IDL. Ventajas (invocación estática): Es útil para programas que en tiempo de compilación conocen las particularidades de las operaciones que necesitarán invocar. Chequeo de tipos robusto (compilador). Buenas prestaciones. Ventajas (invocación dinámica): Flexible (permite añadir clases al sistema sin cambios en el código del cliente). 74 37

CORBA: Invocación Estática 1. Declarar las clases Con IDL declararemos el nombre de la clase, los atributos, los métodos y sus parámetros. 2. Precompilar los ficheros IDL Con un precompilador CORBA-compliant precompilamos y generamos los esquemas de las clases. 3. Añadir la implementación a los esquemas Implementar en el lenguaje objetivo los métodos declarados en los esquemas. 75 CORBA: Invoc. Estática 4. Compilar el código Un compilador CORBA-compliant generará cuatro tipos de ficheros: Código que implementa las clases servidoras. Esquemas para el Cliente (Client stub): esquemas que serán invocados por un programa cliente que necesite acceder estáticamente. Esquemas para el Servidor (Server stub): llama a los métodos en el servidor. Ficheros a Importar (Import Files): describen los objetos en el Almacen de Interfaces. 5. Enlazar las definiciones de las clases al Almacen de Interfaces. Hay una utilidad que lo hace. 76 38

CORBA: Invoc. Estática 6. Instanciar los objetos en el servidor. Misión del Adaptador de Objetos. 7. Registrar los objetos en ejecución en el Almacen de Implementaciones. El Adaptador de Objetos graba en el Almacen de Implementaciones la referencia y el tipo de cualquier objeto instanciado en el servidor. El Almacen de Implementaciones también sabe qué clases son soportadas en un servidor particular. El ORB utiliza esta información para localizar objetos activos o peticiones de activación de objetos en un servidor particular. 77 CORBA: Invocación Dinámica La API de invocación dinámica permite a los objetos cliente construir e invocar dinámicamente peticiones a los objetos servidores. Pasos para invocar un método dinámico: 1. Obtener del AI la descripción del método. CORBA proporciona unas 10 llamadas para localizar y describir los objetos del Almacen de Interfaces. Ejem: lookup_name(), describe(), 2. Crear la lista de argumentos. CORBA especifica una estructura de datos para pasar parámetros NamedValueList y operaciones create_list() y add_arg() 78 39

CORBA: Invoc. Dinámica 3. Crear la solicitud. Se crea con create_request() y se especifica la referencia del objeto, el nombre del método y la lista de argumentos. 4. Lanzar la solicitud. Tres formas: 1. Invoque envía la solicitud y obtiene los resultados. 2. Send devuelve el control al programa que debe lanzar un get_response o un get_next_response. 3. Send sin esperar respuesta. 79 Parte Servidora: Adp. Objetos Qué necesita un Componente del ORB en la parte servidora? Que se registren las clases de la aplicación. Instanciar nuevos objetos y darles identificadores. Informar de la existencia de estos. Invocar sus métodos a petición de los clientes (posiblemente concurrentes). Balanceo de carga, gestión de transacciones, etc. Adaptador de Objetos. Proporciona un entorno para ejecutar la aplicación servidora. 80 40

Estructura del AO 6.Pasar llamada al método Object Implementation Esquema Interfaz A ID Esquema Interfaz B Adaptador de Objetos ID 2.Crear nuevos objetos 1.Registrar nuevas clases ID 3.Referencias a objetos Almacen de Implementaciones 5.Gestionar peticiones 4.Informar de los servicios 81 Adaptador de Objetos Servicios del Adaptador de Objetos: 1. Registra y almacena las clases del servidor en el Almacén de Implementaciones. El AO gestiona las clases del servidor en el AI. 2. Instancia objetos servidores en tiempo de ejecución. Lo hace en el Almacén de Implementaciones, las instancias se crean en función de las peticiones de los clientes. 3. Crea y gestiona referencias a los objetos. A cada nuevo objeto el Adaptador le crea y asigna una nueva referencia (ID). 82 41

Adaptador de Objetos 4. Da a conocer la existencia de los objetos servidores. Puede propagar al ORB Core los servicios que proporciona o puede responder a querys del ORB Core. 5. Gestiona las llamadas de los objetos clientes. El Adaptador de Objetos interactúa con el nivel más alto del ORB Core, desgrana la petición y se la pasa al Esquema del objeto. El Esquema es responsable de interpretar los parámetros y presentarlos de forma adecuada al objeto servidor que invocará el método. 6. Direcciona la llamada al método apropiado. 83 Adaptador de Objetos Básico Un servidor podría soportar diferentes tipos de Adaptadores de Objetos para satisfacer diferentes tipos de peticiones. Ejemplo: un ODBMS podría querer registrar implicitamente todos los objetos que contiene sin lanzar llamadas al AO. En este caso no tendría sentido que el AO mantuviese un estado para cada objeto. El ODBMS podría querer un AO de propósito específico, que no sólo interactuase con el ORB Core sino que también satisfaga sus intereses. 84 42

Adaptador Objetos Básico CORBA prefiere que no proliferen diferentes tipos de Adaptadores de Objetos. Para evitarlo especifica el Adaptador de Objetos Básico. Servicios: El Almacen de Implementaciones debe proporcionar la información que describe a los objetos servidores. Mecanismos para generar e interpretar referencias de objetos; activar y desactivar objetos servidores; invocar métodos y pasar sus parámetros a través de los esquemas. Mecanismo para autentificar al Cliente que hace la llamada. 85 Adaptador Objetos Básico No especifica cómo se localizan los métodos. Políticas para activación (planificación) de objetos servidores: Servidor compartido. Servidor no compartido. Servidor por método. Servidor persistente. 86 43

AOB (Servidor compartido) Proceso Aplicación Primera llamada entra. Las demás esperan Esquema Interfaz A Esquema Interfaz B Adaptador Objetos Básico 87 AOB (Servidor compartido) Crear un proceso por clase, todas las peticiones se dirijen a él. Muchos objetos residen en el mismo proceso. La primera vez que llega una petición para algún objeto del tipo se crea el proceso: impl_is_ready: el proceso indica que puede manejar peticiones. El proceso maneja una petición a la vez: deactivate_obj: fin de procesar una petición. deactivate_impl: el proceso puede terminar. 88 44

AOB (Serv. no compartido) Proceso Proceso Proceso Proceso Aplicación Esquema Interfaz A Esquema Interfaz B Adaptador Objetos Básico 89 AOB (Serv. no compartido) Cada objeto reside en un proceso. La primera vez que llega una petición para un objeto se crea el proceso. obj_is_ready, el proceso indica que puede manejar peticiones. Cuando llega una petición para un objeto no activo se crea un proceso, aunque haya uno creado para algún objeto del mismo tipo. deactivate_obj, deja de procesar peticiones. 90 45

AOB (Serv. por método) El proceso termina con la ejecución del método. Proceso Proceso Proceso Aplicación Esquema Interfaz A Esquema Interfaz B Adaptador Objetos Básico 91 AOB (Serv. por método) Se crea un proceso por petición à no es necesario indicar cuándo se está activo y cuándo no. Diferentes procesos para el mismo objeto (e incluso el mismo método) pueden estar activos concurrentemente. El proceso se destruye cuando concluye la ejecución para la que había sido creado à no hace falta notificaciones. 92 46

AOB (Serv. persistente) Proceso Proceso Proceso Aplicación específica. Aplicación Planificador Esquema Interfaz A Esquema Interfaz B Adaptador Objetos Básico 93 AOB (Serv. persistente) Los procesos no son activados por el ABO. impl_is_ready, notifica al ABO que está preparado para aceptar peticiones. El ABO trata las siguientes peticiones como llamadas a servidor compartido. 94 47

Inicialización Cómo encuentra un Componente su ORB? CORBA define un conjunto de APIs de inicialización que permiten a un objeto insertarse en el entorno de un ORB. Descubrir su ORB, ABO y Almacén de Interfaces. Pseudo-objeto:objeto creado directamente por un ORB. Operaciones para insertarse: 1. Obtener una referencia al ORB. Lanzar la llamada ORB_init para informar al ORB de su presencia y obtener la referencia al ORB. 95 Inicialización 2. Obtener una referencia al Adaptador de Objetos. Invocar el método BOA_init del ORB para decir al AOB que está ahí y obtener su referencia. 3. Descubrir qué servicios iniciales están disponibles. Invocar el método list_initial_services del ORB para obtener la lista de objetos conocidos. 4. Obtener referencias a los objetos cuyos servicios desee invocar. Invocar el método resolve_initial_references. El objeto ya es un ciudadano en el ORB. 96 48

Inicialización Objeto Nuevo CORBA API ORB ORB_init BOA_init list_initial_services resolve_initial_references 97 Interoperabilidad ORBs Objetivo: transferir peticiones de un ORB a otro à Comunicaciones ORB-to-ORB. Las primeras versiones de CORBA no estandarizaron interoperabilidad entre ORBs. Es necesario que exista interoperabilidad entre los ORBs de diferentes fabricantes. CORBA especifica los protocolos: IIOP (Internet Inter-ORB Protocol). GIOP (General Inter-ORB Protocol). 98 49

Interoperabilidad ORBs... Modelo OSI Aplicación Presentación Sesión Transporte Red Enlace Físico CORBA ORB GIOP IIOP TCP IP Enlace Físico 99 Arquitectura Inter-ORB Petición CORBA IDL Obligatorio Opcional Sintaxis de mensajes y transferencia General Inter-ORB Protocol (GIOP) Environment Specific Inter-ORB Protocols (ESIOP) DCE/ESIOP Transporte Internet Inter-ORB Protocol (IIOP) TCP/IP... Otros por ejemplo OSI IPX/SPX DCE RPC sobre TCP/IP DCE RPC sobre OSI etc.... Internet 100 50

GIOP General Inter-ORB Protocol. General por ser independiente del protocolo de transporte. Específico para interacciones ORB-to-ORB. Diseñado para protocolos de transporte orientados a conexión. Especifica un conjunto de formatos de mensajes y representación de datos para comunicaciones entre ORBs. 101 GIOP (Objetivos Diseño) Mayor accesibilidad posible. GIOP/IIOP está asociado a TCP/IP, utiliza Internet (mecanismo de transporte más accesible). Simple. Sólo tiene en cuenta interacciones ORB-to-ORB. Escalable. Bajo coste. Internet. Ejemplo: comunicación CORBA con EJB. 102 51

GIOP (Objetivos Diseño...) General. El formato de mensaje es independiente del medio de transporte. Independiente de la arquitectura. No hace suposiciones sobre la arquitectura del ORB. 103 GIOP (Elementos) Requerimientos de interoperabilidad entre ORBs: Encapsulación: dos ORBs que se comunican desconocen los mecanismos internos. El protocolo de transporte proporciona soporte total a la funcionalidad de CORBA. Para ello es necesario: Common Data Representation (CDR): cómo se representan los datos en el transporte. Formato de los mensajes. Suposiciones de transporte. 104 52

GIOP (CDR) Objetivo: transformar los tipos de datos de IDL en una representación de mensajes de red. Eficiente y segura. El cliente envía el mensaje en su arquitectura nativa. En el mensaje se indica la codificación (bigendian/little endian). El servidor se encarga de transformarlo a su arquitectura. 105 GIOP (Mensajes) Sólo 8 formatos de mensaje: Sencillez. Proporcionan toda la funcionalidad necesaria que dos ORBs necesitan para comunicarse. Proporcionan el soporte necesario para toda la funcionalidad de CORBA. Request LocateRequest CancelRequest CloseConnection MessageError Fragment Reply LocateReply Cliente Cliente Cliente Cliente y Servidor Cliente y Servidor Cliente y Servidor Servidor Servidor 106 53

GIOP (Suposiciones) Soporte bidireccional (full duplex). El cliente abre la conexión. El servidor sólo puede enviar mensajes en una conexión ya abierta à No necesita conocer la dirección del cliente. Cualquiera de las dos partes puede terminar la conexión. El ORB puede multiplexar mensajes. En una única conexión muchos clientes pueden comunicar con un único objeto servidor. Es posible porque en la petición queda identificado el objeto. 107 GIOP (Suposiciones...) El protocolo de transporte es orientado a conexión. El cliente puede tener abierta una conexión con el servidor para más de una transmisión. Si ocurre un error durante la transmisión ambas partes son informadas. 108 54

IIOP Es la implementación de GIOP sobre TCP/IP. Especifica cómo deben ser intercambiados los mensajes GIOP en una red TCP/IP. IIOP hace posible el uso de Internet como el armazón ORB a través del cual otros ORBs pueden puentear. Define un perfil para ser incluido en una IOR. Para instanciar GIOP, IIOP define cómo el perfil codifica TCP/IP info en una IOR, así el servidor puede comunicar con el cliente. 109 IIOP... IOR: ID de repositorio: el tipo del objeto. Perfiles: cada perfil encapsula info para localizar y comunicar con un objeto. Perfil IIOP: Versión IIOP. Identificación del host servidor (dirección IP) y número de puerto. Identificador del objeto servidor. 110 55

ESIOPs Environment-Specific Inter-ORB Protocols. Existen varios, son opcionales, CORBA señala DCE como el primero. DCE soporta IOR usando CDCE tagged profile. DCE utiliza GIOP CDR para representar los tipos IDL sobre DCE RPC, por tanto DCE IDL no es necesario. En cambio los tipos de OMG IDL y CDR son mapeados en DCE s native Network Data Representation. 111 ESIOPs DCE proporciona un robusto entorno para ORBs con misiones críticas. Características: Seguridad Kerberos. Directorios globales. Tiempo distribuido. Múltiples protocolos de transporte (TCP/IP, ). Permite transmitir gran cantidad de información de forma eficiente. 112 56

Puentes ORB-to-ORB CORBA proporciona los mecanismos necesarios para crear puentes ORB-to-ORB (también utilizados para crear pasarelas a OLE/COM). Cliente Operación lógica de solicitud C/S Servidor Interfaz invocación dinámica Puente Invocación Esquemas Dinámicos ORB A ORB B 113 ORBs Federados Se pueden utilizar puentes entre ORB y IIOPs para crear topologías más flexibles. Se pueden segmentar ORBs en dominios basados en necesidades administrativas, protocolos de red, carga en el tráfico, tipos de servicio, seguridad, 114 57

ORBs Federados Esqueleto ORB (DCCE/ESIOP) ORB A ORB B Esqueleto ORB (IIOP) ORB A ORB B 115 Para saber más The Common Object Request Broker: Architecture and Specification OMG Document Revision 3.0.2 Disponible: http://www.omg.org 116 58