3.1 El lenguaje de especificación IDL

El lenguaje de especificación IDL

n Permite especificar interfaces remotas en un lenguaje neutral

n El compilador (preprocesador) de IDL genera código para el lenguaje(s) destino(s) (para poder invocar las operaciones e implementar las interfaces)

n Mappings estandarizados para un buen número de lenguajes (C, C++, Java, COBOL, Smalltalk, Ada, etc.)n Cada vez se van añadiendo más ...

n Actualmente IDL es un lenguaje relativamente extenson Veremos lo esencial ...

Reglas léxicas (1)

n Ficheros fuente IDLn Deben tener la extensión .idln Son preprocesados por el preprocesador de C++

n Se puede usar #define, #include, #ifdef, #ifndef, #endif, etc.

n Comentarios// Esto es un comentario de una línea.

/* Esto es un comentario

de varias líneas. */

n Palabras reservadasn Casi todas en minúsculasn Algunas excepciones: TRUE, FALSE y Object

Reglas léxicas (y 2)

n Identificadoresn Deben comenzar con un carácter alfabético seguido por

cualquier número de caracteres alfabéticos, dígitos o “_” (subrayado)

n No se distingue entre mayúsculas y minúsculas, pero deben utilizarse consistentementen Si definimos el identificador MAX, a partir de ese momento

siempre debemos utilizar MAX y no Max, max, etc.

n Objetivo: permitir mappings de IDL tanto a lenguajes que distinguen entre mayúsculas y minúsculas en identificadores (ej.: C++, Java) como a otros que no (ej.: Ada)

n Es importante evitar nombres de identificadores que sean palabras reservadas en algún de lenguaje de implementación (ej.: package, self)

Tipos predefinidos (1)

n Numéricos

>= 79 bitsIEEE Precisión extendidalong double

>= 32 bitsIEEE Precisión simplefloat

>= 64 bitsIEEE Precisión dobledouble

>= 16 bits0.. 216-1unsigned short

>= 32 bits0.. 232-1unsigned long

>= 32 bits-231.. 231-1long

>= 64 bits0.. 264-1unsigned long long

>= 64 bits-263.. 263-1long long

>= 16 bits-215.. 215-1shortTamañoRangoTipo

Tipos predefinidos (2)

n Numéricos (cont)n El mapping de IDL a un lenguaje de implementación debe

preservar el tamaño, pero no necesita mantener el rangon ¿ Por qué los tamaños pueden ser mayores ?

n Ej.: algunas arquitecturas (CPUs) no disponen de caracteres de 8 bits o enteros de 16 bits, y se mapean a tipos con tamaños mayores

n ¿ Por qué algunos mappings no mantienen los rangosn Ej.: Java no tiene enteros sin signo, y por tanto, mapea los

tipos IDL long y unsigned long al tipo Java int

n long long, unsigned long long, long double se añadieron en CORBA 2.1, por lo que los ORBsantiguos no los soportarán

Tipos predefinidos (3)

n Caracteresn char: 8 bitsn wchar: tamaño dependiente de la implementación

n Codificación: dependiente de la implementación en ambos casos, pero el ORB se preocupará de realizar la conversión (si puede) cuando cliente y servidor utilizan distintos sistemas de codificación

n Cadenas de caracteresn string y wstring. No pueden contener carácter 0n Ejemplosstring<10> // string acotado (10 char como máximo)string // string no acotadowstring<10> // wstring acotado (10 wchar como máximo)wstring // wstring no acotado

n string<x> y wstring<x> son tipos propios (distintos de string y wstring)

n wchar y wstring se añadieron en CORBA 2.1, por lo que los ORBs antiguos no los soportarán

Tipos predefinidos (y 4)

n octetn 8 bitsn No se realiza ninguna conversión entre cliente y servidorn Utilidad: transferir datos binarios

n booleann Proporciona los valores TRUE y FALSE

n anyn En un tipo “contenedor”: un valor de tipo “any” puede

contener un valor de cualquier tipo (predefinido o definido por el usuario)

n Es seguro (type-safe) y permite instrospecciónn Utilidad: cuando en una operación no se conoce el tipo de

uno de sus parámetros en tiempo de compilación (ej.: servicio de eventos)

typedef

n Permiten crear un nuevo nombre para un tipotypedef short Year;typedef short Temperature;typdef Temperature Temp; // ¡ Mal estilo !

