CORBA
Una arquitectura para integrar
ambientes distribuidos y heterogéneos
Carlos Alberto Olarte
Julio 2002
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 3
Comp 1
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
Componentes
Common Facilities
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
 Ciclo
de Vida
 Persistencia
 Control de concurrencia y Transacciones
 Eventos
 Relación, Licencia, Propiedad
Common Facilities
 Colecciones
de componentes
 Horizontales
 Interfaces
de Usuarios
 Administración de la información
 Administración del sistema
 Manejo de tareas (WokFlow)
 Verticales
 Salud,
Finanzas, Telcos, etc
Application/Bussiness Objects
 Objetos
propios de la aplicación
 Deben ser componentes bien definidos
 Deben poder ser reutilizables
 Deben ser distribuibles
CORBA
Una implementación de OMA
La arquitectura
Client
Int
Rep
C.C.I.I.S.S.
D.I. C. I. S. ORB I.
Object
Implementation
S.S.K.K.
S.I.S.
D.S.I
Object Adapter
Object Request Broker Core
Imp
Rep
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
 ESIOP
 IIOP
 Posibilidad
de crear puentes entre
ORBs y crear federaciones
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
 Interfaces
 Operaciones
 Tipos de Datos
 Permite herencia
múltiple, definición
de arrays
(secuencias) y
lanzar excepciones
module formas
{
exception FrmExp;
interfaz cuadrado
{
attribute long area;
void dibujar()
raises (FrmExp);
}
};
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
 Base
del repositorio
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
 APIs
del ORB
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
 API
Skeleton Interface (DSI)
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
 Fácil de programar
 Chequeo de tipos
robusto
 Mejor desempeño
 Auto documentada
Dinámica
 Ambiente de
ejecución flexible
 Adición de clases
sin recompilar el
cliente
 Util para descubrir
servicios en tiempo
de ejecución
Cómo se implementa cada una?
Estática
 Definir el IDL
 Precompilar el IDL
 Implementar el Servidor
 Compilar
 Implementar el cliente
(haciendo invocaciones
“locales”)
 Inic el Servidor
 Hacer las invocaciones
Dinámica
 Obtener la descripción
del repositorio
 Crear la lista de
argumentos
 Crear el requerimiento
 Invocar el requerimiento
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)
... escenario
Context Name
América
Sur
Norte
Objects
Colombia
Ecuador
Chile
USA
Canada
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
Withdraw()
register()
Exporter
Search()
Select()
Importer
Cliente
ServiceType
Factory
createType
ServiceOffer
Factory
Exporter Importer
ServiceType
ServiceOffer
createServiceOffer
Registrar
DefProp
getPropValue
Search/Select
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)
...escenario
En
Folder A
En
Folder B
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
dólar subió
Servidor
Push
Event
Channel
mmm. el
dólar subió
Cliente
Push
ORB
Que pasa?
Cliente
Pull
Event
Channel
Pull
ORB
Evento: El
dólar subió
Servidor
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
... continuación

El OTS esta compuesto de:



Un cliente transaccional que provee invocaciones
de inicio y fin de la transacción
Un servidor transaccional que es la colección de
objetos que se ven afectados por la transacción.
Estos se encargan de transmitir el contexto de la
transacción a los otros servidores
Un servidor recuperable que son objetos que
tienen recursos protegidos y su estado se ve
afectado por el commit o rollback.
... Escenario
Cliente
Transaccional
Inic
Trans
Servidor
Transaccional
Método
Transaccional
Propagación
ORB
Transaction
Context
Servidor
Recuperable
... continuación

Las interfaces involucradas:




Current – para el cliente – (begin,commit, rollback,
get_status, suspend, etc)
Coordinator: La utilizan los objetos recuperables
para participar en la transacción
Resource: Es implementada por un servidor
recuperable (prepare, commit_one_phase,
commit, rollback)
SubtransactionAwareResource: Implementable
por servidores recuperables para transacciones
anidadas (commit_subtransaction,rollback_....)
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
Concurrency Control Service

Control de candados para:



Servicios transaccionales (el servicio transaccional
debe liberarlos automáticamente)
Servicios no transaccionales, en los que el cliente
debe liberar los candados
Interfaces




LockSetFactory (create, create_relates,
create_transaccional,create_transaccional_related)
Lockset(lock,try_lock,unlock,change_mode,get_co
oridinator)
TransactionalLockSet (igual al anterior)
LockCoordinator (drop_locks)
Persistence and Object
Databases (POS)
 Provee
