Corba 3j735g

!

c





c"# $% ##

Introducción 1.

¿Qué es CORBA?

2.

Características del CORBA

3.

¿Porqué usar ³Objetos distribuidos´?

Arquitectura del CORBA ORB (Object Request Broker) 1.

Descripción

2.

Componentes

IDL (Lenguaje de Definición de Interfaces) 1.

Stubs

2.

Esqueletos

Referencias 1.

Cómo hacer solicitudes a objetos CORBA

2.

Cómo obtener referencias a objetos CORBA

Adaptadores de Objetos (Objetct Adapters) 1.

Portable Object Adapter (POA)

2.

Manejadores de sirvientes

Servicios Comunes 1.

Servicio de nombres (Naming Service)

&

& CORBA: Common Object Request Broker Architecture. Arquitectura del de solicitudes de objetos CORBA es una tecnología para el manejo de objetos distribuídos Especificación de una arquitectura e interfaz que permite a una aplicación hacer solicitudes a objetos Independiente del sistema operativo, de la plataforma hardware y del lenguaje de programación Los clientes y servidores pueden residir en la misma computadora o estar distribuidos

& ß

Invocación transparente de objetos

T/IP

Cliente

Comunicación entre procesos

Objeto Llamada directa

Cliente Proceso C

Proceso A Cliente

Computador A

Proceso B

Computador B

& El ORB es el mediador entre el cliente y el servidor

Referencia de objeto

Conexión lógica

Objeto CORBA

Solicitud

ORB cliente

Flujo real

ORB servidor

de la solicitud

Aplicación cliente

Aplicación servidora

&

CORBA fue desarrollado por el OMG (Object Management Group) Una organización formada por más de 700 empresas que desarrollan, venden y utilizan software El OMG desarrolló OMA (Object Management Architecture) como estrategia fundamental para promover el uso de la tecnología orientada a objetos

& OMA: Object Management Architecture - Arquitectura para la manipulación de objetos Application objects Objetos aplicación

Common facilities Facilidades comunes

ORB (Object Request broker)

Common services Servicios comunes

& Componentes de OMA [

Objetos de aplicación (application objects). Son los programas de aplicación que intercambian información durante su ejecución

[

Servicios comunes. Son objetos que ofrecen servicios fundamentales, tales como servicios de directorio, transacciones y persistencia. Estos servicios están estandarizados para que sean interoperables

& Componentes de OMA [

Facilidades comunes. Son objetos que ofrecen servicios cuya funcionalidad responde a necesidades particulares de los dominios de aplicación

[

Object request broker (ORB). El ORB es el encargado de permitir que los demás componentes de OMA puedan interactuar

& El ORB (Object Request Broker - de Solicitudes a Objetos) es el componente central del OMA CORBA es la especificación del ORB El OMG no produce software. Los ORBs son desarrollados y distribuidos por las empresas miembro En la actualidad existen varios ORBs que se adhieren bien a las especificaciones CORBA Esto hace que las aplicaciones CORBA sean interoperables

& Objetos distribuidos La programación orientada objetos se presta de forma natural para el procesamiento distribuido Un objeto distribuido es un objeto que puede recibir solicitudes a través de la red

& ¿Por qué objetos distribuidos? Aplicación A. Supervisión remota Aplicación B. Al ser interrogada Debe interrogar a B para obtener por A lee un sensor y devuelve la lecturas de sensores lectura

]]]







]]]















& Problemas: [

La construcción, envío y decodificación de mensajes no tiene nada que ver con la aplicación propiamente dicha

[

Las operaciones dependen del protocolo de red utilizado (T-IP, IPX-SPX, etc.)

[

Son operaciones orientadas a entrada - salida

& Utilizando objetos distribuidos: Aplicación A ]]] !]

]]]

Aplicación B ]

]]] ]]] ]

La operación s.leer() es una solicitud que se hace al objeto remoto El ORB se encarga de codificar el mensaje, enviarlo a la máquina remota, decodificarlo, entregarlo a la aplicación remota y repetir el proceso a la inversa para devolver el resultado

