CORBA

Una arquitectura para integrar ambientes distribuidos y heterogéneos

Carlos Alberto OlarteJulio 2002

ContenidoEl problema de los ambientes distribuidosArquitectura OMAArquitectura CORBAObjetos de serviciosFacilidaes comunesObject BussinessResumen

El problema de los ambientes distribuidos

Un ambiente distribuido típico

Comp 1Comp 2

Comp 3

Comp 1Comp 2

Comp 3

Comp 1Comp 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 distribuidosSe logra hacer uso de las ventajas de

cada proveedor de plataformasLos componentes pueden ser

desarrollados por diferentes proveedores

Los componentes bien definidos pueden ser reutilizados

Debilidades de los ambientes distribuidosSe pierde un poco de controlLa depuración puede llegar a ser muy

complejaSin herramientas adecuadas la gestión

y administración puede salirse de las manos

Arquitectura OMA

Una solución al problema

Arquitectura OMAPropuesta por OMGSolución al problema de los ambientes

distribuidos Intenta promover un estándar para la

comunicación y construcción de componentes distribuidos

Componentes

Common Object Services

Object Request BrokerObject Request Broker

Application Obj

Common Facilities

ORBCanal de comunicación Invocaciones estáticas y dinámicasTransparencia en el lenguajeSistema autodescribibleTransparencia local / remotaSeguridad en las transaccionesMensajes polimórficos

Object ServicesAumento de la funcionalidad del ORBLos servicios que incluyen:

Nombrado Ciclo de Vida Persistencia Control de concurrencia y Transacciones Eventos Relación, Licencia, Propiedad

Common FacilitiesColecciones de componentesHorizontales

Interfaces de Usuarios Administración de la información Administración del sistema Manejo de tareas (WokFlow)

Verticales Salud, Finanzas, Telcos, etc

Application/Bussiness ObjectsObjetos propios de la aplicaciónDeben ser componentes bien definidosDeben poder ser reutilizablesDeben ser distribuibles

CORBA

Una implementación de OMA

S. K.S. K.S. K.S. K.

ORB I.ORB I.C. I. S.C. I. S.C. I. S.C. I. S.C. I. S.C. I. S.

La arquitectura

Object Request Broker CoreObject Request Broker Core

ImpImpRepRep

IntIntRepRep

D.I.D.I. Object AdapterObject Adapter

D.S.ID.S.IS.I.S.S.I.S.

ClientClient

Object Object ImplementationImplementation

ORBCanal de ComunicaciónCuenta con las características del ORB

de OMA (transparencia, seguridad, transaccionalidad, etc)

CORBA APICORBA API CORBA OACORBA OA

ORBORB

