Você está na página 1de 43

ORBacus

Para C ++ y Java
Versión 3.1.2
2 ORBacus
Copyright (c) 1999 Object-Oriented Concepts, Inc. Todos los derechos reservados.
"Conceptos orientados a objetos", "ORBacus" y "JThreads / C ++" son marcas registradas o registradas
marcas registradas de Object-Oriented Concepts, Inc.
"OMG", "CORBA" y "Object Request Broker" son marcas comerciales o marcas registradas
del grupo de gestión de objetos.
"Java" es una marca comercial de Sun Microsystems, Inc.
"Netscape" es una marca registrada de Netscape Communications Corporation.
Otros nombres, productos y servicios pueden ser marcas comerciales o marcas comerciales registradas de
sus respectivos titulares.
ORBacus 3
CAPÍTULO 1 Introducción 11
¿Qué es ORBacus? 11
¿Cómo está licenciado? 12
Acerca de este documento 12
Obteniendo ayuda 12
CAPÍTULO 2 Comenzar 15
La aplicación "Hello World" 15
El código IDL 16
Implementando el ejemplo en C ++ 16
Implementando el Servidor 17
Implementación del cliente 19
Compilación y enlace 20
Ejecución de la aplicación 21
Implementando el ejemplo en Java 21
Implementación del servidor 21
Implementación del cliente 23
Compilación 24
Ejecución de la aplicación 25
Resumen 25
A dónde ir desde aquí 25
CAPÍTULO 3 Los generadores de código ORBacus 27
Visión general 27
Sinopsis 27
Descripción 28
Opciones para idl 29
Opciones para jidl 31
Opciones para hidl 32
Opciones para ridl 32
Opciones para irserv 33
Opciones para irfeed 34
Opciones para irdel 34
Opciones para irgen 34
4 ORBacus
El traductor IDL-a-C ++ y el repositorio de interfaz 35
Incluir declaraciones 35
Documentación de archivos IDL 36
Usando javadoc 39
CAPÍTULO 4 Inicialización de ORB y BOA 43
Inicialización de ORB 43
Inicializando el C ++ ORB 43
Inicializando el ORB de Java para Aplicaciones 43
Inicializando el ORB de Java en JDK 1.2 44
Inicializando el ORB de Java para Applets 44
Inicialización de BOA 45
Inicializando el C ++ BOA 45
Inicializando el Java BOA 45
Inicializando el Java BOA en JDK 1.2 45
Configurando el ORB y el BOA 46
Propiedades 46
Opciones de línea de comando 49
Opciones de línea de comando de filtrado 50
Usando un archivo de configuración 51
Usando el Registro de Windows NT 52
Definición de propiedades en Java 53
Precedencia de las propiedades 53
Uso avanzado de la propiedad 54
Server Event Loop 58
Aplicaciones de cliente / servidor mixto 58
Desactivando el servidor 59
Applets 61
Adición de Applets de ORBacus a páginas web 61
Definición de opciones de ORB y BOA para un applet 62
Definición de los parámetros de la clase ORB 62
Problemas de seguridad 62
CAPÍTULO 5 Objetos de CORBA 65
Visión general 65
Implementando Sirvientes 66
ORBacus 5
Implementando Servidores con Herencia 67
Implementando Servidores usando la Delegación 69
Creando sirvientes 73
Creando Servidores usando C ++ 73
Creando Servidores usando Java 74
Conectando a los sirvientes 75
Conectando Servidores usando C ++ 75
Conectando Servidores usando Java 75
Nombramientos de sirvientes 76
Objetos de fábrica 77
Objetos de fábrica que usan C ++ 78
Objetos de fábrica con Java 79
Advertencias 80
Obtener un servidor de una referencia 81
Obteniendo un servidor usando C ++ 81
Obteniendo un Servidor usando Java 83
CAPÍTULO 6 Localización de objetos 85
Obtención de referencias a objetos 85
Lifetime of Object References 87
Nombre de host 88
Número de puerto 88
Clave de objeto 88
Referencias de objeto Stringified 89
Usando un archivo 89
Usando una URL 91
Usando los Parámetros de Applet 92
Conexión a objetos con nombre 92
Usando la notación iiop: // 93
Usando get_inet_object 93
Servicios iniciales 94
Resolución de un servicio inicial 94
Proporcionar IOR de servicios iniciales 96
CAPÍTULO 7 Recuento de referencias 99
¿Qué es el recuento de referencias? 99
6 ORBacus
Recuento de referencias en Java 99
Recuento de referencias en C ++ 100
Problemas de Marshalling 100
Liberación de servidores proxy y servidores 102
Referencias de objetos globales 103
Dependencias de Objetos Cíclicos 104
CAPÍTULO 8 C ++ Notas de mapeo 109
Nombres Reservados 109
Mapeo de Módulos 109
Extensiones 110
Extensiones para el tipo de cadena 110
Extensiones a _var Tipos 110
Extensiones a los tipos de secuencia 111
Consejos y trucos de mapeo en C ++ 112
CORBA Strings 112
Referencias de objetos 116
CAPÍTULO 9 Modelos de concurrencia 121
Introducción 121
¿Qué es un modelo de concurrencia? 121
¿Por qué diferentes modelos de simultaneidad? 121
Descripción general de los modelos de simultaneidad de ORBacus 122
Modelos de simultaneidad de rosca simple 122
Bloqueo de clientes y servidores 122
Clientes y servidores reactivos 123
Modelos de simultaneidad multiproceso 126
Clientes y servidores con subprocesos 126
Thread-per-Client Server 127
Servidor de subproceso por solicitud 128
Thread Pool Server 128
Comparaciones de rendimiento 129
Aplicación de muestra 129
Invocaciones a métodos regulares 130
Invocaciones de método anidado 131
Selección de modelos de concurrencia 132
ORBacus 7
CAPÍTULO 10 El reactor 135
¿Qué es un Reactor? 135
Reactores disponibles 135
El reactor X11 136
El Reactor de Windows 137
Escribir un controlador de eventos personalizado 137
Uso de temporizadores 139
CAPÍTULO 11 La interfaz de comunicaciones abiertas 141
¿Qué es la Interfaz de comunicaciones abiertas? 141
Resumen de interfaz 141
Buffer 141
Transporte 142
Aceptador y conector 142
Connector Factory 142
Los registros 142
Los objetos de información 142
Diagrama de clase 143
Referencia OCI 143
OCI para el programador de aplicaciones 144
Una clase "Convertidor" para Java 144
Obtención de nombres de host y puertos 145
Averiguar la dirección IP de un cliente 146
Averiguar la dirección IP de un servidor 148
CAPÍTULO 12 Uso de políticas 151
Visión general 151
Políticas respaldadas 152
Ejemplos 152
Política de reutilización de conexiones en el nivel 153 de ORB
Política de reutilización de la conexión en el nivel de objeto 154
8 ORBacus
CAPÍTULO 13 Servicios básicos de ORBacus 155
Configuración y uso de un servicio básico 155
Iniciar el servicio 156
Conexión al servicio 156
Nombres de objeto para los servicios básicos 157
El servicio de nombres 158
Propiedades 158
Opciones de línea de comando 158
Crear enlaces 159
Resolución de nombre 160
Persistencia 161
Un ejemplo simple 161
Servicio nativo de Windows NT 166
El servicio de propiedad 168
Opciones de línea de comando 168
Creando Propiedades 168
Consulta de propiedades 169
Eliminando propiedades 171
Un ejemplo simple 171
El servicio de eventos 173
Propiedades 173
Opciones de línea de comando 174
Diagnóstico 174
Servicio nativo NT 175
El canal de eventos 176
Proveedores de eventos y consumidores 176
Políticas del canal de eventos 177
Un ejemplo simple 177
CAPÍTULO 14 Excepciones y mensajes de error 183
Excepciones del sistema CORBA 183
La aplicación no conforme afirma 186
APÉNDICE A Referencia de política de ORBacus 191
Módulo SSL 191
ORBacus 9
Interfaz SSL :: ConnectPolicy 192
Módulo OB 193
Interfaz OB :: ProtocolPolicy 194
Interfaz OB :: ConnectionReusePolicy 195
Interfaz OB :: ReconnectPolicy 196
Interfaz OB :: TimeoutPolicy 197
APÉNDICE B Referencia de la interfaz de comunicaciones abiertas 199
Módulo OCI 199
Interfaz OCI :: Buffer 201
Interfaz OCI :: Transporte 203
Interfaz OCI :: TransportInfo 207
Interfaz OCI :: CloseCB 209
Interfaz OCI :: Conector 210
Interfaz OCI :: ConnectorInfo 212
Interfaz OCI :: ConnectCB 213
Interfaz OCI :: Aceptador 214
Interfaz OCI :: AcceptorInfo 216
Interfaz OCI :: AcceptCB 217
Interfaz OCI :: ConFactory 218
Interfaz OCI :: ConFactoryInfo 221
Interfaz OCI :: ConFactoryRegistry 222
Interfaz OCI :: AccRegistry 224
Interfaz OCI :: Actual 226
Módulo OCI :: IIOP 227
Interfaz OCI :: IIOP :: TransportInfo 228
Interfaz OCI :: IIOP :: ConnectorInfo 229
Interfaz OCI :: IIOP :: AcceptorInfo 230
Interfaz OCI :: IIOP :: ConFactoryInfo 231
10 ORBacus
APÉNDICE C Acuerdo de Licencia Pública Libre de Regalías 233
Referencias 239
ORBacus 11

CAPÍTULO 1 Introducción
1.1 ¿Qué es ORBacus?
ORB ACUS es un intermediario de solicitud de objetos (ORB) que cumple con el objeto común
Especificación de solicitud de arquitectura del intermediario (CORBA) tal como se define en "El objeto
común"
Broker de solicitud: arquitectura y especificación "[2] y" Mapeo de lenguaje IDL / Java "
[3].
Estos son algunos de los aspectos más destacados de la versión ORB ACUS 3.1:
• Soporte completo de CORBA IDL
• Completar el mapeo CORBA IDL-a-C ++
• Completar el mapeo de CORBA IDL a Java
• Incluye el nombramiento, el evento y la propiedad de los servicios básicos de CORBA
• Protocolos conectables con IIOP como el plug-in predeterminado
• Compatibilidad con un solo y multi-subprocesos con varios modelos de simultaneidad: bloqueo ,
Reactivo , Roscado , Thread-per-Client , Thread-per-Request y Thread Pool
• Invocaciones de método anidado, incluso en la versión de subproceso único
• Soporte para tiempos de espera
• Integración de bucle de eventos sin problemas con X11 y Windows
• Soporte completo para programación dinámica: Interfaz de Invocación Dinámica, Dinámica
Skeleton Interface, Interface Repository y DynAny
Introducción
12 ORBacus
• Traductores de IDL a HTML e IDL a RTF para generar el estilo "javadoc"
documentación
Esta versión de ORB ACUS tiene las siguientes limitaciones:
• Solo los servidores persistentes (es decir, lanzados manualmente) son actualmente compatibles.
Para la disponibilidad de la plataforma, consulte la página de inicio de ORB ACUS en http: //
www.ooc.com/ob/ .
1.2 ¿Cómo se licencia?
ORB ACUS tiene licencia como "gratis para uso no comercial". Consulte el acuerdo de licencia en
Apéndice C para más detalles. Para obtener información sobre licencias comerciales, consulte los precios
información en nuestro sitio web, o póngase en contacto con support@ooc.com .
1.3 Acerca de este documento
Este manual es, a excepción del capítulo "Primeros pasos", no reemplaza a un buen
Libro CORBA. Este manual tampoco contiene las especificaciones precisas de
Estándar CORBA, que están disponibles gratuitamente en línea. Una buena comprensión de las
especificaciones de CORBA
en [2] y [3] es absolutamente necesario para usar este manual de manera efectiva. En particular,
los capítulos en [2] que cubren CORBA IDL y el mapeo IDL a C ++ deben estudiarse
a fondo.
No espere que ninguno de los libros introductorios de CORBA proporcione una referencia para el IDLto-
Mapeo C ++. Los libros que están actualmente disponibles solo dan una visión general y son
ni completo ni actualizado. No hay sustituto para la especificación oficial de CORBA
como se define en [2].
Lo que este manual contiene, sin embargo, es información sobre cómo ORB ACUS implementa
el estándar CORBA. Una deficiencia de la especificación CORBA actual es que deja
un alto grado de libertad para la implementación de CORBA. Por ejemplo, la semántica precisa
de una llamada unidireccional no están especificadas por el estándar.
Para facilitar el inicio de ORB ACUS , este manual contiene un "Primeros pasos"
capítulo, explicando algunos conceptos básicos de ORB ACUS con un ejemplo muy simple.
1.4 Obtener ayuda
Si necesita ayuda con ORB ACUS , no dude en contactarnos en
support@ooc.com . También puede considerar unirse a nuestra lista de correo de ORB ACUS . Que hacer
Por lo tanto, enviar un mensaje a majordomo@ooc.com (no ob@ooc.com) con
ORBacus 13
Obteniendo ayuda
suscribirse ob
en el cuerpo (no en el campo Asunto :) de su mensaje. Para darse de baja, use
cancelar suscripción ob
en el cuerpo de tu mensaje Para enviar un mensaje a la lista, envíe un correo a ob@ooc.com (no
majordomo@ooc.com ).
Se puede encontrar un archivo de la lista de correo ORB ACUS en http://www.ooc.com/ob/
mailing-list.html .
Introducción
14 ORBacus
ORBacus 15