una interfaz única para múltiples
tipos de datastores
Memoria
Interfaz
única
P.O.S
Archivos
RBD
ODB
PDS
especializados
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
Manager
POM
DDO
ODMS
DA
PDSs
Datastores
SQL
Databases
ODBMs
Simple
Object Stores
... continuación

Interfaces:






PIDFactory: Crear Persistent Object ID
(create_PID_from_key,create_PID_from_string,cre
ate_PID_from_string_and_key)
POFactory: (create_PO)
PID: (get_PIDString)
PO: (connect,disconnect,store,restore, delete)
POM: Comunicación con los datastores (connect,
disconnect, store, restore, delete)
PDS: (connect, disconnect, store, restore, delete)
... 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
... continuación

Evita el uso de las FK para las búsquedas
haciéndolas más eficiente
 Vistas flexibles de estructuras compuestas
 Alta integración con los lenguajes de alto
nivel (OO)
 Posibilidad de crear nuevas estructuras por
medio de la herencia
 Controla el ciclo de vida de los Obj. (copy,
move, delete) manteniendo las relaciones
 Soporte a diferentes versiones de los objetos
... continuación

Provee un ODL (Object Definition Language),
que es un superconjunto del IDL para definir
colecciones, relaciones, etc independientes
del lenguaje
 Provee un OQL (Object Query Language),
que provee operaciones de Select (Upd, Ins,
Del se realizan mediante extensiones al
lenguaje de alto nivel)
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)
... continuación

Interfaces de colección:




CollectionFactory(create)
Collection(add_element,insert, replace, remove
element_at)
Iterator (reset, next)
Interfaces de consulta:




QueryManager(create)
QueryEvaluator(evaluate)
Query(prepare,execute, get_status, get_result)
QueryableCollection: Hereda de Collection y
QueryEvaluator)
Cliente QueryManager
Query
create
prepare
QueryableCollection
execute
Get_result
create_iterator
next
next
Iterator
Collection Service
 Unificación
para el tratamiento de
colecciones (colas, pilas, listas,
vectores, etc) en los objetos CORBA
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
... Continuación

Interfaces Base:






IdentifiableObject: (is_identical)
RelationshipFactory: (create)
RoleFactory: (create_role)
Relationship: (destroy)
Rol: permite la navegación (link,unlink,
get_other_rol,get_other_related_object, etc)
RelationshipIterator: Itera sobre las relaciones
adicionales a las que pertenece el rol (next_one,
next_n, destroy)
... Continuación

Las relaciones se puede ver como grafos por
medio de las siguientes interfaces:






NodeFactory: (create_node)
Node: (add_rol, remove_rol, roles_of_type)
Traversal (next_one, next_n , destroy)
Traversal_criteria (visit_node,next_one,next_n,
destroy)
Role heredado del Rol Base (get_edges)
EdgeIterator (next_one, next_n, destroy)
Externalization Service
 Export
/ import de los objetos
 Alternativa para la persistencia
 Permite portar objetos entre ORBs no
conectados
 Conjunto de interfaces para hacer
streams (read, write) a partir de los
objetos
...continuación
 Almacenamieto
y recuperación de
objetos relacionados (RelationShip
Service) y conjuntos de ellos (context)
 Formato de almacenamiento universal
entre ORBs
Cliente
Stream
Externalize
(streamable)
Streamable
StreamIO
Node
Role
WriteKey
Write_to_
stream
Write primitives
Write_Object
Write Graph
Ext_node
W_prim
W_Obj
Ext_rol
W_Graph
Licensing Service
 Control
de 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)
Arquitectura CosTime
•Absolute_time
•compare_time
UTO
TIO
Time Service
•Universal_time
•newUTC
•newTIO
•overlap
Arquitectura CosTimerEvent
TimerEvent
Handler
TimerEvent
Handler
TimerEventService
•Register
•unregister
Timer
Event
•Set_timer
•cancel_timer
•status
•time_set
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)
... continuación
 La
interacción entre los objetos no es clara
(encapsulamiento)
 Los objetos son polimórficos (es fácil
reemplazar componentes por troyanos)
 Los servidores pueden llegar a ser muchos
 Los objetos se crean y se destruyen “sin
control”
Change Managment Service
 Control
de 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
FIN
Descargar

CORBA