Semana 7 CORBA EPIT

2019
Una mirada al pasado que aun tiene vigencia

Una arquitectura para integrar

ambientes distribuidos y heterogéneos
Adaptado de la Universidad Javeriana de Cali
Carlos Alberto Olarte Julio 2002
CORBA tiene vigencia
https://www.microfocus.com/products/cor
ba/#
¿Para que sirve?
Contenido
 El problema de los ambientes
distribuidos
 Arquitectura OMA
 Arquitectura CORBA
 Objetos de servicios
 Facilidaes comunes
 Object Bussiness
 Resumen
El problema de los ambientes
distribuidos
Un ambiente distribuido típico

Comp 1
Comp 2
Comp 3

Comp 1
Comp 2
Comp 1 Comp 3
Comp 2
Comp 3
Complejidad de los sistemas
distribuidos
 Los datos están distribuidos
 Diferentes lenguajes
 Diferentes formatos

 La computación es distribuida
 Diferentes servidores (Plataforma y S.O)
 Diferentes clientes (Plataforma y S.O)

 Los usuarios están distribuidos

Ventajas de los ambientes
distribuidos
 Se logra hacer uso de las ventajas de
cada proveedor de plataformas
 Los componentes pueden ser
desarrollados por diferentes
proveedores
 Los componentes bien definidos
pueden ser reutilizados
Debilidades de los ambientes
distribuidos
 Se pierde un poco de control
 La depuración puede llegar a ser muy
compleja
 Sin herramientas adecuadas la gestión
y administración puede salirse de las
manos
Arquitectura OMA

Una solución al problema

Arquitectura OMA
 Propuesta por OMG
 Solución al problema de los ambientes
distribuidos
 Intenta promover un estándar para la
comunicación y construcción de
componentes distribuidos
 Common Facilities
Componentes
Application Obj

Object Request Broker

Common Object Services

ORB
 Canal de comunicación
 Invocaciones estáticas y dinámicas
 Transparencia en el lenguaje
 Sistema autodescribible
 Transparencia local / remota
 Seguridad en las transacciones
 Mensajes polimórficos
Object Services
 Aumento de la funcionalidad del ORB
 Los servicios que incluyen:
 Nombrado
 Ciclode Vida
 Persistencia
 Control de concurrencia y Transacciones
 Eventos
 Relación, Licencia, Propiedad
Common Facilities
 Colecciones de componentes
 Horizontales
 Interfacesde Usuarios
 Administración de la información
 Administración del sistema
 Manejo de tareas (WokFlow)

 Verticales
 Salud, Finanzas, Telcos, etc
Application/Bussiness Objects
 Objetospropios de la aplicación
 Deben ser componentes bien definidos
 Deben poder ser reutilizables
 Deben ser distribuibles
CORBA

Una implementación de OMA

ORB
 Canal de Comunicación
 Cuenta con las características del ORB
de OMA (transparencia, seguridad,
transaccionalidad, etc)

CORBA API CORBA OA

ORB
...continuación
 CDRs (Common Data Representation)
 Interoperabilidad entre ORBS gracias a
los protocolos
 GIOP
 IIOP

 Posibilidad de crear puentes entre

ORBs
IDL como estandarización para la
definición de los componentes
 Lenguaje puramente declarativo
 Debe describir cualquier componente que
“vive” en el ORB
 Contrato entre el cliente y el servidor
 Se puede precompilar para generar clases
en un lenguaje de alto nivel que
implemente el componente
Componentes del IDL
 Módulo module formas
{
 Interfaces exception FrmExp;
interfaz cuadrado
 Operaciones
{
 Tipos de Datos attribute long area;

 Permite herencia void dibujar()

múltiple, definición raises (FrmExp);
de arrays }
};
(secuencias) y
lanzar excepciones
Del lado del cliente
 IDL Stubs
 Definen como invocar los servicios
(estáticamente)
 Extraídos directamente del IDL

 DII (Dinamic invocation Interface)

 Descubrir los objetos (metadatos) en
tiempo de ejecución
... continuación
 Interfaz del repositorio
 Base de datos en tiempo de ejecución de
las interfaces IDL
 Permite a los componentes autodescribirse
modificando los metadatos de este
repositorio
 Provee chequeo de tipos a la invocación
de los métodos
... continuación
 Interfaz del ORB
 APIs básicas para interactuar con el ORB
en el lenguaje
 Ej: To_string, to_object
Del lado del servidor
 Server IDL Stubs (Esqueletos)
 Generados a partir del IDL
 Base para implementar el servidor

 Dinamic Skeleton Interface (DSI)

 API para ubicar el método y pasar los
parámetros dinámicamente
 Permiten hacer los puentes entre ORBs
... continuación
 Object Adapter
 Proveen el ambiente de ejecución para el
servidor (instancias de nuevos servidores)
 Proveen las referencias a los objetos y sus
Ids
 Gestionan las peticiones de los clientes a
los respectivos métodos del servidor
 Registran las clases en el repositorio
... continuación
 Implementation Repository
 Repositorio en tiempo de ejecución de las