CAPÍTULO 2 Comenzando
2.1 La aplicación "Hello World"
El ejemplo descrito en este capítulo se basa en una aplicación conocida: Un "Hola"
World! "Programa presentado aquí en una versión especial de cliente-servidor.
Muchos libros sobre programación comienzan con este pequeño programa de demostración. En C ++
introductorio
libros, probablemente encontrará el siguiente fragmento de código en el primer capítulo:
// C ++
#include <iostream.h>
En t
main (int, char * [], char * [])
{
cout << "¡Hola mundo!" << endl;
return 0;
}
O en los libros introductorios de Java:
// Java
clase pública Greeter
{
public static void main (String args [])
Empezando
16 ORBacus
{
System.out.println ("¡Hola mundo!");
}
}
Estas aplicaciones simplemente imprimen "Hello World!" A la salida estándar y eso es exactamente lo que
este capítulo trata sobre: Imprimir "¡Hola mundo!" con una aplicación cliente-servidor basada en CORBA.
En otras palabras, desarrollaremos un programa de cliente que invoque una operación de saludo en
un objeto en un programa de servidor. El servidor responde imprimiendo "Hello World!" En su estándar
salida.
2.2 El código IDL
¿Cómo escribimos una aplicación "Hello World!" Basada en CORBA? El primer paso es crear un
archivo que contiene nuestras definiciones de IDL. Dado que nuestra aplicación de muestra no es complicada,
el código IDL necesario para este ejemplo es simple:
1 // IDL
2
3 interfaz Hola
4 {
5 void hello ();
6 };
3 Se define una interfaz con el nombre Hello . Una interfaz IDL es conceptualmente equivalente
a una clase abstracta pura en C ++, o a una interfaz en Java.
5 La única operación definida es hello , que no toma ningún parámetro ni devuelve ningún
valor.
2.3 Implementando el ejemplo en C ++
El siguiente paso es traducir el código IDL a C ++ usando el traductor IDL-a-C ++. Salvar
el código IDL que se muestra arriba en un archivo llamado Hello.idl . Ahora traduce el código a C ++
usando el siguiente comando:
idl Hello.idl
Este comando creará los archivos hello.h, hello.cpp, y Hello_skel.h
Hello_skel.cpp .
ORBacus 17
Implementando el ejemplo en C ++
2.3.1 Implementando el Servidor
Para implementar el servidor, necesitamos definir una clase de implementación para la interfaz Hello .
Para hacer esto, creamos una clase Hello_impl que se deriva de la clase "esqueleto"
Hello_skel , definido en el archivo Hello_skel.h . La definición de Hello_impl parece
Me gusta esto:
1 // C ++
2
3 #include <Hello_skel.h>
4
5 clase Hello_impl: public Hello_skel
6 {
7 público:
8
9 virtual void hello ();
10 };
3 Dado que nuestra clase de implementación deriva de la clase de esqueleto Hello_skel , debemos
incluye el archivo Hello_skel.h .
5 Aquí definimos Hello_impl como una clase derivada de Hello_skel .
9 Nuestra clase de implementación debe implementar todas las operaciones desde la interfaz IDL. En esto
caso, esta es solo la operación hola .
La implementación de Hello_impl se ve de la siguiente manera:
1 // C ++
2
3 #include <OB / CORBA.h>
4 #include <Hello_impl.h>
5
6 vacío
7 Hello_impl :: hello ()
8{
9 cout << "¡Hola mundo!" << endl;
10 }
3 Debemos incluir OB / CORBA.h , que contiene definiciones para el estándar CORBA
clases, así como para otras cosas útiles.
4 También debemos incluir la definición de clase Hello_impl , contenida en el archivo de encabezado
Hello_impl.h .
Empezando
18 ORBacus
6-10 La función hello simplemente imprime "Hello World!" En salida estándar.
Guarde la definición de clase de Hello_impl en el archivo Hello_impl.h y la implementación
de Hello_impl en el archivo Hello_impl.cpp .
Ahora tenemos que escribir el programa principal del servidor , que se ve así:
1 // C ++
2
3 #include <OB / CORBA.h>
4 #include <Hello_impl.h>
5
6 #include <fstream.h>
7
8 int
9 main (int argc, char * argv [], char * [])
10 {
11 CORBA_ORB_var orb = CORBA_ORB_init (argc, argv);
12 CORBA_BOA_var boa = orb -> BOA_init (argc, argv);
13
14 Hello_var p = new Hello_impl;
15
16 CORBA_String_var s = orb -> object_to_string (p);
17 const char * refFile = "Hello.ref";
18 de salida (refFile);
19 fuera << s << endl;
20 out.close ();
21
22 boa -> impl_is_ready (CORBA_ImplementationDef :: _ nil ());
23 }
3-6 Se incluyen varios archivos de encabezado. De estos, OB / CORBA.h proporciona el estándar CORBA
definiciones, y Hello_impl.h contiene la definición de la clase Hello_impl .
11,13 Lo primero que debe hacer un programa CORBA es inicializar el ORB 1 y el BOA 2 . Esta
está hecho por CORBA_ORB_init y BOA_init . Ambas operaciones esperan los parámetros con
que el programa se inició. Estos parámetros pueden o no ser utilizados por el ORB y
BOA , dependiendo de la implementación de CORBA. ORB ACUS reconoce ciertas opciones
eso se explicará más tarde.
1. O bject R equest B roker
2. B ásico O bject A dapter
ORBacus 19
Implementando el ejemplo en C ++
14 Se crea una instancia de Hello_impl . Hello_var , como todos los tipos _var , es un "inteligente"
puntero, es decir, p liberará el objeto creado por Hello_impl nuevo automáticamente cuando p
sale del alcance.
16-20 El cliente debe poder acceder al objeto de implementación. Esto se puede hacer guardando un
Referencia de objeto "codificado" a un archivo que el cliente puede leer y convertir de nuevo
a la referencia de objeto real. 1 La operación object_to_string () convierte un CORBA
referencia de objeto en su representación de cadena.
22 Finalmente, para reaccionar a las solicitudes entrantes, el servidor debe ingresar su bucle de evento. Esto
es
hecho llamando a impl_is_ready . Dado que ORB ACUS no usa el
El argumento CORBA_ImplementationDef , CORBA_ImplementationDef :: _ nil () puede
ser utilizado como un argumento ficticio.
Guárdelo en un archivo con el nombre Server.cpp .
2.3.2 Implementación del cliente
Escribir al cliente requiere menos trabajo que escribir el servidor, ya que el cliente, en este ejemplo,
solo consiste en la función principal . En varios aspectos, el principal del cliente es similar a
la función principal del servidor :
1 // C ++
2
3 #include <OB / CORBA.h>
4 #include <Hello.h>
5
6 #include <fstream.h>
7
8 int
9 main (int argc, char * argv [], char * [])
10 {
11 CORBA_ORB_var orb = CORBA_ORB_init (argc, argv);
12
13 const char * refFile = "Hello.ref";
14 ifstream en (refFile);
15 caracteres [1000];
16 en >> s;
17 CORBA_Object_var obj = orb -> string_to_object (s);
18
1. Si su aplicación contiene más de un objeto, no necesita guardar referencias de objetos para
todos los objetos Por lo general, guarda la referencia de un objeto que proporciona operaciones que pueden
posteriormente
devolver referencias a otros objetos.
Empezando
20 ORBacus
19 Hello_var hola = Hola :: _ estrecho (obj);
20
21 hola -> hola ();
22 }
4 A diferencia del servidor, el cliente no necesita incluir Hello_impl.h . Solo el generado
archivo Hello.h es necesario.
11 Al igual que la implementación del servidor de las principales salidas principales, de los clientes
con la inicialización de
el ORB . No es necesario inicializar el BOA, porque el BOA solo es necesario por
aplicaciones de servidor.
13-17 La referencia de objeto "codificado" escrita por el servidor se lee y se convierte en
Referencia de objeto CORBA_Object .
19 La operación _narrow genera una referencia de objeto Hello del objeto CORBA_Object
referencia de objeto 1
21 Finalmente, se invoca la operación de saludo en la referencia de objeto hello , causando que el
servidor
para imprimir "¡Hola mundo!".
Guarde esto en el archivo Client.cpp .
2.3.3 Compilación y enlace
Tanto el cliente como el servidor deben estar vinculados con el Hello.cpp compilado , que generalmente
tiene el nombre Hello.o en Unix y Hello.obj en Windows. El compilado
Hello_skel.cpp y Hello_impl.cpp solo son necesarios para el servidor.
La compilación y el enlace dependen en gran medida del compilador y de la plataforma. Muchos
compiladores
requieren opciones únicas para generar el código correcto. Para construir programas ORB ACUS ,
debe al menos vincularse con la biblioteca ORB ACUS libOB.a (Unix) u ob.lib (Windows).
Se requieren bibliotecas adicionales en algunos sistemas, como libsocket.a y libnsl.a
para Solaris o wsock32.lib para Windows.
La distribución ORB ACUS viene con varios archivos README para diferentes plataformas que
dar pistas sobre las opciones necesarias para compilar y las bibliotecas necesarias para vincular.
Por favor, consulte estos archivos README para más detalles.
1. Aunque T :: _ de CORBA estrecho para una interfaz T funciona de forma similar a dynamic_cast <T>
()
para una clase simple de C ++ T , dynamic_cast <T> () no se debe usar para referencias de objetos CORBA.
ORBacus 21
Implementando el ejemplo en Java
2.3.4 Ejecución de la aplicación
Nuestra aplicación "Hello World!" Consta de dos partes: el programa del cliente y el servidor
programa. El primer programa que se inicia es el servidor, porque debe crear el archivo
Hola.ref que el cliente necesita para conectarse al servidor. Tan pronto como el servidor esté
ejecutándose, puede iniciar el cliente. Si todo va bien, aparecerá el mensaje "¡Hola, mundo!"
en la pantalla.
2.4 Implementación del ejemplo en Java
Para implementar esta aplicación en Java, la interfaz especificada en IDL se traduce
a clases Java similares a la forma en que se creó el código C ++. El ORB ACUS IDL a Java
El traductor jidl se usa así:
jidl --package hola Hello.idl
Este comando da como resultado varios archivos fuente Java en los que la implementación real
estar basado. Los archivos generados son Hello.java , HelloHelper.java ,
HelloHolder.java , StubForHello.java y _HelloImplBase.java , todos generados
en un directorio con el nombre hola .
2.4.1 Implementando el Servidor
La clase de implementación Hola del servidor se ve de la siguiente manera:
1 // Java
2
3 paquete hola;
4
5 clase pública Hello_impl extiende _HelloImplBase
6{
7 public void hello ()
8{
9 System.out.println ("¡Hola mundo!");
10 }
11 }
5 La clase de implementación Hello_impl debe heredar de la clase generada
_HelloImplBase .
7-9 Al igual que con la implementación C ++, el método hello simplemente imprime "Hello World!" En
salida estándar.
Guarde esta clase en el archivo Hello_impl.java .
Empezando
22 ORBacus
También tenemos que escribir una clase que contenga el método principal del servidor . Llamamos a esta
clase
Servidor , guardado en el archivo Server.java :
1 // Java
2
3 paquete hola;
4
5 servidor de clase pública
6{
7 public void main public (String args [])
8{
9 java.util.Properties props = System.getProperties ();
10 props.put ("org.omg.CORBA.ORBClass", "com.ooc.CORBA.ORB");
11 props.put ("org.omg.CORBA.ORBSingletonClass",
12 "com.ooc.CORBA.ORBSingleton");
13 System.setProperties (accesorios);
14
15 org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init (args, props);
16 org.omg.CORBA.BOA boa =
17 ((com.ooc.CORBA.ORB) orb) .BOA_init (args, props);
18
19 Hello_impl p = new Hello_impl ();
20
21 intento
22 {
23 String ref = orb.object_to_string (p);
24 String refFile = "Hello.ref";
25 java.io.PrintWriter out = new java.io.PrintWriter (
26 nuevos java.io.FileOutputStream (refFile));
27 out.println (ref);
28 out.flush ();
29 }
30 catch (java.io.IOException ex)
31 {
32 System.err.println ("No se puede escribir en '" +
33 ex.getMessage () + "'");
34 System.exit (1);
35 }
36
37 boa.impl_is_ready (null);
38 }
39 }
9-13 Estas propiedades son necesarias para usar ORBacus ORB con JDK 1.2.
ORBacus 23
Implementando el ejemplo en Java
15-17 El ORB y el BOA deben inicializarse. Esto se hace usando ORB.init y
ORB.BOA_init . Tenga en cuenta que todas las definiciones estándar de CORBA están en el paquete
org.omg.CORBA . Es decir, debe importar este paquete o, como se muestra en nuestro ejemplo,
debe usar org.omg.CORBA explícitamente.
19 Se crea una instancia de Hello_impl . Esta instancia se lanza automáticamente cuando es
ya no se usa
21-35 La referencia del objeto está "codificada" y escrita en un archivo.
37 Finalmente, el servidor ingresa su ciclo de eventos para recibir solicitudes entrantes.
2.4.2 Implementación del cliente
Guárdelo en un archivo con el nombre Client.java :
1 // Java
2
3 paquete hola;
4
5 cliente de clase pública
6{
7 public void main public (String args [])
8{
9 java.util.Properties props = System.getProperties ();
10 props.put ("org.omg.CORBA.ORBClass", "com.ooc.CORBA.ORB");
11 props.put ("org.omg.CORBA.ORBSingletonClass",
12 "com.ooc.CORBA.ORBSingleton");
13 System.setProperties (accesorios);
14
15 org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init (args, props);
dieciséis
17 String ref = null;
18 intentar
19 {
20 String refFile = "Hello.ref";
21 java.io.BufferedReader in = new java.io.BufferedReader (
22 nuevo java.io.FileReader (refFile));
23 ref = in.readLine ();
24 }
25 catch (java.io.IOException ex)
26 {
27 System.err.println ("No se puede leer de '" +
28 ex.getMessage () + "'");
29 System.exit (1);
Empezando
24 ORBacus
30 }
31 org.omg.CORBA.Object obj = orb.string_to_object (ref);
32
33 Hola p = HelloHelper.narrow (obj);
34
35 p.hello ();
36 }
37 }
9-13 Estas propiedades son necesarias para usar ORBacus ORB con JDK 1.2.
15 El ORB está inicializado. La inicialización de BOA no es necesaria para los clientes.
17-31 La referencia del objeto codificado se lee y se convierte en un objeto.
33 La referencia del objeto se "estrecha" para hacer referencia a un objeto Hello . Un simple
elenco de Java
es
no permitido aquí, porque es posible que el cliente necesite preguntar al servidor si
el objeto es realmente del tipo Hello .
35 Finalmente , se invoca la operación de saludo , haciendo que el servidor imprima "Hello World!" En
salida estándar.
2.4.3 Compilación
Para compilar las clases de implementación y las clases generadas por ORB ACUS IDLto-
Traductor de Java, use javac (o el compilador de Java de su elección):
javac * .java hello / *. java
Asegúrese de que su variable de entorno CLASSPATH incluya las clases de Java ORB ACUS ,
es decir, el archivo OB.jar . Si está utilizando el shell Unix Bourne o un shell compatible, puede
haz esto con los siguientes comandos:
CLASSPATH = your_orbacus_directory / lib / OB.jar: $ CLASSPATH
exportar CLASSPATH
Reemplace your_orbacus_directory con el nombre del directorio donde ORB ACUS está
instalado
Si está ejecutando ORB ACUS en un sistema basado en Windows, puede usar lo siguiente
comando dentro del intérprete de comandos de Windows:
establecer CLASSPATH = your_orbacus_directory \ lib \ OB.jar;% CLASSPATH%
Tenga en cuenta que para Windows debe usar ";" y no ":" como delimitador.
ORBacus 25
Resumen
2.4.4 Ejecución de la aplicación
El servidor Java "Hello World" se inicia con:
java hello.Server
Y el cliente con:
java hello.Client
De nuevo, asegúrese de que su variable de entorno CLASSPATH incluya el archivo OB.jar .
También es posible que desee utilizar un servidor C ++ junto con un cliente Java (o viceversa). Esto es
una de las principales ventajas de usar CORBA: si se define algo en CORBA IDL,
el lenguaje de programación utilizado para la implementación es irrelevante. Aplicaciones CORBA
pueden hablar entre ellos, independientemente del idioma en que estén escritos.
2.5 Resumen
En este punto, puede inclinarse a pensar que este es el método más complicado de
imprimiendo una cadena que alguna vez ha encontrado en su carrera como programador. Primero
vistazo, un enfoque basado en CORBA puede parecer complicado. Por otra parte,
piense en los beneficios que este tipo de enfoque tiene para ofrecer. Puede iniciar el servidor y el cliente
aplicaciones en diferentes máquinas con exactamente los mismos resultados. En cuanto a la comunicación
entre el cliente y el servidor, no tiene que preocuparse por la plataforma específica
métodos o protocolos, siempre que exista un CORBA ORB disponible para la plataforma
y el lenguaje de programación de su elección. Si es posible, obtenga experiencia práctica y
iniciar el servidor en una máquina, el cliente en otra 1 . Como verá, basado en CORBA
las aplicaciones se ejecutan de manera intercambiable en entornos locales y de red.
Un último punto a tener en cuenta: es probable que no use CORBA para desarrollar sistemas tan simples
como
nuestro ejemplo "Hello, World!" Las aplicaciones se vuelven más complejas (y las de hoy
las aplicaciones son complejas), más aprenderá a apreciar tener un alto nivel
abstracción de las interfaces clave de sus aplicaciones capturadas en CORBA IDL.
2.6 Dónde ir desde aquí
Para comprender los capítulos restantes de este manual, debe haber leído el CORBA
especificaciones en [2] y [3]. No podrás entender los capítulos que siguen
1. Tenga en cuenta que después del inicio del programa del servidor, debe copiar la referencia del objeto codificado,
es decir, el archivo Hello.ref , a la máquina donde se ejecutará el programa cliente.
Empezando
26 ORBacus
sin un buen conocimiento de CORBA en general, CORBA IDL y IDL-to-C ++ y
Asignaciones de IDL a Java.
ORBacus 27

