Transcript CORBA
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