RESUMEN EXPOSICIÓN CORBA RPC

¿QUÉ SON CORBA Y RPC?

Son tecnologías que ocultan la programación a bajo nivel de aplicaciones distribuidas. No obstante
también brindan al programador una tecnología orientada a objetos; las funciones objetos y estos
objetos pueden estar en diferentes máquinas, pero el programador accederá a ellos a través de
funciones normales dentro de su programa.

Más que especificaciones multiplataforma, también definen servicios habitualmente necesarios

como seguridad y transacciones. Y así este no es un sistema operativo en sí, en realidad es un
middleware.

CORBA

CORBA provee una infraestructura que permite la comunicación de objetos independientes de

plataforma y de implementación. Uno de los componentes garantiza la portabilidad e
interoperabilidad de objetos sobre redes de comunicaciones y sistemas heterogéneos4.

Es una especificación definida por el OMG (Object Management Group) para la creación y uso de
objetos remotos, cuyo objetivo es proporcionar interoperabilidad entre aplicaciones en un
entorno distribuido y heterogéneo. Es conocido como un tipo de “middleware”, ya que no efectúa
las funciones de bajo nivel necesarias para ser considerado un sistema operativo.

A pesar de que debe funcionar sobre sistemas operativos tradicionales, efectúa muchas de las
operaciones que tradicionalmente se han considerado del dominio de los sistemas operativos para
entornos Distribuidos.

CORBA es “Una arquitectura de negociación de petición de objetos comunes y que podrían ser
utilizadas en capas superiores de la Red de Gestión de Telecomunicaciones (RTG) influidas
fuertemente por las funciones propuestas en la industria de la información.

La gestión integrada de las redes de telecomunicación tradicionales y las redes basadas en el IP

son fundamentales para la creación de un marco de referencia que sirva para la gestión unificada
de redes de conmutación de circuitos y redes de conmutación de paquetes constitutivos para una
misma estructura”.

ARQUITECTURA DE CORBA

Para que el cliente pueda realizar una invocación sobre un objeto, se debe tener una referencia
del objeto (IOR) y conocer el tipo de objeto y la operación que desea invocar. El cliente puede
iniciar la petición a través de una conexión IDL o bien construyendo la invocación de forma
dinámica utilizando el DII. El ORB se encarga de encontrar el código de la implementación
apropiada, transmitir los parámetros y transferir el control a la Implementación de la Interfaz a
través del esqueleto IDL, o a través del esqueleto dinámico (DII) como se explica más adelante.
Arquitectura de Corba

OBJETOS CORBA

Las implementaciones de los objetos reciben las invocaciones como llamadas hacia arriba (up-call),
desde el ORB hacia la Implementación de la interfaz. La implementación de la interfaz puede elegir
un adaptador de objetos entre un conjunto de ellos, una decisión que estará basada en la clase de
servicios que pueda requerir dicha implementación.

Los objetos CORBA se diferencian de los objetos de los lenguajes habituales de programación en
que:

• Pueden estar localizados en cualquier lugar de la red.

• Pueden ejecutarse en cualquier plataforma de hardware y de sistema operativo.

• Pueden estar escritos en cualquier lenguaje.

• Pueden tener la capacidad de detectar el entorno, procesar información y además tienen la

capacidad de comunicación.

ORB DE CORBA

Componente que permite que clientes y objetos puedan comunicarse en un ambiente distribuido.
Y que contempla cada una de las interfaces que el ORB manipula.
IDL (INTERFACE DEFNITION LANGUAGE)

Para poder especificar los servicios que ofrecen los objetos que forman parte de un sistema
abierto y distribuido, se necesita contar con algún lenguaje preciso, bien definido, e independiente
de cualquier posible representación de los datos o estructuras que él define, así como la futura
implementación de los objetos que especifica. La norma ISO/IEC 14750 (ITUT X.920) define dicho
lenguaje, al que se conoce como lenguaje de definición de interfaces de ODP, u ODP IDL por su
acrónimo en inglés. Su principal objetivo es describir la signatura de los objetos que especifica, en
términos de las estructuras de datos que se manejan y el perfil de las operaciones que definen sus
servicios. De esta forma se consigue la ocultación necesaria para el desarrollo de aplicaciones
abiertas

STUB

Es el intermediario entre el cliente y el ORB. El Stub recoge del cliente llamadas a métodos y las
transmite al ORB. Se requiere una clase de stub por cada clase remota.

Además, es un componente que actúa como servidor, puede estar ejecutándose en cualquier
máquina conectada a la red que recibe peticiones por parte de clientes que pueden ser locales o
remotos. Indistintamente de ello, el cliente siempre tendrá la ilusión de que la llamada se ejecuta
localmente. En otras palabras el stub logra que el programador no se ocupe de las instrucciones de
programación remotas ya que son objetos que residen en el cliente y que representan objetos
remotos instalados en un servidor. En él se identifica: Host, puerto e identificador del objeto.
SKELETON (ESQUELETO)

Es el intermediario entre ORB y los objetos del servidor. Recibe llamadas del ORB y ejecuta los
métodos correspondientes en el servidor sobre el objeto que corresponda. Cuando el cliente
establece un objeto local (con servicio remoto), la petición se realiza por intermedio del protocolo
de comunicaciones IIOP a través del ORB. El servidor recibe la petición, busca el objeto definido
(compara el esqueleto del método en el módulo esqueleto) lo ejecuta y retorna la respuesta al
cliente.

CONCLUSIONES

CORBA proporciona una infraestructura y un modelo común desde donde los requisitos
expresados en diferentes lenguajes (las diferentes metodologías de desarrollo), pueden ser
integrados para formar un sistema globalmente consistente.

CORBA ofrece un conjunto de mecanismos muy útiles a la hora de desarrollar aplicaciones