clases soportadas por el servidor
 Incluyen trazabilidad, auditoria y funciones
administrativas
 Interfaz ORB
 Similar a la interfaz con el ORB del cliente
Invocación Dinámica Vs Estática

Estática Dinámica
 Fácil de programar  Ambiente de
 Chequeo de tipos ejecución flexible
robusto  Adición de clases
 Mejor desempeño sin recompilar el
 Auto documentada
cliente
 Util para descubrir
servicios en tiempo
de ejecución
Cómo se implementa cada una?

Estática Dinámica
 Definir el IDL  Obtener la descripción
 Precompilar el IDL del repositorio
 Implementar el Servidor  Crear la lista de
 Compilar argumentos
 Implementar el cliente  Crear el requerimiento
(haciendo invocaciones
 Invocar el requerimiento
“locales”)
 Inic el Servidor
 Hacer las invocaciones
Object Services

Objetos con interfaz IDL sobre el

bus del ORB
Visión OMA

Bussiness
Objects
Vertical Facilities

Horizontal Facilities

Object Services

ORB
Naming Service
 Cómo referenciar objetos?
 IOR(Interoperable Object Reference)
 Mediante Nombre

 Mecanismo para localizar otros objetos

 Organización jerárquica a partir de
contextos
... continuación
 Obtiene referencias a partir de nombre
comunes
 Sus interfaces:
 NamingContext (resolve,list,bind,unbind)
 BindingIterator (Next_one,next_n,destroy)
Trader Service
 Servicio de páginas amarillas
 Interés de los servidores por publicar
sus servicios (competencia)
 Disponer de “atributos” (etiquetas) a los
componentes del sistema
 Búsquedas de los objetos de acuerdo a
sus “atributos”
...arquitectura del servicio

Trader
Search()
Withdraw()
Select()
register()

Exporter Importer
Life Cycle Service
 Provee operaciones para crear, copiar,
mover y eliminar objetos
 Permite mantener asociaciones entre
objetos que se relacionan
 Mantiene la jerarquía después de
efectuar las operaciones
... continuación
 Interfaces del servicio:
 Factory Finder (find_factories)
 GenericFactory(crete_object)
 LifeCycleObject(copy,move,remove)
 Interfaces de los componentes del servicio:
 OperationFactory(create_compund_operations)
 Operations(copy,move,remove,destroy)
 Node(copy_node,move_node,remove_node)
 Role(copy_role,move_role)
 Relationship(copy_relation_ship,move_relationship)
Event Service
 Registrar / Desregistrar intereses en
eventos
 Control sobre notificaciones y eventos
 El canal de eventos soporta:
 Modelo Push: El Proveedor notifica al
canal y esta notifica a los clientes
 Modelo Pull: El Cliente hace la petición al
canal y éste intenta pregunta al servidor
 ... escenario
Evento: El mmm. el
dólar subió dólar subió
Event
Servidor Cliente
Channel
Push Push

ORB
Evento: El
dólar subió
Que pasa? Event
Cliente Servidor
Channel
Pull Pull
ORB
Transaction Service (OTS)
 Soporta transacciones planas o
anidadas
 Soporta transacciones que puedan
expandirse sobre varios ORBs
 Para volver un componente
transaccional solo debe heredar una
interfaz
 ... Escenario Servidor
Cliente Servidor Recuperable
Transaccional Transaccional

Inic
Trans Método
Transaccional Propagación

ORB

Transaction
Context
Cliente Recurso A Recurso B Current Coordinator

begin
Acción1
get_control
Register_resource
Acción2
get_control
Register_resource
commit
prepare
prepare
commit
commit
Persistence and Object
Databases (POS)
 Provee una interfaz única para múltiples
tipos de datastores
Memoria

Interfaz
única
P.O.S
PDS
especializados

Archivos RBD ODB Otros

... continuación
 POS soporta almacenamiento de 1
(SQL) y 2 niveles (ODBMs)
 Los Objetos persistentes pueden
delegar sus tareas al POS u obtener
control total sobre su persistencia
 Para el cliente es totalmente la
transparencia de la persistencia
... arquitectura del POS
Cliente
POs

Persistent Obj
POM Manager

DDO ODMS DA PDSs

Datastores

SQL Simple
ODBMs
Databases Object Stores
... ODBMS
 Reemplazo de los RDBMS para la
tecnología de los POs
 Cuenta con control de concurrencia,
candados, protección transaccional,
copias de respaldo
 Posibilidad de crear nuevos tipos de
información y estructuras
Query Service
 Los objetos proveen atributos por los
cuales se puedan consultar (sin romper
su encapsulamiento)
 El servicio de query agrupa varias
consultas y las puede filtrar
(optimizaciones)
Relationship Service
 Permite relacionar objetos dentro del
mundo entre sí
 Mejor que los punteros convencionales
porque no son unidireccionales y
permiten roles
 Navegación transparente y ágil por
medio de las relaciones
 Asociaciones en tiempo de ejecución
Licensing Service
 Controlde uso sobre los componentes
 Medida del uso de los componentes
Property Service
 Etiquetar objetos en tiempo de