& Las principales tecnologías de objetos distribuidos son: [

COM/DCOM (distributed component object model). Tecnología de objetos distribuidos de Microsoft, la cual está siendo sustituida por .NET.

[

.NET. Tecnología de objetos distribuidos de Microsoft, actualmente en desarrollo.

[

RMI (remote method invocation). Tecnología de objetos distribuidos de Java.

[

SOAP (simple object access protocol). Tecnología de objetos distribuidos basada en XML y http.

[

CORBA (common object request broker architecture). Tecnología de objetos distribuidos del OMG.

'

' Componentes principales de CORBA [ Clientes [ Objetos CORBA [ ORB (Object request broker - de

solicitudes a objetos)

' ß

Estructura del CORBA Cliente

Stubs IDL

Dynamic Invocation Interface

Objeto

Interfaz ORB

Dynamic skeleton interface

ORB Núcleo del ORB

IDL Skeleton

Object Adapter

' Cliente: Un ente que hace una solicitud a un objeto CORBA Servidor: Un ente capaz de recibir una solicitud de un cliente, realizar una acción (o múltiples acciones) en respuesta a dicha solicitud y devolver un resultado También recibe el nombre de Objeto, o Implementación de objeto (object implementation) Los demás componentes del diagrama constituyen el ORB



( ) ' * +

Object Request Broker solicitudes a objetos)

(

de

Función: Enviar solicitudes a objetos y devolver las respuestas a los clientes Característica más importante: transparencia

El ORB debe ocultar lo siguiente: [

Ubicación de los objetos. [

[

Implementación de objetos. [

[

El cliente no sabe cómo se ha implementado el servidor, que lenguaje fue usado, en que sistema operativo o en que plataforma de hardware está implementado

Estado del servidor. [

[

El cliente no sabe donde reside el servidor: en el mismo proceso, en la misma computadora o en diferentes computadoras conectadas en red

El cliente no sabe si el servidor está activo o no

Mecanismo de comunicación. [

El cliente no sabe que mecanismo de comunicación se está usando (T/IP, memoria compartida, llamada local, etc.)

Componentes del orb [ Núcleo del ORB (ORB core) [ IDL (lenguaje de definición de interfaces) [ Stubs IDL [ Interfaz de invocación dinámica (DII) [ Esqueletos IDL (IDL skeletons) [ Interfaz del ORB [ Object adapters

Núcleo del ORB [ Es el mediador entre los clientes y los servidores

Referencia de objeto

Conexión lógica

Objeto CORBA

Solicitud

ORB cliente

Flujo real

ORB servidor

de la solicitud

Aplicación cliente

Aplicación servidora

IDL. Lenguaje de definición de interfaces [ Un lenguaje que permite definir las interfaces

CORBA [ Interfaz CORBA: [

Un conjunto de operaciones y sus parámetros

[ Compilador IDL: toma como entrada un archivo

fuente IDL y produce como salida: 1. Stubs IDL 2. Esqueletos IDL (IDL skeletons)

IDL. Lenguaje de definición de interfaces [ El

IDL es independiente programación

del

lenguaje

de

[ Existen compiladores IDL para diversos lenguajes

de programación: C, C++, Java, Pascal, y otros [ Soporta diferentes tipos de datos, incluyendo

tipos básicos (enteros, floats, etc.), estructuras, objetos, arreglos dinámicos, strings, entre otros.



@ @ @ @ @

Archivo fuente en lenguaje IDL

@ @ @ @

Compilador IDL

Stub IDL (archivo fuente en lenguaje C++) @ @ @ @

Esqueleto IDL (archivo fuente en lenguaje C++)

Stubs IDL [ Son archivos fuente, en un lenguaje dado, que

permiten que un cliente haga solicitudes a objetos CORBA que implementan las interfaces definidas [ Son

generados automáticamente por compilador IDL a partir de interfaces CORBA

[ Los

stubs deben programas cliente

ser

incorporados

en

el los

[ Contienen el código necesario para canalizar la

solicitud al ORB

Esqueletos IDL (IDL skeletons) [ Son

archivos fuentes que se incorporan al programa que implementa el o los servidores definidos en el fuente IDL

[ Son

generados automáticamente por compilador IDL a partir de interfaces CORBA

el

[ Contienen los esqueletos (definiciones de las

clases sin la implementación de los métodos) de las interfaces CORBA

IDL. Lenguaje de definición de interfaces [ Ejemplo: _





IDL. Implementación del objeto PozoImpl: _ _ _ _!

"#$ %&'(&''(%)'(%*'(+''(&*' _

, $ $ "#





IDL. Implementación del objeto PozoImpl: _ _ _ _ - _

_ - "#

.

// $ ( // _ 0 0$ 1 1 2 $3 4 0 ,15

2

IDL. Implementación del objeto PozoImpl: // _$ 4 _& 0$ 1 1 $ 3 4 0 //, $ -. _ 2 627 ,8 9!

-. _ ,-. _9!

-. _

( , ,+

Interfaces _



: ( : : ;



Bindings o mappigns [

El IDL es independiente del lenguaje de programación utilizado para implementar las aplicaciones

[

Los mappings determinan como se ven las interfaces en distintos lenguajes de programación

[

Un mapping utiliza los recursos de cada lenguaje para poder tener a objetos CORBA

Módulos _

_



:



Ejercicio no. 1. Cree la interfaz c presentada anteriormente. Siga los siguientes pasos: 1. Utilice un editor de texto para definir la interfaz. 2. Use un compilador IDL para generar el binding correspondiente a Java de la interfaz c . 3. Edite los archivos PozoOperations.java y Pozo.java y estudie su contenido.

Tipos de datos básicos [ Tipos enteros:

1. Short/unsigned short. Enteros de 16 bits 2. long/unsigned long. Enteros de 32 bits 3. Long long/unsigned long long. Enteros de 64 bits [ Tipos de Punto flotante

1. float. IEEE std 754-1985 2. double. IEEE std 754-1985

Tipos de datos básicos [ Tipo char

Caracteres de 8 bits basados en el juego de caracteres ISO Latin-1 (8859.1). Pueden sufrir transformaciones al ser transmitidos a través del sistema de comunicación [ Tipo wchar

Caracteres de más de un byte, por ejemplo Unicode. El tamaño y el juego de caracteres no está especificado

Tipos de datos básicos [ Tipo Boolean

TRUE y FALSE. [ Tipo Octet

Una cantidad de 8 bits que no sufre ninguna conversión al ser transmitida por el sistema de communicación [ Tipo Any

Una variable de tipo any puede contener valores de cualquier otro tipo de dato

Tipos de datos complejos [ Estructuras 1. Similares a las estructuras en lenguaje C



[ Tipos enumerados 1. %

Similares al tipo enum de Pascal y C __ <

0 1 ( 1 (



Tipos de datos complejos [ Tipos definidos por el

Similar al typedef de C++

. ,

[ Arreglos

Arreglos multidimensionales. Sintaxis similar a la del lenguaje C

. "%'#

. "&'#"&'#

Tipos de datos complejos [ Secuencias

Son arreglos unidimensionales con un tamaño máximo fijo y una longitud que puede variar en tiempo de ejecución

. = > (%'? //_

. = > ? // _

Se pueden declarar secuencias de secuencias

. = > ? &

. = > = > ??

Tipos de datos complejos [ Strings

Son secuencias de caracteres con o sin límite

// @_ >%'?// _

erencia [

Una interfaz puede derivarse de otra

[

Puede haber herencia múltiple _



: ( : :

erencia : A 6

9-6



Excepciones [

CORBA permite el manejo de excepciones remotas

[

Para que una aplicación pueda lanzar una excepción, ésta debe ser declarada:

! B C

_ 0

B



Para hacer una solicitud el cliente utiliza una referencia a un objeto Cuando un nuevo objeto es creado se crea una nueva referencia Los objetos son creados en la aplicación servidora Para poder hacer una solicitud el cliente debe obtener, de alguna manera, la referencia al objeto

Inicialmente el cliente no tiene a la referencia de un nuevo objeto creado en la aplicación servidora Crear pozo

?

Aplicación cliente

Referencia

Pozo

ORB

ORB

Referencia al Pozo

Aplicación servidora

A continuación se presenta un mecanismo simple para obtener una referencia // _$ 4 _& _ 0 0$ 1 1 $ 3 4 0

Si se tiene una referencia al objeto, se puede hacer una solicitud de la siguiente manera: // D





//



// , $

Convertir una referencia a string [ Una aplicación servidora puede pedir al ORB que

convierta la referencia en un string (una cadena de caracteres) [ El string se puede almacenar en un archivo o base

de datos [ La aplicación cliente puede leer la referencia-string

del archivo y pedir al ORB que la convierta de nuevo en referencia viva

Se requiere que tanto el programa cliente como el servidor tengan a archivos comunes Por esta razón este método no puede ser usado en todos los casos

ß

Obtener una referencia desde un archivo Aplicación cliente Solicitudes

Pozo Escribir referencia

Leer referencia

... Datos.dat Pozo.ref ...

Archivos en disco

ORB

ORB

Referencia al pozo

Aplicación servidora

Escribir una referencia a un archivo // _



$

_ (

//

0

_ $ 4 _& _ 0

0 $ 1 1

// - $



0 1 1

0

// 9 , ;E

$ 4 ;E 2 2

4

Leer una referencia de un archivo // A

,

; $ 4 ;2 2 $ 4 - $ A // F _ 0

0 $

1 1

0

// , 4

$ 3 4

//

0

D

$$

-. _ 29

2

-. _! %

//



$

Ejemplo: aplicaciones cliente y servidor separadas. Servidor: _ _ _ _

0 _ _ -

-

_ - "#

.

// $ ( // $3 4 1 1 2 ,15 // _ _$ 4 _%

2

// _ 0 0$ 1 1 _

Ejemplo: aplicaciones cliente y servidor separadas. Servidor // ;E $ 4;E 2 2 4 0 1 1 0 // ,8 9!

-. _ ,-. _9!

-. _ ,9!

-. _



Ejercicio no. 2. Implemente la aplicación presentada en esta sección. Siga los siguientes pasos: 1.Agregue una nueva operación dev vercr ducci v id dev vercr ducci ut cr dCrud ut cr dGas); 2.Implemente las clases c , ervid r y Ciete presentadas en esta sección

Obtener referencias mediante una fábrica [ El cliente solicita a un objeto fábrica (factory

object) la creación de un nuevo objeto [ El objeto fábrica crea el objeto en la aplicación

servidora y devuelve una referencia al mismo [ El objeto fábrica es un objeto CORBA y se debe

implementar igual que cualquier otro objeto (no hay fábricas predefinidas) [ Para obtener una referencia de esta manera es

necesario previamente tener la referencia del objeto fábrica

ß

Obtener referencias mediante una fábrica

‘

Crear pozo

‘

Aplicación cliente

Solicitudes

Crear pozo

Referencia

ORB

ORB

Referencia

Objeto fábrica

Pozo

Aplicación servidora

Obtener una referencia al crear un objeto // D



$ $ D

Declaración IDL de una fábrica ;



Implementación de la fábrica ; _! ;

-

.

_ _$ 4 _ _ 0 0$ 1 1 _ $ 3 4 0 ,-. _9!

,8 9!



Aplicación servidora -

_ - "#

.

// . //G ; _ $ 4; _ // _ 0 0$ 1 1 // ;E $ 4;E 2 2 4 0 1 1 0 // // !

Aplicación cliente

_ - "#

.

// $ ( - $ 4 4;2 2A _ 0 0$ 1 1 0 // ; $; 3 4 0 // $$

-. _ 2A G2 -. _! % // . $ % $



Ejercicio no. 3. Implemente la clase fábrica de pozos. Siga los siguientes pasos: 1.Defina la interfaz ˜abricac s. 2.Implemente el objeto ˜abricac s . 3.Modifique las aplicaciones Ciete y ervid r para que utilicen la fábrica.

Obtener referencias mediante un servicio de nombres El cliente puede invocar un servicio de búsqueda para obtener una referencia CORBA define un servicio de nombres: Interoperable Name Service Este servicio no crea objetos, sino que almacena referencias a objetos e información asociada (nombre, propiedades) y entrega la referencia cuando se le hace la solicitud El Name Service es un objeto CORBA, de manera que para obtener una referencia mediante este servicio se requiere tener una referencia al mismo

ß

Obtener una referencia mediante un servicio de nombres Name Service

ORB

‘

Registrarse

Solicitudes

Pozo

ORB

‘

Aplicación cliente Aplicación servidora

Utilizar la operación ³resolve_initial_reference´ Se puede obtener una referencia a objetos que implementan servicios básicos mediante la operación ³resolve_initial_reference´ Esta solicitud se hace directamente al ORB. No requiere una referencia previa 0 0 $

0 $ 1 1 HB_-I

Para que el ORB pueda ³resolver referencias iniciales´ es necesario configurarlo para indicarle como localizar los servicios básicos Cada paquete CORBA tiene su propia mecanismo de configuración Por ejemplo el ORB ³JavaORB´ utiliza un archivo de configuración donde se definen las referencias iniciales de la siguiente manera:

Archivo de configuración del JavaORB ö öJ ö %& ö

ö 0 A 0 A 3 !!!!( 0 KA6J/ 6%'( L. 0 A ( &''' öB_ - B_ -3 !!!!( 0 KA6 _ / B_ /B_ ! 6%'(L.B_ &''%

(

ö . . 3 &MN( 0 KA6 _// .6%'(L.

( &'')

) c

(c ) +

) c Los adaptadores de objetos (object adapters) se ubican entre los objetos y el ORB El ORB delega en el Adaptador de objetos las operaciones de crear y destruir referencias y la activación y desactivación de objetos El primer object adapter fue el BOA - basic object adapter Posteriormente se desarrolló el POA - portable object adapter

) c ß

El object adapter se sitúa entre el ORB y el objeto

Cliente

ORB

Object adapter

Objeto CORBA

) c Inicialmente se creó el BOA (basic object adapter) El BOA estaba subespecificado Cada implementador desarrolló sus extensiones, por lo que el BOA dejó de ser interoperable En respuesta a este problema el OMG desarrolló el POA (portable object adpater) El POA está bien estandarizado y es interoperable Actualmente se recomienda usar el POA en lugar del BOA

c ) c POA: Portable Object Adapter El POA es responsable de: [ Crear referencias a objetos [ Activar objetos [ Despachar las solicitudes que se hacen a los objetos [ Desactivar objetos

c ) c ß

Mecanismo de despacho de solicitudes

Referencia de objeto

Conexión lógica

Objeto CORBA

Servant Solicitud

POA ORB cliente

Flujo real de la solicitud

ORB servidor

c ) c ß

Mecanismo de despacho de solicitudes

Aplicación servidora

Solicitudes

ORB

POA POA Manager

Servidores (servants)

c ) c Algunas definiciones Objeto CORBA. Un ente capaz de recibir solicitudes, realizar operaciones en respuesta a dichas solicitudes y devolver el resultado. Adicionalmente puede tener estado (variables internas). Los solicitudes pueden ser locales o remotas Referencia CORBA. Un bloque de datos que contiene toda la información necesaria para determinar la ubicación de un objeto y poder hacer solicitudes al mismo Clave del objeto (object key). Es una parte de la referencia de un objeto. Identifica al objeto dentro del contexto del ORB donde reside.

c ) c Algunas definiciones ID del objeto (object ID). Es una parte de la clave del objeto. El ID identifica al objeto dentro del contexto del POA que lo maneja Servant. El sirviente es el objeto en el lenguaje de implementación que realiza las operaciones solicitadas al objeto CORBA. Si dicho lenguaje no es orientado a objetos, el sirviente puede ser una estructura de datos con una serie de operaciones asociadas

c ) c Sirviente (servant) Es la unidad de ejecución que encarna al objeto CORBA. Por ejemplo, un objeto en Java o en C++ (También puede ser un proceso). Un objeto CORBA es una entidad conceptual: un ente capaz de recibir solicitudes y ... El objeto existe siempre que exista una referencia al mismo Cuando el objeto recibe una solicitud debe ser asociado con un sirviente que realice la tarea (como suelen hacer los sirvientes)

c ) c Cuando el objeto no tiene un sirviente asociado se dice que está inactivo. Cuando se le asocia un sirviente se dice que está activo Activar un objeto consiste en asociarlo a un sirviente Desactivar un objeto consiste en romper la asociación con su sirviente Un mismo sirviente puede ser asociado con varios objetos. Los sirvientes pueden destruirse cuando se desactivan los objetos o pueden permanecer Estas características permiten crear aplicaciones escalables que utilicen eficientemente los recursos de la máquina

c ) c Ejemplo. Se crea un objeto y se activa al mismo tiempo // _ _$ 4 _

.

//

_ 0 0$ 1 1 1 _ $ 3 4 0 ,-. _9!

,8 9!



c ) c La activación del objeto puede hacerse : Al momento de crear el objeto. Explícitamente, solicitando al POA que active el objeto. Cuando se reciba una solicitud estando el objeto inactivo. Cada vez que se recibe una solicitud.

c ) c

"

#

"





c ) c El POA es altamente configurable Existen diversas opciones para cada una de las responsabilidades del POA agrupadas en categorías Para manejar las diferentes categorías el POA define lo que se conoce como políticas del POA (POA policies) A continuación se describen algunas de las categorías y las políticas correspondientes

c ) c Política de unicidad del ID Determina si más de un ID de objeto puede referirse al mismo sirviente Posibles valores: UNIQUE_ID y MULTIPLE_ID Valor por defecto: UNIQUE_ID

c ) c Política de asignación del ID Determina si el ID del objeto lo asigna el programador o el POA Posibles valores: _ID y SYSTEM_ID Valor por defecto: SYSTEM_ID

c ) c Tiempo de vida Determina si los objetos son transitorios o persistentes. Es decir si los objetos están disponibles después de que el POA haya sido destruido Posibles valores: TRANSIENT y PERSISTENT Valor por defecto: TRANSIENT

c ) c Política de retención de sirvientes Determina si el POA mantiene la asociación entre el ID del objeto y el sirviente en su Mapa de Objetos Activos (Active Object Map) Posibles valores: RETAIN y NON_RETAIN Valor por defecto: RETAIN

c ) c Política de procesamiento de solicitudes Determina que debe utilizar el POA para localizar al sirviente: ß

Mapa de objetos activos

ß

Default servant

ß

Servant locator o Servant activator

Posibles valores: USE_SERVANT_MANAGER, USE_ACTIVE_OBJECT_MAP, USE_DEFAULT_SERVANT Valor por defecto: USE_ACTIVE_OBJECT_MAP

c ) c Política de hilos (threads). El POA ofrece dos opciones al momento de despachar las solicitudes a los servidores (multithreding policy): [

Las solicitudes son colocades en cola y despachadas una a la vez (modelo de un solo hilo de ejecución)

[

Cada solicitud es ejecutada en un hilo de ejecución separado

Posibles valores: ORB_CTRL_MODEL y SINGLE_TREAD_MODEL

Valor por defecto: ORB_CTRL_MODEL

c ) c Política de activación implícita Determina si el POA puede activar implícitamente al sirviente al momento de crear el ID del objeto Posibles valores: IMPLICIT_ACTIVATION Y NO_IMPLICIT_ACTIVATION Valor por defecto: NO_IMPLICIT_ACTIVATION (excepto para el rootPOA que permite IMPLICIT_ACTIVATION)

c ) c Es posible que se desee que diferentes objetos utilicen políticas diferentes Cuando se define una política a un POA la misma se aplica a todos los objetos que maneja Sin embargo, se puede crear más de un POA y cada POA puede tener un conjunto diferente de políticas

c ) c Existe un POA inicial llamado RootPOA Si no se requieren conjuntos de políticas diferentes se puede usar el RootPOA para todos los objetos Por el contrario, se pueden crear diferentes POAs y asignar políticas diferentes a cada uno

c ) c Como crear un POA // $3 4 1 1 2

2

// @ _ . "#$ 4 _ .")# "'#$ 11 _ 1 . _ .C8-91K "%#$ 1 1 .A .C9--<9B< "&#$ 1 1 1 .- .C 9<B "+#$ 1= 1 1 .= .C( 8-91-9CB<15B:9 _. $ 12_.2( ,15 (

c ) c Ejemplo. Se crea un objeto y se activa al mismo tiempo //

_ _$ 4 _

.

//

_ 0 0$ 1 1 1 _ $ 3 4 0 ,-. _9!

,8 9!



c ) c Asignación de sirvientes: Para determinar cual sirviente utilizar el POA usa una tabla denominada AOM (active object map) Cuando el objeto es activado se agrega una entrada al AOM que asocia el ID del objeto con el sirviente Cuando el objeto es desactivado se elimina la entrada del AOM Es posible configurar el POA para que, en lugar del AOM, invoque a un objeto definido por el para obtener el sirviente La política de procesamiento de solicitudes determina como se hace la asociación entre el objeto y el sirviente

c ) c Asignación de sirvientes: Es posible configurar el POA para que, en lugar del AOM, invoque a un objeto definido por el para obtener el sirviente La política de procesamiento de solicitudes determina como obtiene el POA el sirviente que va a procesar las solicitudes. Los posibles valores son: ß

USE_ACTIVE_ OBJECT_MAP

ß

USE_DEFAULT_SERVANT

ß

USE_SERVANT_MANAGER

c ) c Cuando el valor de la política es

USE_DEFAULT_SERVANT

En este caso el POA usará un único sirviente para todas las solicitudes. El programador debe señalarle al POA cual es el sirviente por defecto: _$ 4 _%// 1 // //

c ) c Cuando el valor de la política es

USE_SERVANT_MANAGER

En este caso, cuando un objeto inactivo recibe una solicitud, el POA usará un manejador de sirvientes (servant manager) para obtener el sirviente que se asignará al objeto. Manejador de sirvientes: un objeto que el POA invoca para obtener un sirviente y para destruir el siriviente en caso necesario ay dos tipos: ß

Activador de sirvientes (ServantActivator)

ß

Localizador de sirvientes (ServantLocator)

c ) c Activadores de sirvientes: Son invocados cuando se hace una solicitud a un objeto inactivo o cuando el objeto es activado explícitamente mediante una invocación al POA No son invocados cuando un objeto activo recibe solicitudes Cuando el objeto está activo y se recibe una solicitud, el POA usa el AOM para obtener el sirviente

c ) c Activadores de sirvientes: Para usar un activador de sirvientes las siguientes políticas deben estar definidas: ß

Política de procesamiento de solicitudes:



USE_SERVANT_MANAGER.

ß

Política de retención de sirvientes: RETAIN.

Además, será necesario indicarle al POA cual es el manejador de sirvientes: // _ . $ 4 1 1_ 1 ,

c ) c Localizadores de sirvientes: Son invocados cada vez que se hace una solicitud al objeto En este caso el POA no usa el AOM para localizar el sirviente en ningún momento Para usar un localizador de sirvientes las siguientes políticas deben estar definidas: Política de procesamiento de solicitudes: ß

USE_SERVANT_MANAGER.

ß

Política de retención de sirvientes: NON_RETAIN

También será necesario definir el ServantLocator: // _ . A $ 4A 1 1_ 1 ,

c ) c Ejemplo: una aplicación de objetos persistentes Se presenta una aplicación de pozos que maneja pozos persistentes Los Pozos guardan su estado en un archivo en disco Se usa un ServantActivator para obtener los sirvientes y para leer y escribir el estado de los objetos Se incluye una aplicación de creación de pozos y una aplicación de consulta que pide el ID de un Pozo e imprime los datos del mismo.

c ) c Interfaces _



: : ;



c ) c Implementación de pozos _!

- : _-

, $ -



:

: $

c ) c Implementación de pozos

.

1 1 0 1 1 1 , ,9! 9

.

;E $ 4;E 22772 2 E $ 4 E : , ,;B ; 9! ,9!

c ) c Implementación de pozos 9

.

;$ 4;22772 2 A B_ $ 4A B_ $ A : $ A ,;B ; 9! ,9!

c ) c Aplicación servidora -

_ - "#

.

// $ ( // $3 4 1 1 2 2 // =_ 0 _ . "#$ 4 _ .")# "'#$ 11 _ 1 . _ .C8-91K "%#$ 1 1 . A .C9--<9B< "+#$ 1= 1 1 . = .C8-91-9CB<15B:9 $ 1 2 2( ,15 ( // _ . $ 4 1 1_ 1 ,

c ) c Aplicación servidora // ; _$ 4; _ ( // _ 0 0$

1 1

// , ;E $ 4;E 2 2 4 0 1 1 0

,15

// // !

c ) c Implementación del manajador de sirvientes ! -

- . "# (

, 4 ; 4=

_$ 4 _ 4- 9 , . "# ( ( - ( 1 1 ( _ 1

_$ _ 9

c ) c Aplicación de crear pozos

_ - "#

.

// $ ( // - $ 4 4;2 2A _ 0 0$ 1 1 0 ; $; 3 4 0 // $$

-. _ 29 ( 2 -. _! %

c ) c Aplicación de crear pozos - _$ 4 - _-. _ A B_ $ 4A B_ // -. _ 2 62 - $A -. _ 2 D 62 $ A -. _ 2 D 62 : $ A // $ : : // , ;E $ 4;E 227722 4 0 1 1 // !

Ejercicio no. 4. Implemente la aplicación de objetos persistentes presentada en esta sección. Siga los siguientes pasos: 1.Agregue los métodos GuardarEstad y eerEstad a la clase c . 2.Implemente la clase ctivad rc s. 3.Implemente una clase Cread rc s que pida al los datos del pozo e invoque la fábrica para crear el pozo. 4.Implemente una clase C suta que pida el id del pozo, lea la refencia de un archivo cuyo nombre es el ID del pozo e imprima los datos del mismo. 5.Utilice la clase ervid r suministrada para probar la aplicación.

-

- Los servicios CORBA son una colección de interfaces y objetos que soportan funciones básicas para el uso y la implementación de objetos Estos servicios son necesarios para desarrollar cualquier aplicación y son independientes de cualquier aplicación particular Por ejemplo el servicio de nombres permite registrar referencias CORBA con un nombre y retribuir las referencias Los servicios son objetos CORBA

- Algunos de los servicios más importantes: Nombres (Naming) Notificación (Notification) Persistencia (Persistent Object) Transacciones (Transaction)

- Servicio de nombres El servicio de nombres (name service) es un directorio de objetos CORBA El servicio de nombres de CORBA permite: [ Asociar nombres con objetos CORBA (registrar un

objetos en el servicio de nombres) [ Dado el nombre de un objeto, obtener su referencia

Si se conoce el nombre con el que un objeto está registrado se puede obtener su referencia haciendo una consulta al servicio de nombres (similar a un directorio telefónico)

- Organización del servicio de nombres [ El servicio de nombres consiste en una colección

de objetos CORBA llamados VaiC text (Contexto de nombres) [ Un VaiC text es un objeto CORBA que

almacena pares (nombre, objeto), denominados bindings [ Un

VaiC text puede VaiC texts, lo cual estructuras jerárquicas o grafos

contener permite

otros crear

- ß

Servicio de nombres de CORBA Fabrica de Pozos Pozos de flujo natural

Root context Pozos de gas lift

p128 p129

Pozos BES p200

Naming contex Objetos finales

p500

- Uso del servicio de nombres Se debe ejecutar el servidor de nombres El servidor de nombres crea un contexto vacío denominado rootContext Para acceder al root context se usa la operación resolve_initial_references _ 0 $ 1 1 2B_-2 B_ ! 9! $B_ ! 9! 3 4



- Uso del servicio de nombres Para registrar un objeto en el root context (o en cualquier otro contexto) se usa la operación bid // _ - $ 1 _(

- Uso del servicio de nombres Para crear un nuevo contexto de nombres dentro de otro se usa la operación bidVewC text. // ! ! 1 41 ! 1 _2 2

Para registrar objetos dentro del contexto Pozos se puede obtener su referencia y luego usar la operación bid. // ! _ 0 0$ 1 _2 2 B_ ! 9! $B_ ! 9! 3 4 0 // 1 _2%')2(

También es posible registrar el nuevo Pozo mediante el root context: 1 _2 /%')2(

- Uso del servicio de nombres

Para resolver un nombre se usa la operación res ve. //

_

- $2%')2 _ 0 0$ 1 _2 /27 //, 4

$ 3 4

0

- Ejemplo: aplicación de pozos con servicio de nombres Se presenta una aplicación de pozos que maneja pozos persistentes La aplicación servidora guarda la referencia de la fábrica de pozos en el root context Adicionalmente crea un contexto ¨Pozos¨ donde se registrarán todos los pozos creados Se incluye una aplicación de reporte que lista el contenido del contexto ¨Pozos¨

- Ejemplo: aplicación de pozos con servicio de nombres _ _ B_ _ _ B_ B_ ! O -

_ - "#

.

// $ ( // $ 3 4 1 1 2 2 // =_ 0 _ . "#$ 4 _ .")# "'#$ 11 _ 1 . _ .C8-91K "%#$ 1 1 . A .C9--<9B< "&#$ 1 1 1 . - .C9<B

- Ejemplo: aplicación de pozos con servicio de nombres "+# $ 1= 1 1 . = .C8-91-9CB<15B:9 $ 12 2( ,15 ( // _ . $ 4 1 1_ 1 , // _ ; _$ 4; _ ( _ 0 0$ 1 1 // _ _ 0 $ 1 1 2B_-2 B_ ! 9! $B_ ! 9! 3 4 1 _2; 2( 0 // ! = G 1 41 ! 1 _2 2 ,15 //

- Ejemplo: aplicación de pozos con servicio de nombres

_ - "#

.

// $ ( // // _ _ 0 $ 1 1 2B_-2 B_ ! 9! $B_ ! 9! 3 4 _ 0 0$ 1 _2; 2 ; $; 3 4 0 // $$

-. _ 29 ( G2 -. _! %



- Ejemplo: aplicación de pozos con servicio de nombres // $$

-. _ 29 ( 2 -. _! % - _$ 4 - _-. _ A B_ $ 4A B_ // -. _ 2 62 - $A -. _ 2 D 62 $ A -. _ 2 D 62 : $ A // $ : : // _ 1 _2 /27( // !

- Ejemplo: aplicación de pozos con servicio de nombres

_ - "#

.

// $ ( // _ _ 0 $ 1 1 2B_-2 B_ ! 9! $B_ ! 9! 3 4 - _$ 4 - _-. _ A B_ $ 4A B_ -. _ 2 62 - $A



- Ejemplo: aplicación de pozos con servicio de nombres // _ _ 0 0$ 1 _2 /27 //, 4 $ 3 4

0

// $$

-. _ 29 ( 2772 ! 2 -. _! % $ : $ : -. _ 2 D 627 -. _ 2 D 627 :

- La operación list devuelve el contenido de un contexto de nombres

.

A 3 3 $ 4 A 3 3 3 $ 4 3 // '( 3 ( 3 $ 3 3 3 $ 4 3 // __ -. _ 2K 2 4, ! 1 3

$ 3 B_ _ "#$ 1 _ 0$ $ 3 4 0 -. _ 7227 7227 : ,8 9! !

-. _ !

Ejercicio no. 5. Modifique la aplicación de pozos para que, en lugar de guardar referencias en disco utilice el servicio de nombres CORBA para registrar la referencia de la fábrica de pozos y los pozos creados.

Ejercicio no. 6. Implemente una aplicación que produzca un listado de los pozos registrados en el contexto ³Pozos´ de la aplicación implementada en el ejercicio anterior.

Ejercicio no. 7. Modifique la aplicación de pozos para que incluya las interfaces PozoGasLift y PozoBES definidas en la sección 4.4. Siga los siguientes pasos: 1.Agregue a la interfaz Pozo el método stri t tri)que devuelve un string con la información del Pozo (id, tipo y producción). 2.Implemente los tipos PozoBES y PozoGasLift. 3.Defina un tipo enumerado Ti c que tenga los valores: PozoBES y PozoGasLift. 4.Modifique la fábrica de pozos para que tome como parámetro adicional el tipo de pozo requerido y cree el pozo del tipo correspondiente. 5.Modifique la aplicación de crear pozos para que pida al el tipo de pozo y cree el pozo correspondiente. 6.Modifique la aplicación de reporte para que imprima la información de los diferentes tipos de Pozo.