n Permiten realizar especificaciones más clarasn Se deben evitar alias innecesarios (ej.: la tercera

definición)n Es confuson Puede causar problemas en los mappings que utilicen reglas

estrictas de equivalencia de tipos

Enumeraciones

n Ejemploenum Color {red, green, blue, yellow, white};

n A diferencia de C, Color es un tipo y el nombre del tipo es obligatoriotypedef enum {red, green, blue} Color; // ¡ Error !

n Los valores de un tipo deben ser únicos dentro de su ámbitoenum InteriorColor {red, green, blue};

enum ExteriorColor {blue, yellow, white}; // ¡ Error !

n A diferencia de C++, no se les puede dar valores enum Color {red=0, green=8, blue=16}; // ¡ Error !

Estructuras

n Ejemplostruct Date {

short year;

short month; // 1-12

short day; // 1-31};

n A diferencia de C, Date es un tipo y el nombre del tipo es obligatoriotypedef struct {

short year;

short month; // 1-12

short day; // 1-31

} Date; // ¡ Error !

Union (1)

n Ejemplounion Token switch(Color) {case blue:

float floatValue;case red:case green:

long longValue;default:

string stringValue;};

n El discriminador tiene que ser un tipo entero, char, boolean o una enumeración

n A diferencia de Cn Token es un nombre de tipo y el nombre del tipo es

obligatorion Utilizan discriminador con case y quizás un default

Union (2)

n No se debe utilizar default ni más de un case por campo n Complica algunos mappings (ej.: C++)

n No se debe utilizar una union para simular sobrecarga ...enum OrderDetailInformationKind {text, numeric, none};

union OrderDetailInformation switch(OrderDetailInformationKind) {case text:

string description;case numeric:

long index;};

interface Order {void setOrderDetailInformation(in OrderDetailInformation info);

};

Union (y 3)

n ... es mejor estilointerface Order {

void setDescription(in string description);void setIndex(in long index);

};

n Uso idiomático: simular operaciones con parámetros opcionalesunion AgeOptional switch(boolean) {case TRUE:

unsigned short age;};

n Consejo generaln No usar union

Vectores

n Se pueden definir vectores de una o varias dimensionestypedef Date DateVector[10]; // Tipo “DateVector”

typedef string StringMatrix[10][20]; // Tipo “StringMatrix”

n Se debe usar typedefn A diferencia de otros lenguajes, no soporta vectores

abiertos (“open arrays”)typedef string StringMatrix[][20]; // ¡ Error !

n Hay que tener cuidado cuando se pasan índices de arrays en invocaciones remotasn Es preciso definir una convención

Secuencias

n Las secuencias son vectores de longitud variabletypedef sequence<Color> Colors; // Secuencia no acotada

typedef sequence<Date, 10> Dates10; // Secuencia

// acotada (10 fechas como máximo)

n Se debe usar typedefn ¿ Cuándo usar secuencias y cuándo usar vectores ?

n Una lista de cosas con número fijo de elementos => vectorn Una lista de cosas con número variable de elementos =>

secuencian Cadenas de caracteres de tamaño fijo => vector de charn Vectores dispersos (“sparse arrays”) => secuenciasn Estructuras de datos recursivas => secuencias

Tipos de datos recursivos

n IDL no tiene punteros, pero permite definir estructuras recursivasstruct Node {

long value;

sequence<Node, 2> children;

}; // Un árbol binario

n Restriccionesn Sólo para struct y unionn La recursividad se expresa con una secuencia anónima del

tipo incompleto (recursivo)n No se permite recursividad mutua

Constantes y literales

n Se pueden definir de cualquier tipo predefinido (excepto any) o de un enumeradoconst short MAX_TEMP = 35;

const short MIN_TEMP = -10;

const short AVG_TEMP = (MAX_TEMP+MIN_TEMP)/2;

const float PI = 3.1415926;

const double MAXIMUM = 1E10;

const char FIRST_LOWER_CASE_LETTER = ‘a’;const char NULL = ‘\0’;

const string LAST_WORDS = “My God, it’s full of stars !”;

const octet MSB_MASK = 0x10; // Hexadecimal (tb. en enteros)

const octet MSB_MASK2 = 0100; // Octal (tb. en enteros)

const Color FAVORITE_COLOR = blue;

n Las expresiones pueden utilizarn +, -, *, /, % (con enteros y reales, excepto %)n |, &, ^, <<, >>, ~ (con enteros)

Interfaces (1)

n Ejemplointerface Thermostat {

typedef short Temperature;

typedef string Location;

exception InvalidTemperature {Temperature selectedTemperature;

Temperature minimumPermitedTemperature;

Temperature maximumPermitedTemperature;

};

Tempeature getTemperature();void setTemperature(in Temperature value)

raises(InvalidTemperature)

Location getLocation();

};

Interfaces (y 2)

n Un interfaz es un tipointerface Controller {

typedef sequence<Thermostat> ThermostatList;

ThermostatList findAllThermostats();Thermostat findThermostatByLocation(

in Thermoter::Location loc);

};

n Los objetos remotos se pasan por referencian En el anterior ejemplo, el cliente obtiene una referencia a un

proxy del objeto remoto. ¡¡¡ Los objetos remotos no se mueven !!!

n Existe la referencia especial “nil”n Utilidad: indicar opcionalidad (pasar “nil” en un parámetro que

admita un objeto remoto) o indicar “no encontrado” (findThermostatByLocation)

Operaciones (1)

n Pueden devolver excepcionesn No se pueden sobrecargarn Atributos direccionales

n in: el valor del parámetro se lo envía el cliente al servidorn out: el valor del parámetro se lo envía el servidor al clienten inout: el valor del parámetro se lo envía el cliente al

servidor, quien posiblemente lo modifica, y se lo envía otra vez al cliente (machacando el valor anterior)

n Estilon Si una operación acepta uno o más parámetros in y

devuelve un solo resultado => el resultado se debería devolver como valor de retorno

n Si una operación tiene varios valores de retorno con la misma importancia => usar out para los correspondientes parámetros y void como tipo de retorno

Operaciones (y 2)

n Estilon Si una operación retorna varios valores, pero uno de ellos

tiene más importancia => devolver este último como valor de retorno y el resto como outboolean getNext(out ValueType value);

n Usar los parámetros inout con precauciónn Se asume que el llamador no quiere conservar el valorn Eficientes cuando se pasan valores grandesn Ejemplo

invertMatrix (inout Matrix aMatrix);

Excepciones definidas por el usuario (1)

n Ejemploexception InvalidTemperature {

Temperature selectedTemperature;

Temperature minimumPermitedTemperature;

Temperature maximumPermitedTemperature;};

n Pueden no tener camposn No admiten herencia

n Complicaría algunos mappings

n No se pueden usar como campos de tipos definidos por el usuario

n Si una operación puede levantar varias excepciones, se separan por comas en la cláusula raisesvoid foo() raises(Exception1, Exception2);

Excepciones definidas por el usuario (2)

n Mal estilointerface DataBase {

typedef sequence<Row> RowList;

typedef string Query;

exception NoRow {

Query failedQuery;

};

RowList lookup(in Query q) raises(NoRow);

};

n Puede ser normal que no exista ningún registro que cumpla la query

n El campo failedQuery no aporta nadan ¿ Por qué falló la query ?

n ¿ no había filas que cumplieran la condición ?, ¿ no era sintácticamente correcta ?, ¿ falló la base de datos ?

Excepciones definidas por el usuario (y 3)

n Buen estilointerface DataBase {

typedef sequence<Row> RowList;

typedef string Query;

exception SyntaxError {

unsigned short position;

};

exception DataBaseInternalError {

string explanation;};

RowList lookup(in Query q)

raises(SyntaxException, DataBaseInternalError);

};

Excepciones del sistema

n CORBA define un buen número de excepciones del sisteman Cualquier operación puede levantar una excepción del

sisteman Nunca debe levantarlas el programadorn Todas las excepciones tienen la siguiente definición

enum completion_status {

COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE

};

exception <SystemExceptionName> {

unsigned long minor;completion_status completed;

};

n Ej.: COMM_FAILURE, NO_MEMORY, INTERNAL, OBJ_ADAPTER, INV_OBJREF, etc.

Atributos

n Ejemplointerface Thermostat {

typedef short TemperatureType;

typedef string LocationType;

attribute TemperatureType temperature;

readonly attribute LocationType location;

};

n Los atributos no son el estado del objeto que implemente el interfazn Sólo definen operaciones para leer y escribir valoresn Los atributos readonly sólo definen operaciones de lecturan Inconveniente: no pueden tener cláusula raisesn Consejo: no usuarlos

Declaraciones incompletas

n Ejemplointerface Husband;

interface Wife {

Husband getSpouse();

};

interface Husband {

Wife getSpouse();};

Herencia (1)

n Se permite herencia de interfazinterface Thermometer {

typedef short Temperature;

typedef string Location;

Temperature getTemperature();Location getLocation();

};

interface Thermostat : Thermometer {

void setTemperature(in Temperature t);

};

n .. y en consecuencia se soporta el polimorfismointerface Controller {

Thermometer findByLocation(in Location l);

void add(in Thermometer t);

};

Herencia (y 2)

n Todos los interfaces derivan implícitamente de Objectn En un parámetro de tipo Object se puede pasar una

referencia a un objeto remoto de cualquier tipon La sintaxis de IDL no permite que un interfaz derive

explícitamente de Object

n Un interfaz que deriva de otro no puede volver a declarar (redefinir) una operación del padren No tiene sentido en herencia de interfaz

n Se permite herencia múltipleinterface AmphibiousVehicle : LandVehile, WaterVehicle {

// ...

};

n No se puede heredar un mismo atributo u operación de más de un interfaz base

Módulos

n Similares a los namespaces de C++module es { module udc { module fbellas {

module corba { module clock { module idl {

struct TimeOfDay {// ...

};

interface Clock {

TimeOfDay getTimeOfDay();

};

}; }; }; }; }; };

n Evitan conflictos de nombresn Se pueden cerrar y volver a abrir

Tipos anónimos (1)

n Con CORBA 2.4, los tipos anónimos se consideran desaprobadosn Complican mappingsn Se consideran desaprobados (“deprecated”)n En consecuencia, no se deben usar

n Una mala definición ...struct Order {

long identifier;

string<100> description; // ¡ deprecated !

};

n Una buena definición ...typedef string<100> OrderDescription;

struct Order {long identifier;

OrderDescription description;

};

Tipos anónimos (y 2)

n Hasta CORBA 2.3 (inclusive) no queda más remedio que usar secuencias anónimas para los tipos recursivos

n CORBA 2.4 añade declaraciones incompletas para struct y unionn Ya no es preciso usar tipos anónimos en ningún caso

typedef struct Node;

typedef sequence<Node, 2> ChildSequence;

struct Node {

long value;

ChildSequence children;

};

Identificadores de repositorio (1)

n El compilador de IDL genera un identificador de repositorio por cada identificador

n Con el identificador se puede acceder a su definición (introspección) por medio del Repositorio de Interfaces

n ¡ El identificador debe ser único !n Existen tres tipos de formatos de identificadores

n IDLn DCE UUID (Universally Unique IDentifier)n LOCAL

n El formato IDL es el formato que utiliza el compilador de IDL por defecto y es el usado normalmente

Identificadores de repositorio (y 2)

n Ejemplomodule TCS { // IDL:TCS:1.0

typedef short Temperature; // IDL:TCS/Temperature:1.0interface Thermometer { // IDL:TCS/Thermometer:1.0

Temperature getTemperature(); // IDL:TCS/Thermometer/getTemperature:1.0

};};

n ¿ Y qué ocurre si alguien más ha elegido el nombre TCS para un módulo ?#pragma prefix “es.udc”module TCS { // IDL:TCS:1.0

typedef short Temperature; // IDL:es.udc/TCS/Temperature:1.0interface Thermometer { // IDL:es.udc/TCS/Thermometer:1.0

Temperature getTemperature(); // IDL:es.udc/TCS/Thermometer/getTemperature:1.0

};};

n Otra posibilidad es usar nombres de módulos del estilo “es.udc....”

Ámbito (1)

n Crean ámbito (scope)n módulos, interfaces, estructuras, unions, excepciones y listas de

parámetros

n Dentro de un ámbito los nombres de identificadores deben ser únicos

n Ejemplomodule M1 {

typdef short T1;interface I1 {

typedef long T2;// ...

};};

module M2 {interface I2 {

void foo(in M1::T1 par1, in M1::I1::T2 par2);};

};

Ámbito (y 2)

n Error típicointerface Thermostat {

typedef short Temperature;exception InvalidTemperature {

// ...};

void setTemperature(in Temperature temperature) // ¡ Error !raises(InvalidTemperature)

};