El código de ORBacus
CAPÍTULO 3

Generadores
3.1 Descripción general
ORB ACUS incluye los siguientes generadores de código y herramientas de Repositorio de interfaz:
3.2 Sinopsis
idl [opciones] archivos-idl ...
jidl [opciones] idl-files ...
hidl [opciones] archivos-idl ...
idl El traductor ORB ACUS IDL-to-C ++
jidl El traductor ORB ACUS IDL a Java
hidl El traductor de IDL a HTML de ORB ACUS
El traductor ORL ACUS IDL-to-RTF
irserv El servidor de repositorio de interfaz ORB ACUS
irfeed El alimentador de repositorio de interfaz ORB ACUS
irdel El delegado del repositorio de interfaz ORB ACUS
irgen El ORB ACUS Interface Repository C ++ Code Generator
Los generadores de código ORBacus
28 ORBacus
ridl [opciones] idl-files ...
irserv [opciones] [idl-files ...]
irfeed [opciones] idl-files ...
irdel [opciones] scoped-name ...
irgen nombre-base
3.3 Descripción
idl es el traductor ORB ACUS IDL-to-C ++. Traduce archivos IDL a archivos C ++. por
cada archivo IDL, se generan cuatro archivos C ++. Por ejemplo,
idl MyFile.idl
produce los siguientes archivos:
jidl traduce archivos IDL en archivos Java. Para cada construcción en el archivo IDL que se asigna a un
Clase o interfaz Java, se genera un archivo de clase separado. Los directorios se crean automáticamente
para aquellas construcciones IDL que se asignan a un paquete Java (por ejemplo, un módulo ).
jidl también puede agregar comentarios del archivo IDL comenzando con / ** a la Java generada
archivos. Esto le permite usar la herramienta javadoc para producir documentación de los generados
Archivos Java Consulte "Uso de javadoc" en la página 39 para obtener información adicional.
hidl crea archivos HTML a partir de archivos IDL. Se genera un archivo HTML para cada módulo y
interfaz definida en un archivo IDL. Los comentarios en el archivo IDL se conservan y javadoc
palabras clave de estilo son compatibles. La sección "Documentación de archivos IDL" en la página 36
proporciona
más información.
ridl crea archivos con formato de texto enriquecido (RTF) a partir de archivos IDL. Se genera un archivo
RTF para
cada módulo e interfaz definidos en un archivo IDL. Los comentarios en el archivo IDL se conservan
MYFILE.H archivo de cabecera que contiene los tipos de datos traducidos MyFile.idl 's
y talones de interfaz
MyFile.cpp Archivo fuente que contiene los tipos de datos traducidos de MyFile.idl
y talones de interfaz
MyFile_skel.h Archivo de encabezado que contiene esqueletos para las interfaces de MyFile.idl
MyFile_skel.cpp Archivo fuente que contiene esqueletos para las interfaces de MyFile.idl
ORBacus 29
Opciones para idl
y palabras clave de estilo javadoc son compatibles. La sección "Documentación de archivos IDL" en
la página 36 proporciona más información.
irserv es el servidor de repositorio de interfaz. Junto con irfeed , un programa que alimenta
el repositorio de interfaz con código IDL e irgen , el código C ++ del repositorio de interfaz
Generador, es posible generar código C ++ directamente a partir del contenido de una interfaz
Repositorio. Consulte "El traductor IDL-a-C ++ y el repositorio de interfaz" en la página 35 para
un ejemplo.
3.4 Opciones para IDL
-h, --ayuda
Mostrar un breve mensaje de ayuda.
-v, --version
Muestra el número de versión de ORB ACUS .
-e, --cpp NOMBRE
Use NAME como el programa preprocesador.
-d, --debug
Imprimir mensajes de diagnóstico. Esta opción es solo para propósitos de depuración interna de ORB ACUS .
-DNAME
Define NAME como 1 . Esta opción se pasa directamente al preprocesador.
-DNAME = DEF
Define NAME como DEF . Esta opción se pasa directamente al preprocesador.
-TU NOMBRE
Elimina cualquier definición para NAME . Esta opción se pasa directamente al preprocesador.
-IDIR
Agrega DIR a la ruta de búsqueda de archivos de inclusión. Esta opción se pasa directamente al
preprocesador.
--no-esqueletos
No generes clases de esqueleto.
--no-type-codes
Los generadores de código ORBacus
30 ORBacus
No genere códigos de tipo ni funciones de inserción y extracción para Cualquier tipo. Uso de
esta opción hará que el traductor genere un código más compacto.
--locality-constrained
Genera objetos con restricción de localidad.
--no-virtual-inheritance
No use la herencia virtual de C ++. Si usa esta opción, no puede usar múltiples interfaces
herencia en su código IDL, y tampoco puede usar múltiples herencia C ++ para implementar
tus clases de sirvientes
--Corbata
Genere clases de enlace para implementaciones de interfaz basadas en delegado. Las clases de Tie dependen
de
las clases de esqueleto correspondientes, es decir, no debe usar --no-skeletons en combinación
con --tie .
--c-sufijo SUFFIX
Use SUFFIX como el sufijo para los archivos fuente. El valor predeterminado es .cpp .
--h-sufijo SUFFIX
Use SUFFIX como sufijo para los archivos de encabezado. El valor predeterminado es .h .
--todas
Genere código para archivos incluidos en lugar de insertar instrucciones #include . Ver "Incluir
Declaraciones "en la página 35.
--no-relativo
Al generar código, idl supone que las mismas opciones -I que se utilizan con idl son
también se usará con el compilador de C ++. Por lo tanto, idl intentará hacer todo
#include declaraciones relativas a los directorios especificados con -I . La opción --norelativa
suprime este comportamiento, en cuyo caso IDL no hará declaraciones #include
para archivos incluidos relativos a las rutas especificadas con la opción -I .
--header-dir DIR
Esta opción se puede usar para hacer declaraciones #include para archivos de encabezado relativos a un
directorio.
--other-header-dir DIR
Esta opción funciona como --header-dir , pero solo se aplica a archivos de cabecera para IDL incluido
archivos.
ORBacus 31
Opciones para jidl
--output-dir DIR
Escriba los archivos generados en el directorio DIR.
--dll-import DEF
Coloque DEF delante de cada símbolo que necesite una declaración explícita de importación de DLL.
3.5 Opciones para jidl
-h, --ayuda
-v, --version
-e, --cpp NOMBRE
-d, --debug
-DNAME
-DNAME = DEF
-TU NOMBRE
-IDIR
--no-esqueletos
--locality-constrained
--todas
--Corbata
Estas opciones son las mismas que para el comando idl .
--sin comentarios
El comportamiento predeterminado de jidl es agregar cualquier comentario del archivo IDL que comience
con / **
a los archivos Java generados. Especifique esta opción si no desea agregar estos comentarios a
tus archivos Java
--paquete PKG
Especifica un nombre de paquete para las clases Java generadas. Cada clase se generará relativa
a este paquete
--prefix-paquete PRE PKG
Especifica un nombre de paquete para un prefijo en particular 1 . Cada clase con este prefijo se generará
relativo al paquete especificado.
--auto-paquete
1. El prefijo se refiere al valor de la declaración del prefijo #pragma en un archivo IDL. Por ejemplo, el
declaración #pragma prefijo ooc.com define "ooc.com" como el prefijo. El prefijo es
incluido en los identificadores de repositorio de interfaz para todos los tipos definidos en el archivo IDL.
Los generadores de código ORBacus
32 ORBacus
Deriva los nombres de los paquetes para las clases Java generadas a partir de los prefijos IDL. El prefijo
ooc.com , por ejemplo, da como resultado el paquete com.ooc .
--output-dir DIR
Especifica un directorio donde jidl colocará los archivos Java generados. Sin esta opción
el directorio actual es usado.
--clon
Genera un método de clonación para los tipos struct, union, enum y exception.
3.6 Opciones para hidl
-h, --ayuda
-v, --version
-e, --cpp NOMBRE
-d, --debug
-DNAME
-DNAME = DEF
-TU NOMBRE
-IDIR
Estas opciones son las mismas que para el comando idl .
--no-sort
No clasifique los símbolos alfabéticamente.
--output-dir DIR
Escribir archivos HTML en el directorio DIR.
3.7 Opciones para ridl
-h, --ayuda
-v, --version
-e, --cpp NOMBRE
-d, --debug
-DNAME
-DNAME = DEF
-TU NOMBRE
-IDIR
Estas opciones son las mismas que para el comando idl .
--no-sort
ORBacus 33
Opciones para irserv
No clasifique los símbolos alfabéticamente.
--output-dir DIR
Escribir archivos RTF en el directorio DIR.
- ARCHIVO de archivo único
Crea un archivo .rtf único llamado FILE.
--with-index
Crear entradas de índice.
--nombre de la fuente
Use la fuente NAME como fuente para el cuerpo del texto.
--literal-font NAME
Use la fuente NAME como la fuente para los literales.
--title-font NAME
Use la fuente NAME como fuente para el título.
--heading-font NAME
Use la fuente NAME como la fuente para los encabezados.
--Tamaño de tamaño de fuente
Tamaño de letra del cuerpo del texto en puntos.
--literal-font-size TAMAÑO
Tamaño de fuente literal en puntos.
--title-font-size TAMAÑO
Tamaño de letra del título en puntos.
--heading-font-size TAMAÑO
Encabezado de tamaño de fuente en puntos.
3.8 Opciones para irserv
-h, --ayuda
-v, --version
-e, --cpp NOMBRE
-d, --debug
Los generadores de código ORBacus
34 ORBacus
-DNAME
-DNAME = DEF
-TU NOMBRE
-IDIR
Estas opciones son las mismas que para el comando idl .
-i, --ior
Imprima el IOR en cadena del repositorio de interfaz en salida estándar.
Los argumentos para irserv son cero o más archivos IDL. Si no se especifican archivos IDL en el
línea de comandos, el servidor del Repositorio de Interfaces se puede poblar dinámicamente usando el
comando irfeed .
3.9 Opciones para irfeed
-h, --ayuda
-v, --version
-e, --cpp NOMBRE
-d, --debug
-DNAME
-DNAME = DEF
-TU NOMBRE
-IDIR
Estas opciones son las mismas que para el comando idl .
Los argumentos a irfeed son uno o más archivos IDL.
3.10 Opciones para irdel
-h, --ayuda
-v, --version
Estas opciones son las mismas que para el comando idl .
Los argumentos para irdel son uno o más nombres de ámbito. Un nombre delimitado tiene la forma
"X :: Y :: Z". Por ejemplo, una interfaz que definí en un módulo M puede ser identificada por
nombre de alcance "M :: I".
3.11 Opciones para irgen
-h, --ayuda
-v, --version
--no-esqueletos
ORBacus 35
El traductor IDL-a-C ++ y el repositorio de interfaz
--no-type-codes
--locality-contrained
--no-virtual-inheritance
--Corbata
--c-sufijo SUFFIX
--h-sufijo SUFFIX
--header-dir DIR
--other-header-dir DIR
--output-dir DIR
Estas opciones son las mismas que para el comando idl .
El argumento para irgen es la ruta a usar como nombre base de los nombres de archivo de salida.
Por ejemplo, si la ruta de acceso que proporciona es salida / archivo , entonces irgen producirá
output / file.cpp , output / file.h , output / file_skel.cpp y output /
file_skel.h .
Tenga en cuenta que irgen generará código para todas las definiciones de tipo contenidas en la interfaz
Servidor de repositorio
3.12 El traductor IDL-a-C ++ y el repositorio de interfaz
Los traductores ORB ACUS IDL-to-C ++ e IDL-to-Java usan internamente la interfaz
Repositorio para generar código. Es decir, estos programas tienen su propia interfaz privada
Repositorio que se alimenta con los archivos IDL especificados. Todo el código se genera a partir de ese
privado
Repositorio de interfaz.
También es posible generar código C ++ desde un repositorio de interfaz global. Primero, el comando
irserv se debe usar para iniciar el repositorio de interfaz. Luego, el repositorio de interfaz
debe ser alimentado con el código IDL, usando el comando irfeed . Finalmente, el irgen
comando se puede utilizar para generar el código C ++. Por ejemplo:
irserv --ior> IntRep.ref &
irfeed -ORBrepository 'cat IntRep.ref' file.idl
irgen -ORBrepository 'cat IntRep.ref' archivo
El Idl del traductor IDL-a-C ++ realiza todos estos pasos a la vez, en un solo proceso con un
Repositorio de interfaz privado. Por lo tanto, solo tiene que ejecutar un solo comando:
idl file.idl
3.13 Incluir declaraciones
Si usa la instrucción #include en su código IDL, el traductor ORB ACUS IDL-to-C ++
idl no creará código para los archivos IDL incluidos. El traductor se inserte el appropri la
Generadores de código ORBacus
36 ORBacus
comió declaraciones #include en los archivos de encabezado generados en su lugar. Tenga en cuenta que
hay
varias restricciones sobre dónde colocar las declaraciones #include en sus archivos IDL para este
característica para trabajar correctamente:
• #include puede aparecer solo al comienzo de sus archivos IDL. Todo #include
las declaraciones se deben colocar antes del resto de su código IDL. 1
• Las definiciones de tipo, como las definiciones de interfaz o de estructura , no se pueden dividir
entre
varios archivos IDL. En otras palabras, ninguna declaración #include puede aparecer dentro de
definiciones.
Si no desea que se apliquen estas restricciones, puede usar la opción de traductor --todas
con idl . Con esta opción, el traductor de IDL a C ++ trata el código de los archivos incluidos como si
el código apareció en su archivo IDL en el lugar donde está incluido. Esto significa que el
el compilador no colocará sentencias #include en los archivos de encabezado generados automáticamente,
independientemente de si el código proviene directamente de su archivo IDL o de archivos incluidos por
su archivo IDL
Tenga en cuenta que al generar código de un repositorio de interfaz utilizando irgen , el traductor
se comporta de forma idéntica a IDL con el --all opción. En otras palabras, el comando irgen
no colocará sentencias #include en los archivos generados, sino que generará código para todos
Definiciones de IDL en el repositorio de interfaz.
3.14 Documentación de archivos IDL
Con los traductores ORB ACUS IDL-to-HTML e IDL-to-RTF, hidl y ridl , puedes
genere fácilmente archivos HTML y RTF que contengan descripciones de la interfaz IDL. Los traductores
generará un archivo muy bien formateado para cada módulo e interfaz de IDL. Figura 3.1
muestra un ejemplo HTML y la Figura 3.2 un ejemplo RTF.
La sintaxis de formateo soportada por hidl y ridl es similar a la utilizada por javadoc .
Se reconocen las siguientes palabras clave:
@ autor autor
Denota el autor de la interfaz.
@exception exception-name description
Agrega una descripción de excepción a la lista de excepciones de una operación.
@member member-name description
1. Las declaraciones de preprocesador como #define o #ifdef pueden colocarse antes de su #include
declaraciones.
ORBacus 37
Documentando archivos IDL
Agrega una descripción de miembro a la lista de miembros de un tipo de estructura, unión, enumeración o
excepción.
@param nombre de parámetro descripción
Agrega una descripción de parámetro a la lista de parámetros de una operación.
@return descripción
Agrega texto descriptivo para el valor de retorno de una operación.
Figura 3.1: Documentación generada con el traductor de IDL a HTML
Los generadores de código ORBacus
38 ORBacus
@ver referencia
Agrega una nota "Ver también".
@desde since-text
Comentario relacionado con la disponibilidad de nuevas funciones.
versión @version
El número de versión de la interfaz.
Figura 3.2: Documentación generada con el traductor IDL a RTF
ORBacus 39
Usando javadoc
Al igual que javadoc , hidl y ridl, usa la primera oración en el comentario de documentación como
la oración resumida. Esta oración termina en el primer período seguido de un espacio en blanco,
tabulador o terminador de línea, o en el primer @ .
RILL entiende la mayoría de las etiquetas HTML básicas y producirá un formato equivalente en el
archivos RTF generados Las siguientes etiquetas HTML son compatibles:
<B> <BR> <CÓDIGO> <EM> <HR> <P> <U> <UL>
3.15 Usando javadoc
Si no se suprime explícitamente con la opción --no-comments , ORB ACUS IDL-a-Java
El jidl del traductor agrega comentarios comenzando con / ** desde el archivo IDL al Java generado
archivos, para que javadoc pueda usarse para generar documentación (siempre y cuando los comentarios
están en un formato compatible con javadoc ).
Aquí hay un ejemplo que muestra cómo incluir documentación en una descripción de interfaz IDL
archivo. Supongamos que tenemos una interfaz I en un módulo M :
// IDL
módulo M
{
/ **
*
* Este es un comentario relacionado con la interfaz I.
*
* @author Uwe Seimet
*
* @version 1.0
*
** /
interfaz I
{
/ **
*
* Este comentario describe la excepción E.
*
** /
excepción E {};
/ **
*
Los generadores de código ORBacus
40 ORBacus
* La descripción para la operación S.
*
* @param arg Un argumento ficticio.
*
* @return Una cuerda ficticia.
*
* @exception E provocada bajo ciertas circunstancias.
*
** /
cadena S (en arg largo)
sube (E);
};
};
Al ejecutar jidl en este archivo, los comentarios se agregarán automáticamente a los generados
Los archivos Java M / I.java y M / IPackage / E.java . Para I.java el código generado
se ve de la siguiente manera:
// Java
paquete M;
//
// IDL: M / I: 1.0
//
/ **
* Este es un comentario relacionado con la interfaz I.
*
* @author Uwe Seimet
*
* @version 1.0
*
** /
interfaz pública extiendo org.omg.CORBA.Object
{
//
// IDL: M / I / S: 1.0
//
/ **
*
* La descripción para la operación S.
*
* @param arg Un argumento ficticio.
*
ORBacus 41
Usando javadoc
* @return Una cuerda ficticia.
*
* @exception M.IPackage.E Criado bajo ciertas circunstancias.
*
** /
Cadena pública
S (int arg)
arroja M.IPackage.E;
}
Tenga en cuenta que jidl inserta automáticamente el nombre completo de Java para la excepción E , en
este caso M.IPackage.E .
Estos son los contenidos de IPackage / E.java :
// Java
paquete M.IPackage;
//
// IDL: M / I / E: 1.0
//
/ **
*
* Este comentario describe la excepción E.
*
** /
La clase pública final E amplía org.omg.CORBA.UserException
{
público
MI()
{
}
}
Ahora puede usar javadoc para extraer los comentarios de los archivos Java generados y producir
documentación HTML con buen formato.
Para obtener información adicional, consulte la documentación de javadoc .
Los generadores de código ORBacus
42 ORBacus
ORBacus 43