ejecución
 Adición de atributos sin regenerar IDL
Object Time Service
 Componentes:
 TimeModel: Estructuras básicas para el
manejo del tiempo
 CosTime: Objetos propios del servicio
(UTO, TIO)
 CosTimeEvent: Registrar eventos
periódicos en el tiempo o en un instante
específico del mismo (modelo push de
CosEvent)
Security Service
 Proveer control de acceso (autenticación,
autorización, auditorías, encripción sobre los
componentes)
 Los esquemas son diferentes a los habituales
servicios cliente/servidor:
 Los objetos pueden ser clientes o servidores
 Solo se “ve” la punta del iceberg de los objetos
(hay muchas acciones dinámicas en tiempo de
ejecución)
Change Managment Service
 Controlde versión sobre los
componentes
 Favorece la creación de “industrias” de
componentes
Common Facilities

Frameworks para ayudar a la

contstrucción de Object Bussiness
Visión OMA

Bussiness
Objects
Vertical Facilities

Horizontal Facilities

Object Services

ORB
Horizontales
 User Interface Common Facility
 Protocolos para comunicar componentes
gráficos
 Estándares para poder disponer varios
componentes en una misma GUI
 Manejo de la geometría y aspectos
visuales
 Disponer componentes dentro de otros
componentes
...continuación
 Information Managment Facility:
 Representación de los datos
 Aspectos de seguridad y privacidad
 Complemento de la interfaz del repositorio
para conocer las interfaces de los objetos
implementados
... continuación
 System Management Facility:
 Permite recolectar información de carga
(recursos) de los componentes
 Recolección de los eventos sucedidos con un
objeto
 Seleccionar niveles de servicio de los objetos
(disponibilidad, desempeño, etc)
 Registrar, filtrar, reenviar mensajes (sobre el
servicio de eventos)
 Programar eventos sobre el CosTimeEvent
service
... continuación
 Task Management Common Facility
 Control sobre WorkFlows
 Control sobre largas transacciones

 Creación de reglas de negocio

 Creación de agentes de búsqueda de

información
Vertical Facilities
 Control de imágenes (manejos de tipos
BLOB)
 Facturación, monitoreo de
componentes para el comercio
electrónico
 Computer Integrated Manufacturing
(CIM) - control de procesos,
trazabilidad, aseguramiento de la
calidad
... continuación
 Simulaciones distribuidas (control de
tráfico, escenarios de negocios, vídeo
juegos)
 Exploraciones de gas y petróleo
(algoritmos propios para esta tarea)
 Servicios de facturación (transacciones,
cambios de moneda, ordenes de
compra, etc)
Object Bussiness (Application
Object)

Componentes bien definidos y

reutilizables
Visión OMA

Bussiness
Objects
Vertical Facilities

Horizontal Facilities

Object Services

ORB
Bussiness Objects
 Deben ser reutilizables (bien definidos)
 Objetos tal cual como se ven en la
realidad
 Definidos por interfaces IDL
 Interacción trasparente con ayuda de
los servicios CORBA
 Flexibles (no atados a un sistema
monolítico)
...continuación
 Deben ser libres del contexto
(utilizables en diferentes situaciones)
Modelo de Objetos
 Bussiness Objects:
 Encapsulan los datos, reglas del negocio
(como reaccionar a eventos)
 Implementan procesos en sí mismos

 Definen como cambiar su estado

 Bussiness Process Objects:

 Encapsulan la lógica del negocio a nivel
más general (procesos)
 Implementan procesos que involucran
varios objetos
... Continuación
 Realizan transacciones
 Definen como deben cambiar los objetos
de acuerdo al entorno
 Presentation Object
 Representación visual de los objetos
 Comunicación con los Object Bussiness
para extraer y modificar datos
 Algunos no son GUI (interfaces con otros
sistemas)
Resumen
 OMA Arquitectura para la distribución
de procesos en ambientes
heterogéneos
 CORBA una implementación de OMA
con un bus de datos bien definido para
la comunicación entre los componentes
 Objetos de servicio, extensión al bus de
comunicación proveyendo servicios de
nombrado, comercio, eventos,
seguridad, propiedades, etc
 Facilidades horizontales, una serie de
APIs con interfaces IDL que proveen
mecanismos comunes a múltiples tipos
de aplicaciones basadas en
componentes
 Facilidades verticales, marcos de
trabajo propios para tipos específicos
de aplicaciones (finanzas, salud, etc)
 Object Bussiness, componentes a
desarrollar para que sean totalmente
flexibles, bien definidos,
autodescribibles, lo mas aproximados a
la realidad y reutilizables en varios
escenarios
Cerca de 10 proyectos libres
CORBA
 JacORB
 JacORB is an object request broker written in Java, available
under the LGPL. For a complete list of details, and to download,
go to http://www.jacorb.org/ JacORB is also available for free
download at the github site https://github.com/JacORB/JacORB.
 R2CORBA

 R2CORBA is an open source CORBA implementation for the

Ruby Programming Language created by Remedy IT.

 www.corba.org/corbadownloads.htm
FIN