View
80
Download
0
Category
Preview:
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
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
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 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
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
ImpImpRepRepIntInt
RepRepD.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
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)
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”
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)
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
beginbeginAcción1Acción1
get_controlget_controlRegister_resourceRegister_resource
Acción2Acción2get_controlget_control
Register_resourceRegister_resourcecommitcommit
prepareprepareprepareprepare
commitcommitcommitcommit
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_cooridinator
) 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 POSClienteCliente
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)
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
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)
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)
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
Recommended