Tema 08

Tema 8.
CORBA (y Mono )
1. Introducción y objetivos
2. La invocación remota en CORBA
3. Un ejemplo
4. La arquitectura
5. El Lenguaje de Definición de Interfaz
6. Los Servicios CORBA
7. El proyecto Mono (.NET )
Tema 8 CORBA (y Mono) 1

Introducción y objetivos

Introducción. 1
• OMG (Object Management Group):

– creado en 1989
– aboga por el uso de sistemas abiertos con
interfaces estándar orientadas a objetos
• construidos con hardware, redes, sistemas operativos
y lenguajes heterogéneos
 diseño de un lenguaje de interfaz
• ORB (Object Request Broker):
– literalmente: corredor de solicitudes a objetos
– mediador entre el cliente y los métodos de un
objeto
• localizar el objeto, activarlo, y pasarle la solicitud
• y hacer llegar los resultados al cliente
Introducción. 2
• CORBA (Common ORB Architecture)

– aprobada en 1991
• En 1996: CORBA 2.0
– GIOP (General Inter-ORB Protocol):
• normas que permiten que puedan cooperar
implementaciones de diferentes fabricantes
• implementado sobre cualquier nivel de
transporte
• en Internet, sobre TCP/IP: IIOP (Internet
IOP)
• Normas + productos

Objetivos
• Conocer el marco CORBA para la

invocación de métodos remotos
– El lenguaje de definición de interfaz:
IDL
– La arquitectura
– La representación externa de datos:
CDR
– Las referencias a objetos remotos
– Los servicios CORBA

La invocación remota en CORBA

La Invocación Remota en CORBA
• Similar al modelo:
– el programador define las interfaces remotas
– el CI genera delegados y esqueletos
• delegados: en el lenguaje del cliente
• esqueletos: en el lenguaje del servidor
• Novedades:
– LDI propio: CORBA IDL
– modelo propio de objeto
• los clientes no tienen por qué ser objetos
• objeto CORBA: un objeto remoto
– implementa una interfaz remota
– puede estar escrito en cualquier lenguaje
 CORBA no soporta la noción de clase

Ejemplos de interfaces remotas en CORBA IDL
struct Rectangulo {
long ancho; struct ObjetoGrafico {
long alto; string tipo;
long x; Rectangulo region;
long y; boolean relleno;
}; };
interface Figura {
long dameVersion();
ObjetoGrafico dameEstado();
};
typedef sequence <Figura, 100> Todas;
interface Pizarra{
exception ExcepcionLleno {};
Figura creaFigura(in ObjetoGrafico g)
raises(ExcepcionLleno);
Todas dameLasFiguras();
long dameVersion();
};

Parámetros y resultados en CORBA IDL
• No podemos pasar individuos de clases,

pero sí estructuras
• movimiento: in, out e inout
– el resultado siempre es out (puede ser void)
• tipos: primitivos o estructurados
• forma de paso:
– objetos CORBA: por referencia (ROR)
• especificados por el nombre de una interfaz IDL
– primitivos y estructurados: por valor
• tipo Object: sus valores son RORs

– supertipo de todos los tipos de interfaces IDL
Otras características de CORBA IDL
• Excepciones remotas:
– se definen en las interfaces
• Semántica: por defecto, como-mucho-una-vez
– opcionalmente: oneway  tal-vez
• Pseudo-objetos:
– interfaces provistas por las implementaciones
– especiales: no se pueden pasar como argumentos de
métodos remotos, ...
– Ejemplos:
• POA, con métodos:
– activate: para activar el gestor del POA
– servant_to_reference: para registrar objetos CORBA
• ORB, con métodos:
– init: para inicializar un ORB
– resolve_initial_references: para encontrar el POA, el Servidor
de Nombres, …
– object_to_string y string_to_object: ROR  cadenas

Un ejemplo

