PDF de programación - Introducción al modelo de componentes de CORBA: motivación y visión general

Introducción al modelo de componentes

de CORBA:

motivación y visión general

Simon Pickin

Departamento de Ingeniería Telemática

Universidad Carlos III de Madrid

Aplicaciones corporativas

Un requisito fundamental:

– gestión eficaz del almacenamiento y acceso a datos

Algunos aspectos a tratar

– SGBD
– conectividad a la BD

• BD distintas
• BD múltiples
• sistemas heredados (legacy systems)

– representación de datos

• correspondencia entre la representación del programa y la de la BD

– integridad de los datos:

• control de accesos concurrentes
• monitores de transacciones

– acceso rápido:

• cachés de datos
– control de acceso:

2004

• autenticación

Sistemas de Información

2

Modelos de componentes (I)

¿Qué es un componente?: un módulo de software:

– orientado al desarrollo de aplicaciones por ensamblaje de módulos

existentes

– que facilita la división del trabajo (responsabilidades claras)
– que se puede escoger “de la estantería”, listo para su empleo

(COTS: Components “Off-The-Shelf” ): unidad de reuso

– que se compila y despliega de manera independiente: unidad de

despliegue

Podemos requerir también:

– que pueda formar parte de una aplicación distribuida
– que sea de uso flexible ⇒ múltiples interfaces
– que se comunique de manera flexible

• comunicación síncrona por invocación de métodos
• comunicación asíncrona por canales (eventos)

2004

Sistemas de Información

3

Modelos de componentes (II)

¿Qué incluye un modelo de componentes?

– una noción de componente individual
– una definición de cómo ensamblar componentes

• conectando interfaces compatibles

– Una definición de un entorno de componentes

• es decir, un entorno de despliegue y ejecución de componentes

¿Qué proporciona un modelo de componentes?

– diseño y desarrollo por ensamblaje: reuso
– visión clara de la arquitectura de una aplicación
– separación de los aspectos funcionales y no funcionales

No cumplen las condiciones anteriores:

– modelos basados en objetos, p.e. RMI,...
– modelos basados en servicios, p.e. CORBA 2, Jini,...

2004

Sistemas de Información

4

Entornos de componentes distribuidos (I)

¿Qué es un entorno de componentes distribuidos?

– un entorno concebido para el despliegue y ejecución de aplicaciones

distribuidas basadas en componentes

¿Qué conlleva un entorno de componentes distribuidos?
– la separación de los aspectos funcionales y no funcionales
– la gestión y soporte implícitos por el entorno de ejecución (vía
perfiles estándar) de los aspectos no funcionales tales como:

transacciones (definición declarativa o vía API)

• seguridad (autenticación, autorización,...)
•
• control de concurrencia
• persistencia (gestionada por el entorno o vía API)
• gestión de ciclo de vida
• nombrado (naming), trading, búsqueda de componentes
• activación / desactivación
• protocolos de comunicación
• administración de componentes

– soporte para el despliegue

2004

Sistemas de Información

5

Entornos de componentes distribuidos (II)

G EN ESIS

Developm entCorporation

A Component in a Container

Generic Industry Model

Container

Home

Client

Component

Packaging/
Deployment
Descriptors

Container API

Transaction

Security PersistenceNotification

9/6/99

Distributed Object Bus

2004

Sistemas de Información

6

Entornos de componentes distribuidos (III)

G EN ESIS

Developm entCorporation

EJB Components and Containers Tod

EJB Container

Home

Client

EJ Bean

EJB Container API

Packaging/
Deployment
Descriptors

(XML)

CORBA
Services

Data Bases

9/6/99

ORB (IIOP/RMI)

2004

Sistemas de Información

7

Entornos de componentes distribuidos (IV)

G EN ESIS

Developm entCorporation

Microsoft Transaction Server

Client

MTS.EXE

COM

Component

No

Home

Packaging/
Deployment
Descriptors
(Proprietary

Format)

MTS API

Transaction

Monitor

ODBC

XA

9/6/99

DCOM

2004

Sistemas de Información

8

Entornos de componentes distribuidos (V)

G EN ESIS

Developm entCorporation

CORBA Components

CCM Container

Home

Client

Component

Packaging/
Deployment
Descriptors
(XMI/MOF)

CCM Container API

Transaction

Security PersistenceNotification

9/6/99

ORB/POA

2004

Sistemas de Información

9

El modelo de componentes de CORBA 3

CORBA 3: estándar del OMG de junio de 2002

– salto significativo con respecto a CORBA 2
– ¿nuevo impulso para CORBA?
– novedad más importante: CCM (modelo de componentes)
– otras mejoras: calidad de servicio, integración Internet

Fuentes de inspiración para CCM

– objetos computacionales de TINA (y de ODP)
– sobre todo, EJB (Enterprise Java Beans) de Sun
– Microsoft Transaction Server

Mercado inicial previsto para CCM (y también EJB)

– aplicaciones corporativas (enterprise applications)

2004

Sistemas de Información

10

Desde CORBA 2 . . .

Un modelo de objetos distribuidos

– heterogeneidad: OMG Interface Definition Language
– portabilidad: mapeo de IDL a distintos lenguajes estandarizado
– interoperabilidad: GIOP / IIOP
– distintos modelos de invocación: SII, DII y AMI (CORBA 2.4)
– middleware: ORB, POA, etc.; distintos perfiles

No hay facilidad de empaquetado y despliegue

Propiedades no funcionales se programan explícitamente

– ciclo de vida, (des)activación, nombres, trading, notificación,

persistencia, transacciones, seguridad, tiempo real, tolerancia a
fallos, ...

Ausencia de una visión de la arquitectura de software

2004

Sistemas de Información

11

. . . hasta el CCM de CORBA 3

Un modelo distribuido orientado a componentes

– una arquitectura para definir componentes y sus relaciones

• tanto en el lado cliente como en el lado servidor

– una tecnología de empaquetado para el despliegue de ejecutables

multi-lenguaje binarios

– Una noción de contenedor para inyectar servicios de ciclo de vida,

(des)activación, seguridad, transacciones, persistencia y eventos

– interoperabilidad con Enterprise Java Beans (EJB)

El primer estándar de componentes abierto

– CCM: multi-lenguaje, multi-SO, multi-ORB, multi-vendedor, etc.
– modelo EJB: restricción a Java
– modelo .NET: restricción a SO Microsoft

2004

Sistemas de Información

12

CCM comparado con EJB, COM y .NET

Como Enterprise Java Beans (EJB) de SUN Microsystems

– componentes CORBA creados y gestionados por homes
– ejecutan en contenedores que gestionan los servicios de sistema

de manera transparente

– alojados en servidores de componentes de aplicación

Como Component Object Model (COM) de Microsoft

– tienen varios interfaces de entrada y de salida

• tanto operaciones síncronas como eventos asíncronos

– posibilidades de navigación e introspección

Como .NET de Microsoft

– pueden escribirse en distintos lenguajes de programación
– pueden empaquetarse para distribución

2004

Sistemas de Información

13

Introducción al modelo de componentes

de CORBA:

CCM (CORBA Component Model)

Simon Pickin

Departamento de Ingeniería Telemática

Universidad Carlos III de Madrid

Indice

Introducción
Modelo abstracto
Modelo de programación
Modelo de ejecución
Modelo de despliegue
Relación / comparación CCM - EJB

2004

Sistemas de Información

15

Los cuatro modelos del CCM

Modelo abstracto

– uso de IDL3 (Interface Definition Language de CORBA 3)

Modelo de programación

– uso de CIDL (Component Implementation Definition Language)
– uso del CIF (Component Implementation Framework)
– uso de IDL2 (Interface Definition Language de CORBA 2)

Modelo de ejecución

– contenedores
– servidores de aplicaciones
Modelo de despliegue

– uso de OSD (Open Software Description)

2004

Sistemas de Información

16

Indice

Introducción
Modelo abstracto
Modelo de programación
Modelo de ejecución
Modelo de despliegue
Relación / comparación CCM - EJB

2004

Sistemas de Información

17

El modelo abstracto: visión general

Permite la definición de interfaces y propiedades de componentes
IDL3 extiende IDL2 con la descripción de

– componentes con múltiples puertos (ports) de distinta índole

•

facetas (facets): interfaces de invocación ofrecidas

– primaria: la “interfaz equivalente” / la “faceta de component”; IDL3: supports
– secundarias: las otros facetas; IDL3: provides

• receptáculos (receptacles): interfaces de invocación requeridas

– de tipo sencillo; IDL3: uses
– de tipo múltiple; IDL3: uses multiple

•

fuentes (sources): interfaces de origen de eventos:

– topología 1-n: como editor; IDL3: publishes
– topología 1-1: como emisor; IDL3: emits

• sumideros (sinks): interfaces de destino de eventos:

– IDL3: consumes
– no puede distinguir entre conexiones (emits) y suscripciones (publishes)

– interconexiones entre estos puertos
– atributos cuyos accesores/modificadores pueden lanzar excepciones

2004

Sistemas de Información

18

Modelos de componentes (III)

2004

Sistemas de Información

19

Flujos de eventos en CCM: editor / emisor

Se distinguen dos tipos de interfaz de envío por canal de

comunicación asíncrona:
– editor (publisher):

varios componentes pueden ser destino de los mensajes del canal

– emisor (emisor):

un solo componente puede ser el destino de los mensajes del canal

2004

Sistemas de Información

20

El modelo abstracto: homes

home: meta-tipo nuevo de IDL3, e.g.

home aHome manages Server {...};
home CustomerHome manages Customer primaryKey SS# {...};

Un home es un gestor de instancias de un tipo particular

– patrón de diseño: factory (fábrica), e.g.

home aHome manages Server {
};

factory mycreate(in long n)

– patrón de diseño: finder (buscador), e.g.

home aHome manages Server {
finder myop(in long m)
};

Cada home sirve para crear/