...continuaciónCDRs (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 IDLDII (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 servidorServer 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 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

BussinessObjects

ORBORB

Object ServicesObject Services

Horizontal FacilitiesHorizontal Facilities

Vertical FacilitiesVertical Facilities

Naming ServiceCómo referenciar objetos?

IOR (Interoperable Object Reference) Mediante Nombre

Mecanismo para localizar otros objetosOrganización jerárquica a partir de

contextos

... continuaciónObtiene referencias a partir de nombre

comunesSus interfaces:

NamingContext (resolve,list,bind,unbind) BindingIterator (Next_one,next_n,destroy)

... escenario

América

Sur Norte

ColombiaEcuador

ChileUSA Canada

Context Name

Objects

Trader ServiceServicio de páginas amarillas Interés de los servidores por publicar

sus servicios (competencia)Disponer de “atributos” (etiquetas) a los

componentes del sistemaBúsquedas de los objetos de acuerdo a

sus “atributos”

...arquitectura del servicio

Trader

Exporter Importer

Withdraw()register()

Search()Select()

Cliente ServiceTypeFactory

createTypecreateTypeServiceType

ServiceOfferFactory

createServiceOffercreateServiceOffer

ServiceOffer

Exporter Importer

RegistrarRegistrar

DefPropDefProp

getPropValuegetPropValue

Search/SelectSearch/Select

Life Cycle ServiceProvee operaciones para crear, copiar,

mover y eliminar objetosPermite mantener asociaciones entre

objetos que se relacionanMantiene 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

Folder A

Folder B

En

En

Event ServiceRegistrar / Desregistrar intereses en

eventosControl sobre notificaciones y eventosEl 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

ORBORB

ORBORB

ServidorServidor EventEventChannelChannel ClienteCliente

Push Push

mmm. el dólar subió

Evento: El dólar subió

ServidorServidorEventEvent

ChannelChannelClienteClienteQue pasa?

Evento: El dólar subió

Pull Pull

Transaction Service (OTS)Soporta transacciones planas o

anidadasSoporta transacciones que puedan

expandirse sobre varios ORBsPara 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

ORBORB

TransactionContext

ClienteTransaccional

ServidorTransaccional

Servidor Recuperable

InicTrans Método

Transaccional Propagación

... 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

beginbegin

Acción1Acción1get_controlget_control

Register_resourceRegister_resource

Acción2Acción2get_controlget_control

Register_resourceRegister_resource

commitcommit

prepareprepare

prepareprepare

commitcommit

commitcommit

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_cooridina

tor) TransactionalLockSet (igual al anterior) LockCoordinator (drop_locks)

Persistence and Object Databases (POS)Provee una interfaz única para múltiples

tipos de datastores

MemoriaMemoria

P.O.SP.O.S

Interfazúnica

PDS especializados

Archivos RBD ODB Otros

... continuaciónPOS 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

ClienteCliente

POMPOM

DDODDO ODMSODMS DADA

SQLDatabases ODBMs Simple

Object Stores

POs

Persistent ObjManager

PDSs

Datastores

... continuación Interfaces:

PIDFactory: Crear Persistent Object ID (create_PID_from_key,create_PID_from_string,create_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)

... ODBMSReemplazo de los RDBMS para la

tecnología de los POsCuenta 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 ServiceLos 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

QueryableCollection

Iterator

createcreate

prepareprepare

executeexecute

Get_resultGet_result

create_iteratorcreate_iterator

nextnextnextnext

Collection ServiceUnificación para el tratamiento de

colecciones (colas, pilas, listas, vectores, etc) en los objetos CORBA

Relationship ServicePermite 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 ServiceExport / import de los objetosAlternativa para la persistenciaPermite portar objetos entre ORBs no

conectadosConjunto de interfaces para hacer

streams (read, write) a partir de los objetos

...continuaciónAlmacenamieto y recuperación de

objetos relacionados (RelationShip Service) y conjuntos de ellos (context)

Formato de almacenamiento universal entre ORBs

Cliente Stream

WriteKey

Streamable

Write_to_Write_to_streamstream Write_ObjectWrite_Object

StreamIO

Write primitivesWrite primitives

Write GraphWrite Graph

Node

Ext_nodeExt_node

W_primW_prim

W_ObjW_Obj

W_GraphW_Graph

Role

Ext_rolExt_rol

ExternalizeExternalize (streamable)(streamable)

Licensing ServiceControl de uso sobre los componentesMedida del uso de los componentes

Property ServiceEtiquetar objetos en tiempo de

ejecuciónAdición de atributos sin regenerar IDL

Object Time ServiceComponentes:

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

Time ServiceTime Service

UTOUTO

TIOTIO

•Universal_time•newUTC•newTIO

•Absolute_time•compare_time

•overlap

Arquitectura CosTimerEvent

TimerEventServiceTimerEventService

TimerEventTimerEventHandlerHandler

TimerEventTimerEventHandlerHandler

•Register•unregister

TimerTimerEventEvent

•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 ServiceControl de versión sobre los

componentesFavorece la creación de “industrias” de

componentes

Common Facilities

Frameworks para ayudar a la contstrucción de Object Bussiness

Visión OMA

BussinessObjects

ORBORB

Object ServicesObject Services

Horizontal FacilitiesHorizontal Facilities

Vertical FacilitiesVertical Facilities

HorizontalesUser 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ónSystem 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ónTask 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 FacilitiesControl de imágenes (manejos de tipos

BLOB)Facturación, monitoreo de componentes

para el comercio electrónicoComputer Integrated Manufacturing (CIM)

- control de procesos, trazabilidad, aseguramiento de la calidad

... continuaciónSimulaciones 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

BussinessObjects

ORBORB

Object ServicesObject Services

Horizontal FacilitiesHorizontal Facilities

Vertical FacilitiesVertical Facilities

Bussiness ObjectsDeben ser reutilizables (bien definidos)Objetos tal cual como se ven en la

realidadDefinidos por interfaces IDL Interacción trasparente con ayuda de los

servicios CORBAFlexibles (no atados a un sistema

monolítico)

...continuaciónDeben ser libres del contexto

(utilizables en diferentes situaciones)

Modelo de ObjetosBussiness 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 entornoPresentation 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)

ResumenOMA 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