Un ejemplo con Java como lenguaje de aplicación
• Dada NombreInterfaz, el CI (idltojava, jidl ...)
genera:
– las correspondientes interfaces Java:
• NombreInterfazOperations.java: define las operaciones
• NombreInterfaz.java: extiende la anterior y otras que
soportan a los objetos CORBA
– la clase del esqueleto para cada interfaz IDL
• NombreInterfazPOA.java
– la clase del delegado para cada interfaz IDL
• _NombreInterfazStub.java
– una clase Java para cada struct
• una variable de individuo para cada campo
• sólo 2 métodos: constructores
– clases ayudantes (helpers)
• método narrow: pasa una ROR a una clase concreta
– clases contenedores (holders)
• para tratar parámetros out e inout
Interfaces Java para Pizarra
• El compilador de interfaz genera:
public interface PizarraOperations {
Figura creaFigura(ObjetoGrafico g)
throws PizarraPackage.ExcepcionLleno;
Figura[] dameLasFiguras();
int dameVersion();
}
public interface Pizarra extends PizarraOperations,
org.omg.CORBA.Object,
org.omg.CORBA.portable.IDLEntity
{ }
public abstract class PizarraPOA
extends org.omg.PortableServer.Servant
implements org.omg.CORBA.portable.InvokeHandler,
PizarraOperations
{ }
El programa del servidor
• Implementa una o más interfaces IDL
– como objetos de clases sirvientes:
• al crear un individuo se lo debe registrar en el POA
– eso lo convierte en un objeto CORBA y le da una ROR
– necesario para poder recibir invocaciones remotas
– en nuestro ejemplo:
• 1 clase SirvientePizarra
• 1 clase SirvienteFigura
• 1 clase ServidorPizarra, con la inicialización:
– método main que crea e inicializa el ORB
– localiza el POA y activa el gestor del POA
– crea 1 individuo de SirvientePizarra
» los de SirvienteFigura se crean con métodos factoría
– lo registra en el POA  ROR
– lo registra en el Servicio de Nombres
– y se queda a la espera de invocaciones

Clase ServidorPizarra con método main
import org.omg.CORBA.*;
import org.omg.CosNaming.*;
import org.omg.PortableServer.*;
public class ServidorPizarra {
public static void main(String args []) {
try{
ORB elOrb = ORB.init(args, null);
org.omg.CORBA.Object PoaObj =
elOrb.resolve_initial_references(″RootPOA″);
POA elPoa = POAHelper.narrow(PoaObj);
elPoa.the_POAManager().activate();
SirvientePizarra pizarraLocal = new SirvientePizarra(elPoa);
org.omg.CORBA.Object sirviente =
elPoa.servant_to_reference(pizarraLocal);
org.omg.CORBA.Object refObj =
elOrb.resolve_initial_references(″NameService″);
NamingContext refSN = NamingContextHelper.narrow(refObj);
NameComponent nc = new NameComponent(″Pizarra″, ″″);
NameComponent nombre [] = { nc };
refSN.rebind(nombre, sirviente);
elOrb.run();
} catch(Exception e) { ... }
}
}

Clase SirvientePizarra del programa servidor en
Java para la interfaz CORBA Pizarra
import org.omg.PortableServer.*;
public class SirvientePizarra extends PizarraPOA {
private POA elPoa;
private Figura laLista[];
private int version;
private static int n = 0;
public SirvientePizarra(POA poa) {
elPoa = poa; // e inicialización del resto de variables de individuo
}
public Figura creaFigura(ObjetoGrafico g)
throws PizarraPackage.ExcepcionLleno {
if (n>=100) throw PizarraPackage.ExcepcionLleno();
version++;
Figura s = null;
SirvienteFigura figuraLocal = new SirvienteFigura(g, version);
try {
org.omg.CORBA.Object sObj = elPoa.servant_to_reference(figuraLocal);
s = FiguraHelper.narrow(sObj);
} catch (Exception e) { … }
laLista[n++] = s;
return s;
}
public Figura[] dameLasFiguras(){ ... }
public int dameVersion() { ... }
}