ORB y BOA
CAPÍTULO 4

Inicialización
4.1 Inicialización de ORB
4.1.1 Inicializando el ORB de C ++
En C ++, el ORB se inicializa con CORBA_ORB_init () . Por ejemplo:
// C ++
int main (int argc, char * argv [], char * [])
{
CORBA_ORB_var orb = CORBA_ORB_init (argc, argv);
// ...
}
La llamada CORBA_ORB_init () interpreta los argumentos que comienzan con -ORB . Todos estos
argumentos,
pasado a través de los parámetros argc y argv , se eliminan automáticamente de
la lista de argumentos
4.1.2 Inicializando el ORB de Java para aplicaciones
Una aplicación Java puede inicializar el ORB de la siguiente manera:
// Java
import org.omg.CORBA. *;
public static void main (String args [])
{
Inicialización de ORB y BOA
44 ORBacus
ORB orb = ORB.init (args, new java.util.Properties ());
// ...
}
La llamada ORB.init () interpreta los argumentos que comienzan con -ORB . A diferencia de la versión
de C ++,
estos argumentos no se eliminan (consulte "Filtrar las opciones de línea de comando" en la página 50 para
más información).
4.1.3 Inicializando el ORB de Java en JDK 1.2
El ORB incluido en JDK 1.2 no está completo y carece de algunas funciones (consulte el JDK 1.2
documentación para más información). Para usar ORBacus ORB en lugar de ORB
incluido con JDK 1.2, debe iniciar su aplicación con las siguientes propiedades:
java -Dorg.omg.CORBA.ORBClass = com.ooc.CORBA.ORB \
-Dorg.omg.CORBA.ORBSingletonClass = com.ooc.CORBA.ORBSingleton \
MyApp
Una alternativa es establecer estas propiedades en su programa antes de inicializar el ORB. por
ejemplo:
// Java
import org.omg.CORBA. *;
public static void main (String args [])
{
Propiedades props = System.getProperties ();
props.put ("org.omg.CORBA.ORBClass", "com.ooc.CORBA.ORB");
props.put ("org.omg.CORBA.ORBSingletonClass",
"com.ooc.CORBA.ORBSingleton");
System.setProperties (props);
ORB orb = ORB.init (args, props);
// ...
}
4.1.4 Inicializando el ORB de Java para Applets
Se proporciona una sobrecarga diferente de ORB.init () para el uso de los applets:
// Java
import org.omg.CORBA. *;
public void init ()
{
ORB orb = ORB.init (esto, nuevo java.util.Properties ());
// ...
ORBacus 45
Inicialización de BOA
}
Consulte "Applets" en la página 61 para obtener más información sobre el uso de ORB ACUS en un applet.
4.2 Inicialización BOA
4.2.1 Inicializando el C ++ BOA
En C ++, el BOA se inicializa con CORBA_ORB :: BOA_init () . Por ejemplo:
// C ++
int main (int argc, char * argv [], char * [])
{
CORBA_ORB_var orb = CORBA_ORB_init (argc, argv);
CORBA_BOA_var boa = orb -> BOA_init (argc, argv);
// ...
}
BOA_init () elimina todos los argumentos que comienzan con -OA pasado por el argc y argv
parámetros.
4.2.2 Inicializando el Java BOA
En Java, la inicialización de BOA tiene este aspecto:
// Java
import org.omg.CORBA. *;
public static void main (String args [])
{
ORB orb = ORB.init (args, new java.util.Properties ());
BOA boa = orb.BOA_init (args, new java.util.Properties ());
// ...
}
4.2.3 Inicializando el Java BOA en JDK 1.2
La clase org.omg.CORBA.ORB incluida con JDK1.2 no es compatible con BOA_init ()
método. Por lo tanto, para usar BOA_init () con JDK1.2, debe convertir el ORB a
com.ooc.CORBA.ORB , como se muestra a continuación.
// Java
import org.omg.CORBA. *;
public static void main (String args [])
{
Inicialización de ORB y BOA
46 ORBacus
Propiedades props = System.getProperties ();
props.put ("org.omg.CORBA.ORBClass", "com.ooc.CORBA.ORB");
props.put ("org.omg.CORBA.ORBSingletonClass",
"com.ooc.CORBA.ORBSingleton");
System.setProperties (props);
ORB orb = ORB.init (args, props);
BOA boa = ((com.ooc.CORBA.ORB) orb) .BOA_init (args, props);
// ...
}
4.3 Configurando el ORB y el BOA
Las aplicaciones ORB ACUS pueden adaptar el comportamiento de los objetos ORB y BOA utilizando una
colección
de propiedades 1 . Estas propiedades se pueden definir de varias maneras:
• utilizando un archivo de configuración
• usando las propiedades del sistema (Java)
• usando opciones de línea de comando
• programáticamente en tiempo de ejecución
4.3.1 Propiedades
Las propiedades de configuración de ORB ACUS se describen en las secciones a continuación. A menos que
de otro modo
notado, cada propiedad se puede usar tanto en aplicaciones C ++ como Java.
Propiedades de ORB
ooc.orb.add_iiop_connector
Valor: verdadero , falso
Determina si el ORB debe registrar un conector IIOP durante la inicialización. los
el valor predeterminado es verdadero .
ooc.orb.conc_model
Valor: bloqueo , reactivo , roscado
1. Tenga en cuenta que estas propiedades no tienen nada que ver con el Servicio de Propiedad como se describe en "El
Servicio de propiedad "en la página 168.
ORBacus 47
Configurando el ORB y el BOA
Selecciona el modelo de concurrencia del lado del cliente. El modelo de concurrencia reactiva no está actualmente
disponible
en ORB ACUS para Java. El valor predeterminado es el bloqueo para aplicaciones C ++ y Java. Ver
Capítulo 9 para más información sobre modelos de concurrencia.
ooc.orb.id
Valor: id
Especifica el identificador del ORB que utilizará la aplicación. El único identificador válido
es OB_ORB .
ooc.orb.trace_level
Valor: nivel > = 0
Define el nivel de salida para mensajes de diagnóstico impresos por ORB ACUS . Un nivel de 1 produce
información sobre eventos de conexión. El nivel predeterminado es 0, que no produce salida.
ooc.service.name
Valor: ior
Agrega un servicio inicial a la lista interna del ORB. Esta lista se consulta cuando la aplicación
invoca la operación ORB resolve_initial_references . nombre es la clave que
está asociado a un IOR con cadenas creado con object_to_string . Por ejemplo, el
propiedad ooc.service.NameService agrega "NameService" a la lista de servicios iniciales.
Consulte "Referencias de objetos Stringified" en la página 89 y "Servicios iniciales" en la página 94 para
obtener más información.
información.
Propiedades de BOA
ooc.boa.add_iiop_acceptor
Valor: verdadero , falso
Determina si el BOA debe registrar un aceptador IIOP durante la inicialización. los
el valor predeterminado es verdadero .
ooc.boa.conc_model
Valor: bloqueo , reactivo , roscado , thread_per_client ,
thread_per_request , thread_pool
Inicialización de ORB y BOA
48 ORBacus
Selecciona el modelo de simultaneidad del lado del servidor. El modelo de concurrencia reactiva no está disponible en
ORB ACUS para Java. El valor predeterminado es reactivo para aplicaciones C ++ y enhebrado para Java
aplicaciones. Consulte el Capítulo 9 para obtener más información sobre los modelos de concurrencia. Si esta propiedad
está configurada para
thread_pool , luego la propiedad ooc.boa.thread_pool determina cuántos hilos hay en
la piscina.
ooc.boa.disable_iiop_acceptor
Valor: verdadero , falso
Determina si el BOA debe desactivar el aceptador de IIOP después de registrarlo. los
el valor predeterminado es falso .
ooc.boa.host
Valor: nombre de host
Define explícitamente el nombre de host que se utilizará en las referencias de objetos generadas por el BOA.
los
el valor predeterminado es el nombre de host canónico de la máquina. Esta propiedad es especialmente útil
si un host tiene más de un nombre Tenga en cuenta que esta propiedad se ignora si ooc.boa.numeric
es cierto .
ooc.boa.id
Valor: id
Especifica el identificador del BOA que utilizará la aplicación. El único identificador válido
es OB_BOA .
ooc.boa.numeric
Valor: verdadero , falso
Si es verdadero , el BOA generará referencias de objeto que contienen una dirección de Internet (IP) en decimal con
puntos
notación en lugar del nombre de host canónico. El valor predeterminado es falso .
ooc.boa.port
Valor: 0 <= puerto <= 65535
Especifica el número de puerto en el que el servidor debe escuchar nuevas conexiones. Si no hay puerto
se especifica, uno será seleccionado automáticamente por el BOA. Use esta propiedad si planea
publicar un IOR (por ejemplo, en un archivo, un servicio de nombres, etc.) y desea que el IOR permanezca
válido en todas las ejecuciones de su servidor. Sin esta propiedad, es probable que su servidor use una
ORBacus 49
Configurando el ORB y el BOA
diferente número de puerto cada vez que se ejecuta el servidor. Ver el Capítulo 6 para más información.
ooc.boa.thread_pool
Valor: n > 0
Determina la cantidad de subprocesos que se deben reservar para atender las solicitudes entrantes. El valor
por defecto
el valor es 10 . Esta propiedad solo es efectiva cuando la propiedad ooc.boa.conc_model tiene
el valor thread_pool .
4.3.2 Opciones de línea de comando
Hay opciones de línea de comando equivalentes para muchas de las propiedades de ORB ACUS . los
las opciones y sus configuraciones de propiedades equivalentes se muestran en la Tabla 4.1. Consulte
"Propiedades"
en la página 46 para una descripción de las propiedades.
Propiedad de Opción
-OAbloqueo ooc.boa.conc_model = bloqueo
-OAdisable_iiop_acceptor ooc.boa.disable_iiop_acceptor = true
-Ordenador host ooc.boa.host = host
-OAid id ooc.boa.id = id
-OAnumeric ooc.boa.numeric = true
-port puerto ooc.boa.port = puerto
-Oreactiva ooc.boa.conc_model = reactiva
-OAthreaded ooc.boa.conc_model = enhebrado
-OAthread_per_client ooc.boa.conc_model = thread_per_client
-OAthread_per_request ooc.boa.conc_model = thread_per_request
-OAthread_pool n ooc.boa.conc_model = thread_pool
ooc.boa.thread_pool = n
-ORBblocking ooc.orb.conc_model = bloqueando
-ORBid id ooc.orb.id = id
-ORBnaming ior ooc.service.NameService = ior
Tabla 4.1: Opciones de línea de comandos
Inicialización de ORB y BOA
50 ORBacus
Se admiten algunas opciones de línea de comandos adicionales que no tienen propiedades equivalentes.
Estas opciones se describen en la Tabla 4.2.
4.3.3 Filtrar las opciones de línea de comandos
En C ++, todas las opciones de línea de comandos reconocidas por ORB ACUS se eliminan automáticamente
de la matriz argv después de inicializar el ORB y BOA.
En Java, ORB ACUS no elimina automáticamente las opciones de línea de comandos . Si tú pudieras
desea eliminar las opciones específicas de ORB ACUS de la lista de argumentos, necesitará
hazlo usando dos métodos adicionales.
El siguiente ejemplo muestra cómo eliminar las opciones de ORB y BOA en Java:
1 // Java
2 org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init (args, null);
3 org.omg.CORBA.BOA boa = orb.BOA_init (args, null);
4 String [] noOrbArgs = ((com.ooc.CORBA.ORB) orb) .filter_options (args);
5 String [] noBoaArgs =
6 ((com.ooc.CORBA.BOA) boa) .filter_options (noOrbArgs);
2,3 Inicializa el ORB y el BOA.
-ORBreactive ooc.orb.conc_model = reactive
-ORBrepository ior ooc.service.InterfaceRepository = ior
-Ordenar el nombre de servicio ior ooc.service. nombre = ior
-ORBthreaded ooc.orb.conc_model = enhebrado
-ORBtrace_level level ooc.orb.trace_level = level
Opción Descripción
-ORBversion hace que el ORB imprima su versión a la salida estándar.
-ORBlicense Hace que el ORB imprima su licencia a la salida estándar.
Tabla 4.2: Opciones adicionales de línea de comandos
Propiedad de Opción
Tabla 4.1: Opciones de línea de comandos
ORBacus 51
Configurando el ORB y el BOA
4 Elimine las opciones de ORB (es decir, opciones que comienzan con -ORB ) desde args . La matriz
noOrbArgs contiene las opciones filtradas.
5,6 Eliminar las opciones de BOA (es decir, opciones que comienzan con -OA ). Pasando noOrbArgs a
esto
método, nos aseguramos de que se hayan eliminado las opciones de ORB y BOA.
Tenga en cuenta que los moldes para el ORB y el BOA son necesarios porque filter_options es un
Operación específica de ORB ACUS , que solo existe en las clases ORB y BOA que residen en
el paquete com.ooc.CORBA , y no en el paquete org.omg.CORBA .
4.3.4 Usando un archivo de configuración
Una forma conveniente de definir un grupo de propiedades es usar un archivo de configuración. Una muestra
El archivo de configuración se muestra a continuación:
# Modelos de simultaneidad
ooc.orb.conc_model = enhebrado
ooc.boa.conc_model = thread_pool
ooc.boa.thread_pool = 5
# Servicios iniciales
ooc.service.NameService = iiop: // myhost: 5000 / DefaultNamingContext
ooc.service.EventService = iiop: // myhost: 5001 / DefaultEventChannel
ooc.service.TradingService = iiop: // myhost: 5002 / TradingService
Puede definir el nombre del archivo de configuración 1 usando una opción de línea de comando, un entorno
variable (C ++), o una propiedad del sistema (Java):
• Opción de línea de comando:
-ORBconfig nombre de archivo
• Variable ambiental:
ORBACUS_CONFIG = nombre de archivo
• Propiedad del sistema Java:
ooc.config = nombre de archivo
El archivo se lee una vez cuando se inicializa el ORB, y no se vuelve a leer durante la vida útil de
el proceso de solicitud.
1. ORB ACUS para Java también acepta una especificación de URL como nombre de archivo.
Inicialización de ORB y BOA
52 ORBacus
4.3.5 Uso del registro de Windows NT
Otro mecanismo conveniente para usar con aplicaciones C ++ en Windows NT es
use el registro del sistema 1 . Las propiedades se pueden almacenar en el registro bajo el siguiente registro
llaves:
HKEY_LOCAL_MACHINE \ Software \ OOC \ Properties
HKEY_CURRENT_USER \ Software \ OOC \ Properties
Las propiedades individuales se definen como subclaves de la base. Por ejemplo, la propiedad
ooc.orb.trace_level = 5 se almacena en el registro como la siguiente clave que contiene un
value named trace_level con un miembro de datos REG_SZ igual a "5" :
Software \ OOC \ Properties \ ooc \ orb
RegUpdate
La distribución ORB ACUS incluye una utilidad llamada RegUpdate. La herramienta primero elimina
todas las subclases definidas bajo la clave de registro especificada. A continuación, todos los valores
definidos en un ORB ACUS
archivo de configuración se transfieren al registro.
Sinopsis
RegUpdate [-ORBconfig archivo] HKEY_LOCAL_MACHINE | HKEY_CURRENT_USER
Opciones para RegUpdate
-archivo ORBconfig
Lea las propiedades de este archivo de configuración. Si la opción -ORBconfig no está especificada
las propiedades se leen del archivo definido por la variable de entorno ORBACUS_CONFIG .
Ejemplo:
RegUpdate -ORBconfig ob.conf HKEY_LOCAL_MACHINE
Este comando leerá las propiedades definidas en el archivo ob.conf y escribirá los valores
bajo la siguiente clave de registro:
HKEY_LOCAL_MACHINE \ Software \ OOC \ Properties
1. Tenga cuidado al definir las propiedades de ORB ACUS en el registro, ya que se convierten en propiedades globales
que se usará en cada aplicación ORB ACUS para C ++. Por ejemplo, los errores sutiles pueden
ocurrir si la propiedad ooc.boa.port se define de forma global.
ORBacus 53
Configurando el ORB y el BOA
4.3.6 Definición de propiedades en Java
Las aplicaciones Java pueden usar el mecanismo estándar de Java para definir las propiedades del sistema.
porque ORB ACUS también buscará las propiedades del sistema durante la inicialización de ORB y BOA.
Por ejemplo:
1 // Java
2 java.util.Properties props = System.getProperties ();
3 props.put ("ooc.orb.conc_model", "threaded");
4 props.put ("ooc.boa.port", "10000");
5 org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init (args, null);
2 Obtenga las propiedades del sistema.
3,4 Define las propiedades de ORB ACUS .
5 Inicializa el ORB.
Las máquinas virtuales Java por lo general le permiten definir las propiedades del sistema en el comando
línea. Por ejemplo, usando la JVM de Sun puedes hacer lo siguiente:
java -Dooc.boa.port = 5000 MyServer
También puede usar el objeto java.util.Properties que se pasa al
org.omg.CORBA.ORB.init () y org.omg.CORBA.ORB.BOA_init () métodos para
proporcionar las definiciones de propiedad de ORB ACUS :
1 // Java
2 java.util.Properties props = new java.util.Properties ();
3 props.put ("ooc.boa.numeric", "true");
4 org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init (args, props);
5 org.omg.CORBA.BOA boa = orb.BOA_init (args, props);
2 Cree un objeto java.util.Properties para mantener nuestras propiedades.
3 Defina las propiedades de ORB ACUS .
4,5 Inicialice ORB y BOA utilizando el objeto java.util.Properties .
4.3.7 Precedencia de las propiedades
Dado que las propiedades se pueden definir de varias maneras, es importante establecer el orden
de prioridad utilizado por ORB ACUS al recopilar y procesar las definiciones de propiedad.
Inicialización de ORB y BOA
54 ORBacus
El orden de precedencia se detalla a continuación, de mayor a menor. Propiedades definidas en a
una precedencia más alta anula las mismas propiedades definidas en una precedencia más baja.
1. Opciones de línea de comando
2. Propiedades del sistema (solo Java)
3. Propiedades proporcionadas por el usuario (solo Java)
4. Archivo de configuración
5. HKEY_CURRENT_USER \ Software \ OOC \ Properties (Windows NT / C ++ solamente)
6. HKEY_LOCAL_MACHINE \ Software \ OOC \ Properties (Windows NT / C ++ solamente)
Por ejemplo, una propiedad definida usando una opción de línea de comando anula la misma propiedad
definido en un archivo de configuración.
4.3.8 Uso avanzado de la propiedad
Si necesita un control explícito de las propiedades desde su aplicación, también puede
elija utilizar las clases específicas de ORB ACUS para crear y recuperar definiciones de propiedad. 1
En Java, esta clase es com.ooc.CORBA.Properties , y en C ++ la clase es
OBProperties . Estas clases son usadas internamente por ORB ACUS , pero también puede usar
ellos en sus aplicaciones.
// Java
paquete com.ooc.CORBA;
Propiedades de clase
{
public static Propiedades init (String [] args);
public static Instancia de propiedades ();
public String getProperty (clave de cadena);
public void setProperty (String key, String value);
public String [] getKeys (String prefix);
public String [] getKeys ();
}
// C ++
clase OBProperties
{
1. La clase de Propiedades es probablemente más útil para las aplicaciones C ++, ya que las aplicaciones Java
puede usar las propiedades del sistema para lograr el mismo efecto.
ORBacus 55
Configurando el ORB y el BOA
público:
OBProperties estático * init (int & argc, char ** argv);
estática OBProperties * instance ();
typedef OBStrSeq KeySeq;
void setProperty (const char * key, const char * value);
const char * getProperty (const char * key);
KeySeq getKeys (prefijo const char *);
KeySeq getKeys ();
};
En la discusión a continuación, estas clases se denominan genéricamente como la clase Propiedades .
Para usar una clase de Propiedades correctamente, debe tener en cuenta los pasos de inicialización
tomados
por los objetos ORB y BOA. La clase de Propiedades es una clase de Singleton , en ese solo uno
instancia de la clase está permitido. El ORB inicializa el objeto Properties durante su
propia inicialización Sin embargo, si necesita usar la clase Propiedades antes de que el ORB tenga
inicializado (por ejemplo, si necesita definir una propiedad ORB), entonces deberá inicializar
la clase Propiedades de forma manual.
Definición de propiedades de ORB
El siguiente código muestra una situación en la que una aplicación necesita definir una propiedad
antes de inicializar el ORB. Primero, mostraremos el ejemplo en C ++:
1 // C ++
2 #include <OB / CORBA.h>
3 #include <OB / Properties.h>
4
5 // ...
6
7 OBProperties * properties = OBProperties :: init (argc, argv);
8 propiedades -> setProperty ("ooc.orb.conc_model", "reactivo");
9 CORBA_ORB_var orb = CORBA_ORB_init (argc, argv);
2,3 Incluye los archivos de encabezado necesarios.
7 La llamada a OBProperties :: init () crea el objeto OBProperties y lo inicializa
con los contenidos de un archivo de configuración (si es necesario).
8 Establezca el modelo de concurrencia ORB utilizando una propiedad.
9 Inicialice el ORB.
Inicialización de ORB y BOA
56 ORBacus
El código se ve muy similar en Java:
1 // Java
2 com.ooc.CORBA.Properties properties =
3 com.ooc.CORBA.Properties.init (args);
4 properties.setProperty ("ooc.orb.conc_model", "threaded");
5 org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init (args, null);
2,3 Crea el objeto com.ooc.CORBA.Properties y lo inicializa con el contenido de un
archivo de configuración (si es necesario).
4 Establezca el modelo de simultaneidad ORB utilizando una propiedad.
5 Inicializa el ORB.
Definición de las propiedades de BOA
En una situación donde no necesita acceso al objeto Propiedades hasta después del ORB
se ha inicializado, simplemente puede hacer lo siguiente:
1 // C ++
2 #include <OB / CORBA.h>
3 #include <OB / Properties.h>
4
5 // ...
6
7 CORBA_ORB_var orb = CORBA_ORB_init (argc, argv);
8 OBProperties * properties = OBProperties :: instance ();
9 propiedades -> setProperty ("ooc.boa.conc_model", "reactivo");
10 CORBA_BOA_var boa = orb -> BOA_init (argc, argv);
2,3 Incluye los archivos de encabezado necesarios.
7 Inicialice el ORB. El ORB inicializará el objeto Properties .
8 Obtenga la instancia OBProperties .
9,10 Configure el modelo de concurrencia BOA utilizando una propiedad e inicialice el BOA.
Tenga en cuenta que en este ejemplo estamos definiendo una propiedad BOA antes de inicializar el BOA.
También tenga en cuenta que el objeto Propiedades ya ha sido inicializado por el ORB, por lo que
la aplicación simplemente necesita obtener un puntero al objeto usando el método de instancia .
Este es el mismo ejemplo en Java:
ORBacus 57
Configurando el ORB y el BOA
1 // Java
2 org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init (args, null);
3 com.ooc.CORBA.Properties properties =
4 com.ooc.CORBA.Properties.instance ();
5 properties.setProperty ("ooc.boa.conc_model", "threaded");
6 org.omg.CORBA.BOA boa = orb.BOA_init (args, null);
2 Inicialice el ORB. El ORB inicializará el objeto Properties .
3,4 Obtenga la instancia de Propiedades .
5,6 Configure el modelo de concurrencia BOA utilizando una propiedad e inicialice el BOA.
Propiedades específicas de la aplicación
Otra situación en la que la clase Propiedades puede ser útil es si desea obtener
propiedades específicas de la aplicación del archivo de configuración de ORB ACUS . Supongamos que su
configuración
el archivo se ve de la siguiente manera:
# Archivo de configuración ORBacus
ooc.orb.conc_model = enhebrado
# Configuraciones específicas de la aplicación
acme.widget_count = 20
El siguiente ejemplo de C ++ muestra cómo acceder a las propiedades específicas de la aplicación:
1 // C ++
2 #include <OB / CORBA.h>
3 #include <OB / Properties.h>
4
5 // ...
6
7 CORBA_ORB_var orb = CORBA_ORB_init (argc, argv);
8 OBProperties * properties = OBProperties :: instance ();
9 const char * value = propiedades -> getProperty ("acme.widget_count");
2,3 Incluye los archivos de encabezado necesarios.
7 El ORB debe inicializarse para que se procese el archivo de configuración.
8,9 Obtenga la instancia OBProperties y luego recupere el valor de la propiedad.
Y en Java:
Inicialización de ORB y BOA
58 ORBacus
1 // Java
2 org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init (args, null);
3 com.ooc.CORBA.Properties properties =
4 com.ooc.CORBA.Properties.instance ();
5 String value = properties.getProperty ("acme.widget_count");
2 El ORB debe inicializarse para que se procese el archivo de configuración.
3-5 Obtenga la instancia de Propiedades y luego recupere el valor de la propiedad.
Finalmente, es importante recordar las reglas de precedencia para las propiedades de ORB ACUS .
Específicamente,
las opciones de la línea de comando anularán siempre las definiciones de propiedad existentes,
incluidos los que establece dentro de su aplicación.
4.4 Bucle de evento del servidor
El ciclo de eventos de un servidor se ingresa llamando a BOA :: impl_is_ready . Por ejemplo, en Java: 1
// Java
org.omg.CORBA.BOA boa = ... // Obtener el BOA de alguna manera
boa.impl_is_ready (null);
Y en C ++:
// C ++
CORBA_BOA_var boa = ... // Obtener el BOA de alguna manera
boa -> impl_is_ready (CORBA_ImplementationDef :: _ nil ());
impl_is_ready solo devuelve, si:
• Se ha elegido el modelo de simultaneidad de bloqueo (ver Capítulo 9) para el servidor, y
el cliente se desconecta
• deactivate_impl se llama (consulte "Desactivación del servidor" en la página 59).
4.4.1 Aplicaciones de servidor / servidor mixto
En caso de que se haya elegido el modelo reactivo o el de concurrencia roscada (ver Capítulo
9) es posible atender solicitudes sin llamar a impl_is_ready . Esto es especialmente
útil en aplicaciones mixtas de cliente / servidor. Por ejemplo, considere un cliente / servidor mixto
programa que quiere invocar operaciones en un servidor en la función principal del programa , pero
todavía quiere poder recibir "devoluciones de llamada" desde este servidor. Para recibir estos
1. El argumento de impl_is_ready no está siendo utilizado actualmente por ORB ACUS , por lo tanto, el "dummy"
Se usa argumento null (Java) o CORBA_ImplementationDef :: _ nil () (C ++).
ORBacus 59
Server Event Loop
Las solicitudes de "devolución de llamada", generalmente impl_is_ready tendrían que ser llamadas en
main . Sin embargo,
esto no es posible, ya que impl_is_ready bloquea, lo que hace que sea imposible para el
programa mixto cliente / servidor para invocar operaciones en el servidor después de la llamada a
impl_is_ready .
Para resolver este problema, ORB ACUS proporciona la operación init_servers . Así es cómo
init_servers se llama en Java:
// Java
org.omg.CORBA.BOA boa = ... // Obtener el BOA de alguna manera
((com.ooc.CORBA.BOA) boa) .init_servers ();
Esto es similar a impl_is_ready , excepto que init_servers no bloquea. Tenga en cuenta que
el lanzamiento para el BOA es necesario porque init_servers es una operación ORB ACUS-specific ,
que solo existe en com.ooc.CORBA.BOA , y no en org.omg.CORBA.BOA .
La versión de C ++ es similar:
// C ++
CORBA_BOA_var boa = ... // Obtener el BOA de alguna manera
boa -> init_servers ();
4.4.2 Desactivar el servidor
Un servidor se puede desactivar con una llamada a BOA :: deactivate_impl . Esto causa
BOA :: impl_is_ready para volver. Por ejemplo, considere un servidor que se puede cerrar
por un cliente llamando a una operación de desactivación en uno de los objetos del servidor. Primero el
Código IDL:
// IDL
interfaz ShutdownObject
{
void deactivate ();
};
En el lado del servidor, ShutdownObject se puede implementar así:
1 // C ++
2
Clase 3 ShutdownObject_impl: público virtual ShutdownObject_skel
4 {
5 CORBA_BOA_var boa_;
6
7 público:
8
9 ShutdownObject_impl (CORBA_BOA_ptr boa)
Inicialización de ORB y BOA
60 ORBacus
10 : boa_ (CORBA_BOA :: _ duplicado (boa))
11 {
12 }
13
14 virtual void desactivado ()
15 {
16 boa_ -> deactivate_impl (CORBA_ImplementationDef :: _ nil ());
17 }
18 };
3 Se define una clase de servidor para ShutdownObject . Para más información sobre cómo implementar
clases de sirvientes, ver el Capítulo 5.
5 Se necesita una BOA para llamar a deactivate_impl .
9-12 El constructor inicializa al miembro BOA.
14-17 desactivar llamadas deactivate_impl en el BOA.
Aquí está el código principal para este ejemplo:
1 // C ++
2
3 int main (int argc, char * argv [], char * [])
4 {
5 CORBA_ORB_var orb = CORBA_ORB_init (argc, argv);
6 CORBA_BOA_var boa = orb -> BOA_init (argc, argv);
7
8 ShutdownObject_var shutdownObj = new ShutdownObject_impl (boa);
9
10 boa -> impl_is_ready (CORBA_ImplementationDef :: _ nil ());
11
12 retorno 0;
13 }
5,6 Inicialización de ORB y BOA.
8 Se crea el objeto de cierre.
10 Se ingresa el bucle de evento principal impl_is_ready . Esta llamada solo vuelve si desactivar
es
llamado.
12 El servidor fue desactivado, por lo que main ahora puede regresar.
El cliente puede usar la llamada desactivada como se muestra a continuación:
ORBacus 61
Applets
1 // C ++
2
3 int main (int argc, char * argv [], char * [])
4 {
5 CORBA_ORB_var orb = CORBA_ORB_init (argc, argv);
6
7 ShutdownObject_var shutdownObj = ... // Obtener una referencia de alguna manera
8
9 intentar
10 {
11 shutdownObj -> deactivate ();
12 }
13 catch (const CORBA_COMM_FAILURE & ex)
14 {
15 }
dieciséis
17 retorno 0;
18 }
5 Inicializa el ORB.
7 Obtenga una referencia al objeto de cierre del servidor de alguna manera, por ejemplo leyendo en un
Referencia del objeto "stringified" (ver "Referencias al objeto Stringified" en la página 89).
9-15 Llamada desactivada en el objeto de apagado. Las excepciones COMM_FAILURE se deben
ignorar,
ya que el servidor puede cerrarse inmediatamente, sin posibilidad de recibir un mensaje de respuesta
adecuado
para ser entregado de vuelta al cliente. Por lo tanto, el cliente generalmente obtendrá un
Excepción COMM_FAILURE en este punto.
4.5 applets
4.5.1 Adición de Applets de ORBacus a páginas web
Al igual que cualquier otro applet, los applets ORB ACUS se pueden agregar a las páginas HTML con el
APPLET
etiqueta:
<APPLET CODE = "Client.class" ARCHIVE = "OB.jar" WIDTH = 500 HEIGHT = 300>
</ APPLET>
Es necesario indicarle al navegador web dónde encontrar las clases de Java de ORB ACUS . Esto es
mejor hecho con el atributo ARCHIVE como se muestra arriba. Una alternativa es usar el
Atributo CODEBASE y para extraer el archivo OB.jar en el directorio definido por
CODEBASE . Para obtener más información, consulte la documentación de su kit de desarrollo de Java.
Inicialización de ORB y BOA
62 ORBacus
4.5.2 Definición de opciones de ORB y BOA para un applet
La etiqueta PARAM se usa en HTML para definir parámetros para un applet. Cuando se inicializa por un
applet, el ORB busca los parámetros ORBparams y BOAparams , cuyos valores
deberían ser opciones de línea de comando separadas por espacios.
Por ejemplo, el código HTML a continuación usa la opción -ORBconfig para especificar la URL de
el archivo de configuración ORB:
<APPLET CODE = "Client.class" ARCHIVE = "OB.jar" WIDTH = 500 HEIGHT = 300>
<PARAM NAME = "ORBparams" VALOR = "- ORBconfig http: //www/orb.cfg">
</ APPLET>
Su applet también puede definir las propiedades de configuración de ORB ACUS usando propiedades del
sistema Java,
o usando el objeto java.util.Properties pasado a
org.omg.CORBA.ORB.init () . Consulte "Inicializar Java BOA en JDK 1.2" en la página 45
para más información.
4.5.3 Definición de los parámetros de la clase ORB
Algunos navegadores web 1 tienen incorporado un ORB. Para usar ORB ACUS en lugar de este incorporado
ORB, debe establecer los siguientes parámetros de applet:
<APPLET CODE = "Client.class" ARCHIVE = "OB.jar" WIDTH = 500 HEIGHT = 300>
<PARAM NAME = "org.omg.CORBA.ORBClass"
VALUE = "com.ooc.CORBA.ORB">
<PARAM NAME = "org.omg.CORBA.ORBSingletonClass"
VALUE = "com.ooc.CORBA.ORBSingleton">
</ APPLET>
4.5.4 Problemas de seguridad
Los navegadores web generalmente colocan varias restricciones de seguridad en los applets que necesita para
ser
consciente de cuando se desarrolla un applet usando ORB ACUS :
• Los applets solo pueden comunicarse con el host desde el que se descargó el applet.
• Los applets no pueden aceptar conexiones de ningún host.
La primera limitación te obliga a ejecutar cualquier aplicación de servidor CORBA que tu applet
se comunica con su servidor de servidor web. 2 La segunda limitación impide que tu applet
de actuar como un servidor CORBA, que a menudo es necesario cuando un cliente desea recibir
devoluciones de llamada desde un servidor.
1. Por ejemplo, Netscape v4 tiene un ORB incorporado.
ORBacus 63
Applets
Estas limitaciones son las causas más comunes de excepciones de seguridad en un applet. Tú
debe asegurarse de que cualquier referencia de objeto utilizada por su applet se refiera a objetos en la Web
servidor host Además, no debe intentar habilitar la funcionalidad del servidor CORBA en
su applet inicializando el BOA.
2. Netscape v4 tampoco permite que los applets de CORBA se carguen desde un local (es decir, sistema de archivos)
Archivo HTML, que causa una SecurityException cuando el applet intenta conectarse al
Servidor CORBA. Para evitar este problema, los applets de CORBA se deben descargar de una Web
servidor.
Inicialización de ORB y BOA
64 ORBacus
ORBacus 65