distribuidas, junto con un soporte tecnológico suficientemente maduro como para construir
aplicaciones robustas, eficientes y competitivas, a la vez que integrables con otros sistemas que
cumplan estos estándares.

RPC

Una llamada de procedimiento remoto (RPC) consiste en un protocolo que permite a un software
o programa ejecutar código en otra máquina remota sin preocuparse por la comunicación, por lo
regular es bastante utilizado en el paradigma cliente y servidor. Existen varios tipos de RPC pero
estos son los más comunes:

ONC RPC de Sun

DCE/RPC de OSF

Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM

MODELO RPC

OBJETIVOS DE RPC

 Proporcionar un middelware que simplifique el desarrollo de aplicaciones distribuidas

 Evitar que programador tenga que interactuar directamente con el interfaz de Sockets
 Abstraer (ocultar) los detalles relativos a la red
 El Servidor ofrece procedimientos que el cliente llama como si fueran procedimientos
locales
 Se busca ofrecer un entorno de programación lo más similar posible a un entorno no
distribuido.
 El sistema RPC oculta los detalles de implementación de esas llamadas remotas
Implementa la llamada remota mediante un dialogo petición respuesta -- Mensaje de
petición: identifica procedimiento llamado, contiene parámetros de la llamada -- Mensaje
de respuesta: contiene valor/es devuelto/s se encarga de enviar/recibir mensajes para
comunicar ambas partes se encarga de gestionar los contenidos de esos mensajes
(empaquetado y formateado de datos)
DIFERENCIAS CON LLAMADAS LOCALES (LPC)

 Punto clave: manejo de errores.

 Con RPC pueden existir fallos en servidor remoto o en la red.
 Acceso a variables globales y efectos laterales en el cliente no son posible
 Procedimiento. Remoto (servidor) no tiene acceso al espacio de direcciones del cliente /
imposibilidad de usar punteros.
 RPC impone un mayor nivel de encapsulamiento
 Los parámetros para la llamada remota no pueden pasarse por referencia (solo por valor).
 Mayor sobrecarga en llamadas RPC (transferencia por red, aplanamiento de datos, etc.)
 En algunos entornos se limita el intercambio de estructuras complejas, en otros se usan
métodos de aplanado/desaplanado

EL MECANISMO DE RPC

El stub del cliente: se encarga de empaquetar los parámetros y la solicitud, enviarlos al

intermediario en el servidor, y luego esperar la respuesta, desempaquetarla y entregarla a la
aplicación.

El programa principal del servidor (que incluye el stub y el dispatcher). se encarga de recibir
peticiones, desempaquetar los parámetros, invocar la función solicitada, pasarle los parámetros,
luego obtener el resultado, empaquetarlo y enviarlo al cliente.

Las rutinas de serialización de datos: Se debe tomar en cuenta que las máquinas cliente y servidor
puedan ser de arquitectura diferente (y no compatible).

Servicio de binding: Responsable de la transparencia de localización, gestiona la asociación entre

el nombre del procedimiento remoto (y su versión) con su localización en la maquina servidor
(dirección, puertos, skeleton, etc). Realiza la búsqueda del skeleton de la implementación concreta
del procedimiento remoto llamado por un cliente.

EJEMPLOS

 portmapper en Sun-RPC
 protocolo UDDI en servicios web
 rmiregistry en Java-RMI.

CARACTERÍSTICAS DEL STUB

La base del mecanismo RPC consiste en la introducción de “representantes” que “hacen como si”
fuesen el cliente/servidor

 En el lado cliente, el representante del servidor se denomina Stub (o Proxy)

  El stub es quien proporciona transparencia en la invocación del cliente
 El stub debe poseer llamadas con la misma declaración (forma) que el servidor
 El cliente invoca las llamadas del stub “como si” fuese el servidor
 El stub, a través de un protocolo RPC y con unos mecanismos de aplanamiento, envía un
mensaje al extremo remoto solicitando la “ejecución real” de la llamada
 El stub, a través de un protocolo RPC y con unos mecanismos de desaplanamiento, recibe
un mensaje del extremo remoto y recupera el “resultado” de la invocación.
 El stub oculta los detalles de referencia del objeto remoto. Es decir, debe saber en qué
dirección IP y en qué puerto hay que contactar con el extremo remoto
 Cada procedimiento que el cliente quiera invocar a través de RPCs necesita su propio stub

CARACTERÍSTICAS DEL SKELETON

En el lado servidor, el representante del cliente se llama Skeleton

 El skeleton es quien proporciona transparencia en el lado del servidor

 El skeleton debe conocer las llamadas ofrecidas por el servidor
 El skeleton, a través de un protocolo RPC y con unos mecanismos de desaplanamiento,
recibe un mensaje del extremo remoto solicitando la “ejecución real” de la llamada
 El skeleton invoca la llamada del servidor “como si” fuese el cliente
 El skeleton, a través de un protocolo RPC y con unos mecanismos de aplanamiento, envía
un mensaje al extremo remoto indicando el “resultado” de la invocación. Cada
procedimiento que el servidor exporte a través de RPCs requiere su propio skeleton

LA INTERFAZ

La interfaz que proporciona el servidor se refiere a la “forma” de las llamadas exportadas por el
servidor Una interface es el principal acuerdo entre el componente de software y el cliente. El
lenguaje de definición de interfaces (IDL) fue desarrollado para que los objetos en lenguajes
diferentes puedan invocarse entre sí. Corba usa CORBA IDL, Sun propone XDR para su RPC, DCE
usa su IDL para RPC, Microsoft usa DCOM IDL. Un punto interesante. Es si estos IDLs exponen las
interfaces de manera tal que sean comprendidos por cualquier objeto invocante.