Cliente Java para las interfaces CORBA
Figura y Pizarra
import org.omg.CosNaming.*;
import org.omg.CORBA.*;
public class ClientePizarra {
public static void main(String args []) {
try {
ORB elOrb = ORB.init(args, null);
org.omg.CORBA.Object refObj =
elOrb.resolve_initial_references(″NameService″);
NamingContext refSN =
NamingContextHelper.narrow(refObj);
Name nombre;
nombre[0] = new NameComponent(″Pizarra″, ″″);
org.omg.CORBA.Object laPizarraObj =
refSN.resolve(nombre);
Pizarra laPizarra =
PizarraHelper.narrow(laPizarraObj);
Figura[] laListaFiguras = laPizarra.dameLasFiguras();
ObjetoGrafico g = laListaFiguras[0].dameEstado();
} catch(org.omg.CORBA.SystemException e) { ... }
}
}

ClientePizarra en C++
#include <OB/CORBA.h>
#include <OB/CosNaming.h>
#include <Pizarra.h>
int main(int argc, char* argv[], char*[]) {
try{
CORBA::ORB_var elOrb = CORBA::ORB_init(argc, argv);
CORBA::Object_var refObj =
elOrb->resolve_initial_references(″NameService″);
CosNaming::NamingContext_var refSN =
CosNaming::NamingContext::_narrow(refObj.in());
CosNaming::Name nombre;
nombre.length(1);
nombre[0].id = CORBA::string_dup(″Pizarra");
nombre[0].kind = CORBA::string_dup("");
CORBA::Object_var obj = contextoInic->resolve(nombre);
Pizarra_var laPizarra = Pizarra::_narrow(obj.in());
Todas_var laListaFiguras;
laListaFiguras = laPizarra.dameLasFiguras();
ObjetoGrafico_var g;
g = laListaFiguras[0].dameEstado();
} catch(const CORBA::Exception& e) { ... }
}

ServidorPizarra en C++
#include <OB/CORBA.h>
#include <OB/CosNaming.h>
#include <SirvientePizarra.h>
int main(int argc, char* argv[], char*[]) {
try{
CORBA::ORB_var elOrb = CORBA::ORB_init(argc, argv);
PortableServer::POA_var elPoa =
PortableServer::POA::_narrow(CORBA::Object_var(
elOrb->resolve_initial_references(″RootPOA")));
elPoa->the_POAManager()->activate();
SirvientePizarra* pizarraLocal = new SirvientePizarra(elPoa);
CORBA::Object_var sirviente = elPoa->servant_to_reference(pizarraLocal);
CORBA::Object_var refObj =
elOrb->resolve_initial_references(″NameService″);
CosNaming::NamingContext_var refSN =
CosNaming::NamingContext::_narrow(refObj.in());
CosNaming::Name nombre;
nombre.length(1);
nombre[0].id = CORBA::string_dup(″Pizarra");
nombre[0].kind = CORBA::string_dup("");
refSN->rebind(nombre, sirviente.in());
elOrb->run( );
} catch(const CORBA::Exception& e) { ... }
}

Retrollamadas (callbacks)
• Similar al caso de Java RMI
– el cliente implementa una interfaz como un objeto CORBA
• Interfaz del objeto de retrollamada del cliente:
interface RetroPizarra {
oneway void avisa(in int version);
}
• Métodos adicionales en la interfaz Pizarra
int registra(in RetroPizarra retro);

void daDeBaja(in int idRetro);

La arquitectura

La Arquitectura
• Objetivo: soportar el papel de un ORB:

– permite a los clientes invocar métodos de ORs
– clientes y servidores en lenguajes variados
• Novedades:
– adaptador de objetos,
– repositorio de interfaces,
– repositorio de implementaciones
• El núcleo del ORB
– similar al módulo de comunicaciones, más:
• operaciones para arrancarlo y pararlo,
• convertir entre RORs y cadenas,
• proveer de listas de argumentos para IMR dinámica
Los componentes principales de la arquitectura CORBA
Repositorio de
Cliente Servidor
implementaciones
Adaptador de objetos
Programa cliente
Núcleo del ORB
Núcleo del ORB
Esqueleto de A
Delegado de A
Sirviente de A
Repositorio de
interfaces
Solicitud
Respuesta
o invocación dinámica o invocación dinámica

El adaptador de objetos (POA)
• A partir de CORBA 2.2: POA (portable OA)
• Sirve para salvar las distancias entre:
– objetos CORBA con interfaces IDL y las interfaces en los
lenguajes de programación de los sirvientes
• Equivale a:
– módulo de ROR + repartidor
• Funciones:
– para cada objeto CORBA crea la correspondiente ROR
• incorpora un nombre de objeto único
– generado por el POA o impuesto por la aplicación
• el nombre del POA también forma parte de dicha ROR
• mantiene la tabla {nombre de objeto}  {sirviente}
– entrega cada IMR al sirviente, a través de su esqueleto
– participa en la activación de los objetos persistentes

El repositorio de implementaciones (IMR )
• Los objetos no activables no usan el IMR
• Activa bajo demanda servidores registrados, y
• localiza servidores actualmente en ejecución
• Al registrar un servidor:
– se establece una correspondencia entre:
• su nombre de objeto en el adaptador de objetos, y
• la ruta de acceso al fichero que contiene la implementación
del objeto
• Al activar un servidor, se añade:
– el nombre del ordenador y el puerto de servicio
• Entrada del IMR:
Nombre del Ruta de acceso a Nombre de ordenador
objeto en el la implementación y número de puerto
adaptador de objetos del objeto del servidor
El repositorio de interfaces (IFR )
• No todos los ORBs implementan el IFR:
– las aplicaciones con IMR estática no lo necesitan
• Por cada interfaz IDL registrada provee:
– los nombres de sus métodos, y
– por cada método:
• los nombres y los tipos de sus argumentos y excepciones
• Reflexión en CORBA:
– un cliente que recibe una ROR y no tiene el delegado
correspondiente, le pide la información al IFR
• Identificador de Repositorio (repository ID):
– asignado al tipo de cada interfaz por el CI
– añadido a las ROR de los objetos CORBA

La invocación dinámica
• Utilizada en casos en que no se conoce el
tipo de la interfaz en tiempo de compilación
• Interfaz de invocación dinámica:
– si un cliente no tiene la clase del delegado de
un objeto remoto, le pide los datos al IFR
• (no puede descargar la clase como en Java RMI)
• Interfaz de esqueleto dinámico:
– permite a un objeto CORBA recibir solicitudes
sobre una interfaz de la que no tiene esqueleto:
• inspeccionar las solicitudes,
• obtener el objeto destino, el método y sus argumentos
• y llamar al correspondiente método del sirviente

El lenguaje de
definición de interfaz

El Lenguaje de Definición de Interfaz
• CORBA IDL permite definir:

– módulos, interfaces, tipos, atributos y
signaturas de métodos
• Es un subconjunto de C++, con
construcciones adicionales
• Módulo (module):
– permite agrupar interfaces y definiciones de
tipos en unidades lógicas
– define un ámbito propio de nombramiento
module PizarraElectronica {
...
};

Tipos en IDL
• 15 tipos primitivos:
– octet, short, long, long long, unsigned short,
unsigned long, unsigned long long, float,
double, char, wchar, string, wstring,
boolean y any
– constantes de estos tipos: declaradas con const
• 6 tipos estructurados:
– pasados siempre por valor
– arrays y secuencias: siempre definidos con
typedef
• any puede representar a cualquier tipo
primitivo o estructurado
Los tipos estructurados de IDL
Tipo Ejemplos Uso

Define un tipo para una sucesión de longitud varia-
typedef sequence <Figura, 100 > Todas;
secuencia typedef sequence <Figura > Todas;
ble de elementos de un tipo IDL especificado. Se
puede especificar un límite superior de la longitud
Define una cadena de caracteres terminada en
string nombre;
string typedef string<8 > cadenaCorta;
nulo. Se puede especificar un límite superior de
la longitud
typedef octet IdUnico[12]; Define un tipo para un vector de longitud fija de
array typedef ObjetoGrafico OG[10][8]; elementos de un tipo IDL especificado
struct ObjetoGrafico {
string tipo; Define un tipo para un registro o estructura. Se
registro Rectangulo region;
boolean relleno; pasan por valor en los argumentos y resultados
}
enumerado enum Rand (Exp, Numero, Nombre); El tipo enumerado en IDL

union Exp switch (Rand) { La unión discriminada de IDL permite pasar como
case Exp: string voto; argumento a uno de entre un conjunto de tipos. La
unión case Numero: long n;
case Nombre: string s; cabecera se parametriza con un enum, que
} especifica qué miembro se está usando.

Herencia
• Permite extender interfaces
interface B : A{ };
• Una interfaz extendida puede:
– añadir nuevos tipos, constantes, excepciones, métodos y
atributos
– redefinir tipos, constantes y excepciones
– extender más de una interfaz
interface C : A, B{ };
• conflictos en tipos, constantes o excepciones: cualificación
 A ::Q  B ::Q
• conflictos en métodos o atributos: no permitidos
• Un valor de un tipo extendido es válido como valor
de un argumento del tipo padre
• Todas las interfaces IDL heredan de Object

Las ROR en CORBA
• En CORBA 2.0 se definen las ROR como:
– referencias a objetos interoperables (IOR)
Nombre del tipo de Protocolo de transporte y Clave de objeto
la interfaz IDL detalles de la dirección
Identificador de Nombre
IIOP Nombre del Número del POA
Nombre del objeto
repositorio interfaces ordenador de puerto en el POA
• IOR transitorio:
– dura lo que el proceso que aloja al objeto
– contiene los detalles del servidor
• IOR persistente:
– permanece entre activaciones del objeto CORBA
– contiene los detalles del IMR
Cuestiones con los lenguajes de programación
• Java: traducción casi directa, pero

– problemas con los argumentos de salida
void tomaPersona(in string nombre, out Persona p);
– en Java hay que usar una clase contenedor:
void tomaPersona(String nombre, PersonaHolder p);
• donde el valor recibido está en: p.value
• C++: también es fácil, pero:
– el problema está en la gestión de la memoria
• los argumentos de salida se liberan al terminar el
método
• si aún se necesitan, se deben duplicar previamente

Los servicios CORBA

Los Servicios CORBA
• Los servicios más importantes son:

Nombramiento (Naming)
Eventos
Notificación
Seguridad
Comercio (Trading)
Transacciones
Control de la Concurrencia
Objetos persistentes

El Servicio de Nombramiento
• Es un binder sofisticado. Permite:

– enlazar nombres a ROR de objetos CORBA
– dentro de contextos de nombramiento (CN)
• Estructura jerárquica
– nombre enlazado a ROR o a otro CN
• Un contexto inicial de nombramiento (CIN)
proporciona una raíz para un conjunto de
enlaces
– cada ejemplar de ORB tiene un CIN
• pero los SN de varios ORB se pueden federar
– a un punto se puede llegar desde más de 1 CIN
Funcionamiento del Servicio de Nombramiento
• Los clientes y servidores le piden un CIN

al ORB
elOrb.resolve_initial_references (”NameService”);
• el ORB retorna una referencia a un objeto

que implementa NamingContext
– se refiere al contexto inicial del SN de ese ORB
• No hay nombre absolutos
– siempre son relativos a un CIN
• Nombres multi-componente:
– búsqueda recursiva desde un CN
• cada componente nos va llevando a sucesivos CN
• el último componente nos proporciona una ROR

La interfaz IDL NamingContext del
Servicio de Nombramiento de CORBA (fragmento)
struct NameComponent { string id; string kind; };
typedef sequence <NameComponent> Name;
interface NamingContext {
void bind(in Name n, in Object obj);
Enlaza en mi contexto el nombre dado y la referencia al objeto remoto
void unbind(in Name in);

Deshace un enlace
void bind_new_context(in Name n);

Crea un nuevo contexto de nombramiento y lo enlaza en mi contexto
al nombre dado
Object resolve(in Name in);

Busca el nombre en mi contexto y retorna su ROR asociada
void list(in unsigned long how_many, out BindingList bl, out BindingIterator bi);
Retorna los nombres de los enlaces de mi contexto
};

Árboles de nombres en el
Servicio de Nombramiento de CORBA
Contexto inicial Contexto inicial Contexto inicial

de nombramiento de nombramiento de nombramiento
A P XX T
Pizarra
B
C U W
D S R V

Los nombres
• Son secuencias de NameComponent

• Tienen dos partes (cadenas):
– el nombre propiamente dicho (id)
– la categoría (kind), un atributo:
• interpretado por las aplicaciones, no por el SN
• No es posible usar rutas de acceso
– porque los nombres admiten cualquier carácter
– el argumento de resolve es del tipo Name
• una secuencia de NameComponent
• bind y rebind permiten enlazar un nombre a
una ROR en un contexto dado
– rebind admite reemplazar una ROR por otra
Federación y Java
• Federación de SN:
– cada SN gestiona un subconjunto del árbol de
nombres
– algunos enlaces se refieren a CN en los
subconjuntos gestionados por otros SN
• Implementación Java del Servicio de

Nombramiento de CORBA:
– transitoria: guarda todos los enlaces en
memoria volátil
– muy simple
– muy poco operativa
El Servicio de Eventos
• Define interfaces para comunicar notificaciones
– desde objetos de interés: suministradores (suppliers)
– a sus suscriptores: consumidores (consumers)
– como argumentos o resultados de IMR síncronas
• Dos mecanismos de propagación:
– empujados (push) desde el suministrador
• los consumidores implementan la interfaz PushConsumer
• que incluye el método push, invocado por el suministrador
– cuyo argumento (de tipo any) es lo notificado
• los consumidores previamente registran su ROR
– extraídos (pull) por los consumidores
• el suministrador implementa la interfaz PullSupplier
• que incluye el método pull, invocado por los consumidores
– cuyo resultado (de tipo any) es lo notificado
• el suministrador previamente registra su ROR

Los canales de eventos
• Permiten la notificación asíncrona entre:
– múltiples suministradores y
– con múltiples consumidores
• Son un buffer entre los suministradores y los
consumidores
• Admiten push, pull o una mezcla de ambos
• Se pueden construir cadenas de canales
canal de eventos
suministrador consumidor
notificación notificación notificación
consumidor delegado suministrador delegado

El Servicio de Notificación
• Es una extensión del Servicio de Eventos:

– definir las notificaciones como estructuras de datos
– un consumidor puede usar filtros para especificar sus
eventos de interés
– un suministrador puede descubrir los eventos de interés
de sus consumidores
• y generar sólo esos eventos
– el consumidor puede descubrir los tipos de nuevos
eventos ofrecidos por el suministrador
• y suscribirse a ellos
– configurar las propiedades de un canal, un delegado o
un evento concreto:
• garantías de entrega, prioridades y ordenación de los
eventos, política de descarte, ...

El Servicio de Seguridad
• Autenticación de participantes (usuarios y
servidores):
– generación de credenciales, etc.
• Control de acceso a los objetos CORBA:
– listas de control de acceso, etc.
• usuarios agrupados por sus papeles (roles)
– en función de ellos reciben una credencial (privilege)
• objetos agrupados en dominios
– que especifican los derechos de acceso
• métodos clasificados en 4 grupos
– get, set, use y manage
• Auditoría de las IMR por los servidores
• Facilidades de no repudiación

El Servicio de Comercio
• Es un servicio de directorio:
– permite búsqueda de objetos por atributos
• establece una correspondencia:
{tipos y atributos de servicios}  {RORs de objetos CORBA}
– donde:
• el tipo es un nombre
• cada atributo es un par (nombre, valor)
– el cliente especifica el tipo de servicio y lo
restringe con los atributos deseados
• los servidores de comercio pueden formar
federaciones
– comparten sus bases de datos

Los Servicios de Transacciones y
de Control de Concurrencia
• El Servicio de Transacciones:
– Permite a los objetos CORBA participar en transacciones
• el cliente especifica una transacción como
– una secuencia de invocaciones de métodos remotos
– introducidas por un begin
– y terminadas por un commit o un rollback
• el ORB asocia un TID a las IMRs
– y se ocupa de los begin, commit y rollback
– implementa el protocolo de compromiso en dos fases
• El Servicio de Control de Concurrencia
– permite aplicar cerrojos sobre los accesos a los objetos
CORBA
– se puede usar independientemente de las transacciones

El Servicio de Objetos Persistentes (POS)
• Los ORBs activan los objetos persistentes

– pero no son responsables de salvar y restaurar su estado
– eso lo deben hacer los objetos CORBA
• El POS pretende facilitarles la tarea
– define una interfaz
– puede usar ficheros o bases de datos
– asocia un identificador persistente a cada OP
• incluye una identificador del almacén y un número de objeto
– el objeto decide cuándo salvar su estado
• o sus clientes, para lo que el OP hereda una interfaz que
incluye las operaciones para salvar, restaurar, ...
– La implementación de un OP debe elegir un protocolo
para comunicarse con un almacén de datos
• p.ej.: stream , o con acceso directo a los atributos, ...

El proyecto Mono (.NET )

El proyecto Mono (.NET )
• Plataforma .NET
– marco multi-lenguaje para desarrollo de Sistemas
Distribuidos
– creado por Microsoft
– actualmente: estándar ECMA-335
– la aplicación se compila a un lenguaje intermedio
– el entorno de ejecución de la plataforma procesa el
ejecutable en tiempo real
• lo traduce a código máquina (JIT)
• lo ejecuta
• Mono:
– versión multiplataforma y de código abierto
– creado por Ximian; actualmente: Novell
– independencia de lenguaje y de plataforma

Componentes fundamentales
• CLI: entorno de ejecución:
– (Common Language Infrastructure)
– CLR: máquina virtual
• (Common Language Runtime)
– cargador de clases
– compilador en tiempo de ejecución (JIT)
– gestión de memoria (inc. recolector de residuos)
– gestión de excepciones, seguridad, permisos, …
• proporcionado por el ejecutable de Mono (en Linux: mono)
– FCL: biblioteca de clases
• manejo de XML, acceso a bases de datos, exclusión
mutua, hilos, colecciones de objetos, …
• Compilador a código intermedio
– genera ensamblados: código binario Mono
– en CIL (Common Intermediate Language)
• bytecodes de la CLR, pueden ser:
– bibliotecas (.dll), o
– ejecutables (.exe)

El lenguaje C#
• Lenguaje de programación orientada a

objetos:
– creado para Microsoft
– por A. Hejlsberg, A. Wiltamuth y P. Golde
– actualmente: estándar ECMA 334
– fuerte y estáticamente tipado
– desarrollo basado en componentes
• Compilador de C#
– el ensamblado mcs.exe
• es un binario Mono (escrito en C#)
• genera ensamblados en el binario Mono
• necesita la plataforma Mono (.NET) para ejecutarse

Una interfaz Mono en C#
using System;
using System.IO;
public interface IEco {

string eco(string mensaje);
}

Un Servidor Mono en C#
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
public class EcoServidor {
public static void Main(string [] args) {

int puerto = int.Parse(args[0]);
ChannelServices.RegisterChannel(new HttpChannel(puerto));
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(EcoSirviente), "mi-EcoMono",
WellKnownObjectMode.Singleton);
Console.WriteLine("Pulsa enter para salir...");
Console.ReadLine( );
}
}

Un Sirviente Mono en C#
using System;
using System.IO;
public class EcoSirviente : MarshalByRefObject, IEco {
public string eco(string mensaje) {

Console.WriteLine("Recibido: " + mensaje);
return mensaje;
}
}

Un Cliente Mono en C#
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
public class EcoCliente {

public static void Main(string [] args) {
String mensajeEnviado, mensajeRecibido;
string maquina = args[0];
string puerto = args[1];
ChannelServices.RegisterChannel(new HttpChannel());
IEco miEco = (IEco) Activator.GetObject( typeof(IEco),
″http://" + maquina + ":" + puerto + "/mi-EcoMono");
Console.Write("Eco> ");
mensajeEnviado = Console.ReadLine( );
while (!mensajeEnviado.Equals("x")) {
mensajeRecibido = miEco.eco(mensajeEnviado);
Console.WriteLine(mensajeRecibido);
Console.Write("Eco> ");
mensajeEnviado = Console.ReadLine( );
}
}
}

Tema 08

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 08

Cargado por

Copyright:

Formatos disponibles

Tema 8.

Tema 8 CORBA (y Mono) 1

Tema 8 CORBA (y Mono) 2

• OMG (Object Management Group):

• CORBA (Common ORB Architecture)

Tema 8 CORBA (y Mono) 4

• Conocer el marco CORBA para la

Tema 8 CORBA (y Mono) 5

Tema 8 CORBA (y Mono) 6

Tema 8 CORBA (y Mono) 7

Tema 8 CORBA (y Mono) 8

• No podemos pasar individuos de clases,

• tipo Object: sus valores son RORs

Tema 8 CORBA (y Mono) 10

Tema 8 CORBA (y Mono) 11

Tema 8 CORBA (y Mono) 14

Tema 8 CORBA (y Mono) 15

Tema 8 CORBA (y Mono) 16

Tema 8 CORBA (y Mono) 17

Tema 8 CORBA (y Mono) 18

Tema 8 CORBA (y Mono) 19

• Métodos adicionales en la interfaz Pizarra

int registra(in RetroPizarra retro);

Tema 8 CORBA (y Mono) 20

Tema 8 CORBA (y Mono) 21

• Objetivo: soportar el papel de un ORB:

Núcleo del ORB

Núcleo del ORB

o invocación dinámica o invocación dinámica

Tema 8 CORBA (y Mono) 23

Tema 8 CORBA (y Mono) 24

Tema 8 CORBA (y Mono) 26

Tema 8 CORBA (y Mono) 27

Tema 8 CORBA (y Mono) 28

• CORBA IDL permite definir:

Tema 8 CORBA (y Mono) 29

Tipo Ejemplos Uso

enumerado enum Rand (Exp, Numero, Nombre); El tipo enumerado en IDL

Tema 8 CORBA (y Mono) 31

Tema 8 CORBA (y Mono) 32

• Java: traducción casi directa, pero

Tema 8 CORBA (y Mono) 34

Tema 8 CORBA (y Mono) 35

• Los servicios más importantes son:

Tema 8 CORBA (y Mono) 36

• Es un binder sofisticado. Permite:

• Los clientes y servidores le piden un CIN

• el ORB retorna una referencia a un objeto

Tema 8 CORBA (y Mono) 38

typedef sequence <NameComponent> Name;

void unbind(in Name in);

void bind_new_context(in Name n);

Object resolve(in Name in);

Tema 8 CORBA (y Mono) 39

Contexto inicial Contexto inicial Contexto inicial

Tema 8 CORBA (y Mono) 40

• Son secuencias de NameComponent

• Implementación Java del Servicio de

Tema 8 CORBA (y Mono) 43

notificación notificación notificación

consumidor delegado suministrador delegado

Tema 8 CORBA (y Mono) 44

• Es una extensión del Servicio de Eventos: