1 / 90

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.

haruki
Download Presentation

CORBA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Comp 1 Comp 2 Comp 3 Comp 1 Comp 2 Comp 3 Comp 1 Comp 2 Comp 3 Un ambiente distribuido típico

  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. Common Facilities Application Obj Object Request Broker Componentes Common Object Services

  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. Int Rep La arquitectura Object Implementation Client S. K. S. K. S.I.S. D.S.I C. I. S. C. I. S. Imp Rep D.I. C. I. S. ORB I. Object Adapter Object Request Broker Core

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

  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. 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 IDL como estandarización para la definición de los componentes

  20. 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); } }; Componentes del IDL

  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. 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 Invocación Dinámica Vs Estática

  28. 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 Cómo se implementa cada una?

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

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

  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 Context Name América Sur Norte Objects Colombia Chile Canada Ecuador USA

  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 Search() Select() Withdraw() register() Importer Exporter

  36. Cliente ServiceType Factory ServiceOffer Factory Exporter Importer ServiceType createType ServiceOffer createServiceOffer 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 En Folder A En Folder B

  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 Evento: El dólar subió mmm. el dólar subió Servidor Event Channel Cliente Push Push ORB Evento: El dólar subió Que pasa? Cliente Event Channel Servidor Pull Pull ORB

  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 Servidor Recuperable Cliente Transaccional Servidor Transaccional Inic Trans Método Transaccional Propagación ORB Transaction Context

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

  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_cooridinator) • TransactionalLockSet (igual al anterior) • LockCoordinator (drop_locks)

  48. Persistence and Object Databases (POS) • Provee una interfaz única para múltiples tipos de datastores Memoria Interfaz única P.O.S 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 POs Persistent Obj Manager POM DDO ODMS DA PDSs Datastores SQLDatabases Simple Object Stores ODBMs

More Related