CAPÍTULO 5 Objetos de CORBA


5.1 Descripción general
Un objeto CORBA es un objeto con una interfaz definida en CORBA IDL. Objetos CORBA
tener diferentes representaciones en clientes y servidores.
• Un servidor implementa un objeto CORBA en un lenguaje de programación concreto, para
ejemplo en C ++ o Java. Esto se hace escribiendo una clase de implementación para el
Objeto CORBA y al crear una instancia de esta clase. El objeto resultante se llama servidor .
• Un cliente que quiere hacer uso de un servidor implementado por un servidor crea un objeto
que delega todas las llamadas de operación al servidor a través del ORB. Tal objeto se llama
proxy .
Cuando un cliente invoca un método en el objeto proxy local, el ORB empaqueta la entrada
parámetros y los envía al servidor, que a su vez descomprime estos parámetros y
invoca el método real en el servidor. Los parámetros de salida y los valores de retorno, si los hay, siguen
el camino inverso al cliente. Desde la perspectiva del cliente, el proxy actúa solo
como el servidor, ya que oculta todos los detalles de comunicación dentro de sí mismo.
Un servidor debe estar conectado de alguna manera al ORB, de modo que el ORB pueda invocar un método
en el servidor cuando se recibe una solicitud de un cliente. Esta conexión es manejada por
adaptador de objeto, como se muestra en la Figura 5.1.
ORB ACUS viene con un adaptador de objeto llamado "Adaptador de objeto básico" (BOA).
Desafortunadamente,
la especificación para el BOA [2] es bastante incompleta, dejando mucha libertad para
Objetos CORBA
66 ORBacus
Implementadores ORB. 1 Por lo tanto, todos los BOA son, de hecho, más o menos específicos del vendedor.
Es
por lo tanto, es necesario tener un capítulo que explique cómo se implementan los servidores en ORB ACUS
y cómo están conectados a la implementación de ORB ACUS BOA.
5.2 Implementación de servidores
En este capítulo, implementaremos clases de servidores (o "clases de implementación") para el
Interfaces IDL definidas a continuación:
1 // IDL
2
3 interfaz A
4 {
5 void op_a ();
6 };
7
8 interfaz B
9 {
10 void op_b ();
11 };
12
13 interfaz I: A, B
14 {
Figura 5.1: Servidores, Proxies y el Adaptador de Objetos
1. Debido a estos problemas, OMG está definiendo un nuevo adaptador de objeto, el llamado
"Adaptador de objetos portátil" (POA). Las versiones futuras de ORB ACUS implementarán el POA.
Apoderado
Servidor
Objeto
Adaptador
ORBE
Servidor de cliente
ORBacus 67
Implementando Servidores
15 void op_i ();
16 };
3-6 Una interfaz A se define con la operación op_a .
8-11 Una interfaz B se define con la operación op_b .
13-16 interfaz I está definido, que se deriva de A y B . También define una nueva operación
op_i .
5.2.1 Servidores Implementadores que usan Herencia
ORB ACUS para C ++ y ORB ACUS para Java admiten el uso de herencia para la interfaz
implementación. Para implementar una interfaz usando herencia, escriba un servidor
clase que hereda de una clase básica generada por el traductor IDL. Por convención,
el nombre de la clase sirviente debe ser el nombre de la interfaz con el sufijo _impl ,
por ejemplo, para una interfaz I , la clase de implementación se llama I_impl . 1
Herencia usando C ++
En C ++, I_impl debe heredar de la clase de esqueleto I_skel que fue generado por el
Traductor de IDL a C ++. Si lo hereda de otras interfaces, por ejemplo, de las interfaces
A y B , entonces I_impl también debe heredar de las clases de implementación correspondientes
A_impl y B_impl .
1 // C ++
2
3 clase A_impl: público virtual A_skel
4 {
5 público:
6 virtual void op_a ();
7 };
8
9 clase B_impl: público virtual B_skel
10 {
11 público:
12 virtual void op_b ();
13 };
14
15 clase I_impl: público virtual I_skel,
16 público virtual A_impl,
1. Estas reglas de denominación no son obligatorias, solo son una recomendación.
Objetos CORBA
68 ORBacus
17 público virtual B_impl
18 {
19 público:
20 virtual void op_i ();
21 };
3-7 Se define la clase de servidor A_impl , que hereda de la clase de esqueleto A_skel . Si op_a
tenía algún parámetro, estos parámetros se mapearían según el estándar IDL-to-
Reglas de mapeo de C ++ [2].
9-14 Esta es la clase de servicio para B_impl .
15-21 La clase sirviente para I_impl no solo se deriva de I_skel , sino también del servidor
clases A_impl y B_impl .
Tenga en cuenta que se debe usar la herencia pública virtual . La única situación en la que
la palabra clave virtual no es necesaria para una interfaz I que no hereda de ninguna
otra interfaz y de la que no hereda ninguna otra interfaz. Esto significa que la implementación
la clase I_impl solo hereda de la clase de esqueleto I_skel y no se implementa
la clase hereda de I_impl .
No es estrictamente necesario tener una clase de implementación para cada interfaz. Por ejemplo,
es suficiente tener solo la clase I_impl mientras I_impl implemente toda la interfaz
operaciones, incluidas las operaciones de las interfaces base:
1 // C ++
2
3 clase I_impl: público virtual I_skel
4 {
5 público:
6 virtual void op_a ();
7 virtual void op_b ();
8 virtual void op_i ();
9 };
3 Ahora I_impl solo se deriva de I_skel , pero no de las otras clases de servidores.
6-8 I_impl debe implementar todas las operaciones desde la interfaz I , así como las operaciones de todos
interfaces de las que se deriva I
Herencia usando Java
Varios archivos son generados por el traductor de IDL-to-Java de ORB ACUS para una interfaz I ,
incluso:
ORBacus 69
Implementando Servidores
• I.java , que define una interfaz I de Java que contiene métodos públicos para el
operaciones y atributos de I , y
• _IImplBase.java , que es una clase de esqueleto abstracto que sirve como clase base
para las clases de sirvientes.
A diferencia de C ++, la falta de herencia múltiple de Java actualmente hace que sea imposible
clase de servidor para heredar implementaciones de operación de otras clases de servidores. Para nuestro
interfaz I, por lo tanto, es necesario implementar todas las operaciones en una sola clase de servidores
I_impl , independientemente de si esas operaciones están definidas en I o en una interfaz de
del cual yo derivo.
1 // Java
2
3 public class I_impl extiende _IImplBase
4 {
5 public void op_a ()
6 {
7 }
8
9 public void op_b ()
10 {
11 }
12
13 public void op_i ()
14 {
15 }
16 }
3-16 Se define la clase sirviente I_impl , que implementa op_i , así como la herencia
operaciones op_a y op_b .
5.2.2 Implementando Servidores utilizando Delegación
Algunas veces no es deseable usar un enfoque basado en la herencia para implementar un
interfaz. Esto es especialmente cierto si el uso de la herencia daría lugar a una implementación
siendo incompatible con el código heredado existente. Por lo tanto, otra alternativa está disponible
para implementar servidores que no usan herencia. Una clase especial, conocida como
una clase de enlace , se puede utilizar para delegar la implementación de una interfaz a otra clase.
Objetos CORBA
70 ORBacus
Delegación usando C ++
El traductor ORB ACUS IDL-to-C ++ puede generar automáticamente una clase de enlace para una interfaz
en la forma de una clase de plantilla. Una clase de plantilla de enlace se deriva de la correspondiente
clase esqueleto y tiene el mismo nombre que el esqueleto, con el sufijo _tie agregado.
Para la interfaz I del ejemplo C ++ anterior, se genera la plantilla I_skel_tie
y debe ser una instancia de una clase que implementa todas las operaciones de I . Por convención,
el nombre de esta clase debe ser el nombre de la interfaz con _impl_tie anexado. 1
En contraste con el enfoque basado en la herencia, no es necesario que la clase que implementa
I 's operaciones, es decir, I_impl_tie , puede derivar de cualquier clase esqueleto. En cambio, un
instancia de I_skel_tie delega todas las llamadas de operación a I_impl_tie , como se muestra en la
Figura
5.2.
1. Nuevamente, puedes elegir el nombre que quieras. Esto es solo una recomendación.
Figura 5.2: Jerarquía de clase para la implementación de herencia y delegación en C ++
I_skel_tie
yo
T
delegados a
I_skel
I_impl
I_impl_tie
ORBacus 71
Implementando Servidores
Aquí está nuestra definición de I_impl_tie :
1 // C ++
2
3 clase I_impl_tie
4 {
5 público:
6 virtual void op_a ();
7 virtual void op_b ();
8 virtual void op_i ();
9 };
3 I_impl_tie está definido, que no se deriva de ninguna otra clase.
6-8 I_impl_tie debe implementar todas las operaciones de I , incluidas las operaciones heredadas.
Una clase de servidor para I se puede definir utilizando la plantilla I_skel_tie :
1 // C ++
2 typedef I_skel_tie <I_impl_tie> I_impl;
2 La clase sirviente I_impl se define como una instancia de plantilla de I_skel_tie , parametrizada
con I_impl_tie.
Delegación usando Java
El traductor de ORB ACUS IDL a Java genera dos archivos adicionales para admitir la delegación basada
implementación del servidor para una interfaz I :
• IOperations.java , una interfaz que define los métodos públicos para todos los atributos y
operaciones de I , y
• _IImplBase_tie.java , la clase de enlace que hereda de _IImplBase y delegados
todas las solicitudes a una instancia de IOperations .
Para implementar nuestra clase sirviente usando la delegación, necesitamos escribir una clase que implemente
la interfaz IOperations :
1 // Java
2
3 public class I_impl_tie implementa IOperations
4 {
5 public void op_a ()
6 {
7 }
8
Objetos CORBA
72 ORBacus
9 public void op_b ()
10 {
11 }
12
13 public void op_i ()
14 {
15 }
16 }
3 La clase de servidor I_impl_tie se define para implementar la interfaz IOperations .
5-15 I_impl_tie debe implementar todas las operaciones de I , incluidas las operacionesheredadas.
La Figura 5.3 ilustra la relación entre las clases generadas por el IDL a Java
traductor y las clases de implementación de servidor.
Figura 5.3: Jerarquía de clases para la implementación de herencia y delegación en Java
_IImplBase_tie
yo
delegados a
_IImplBase
I_impl IOperations
I_impl_tie
ORBacus 73
Creando Servidores
5.3 Creando Servidores
Los servidores se crean de la misma manera tanto en C ++ como en Java: una vez que se escribe su clase de
servidor,
simplemente crea una instancia de un servidor con nuevo .
5.3.1 Creando Servidores usando C ++
Aquí se muestra cómo crear servidores usando C ++:
1 // C ++
2 I_var impl = new I_impl;
3 I_var anotherImpl = new I_impl;
2,3 Dos sirvientes, impl y anotherImpl , se crean con nueva .
En caso de que la clase sirviente se haya escrito utilizando el enfoque de delegación, un objeto de la clase
las operaciones de implementación I deben pasarse al constructor del servidor:
1 // C ++
2 I_impl_tie * impl = new I_impl_tie;
3 I_var tie = new I_skel_tie <I_impl_tie> (impl, CORBA_TRUE);
2 Se crea una nueva I_impl_tie con nueva .
3 Se crea una instancia de I_skel_tie parametrizada con I_impl_tie , tomando impl como
parámetro. Todas las llamadas de operación para empatar se delegarán a impl .
En este ejemplo, la vida útil de impl está acoplada a la duración del enlace de servidor . Es decir,
cuando se destruye el empate , se llama eliminar impl . En caso de que no quieras la vida de
impl para ser acoplado a la duración de la vinculación , por ejemplo, porque desea crear impl
en la pila y no en el montón (por lo que es ilegal llamar a eliminar en impl ), utilice la siguiente
código:
1 // C ++
2 I_impl_tie impl;
3 I_var tie = new I_skel_tie <I_impl_tie> (& impl, CORBA_FALSE);
2 Se crea una nueva I_impl_tie , esta vez en la pila, no en el montón.
3 Se crea una instancia de I_skel_tie . El CORBA_FALSE parámetro indica la corbata no llamar
eliminar en impl .
Objetos CORBA
74 ORBacus
5.3.2 Creando Servidores usando Java
Este ejemplo muestra cómo crear servidores que usan Java:
1 // Java
2 I impl = new I_impl ();
3 I anotherImpl = new I_impl ();
2,3 Dos sirvientes, impl y anotherImpl , se crean con nueva .
En caso de que la clase sirviente se haya escrito utilizando el enfoque de delegación, un objeto que
implemente
la interfaz IOperations se debe pasar al constructor del servidor:
1 // Java
2 I_impl_tie impl = new I_impl_tie ();
3 _IImplBase_tie tie = new _IImplBase_tie (impl);
2 Se crea una nueva I_impl_tie .
3 Se crea una instancia de _IImplBase_tie , tomando impl como parámetro. Toda operación
las llamadas a empate se delegarán a impl .
Cada clase de vinculación generada por el traductor de IDL a Java incluye métodos para acceder y
cambiando el objeto de implementación:
1 // Java
2
3 public class _IImplBase_tie extiende _IImplBase
4 {
5 ...
6
7 public IOperations _delegate () {...}
8
9 public void _delegate (delegado de IOperations) {...}
10
11 ...
12 }
3 La clase de enlace para la interfaz I está definida.
7 Este método devuelve el objeto delegado actual (es decir, implementación).
9Este método cambia el objeto delegado.
ORBacus 75
Conectando Servidores
5.4 Conectando Servidores
Los servidores deben estar conectados al adaptador de objeto para recibir solicitudes de los clientes.
Por lo general, esto se hace automáticamente cuando una referencia de objeto a un servidor se pasa a un
cliente como un parámetro o valor de retorno. Los servidores también están conectados implícitamente
cuando se usan en
llama a operaciones como object_to_string . Sin embargo, también es posible conectar un servidor
explícitamente.
5.4.1 Conectando Servidores usando C ++
El siguiente código muestra cómo conectar explícitamente un servidor:
1 // C ++
2 CORBA_ORB_var orb = ... // Obtener una referencia al ORB de alguna manera
3 I_var impl = new I_impl;
4 orb -> conectar (impl);
2 Para conectar un servidor, necesitamos el ORB.
3 Se crea un nuevo servidor impl .
4 El nuevo servidor está conectado al adaptador de objeto.
Un servidor también se puede desconectar del adaptador de objeto. Esto se hace con el
desconectar llamada:
1 // C ++
2 orb -> desconexión (impl);
2 El servidor impl está desconectado del adaptador de objeto. A partir de ahora, las solicitudes de
los clientes de este servidor provocarán una excepción OBJECT_NOT_EXIST .
5.4.2 Conectando Servidores usando Java
Así es como los servidores Java están explícitamente conectados al adaptador de objeto:
1 // Java
2 org.omg.CORBA.ORB orb = ... // Obtener una referencia al ORB de alguna manera
3 I impl = new I_impl ();
4 orb.connect (impl);
2 Para conectar un servidor, necesitamos el ORB.
3 Se crea un nuevo servidor impl .
Objetos CORBA
76 ORBacus
4 El nuevo servidor está conectado al adaptador de objeto.
Un servidor también se puede desconectar del adaptador de objeto. Esto se hace con el
desconectar llamada:
1 // Java
2 orb.disconnect (impl);
2 El servidor impl está desconectado del adaptador de objeto. A partir de ahora, las solicitudes de
los clientes de este servidor provocarán una excepción OBJECT_NOT_EXIST .
5.4.3 Servidores nombrados
ORB ACUS para C ++ y ORB ACUS para Java respaldan la noción de servidores nombrados, en los que
un nombre se asigna a un servidor cuando está conectado al adaptador de objeto, lo que permite que un cliente
para identificar a un sirviente por su nombre. La operación de ORB get_inet_object se usa en
del lado del cliente para resolver un servidor nombrado dentro de un servidor específico (ver "Conectarse a un
nombre")
Objetos "en la página 92).
Para los servidores con nombre, se debe proporcionar un parámetro para el nombre del servidor para
conectarse . por
ejemplo, en C ++:
// C ++
CORBA_ORB_var orb = ... // Obtener una referencia al ORB de alguna manera
orb -> connect (impl, "MyName");
Y en Java;
// Java
org.omg.CORBA.ORB orb = ... // Obtener una referencia al ORB de alguna manera
((com.ooc.CORBA.ORB) orb) .connect (impl, "MyName");
En ambos ejemplos, el servidor impl está conectado al adaptador de objeto, utilizando el nombre
"Mi nombre".
El reparto de com.ooc.CORBA.ORB es necesario porque la sobrecarga de Java de conexión
en apoyo de servidores nombrados es una extensión específica de ORB ACUS y no está disponible en
org.omg.CORBA.ORB .
El nombre asignado a un servidor debe ser único entre todos los servidores en un servidor. En caso de que
nombre ya está en uso, se genera la excepción INV_IDENT .
ORBacus 77
Objetos de fábrica
5.5 Objetos de fábrica
Es bastante común usar el patrón de diseño Factory [10] en aplicaciones CORBA. En breve,
un objeto de fábrica proporciona acceso a uno o más objetos adicionales. En aplicaciones CORBA,
un objeto de fábrica puede representar un punto focal para los clientes. En otras palabras, la referencia del
objeto
del objeto de fábrica se puede publicar en un lugar conocido, y los clientes saben
que solo necesitan obtener esta referencia de objeto para obtener acceso a otros objetos en
el sistema, lo que minimiza el número de referencias de objetos que deben publicarse.
El patrón de Fábrica se puede aplicar en una amplia variedad de situaciones, incluidas las siguientes:
• Seguridad : un cliente debe proporcionar información de seguridad antes de la fábrica
objeto permitirá que el cliente tenga acceso a otro objeto.
• Equilibrio de carga : el objeto de fábrica gestiona un conjunto de objetos, a menudo representando
un recurso limitado y los asigna a los clientes en función de alguna utilización
algoritmo.
• Polimorfismo : un objeto de fábrica permite el uso de polimorfismo al regresar
referencias de objetos a diferentes implementaciones según los criterios especificados por un
cliente.
Estos son solo algunos ejemplos de las posibles aplicaciones del patrón Factory. los
Los ejemplos enumerados anteriormente también se pueden usar en cualquier combinación, según los
requisitos.
del sistema que está siendo diseñado.
Una aplicación simple del patrón Factory, en el que se crea un nuevo objeto para cada cliente,
se ilustra a continuación. La implementación usa las siguientes definiciones de interfaz:
1 // IDL
Producto de 2 interfaces
3 {
4 void destroy ();
5 };
6
7 interfaz Fábrica
8 {
9 Producto createProduct ();
10 };
2-5 La interfaz del Producto está definida. La operación de destrucción permite a un cliente destruir el
objeto cuando ya no es necesario.
7-10 La interfaz de Factory está definida. La operación createProduct devuelve la referencia del
objeto
de un nuevo Producto .
Objetos CORBA
78 ORBacus
5.5.1 Objetos de fábrica que usan C ++
Primero, implementaremos la interfaz del Producto :
1 // C ++
2 clase Product_impl: public virtual Product_skel
3 {
4 CORBA_ORB_var orb_;
5
6 público:
7 void Product_impl (CORBA_ORB_ptr orb)
8 : orb_ (CORBA_ORB :: _ duplicado (orb))
9 {
10 }
11
12 virtual void destroy ()
13 {
14 orb_ -> desconectar (esto);
15 }
16 };
2 La clase Servant Product_impl se define como una implementación de la interfaz del Producto .
7-8 El constructor toma un parámetro ORB y lo guarda para un uso posterior.
14 La operación de destrucción desconecta el objeto del adaptador de objeto. Un efecto secundario de
desconectar el objeto es que el adaptador del objeto ya no contiene una referencia al servidor.
Si no hay otras referencias a este servidor en el servidor, entonces el servidor será
destruido. Consulte "Liberación de servidores proxy y servidores" en la página 102 para obtener más
información.
A continuación, implementaremos la fábrica:
1 // C ++
2 clase Factory_impl: public virtual Factory_skel
3 {
4 CORBA_ORB_var orb_;
5
6 público:
7 void Factory_impl (CORBA_ORB_ptr orb)
8 : orb_ (CORBA_ORB :: _ duplicado (orb))
9 {
10 }
11
12 virtuales Product_ptr createProduct ()
13 {
ORBacus 79
Objetos de fábrica
14 Product_ptr result = new Product_impl (orb_);
15 orb_ -> conectar (resultado);
16 resultado de devolución;
17 }
18 };
2 La clase Servant Factory_impl se define como una implementación de la interfaz Factory .
7-8 El constructor toma un parámetro ORB y lo guarda para un uso posterior.
14-16 La operación createProduct crea una instancia de un nuevo servidor del Producto , lo conecta
al
adaptador de objeto, y devuelve una referencia de objeto al cliente. Uso de la operación de conexión
es opcional; un objeto se conectará automáticamente si aún no se ha conectado
en el momento en que se transmite una referencia al objeto a un cliente.
Los usuarios familiarizados con otras implementaciones de CORBA pueden pensar que hay un error en el
Método createProduct porque _duplicate no se está utilizando. Sin embargo, el código es
correcto. Vea el Capítulo 7 para una discusión completa de los recuentos de referencia.
5.5.2 Objetos de fábrica que usan Java
Aquí está nuestra implementación de Java de la interfaz del Producto :
1 // Java
2 clase pública Product_impl extiende _ProductImplBase
3 {
4 org.omg.CORBA.ORB orb_;
5
6 público Product_impl (org.omg.CORBA.ORB orb)
7 {
8 orb_ = orb;
9 }
10
11 public void destroy ()
12 {
13 orb_.disconnect (esto);
14 }
15 }
2 La clase Servant Product_impl se define como una implementación de la interfaz del Producto .
13 La operación de destrucción desconecta el objeto del adaptador de objeto. Mientras no haya
otras referencias al servidor se mantienen en el servidor, el objeto será elegible para la basura
colección. Consulte "Recuento de referencias en Java" en la página 99 para obtener más información sobre la
basura.
colección de objetos de servicio.
Objetos CORBA
80 ORBacus
Aquí está nuestra implementación de la fábrica:
1 // Java
2 public class Factory_impl extiende _FactoryImplBase
3 {
4 org.omg.CORBA.ORB orb_;
5
6 público Factory_impl (org.omg.CORBA.ORB orb)
7 {
8 orb_ = orb;
9 }
10
11 público Producto createProduct ()
12 {
13 Resultado del producto = nuevo Product_impl (orb_);
14 orb_.connect (resultado);
15 resultado de devolución;
16 }
17 }
2 La clase Servant Factory_impl se define como una implementación de la interfaz Factory .
13-16 La operación createProduct crea una instancia de un nuevo servidor de Producto , lo conecta
al
adaptador de objeto, y devuelve una referencia de objeto al cliente. Al igual que en la versión de C ++, el
llamada explícita para conectarse es opcional.
5.5.3 Advertencias
En estos ejemplos simples, los objetos de fábrica no mantienen ninguna referencia al
Servidores de productos que crean; es responsabilidad del cliente asegurarse de que destruya
un objeto Producto cuando ya no es necesario. Este diseño tiene un potencial significativo para
los recursos se filtran en el servidor, ya que es muy posible que un cliente no destruya su Producto
objetos, ya sea porque el programador que escribió el cliente se olvidó de invocar destruir , o
porque el programa del cliente se colgó antes de que tuviera la oportunidad de limpiar. Debes mantener
estos problemas en mente cuando diseñe sus propios objetos de fábrica. 1
1. Dos posibles estrategias para manejar este problema incluyen: tiempos de espera, en los que un servidor que no tiene
ha sido utilizado durante un período de tiempo se libera automáticamente; y expiración, en la cual un objeto
la referencia solo es válida por un cierto período de tiempo, después del cual un cliente debe obtener una nueva referencia.
La implementación de estas soluciones está fuera del alcance de este manual.
ORBacus 81
Obtener un servidor de una referencia
5.6 Obtener un servidor de una referencia
En algunas situaciones, puede ser necesario obtener el objeto de implementación de servidor de un
referencia de objeto (normalmente porque necesita invocar un método en la implementación del servidor)
objeto que no está disponible a través de su interfaz IDL).
En ORB ACUS , las clases de servidor se derivan de las clases de esqueleto, que se derivan de
clases de proxy (llamadas clases "stub"). Por lo tanto, puedes simplemente lanzar una referencia de objeto
a su clase de sirvientes.
5.6.1 Obteniendo un servidor usando C ++
En C ++, dynamic_cast <> se puede utilizar para obtener un puntero al servidor, como se muestra a
continuación:
1 // C ++
2
3 clase I_impl: público virtual I_skel
4 {
5 };
6
7 void foo (I_ptr ref)
8 {
9 I_impl * p = dynamic_cast <I_impl *> (ref);
10
11 si (p)
12 {
13 // La implementación para ref está en el mismo proceso
14 }
15 else
16 {
17 // La implementación para ref no está en el mismo proceso
18 }
19 }
3 Una clase de servidor para una interfaz I está definida.

Você também pode gostar