1 CORBA Una arquitectura para integrar ambientes distribuidos y heterogéneos Carlos Alberto Olarte Julio 2002

2 Contenido  El problema de los ambientes distribuidos  Arquitectura OMA  Arquitectura CORBA  Objetos de servicios  Facilidaes comunes  Object Bussiness  Resumen

3 El problema de los ambientes distribuidos

4 Un ambiente distribuido típico Comp 1Comp 2Comp 3Comp 1Comp 2Comp 3Comp 1Comp 2Comp 3

5 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

6 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

7 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

8 Arquitectura OMA Una solución al problema

9 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

10 Componentes Common Object Services Object Request Broker Application Obj Common Facilities

11 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

12 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

13 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

14 Application/Bussiness Objects  Objetos propios de la aplicación  Deben ser componentes bien definidos  Deben poder ser reutilizables  Deben ser distribuibles

15 CORBA Una implementación de OMA

16 S. K. ORB I. C. I. S. La arquitectura Object Request Broker Core ImpRep IntRep D.I. Object Adapter D.S.IS.I.S. Client ObjectImplementation

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

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

19 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

20 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); } };

21 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

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

23 ... continuación  Interfaz del ORB  APIs básicas para interactuar con el ORB en el lenguaje  Ej: To_string, to_object

24 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

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

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

27 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

28 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

29 Object Services Objetos con interfaz IDL sobre el bus del ORB

30 Visión OMA Bussiness Objects ORB Object Services Horizontal Facilities Vertical Facilities

31 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

32 ... continuación  Obtiene referencias a partir de nombre comunes  Sus interfaces:  NamingContext (resolve,list,bind,unbind)  BindingIterator (Next_one,next_n,destroy)

33 ... escenario América Sur Norte Colombia Ecuador Chile USA Canada Context Name Objects

34 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”

35 ...arquitectura del servicio Trader Exporter Importer Withdraw() register() Search() Select()

36 ClienteServiceType Factory createType ServiceType ServiceOffer Factory createServiceOffer ServiceOffer ExporterImporter Registrar DefProp getPropValue Search/Select

37 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

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

39 ...escenario Folder A Folder B En

40 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

41 ... escenario ORB ORB ServidorEventChannelCliente Push mmm. el dólar subió Evento: El dólar subió Servidor EventChannelCliente Que pasa? Evento: El dólar subió Pull

42 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

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

44 ... Escenario ORB Transaction Context Cliente Transaccional Servidor Transaccional Servidor Recuperable Inic Trans Método Transaccional Propagación

45 ... 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_....)

46 ClienteRecurso ARecurso BCurrentCoordinator begin Acción1 get_control Register_resource Acción2 get_control Register_resource commit prepare prepare commit commit

47 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)

48 Persistence and Object Databases (POS)  Provee una interfaz única para múltiples tipos de datastores Memoria P.O.S Interfaz única PDS especializados Archivos RBD ODB Otros

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

50 ... arquitectura del POS Cliente POM DDOODMSDA SQL Databases ODBMs Simple Object Stores POs Persistent Obj Manager PDSs Datastores

51 ... continuación  Interfaces:  PIDFactory: Crear Persistent Object ID (create_PID_from_key,create_PID_from_string,cr eate_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)

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

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

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

55 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)

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

57 ClienteQueryManager Query QueryableCollection Iterator create prepare execute Get_result create_iterator next next

58 Collection Service  Unificación para el tratamiento de colecciones (colas, pilas, listas, vectores, etc) en los objetos CORBA

59 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

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

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

62 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

63 ...continuación  Almacenamieto y recuperación de objetos relacionados (RelationShip Service) y conjuntos de ellos (context)  Formato de almacenamiento universal entre ORBs

64 ClienteStream WriteKey Streamable Write_to_stream Write_Object StreamIO Write primitives Write Graph Node Ext_node W_prim W_Obj W_Graph Role Ext_rol Externalize (streamable) (streamable)

65 Licensing Service  Control de uso sobre los componentes  Medida del uso de los componentes

66 Property Service  Etiquetar objetos en tiempo de ejecución  Adición de atributos sin regenerar IDL

67 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)

68 Arquitectura CosTime Time Service UTO TIO Universal_time newUTC newTIO Absolute_time compare_time overlap

69 Arquitectura CosTimerEvent TimerEventService TimerEventHandler TimerEventHandler Register unregister TimerEvent Set_timer cancel_timer status time_set

70 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)

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

72 Change Managment Service  Control de versión sobre los componentes  Favorece la creación de “industrias” de componentes

73 Common Facilities Frameworks para ayudar a la contstrucción de Object Bussiness

74 Visión OMA Bussiness Objects ORB Object Services Horizontal Facilities Vertical Facilities

75 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

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

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

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

79 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

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

81 Object Bussiness (Application Object) Componentes bien definidos y reutilizables

82 Visión OMA Bussiness Objects ORB Object Services Horizontal Facilities Vertical Facilities

83 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)

84 ...continuación  Deben ser libres del contexto (utilizables en diferentes situaciones)

85 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

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

87 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

88  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

89  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

90 FIN