Download componentes - Departamento de Lenguajes y Ciencias de la

3ª Parte:
Programación Orientada a
Componentes
Raúl Monge
Departamento de Informática
Universidad Técnica Federico Santa María
Valparaíso - Chile
rmonge@inf.utfsm.l
Contenido:
Programación, Modelos y Plataformas de
Componentes
 RM-ODP
 Corba de OMG
 Java, Java/RMI y JavaBeans de Sun
 DCOM de Microsoft

2
Programación de
Sistemas Abiertos y Distribuidos

Deficiencias de la Programación Orientada a
Objetos (POO):
 No permite separar aspectos computacionales de
los composicionales
 Dificultad a la hora de reutilizar objetos
 No incorpora aspectos de mercadotecnia:
 Distribución
 Empaquetamiento
 Adquisición o composición tardía de
3
componentes
Programación de
Sistemas Abiertos y Distribuidos

Programación Orientada a Componentes:
 “Extensión” de la POO
 Sistemas Abiertos y Distribuidos
 Basada en la noción de COMPONENTE
Unidad de composición de aplicaciones software que posee un
conjunto de requisitos, y que ha de poder ser desarrollado,
adquirido, incorporado al sistema y compuesto con otros
componentes, de forma independiente en tiempo y espacio.
Szyperski, 1998
4
Programación Orientada a
Componentes (POC)








Composición tardía
Entornos (de diseño y de ejecución)
Eventos y comunicaciones asíncronas
Reutilización
Interfaces y contratos
Polimorfismo (subtipos, paramétrico, acotado)
Seguridad (a nivel de tipos y de módulos)
Reflexión
5
Problemas Típicos de POC
Clarividencia
 Evolución de componentes
 Percepción del entorno
 Particularización
 Falta de soporte formal
 Asincronía y carreras de eventos
 Interoperabilidad

6
Modelos de Componentes
Definen la forma de las interfaces de sus
componentes
 Determinan los mecanismos de composición y
comunicación entre ellos
 Especifican la forma en la que se proveen los
servicios (seguridad, trading, etc.)
 Ejemplos: COM, JavaBeans, CORBA

7
Plataformas de Componentes
Basadas en un modelo concreto
 Ofrecen una implementación de los conceptos y
mecanismos del modelo
 Proporcionan entornos de desarrollo y ejecución
para los componentes
 Suelen ofrecer pasarelas a otros modelos y
plataformas
 Ejemplos: ActiveX/OLE, Enterprise Beans, Orbix

8
Componentes e Interfaces



Interfaces:
 atributos,
 métodos y
 eventos
Lenguajes de definición de Interafaces (IDL)
Interacción entre componentes
 RPCs para los métodos
 Publish-and-subscribe para los eventos
 Mensajes asíncronos
9
Plataformas de Componentes
Distribuidas
Componentes e Interfaces
 Contenedores de componentes
 Meta-información
 Inspección
 Reflexión e introspección
 Entornos de Desarrollo Integrados (IDE)
 Servicios y facilidades

10
Entornos de Desarrollo
Integrados (IDE)







paletas
lienzo o contenedor
editores para configurar y especializar componentes
browsers
repositorio de componentes
acceso a intérpretes, compiladores y depuradores
herramientas de control y gestión de proyectos
11
Servicios y Facilidades
Comunicaciones remotas
 Servicios de Directorios
 Seguridad
 Transacciones
 Gestión y Administración

12
Ejemplos de Modelos y
Plataformas de Componentes




RM-ODP
CORBA
Java/RMI, JavaBeans y Enterprise Beans
COM, DCOM, OLE, ActiveX
13
Open Distributed Processing


RM-ODP: Modelo de referencia para el diseño de
sistemas abiertos y distribuidos
Objetivo: hacer transparente al usuario la
heterogeneidad del:
 hardware
 sistemas operativos
 redes
 lenguajes de programación
 bases de datos
 tipos de gestión
14
Open Distributed Processing


RM-ODP se divide en:
 Descripción general y recomendaciones de uso
 Modelo descriptivo
 Modelo prescriptivo
 Semántica arquitectónica
Conceptos fundamentales:
 Transparencia
 Perspectivas: empresa, información, computacional,
ingeniería, tecnológico
 Funciones y servicios comunes
15
 Corredor de servicios
CORBA:
Common Object Request Broker Architecture



OMG: Object Management Group (1989)
 Definición de estándares para permitir
interoperabilidad y portabilidad
OMA: Object Management Architecture
ORB: Object Request Broker (bus de objetos):
 Bus de datos para la comunicación entre objetos
 Transparencia de la heterogeneidad, dispersión y
activación de objetos en sistemas abiertos y
distribuidos
16
CORBA 1.1



Primera versión de CORBA (1991)
Descripción concreta de las interfaces y los servicios
que deben proporcionar los implementadores de ORBs
Elementos básicos de CORBA 1.1:
 Núcleo del ORB
 Lenguaje de Descripción de Interfaces (IDL)
 Repositorios de interfaces
 Adaptadores de objetos (OA)
17
Núcleo del ORB





Objeto como pieza fundamental
Cada objeto dispone de una referencia, y se comunica
con otros objetos mediante el ORB
Comunicación: estática y dinámica
El ORB se encarga de:
 localizar los objetos sirvientes,
 activarlos (si no lo están),
 invocar el método solicitado
 devolver el resultado al cliente
El Adaptador de Objetos (OA) se encarga de
ocultar la implementación del objeto sirviente
18
IDL de CORBA






Lenguaje textual y orientado a objetos (similar a C++) para
definir las interfaces de los objetos CORBA.
Independiente del lenguaje en que se implementan los objetos.
Soporta herencia y polimorfismo.
Los compiladores de IDLs se encargan de generar un conjunto
de módulos descritos en el lenguaje base.
Existen compiladores para los principales lenguajes:
 C, C++, Smalltalk, Java, Ada, Cobol.
Las interfaces de los objetos definidos en un ORB se registran
en repositorios (a modo de páginas amarillas).
19
Estructura básica de un ORB
Implementación
Servidor
Cliente
DII
IDL Stub
DSI
IDLSkel
Adaptador de Objetos
Interfaz ORB
Object Request Broker
20
CORBA 2.0


CORBA 2.0 (1996)
 proporciona servicios básicos para componentes
CORBA que estandarizan y complementan los COSS
(Common Object Service Specification):
 trading, naming, events, etc.
 ofrece mecanismos de interoperabilidad entre
distintas implementaciones de ORBs
Extensión de la arquitectura OMA:
 Servicios Comunes (CORBAservices)
 Facilidades Comunes (CORBAfacilities)
21
Servicios CORBA

CORBA 2.0 proporciona 15 servicios comunes:
 Acceso a las referencias de los objetos (naming)
 correduría de servicios (trading)
 localización (query)
 notificación (notification) y difusión de eventos
(events)
 transacciones (OTS)
 seguridad y confidencialidad (security)
 persistencia, concurrencia, reflexión, tiempo real, ...
22
Facilidades CORBA



Conjunto de servicios de nivel superior a los
CORBAservices. Facilitan el desarrollo de aplicaciones
CORBAfacilities horizontales (de carácter general):
 impresión (print spooling)
 gestión del sistema (system management)
 correo electrónico (e-mail), ...
CORBAfacilities verticales (para dominios específicos):
 objetos de negocio,
 comercio electrónico,
 seguros y finanzas, ...
23
Arquitectura OMA
Objetos y
Aplicaciones
Facilidades
Verticales
Facilidades
Horizontales
Object Request Broker
Servicios comunes
(CORBAservices)
24
GIOP y IIOP
GIOP (General Inter-ORB Protocol)
 Define todos los aspectos de interoperabilidad
entre distintos ORBs, independientemente del
nivel de transporte
 IIOP (Internet Inter-ORB Protocol)
 GIOP + TCP/IP
 Protocolo recomendado por OMG
 Cualquier ORB que proporcione pasarelas
IIOP cumple el estándar CORBA

25
CORBA 3.0

CORBA 3.0 (1998) añade:
 Portable Object Adapters (POAs)
 Extienden los adaptadores de objetos
básicos para soportar sirvientes multihebra,
persistentes, y permiten gestionar los
sirvientes de una aplicación.
 Invocaciones asíncronas (además de RPCs)
 Paso de objetos por valor y no sólo por
referencia
26
Implementaciones de CORBA
Existen más de 25 implementaciones de
CORBA
 Orbix (Iona)
 Object Broker (Digital)
 Visibroker (Visigenic -Netscape)
 Component Broker (IBM)

27
Ejemplo de CORBA (1/4)
// fichero translator.idl
interface Translator {
string translate(in string frase);
};
$ idl translator.idl
//fichero Translator.java
//Generated by the OrbixWeb IDL compiler
public interface Translator
extends org.omg.CORBA.Object {
public String translate (String frase);
}
28
Ejemplo de CORBA (2/4)
El fichero _TranslatorImplBase.java contendrá
el esqueleto de la implementación, invocando toda la
funcionalidad de proxies, stubs, BOAs, etc. Esta
implementación básica se puede extender:
public class TranslatorImplementation
extends _TranslatorImplBase {
public String translate(String s) {
...código interno de la función...
}
}
29
Ejemplo de CORBA (3/4)
El código para arrancar el servidor podría ser:
import IE.Iona.OrbixWeb._CORBA;
import IE.Iona.OrbixWeb.CORBA.ORB;
public class orbixtranslator {
public static void main (String args[]) {
Translator txImpl = null;
org.omg.CORBA.ORB orb =org.omg.CORBA.ORB.init();
txImpl = new TranslatorImplementation();
_CORBA.Orbix.impl_is_ready("orbixtranslator");
System.out.println("Shutting down server...");
orb.disconnect(txImpl);
System.out.println("Server exiting...");
}
30
}
Ejemplo de CORBA (4/4)
Para registrar el sirviente en el repositorio CORBA:
$ putit
orbixtranslator -java orbixtranslator.class
Código de un cliente:
import org.omg.CORBA.ORB;
import IE.Iona.OrbixWeb._CORBA;
public class Cliente {
public static void main(String args[]){
ORB.init();
String srvHost = new String (args[0]);
Translator TX =
TranslatorHelper.bind(":orbixtranslator", srvHost );
System.out.println(args[1]+"->"+TX.translate(args[1]));
}
}
31
Java/RMI, JavaBeans y
Enterprise Beans







Gran auge de Internet
Inicialmente: acceso pasivo a la información
1995: CGI (Common Gateway Interface)
1996: Uso de Java en Internet
Java como lenguaje de programación orientado a
objetos
JavaBeans: Un modelo de componentes
Diversas extensiones: Glasgow, Edinburgh,
Enterprise Beans
32
Java
Java es un lenguaje “simple, distribuido,
interpretado, robusto, seguro, independiente de
la arquitectura, portable, multihebra y dinámico”
 “Parcialmente” interpretado (bytecodes)
 Java aporta las “applets”
 Proliferación de plataformas soportando JVM
 Inclusión en los navegadores web

33
Java



La computación no sólo se realiza en el servidor, sino
que es posible que los clientes ejecuten código que
toman del servidor (applets).
La seguridad se comprueba tanto durante la carga
como la ejecución de las applets.
Paquetes de especial relevancia para aplicaciones
distribuidas:
 Empaquetamiento secuencial de objetos
(serialization)
 Acceso a base de datos (JDBC)
 Invocación remota de métodos (RMI)
34
Empaquetamiento secuencial
Objetos empaquetables como secuencias de
datos.
 Cada stream incluye la identidad del objeto, su
estado y referencias a otros objetos.
 No existen problemas con la representación de
los datos (como ocurre en otras plataformas
distribuidas), debido a la existencia de JVM.

35
Java/RMI



RMI (Remote Method Invocation) implementa un
modelo cliente-servidor donde el cliente puede invocar
de forma remota los métodos del servidor.
Extensión del concepto de RPC: los argumentos de las
funciones invocadas pueden ser objetos que son
transferidos de una máquina a otra.
RMI es un mecanismo dependiente del lenguaje (es una
extensión de Java), pero es independiente de la
plataforma (al estar basado en la máquina virtual JVM)
36
Ejemplo de Java/RMI (1/3)
Una interfaz para generar el string “Hello ...”:
public interface InterfaceHello extends java.rmi.Remote {
public String hello() throws java.rmi.RemoteException
}
37
Ejemplo de Java/RMI (2/3)
La implementación de la interfaz y el servidor:
public class ServerHello
extends UnicastRemoteObject
implements InterfaceHello {
public ServerHello() throws java.rmi.RemoteException
{super();}
public String hello() throws java.rmi.RemoteException
{return “Hello... I’m the server...”;}
public static void main(String argv[])
{ServerHello s;
Registry registry = null;
... //Código para asignar registro
try {System.setSecurityManager(new RMISecurityManager());
s = new ServerHello();
registry.rebind(“ServerHello”,s); }
catch (Exception e) { ... }
}
38
Ejemplo de Java/RMI (3/3)
El cliente:
public class ClientHello {
public static void main(String argv[])
{InterfaceHello s;
Registry registry;
try {... //Código para obtener registro
s = (InterfaceHello(registry.lookup(“ServerHello”);
System.out.println(s.hello()); }
catch (Exception e) {System.out.println(“System error”);
System.out.println(e.getMessage());
e.printStackTrace(); }
}
39
Arquitectura de 3 Niveles (3-tier)

Java no define una infraestructura de objetos
distribuidos, sino que proporciona herramientas
para su construcción y comunicación.
Applets
Cliente:
Interfaces de
usuario
RMI
Servidores
Aplicaciones
JDBC
B.D.
Almacenamiento
persistente
de datos
40
JavaBeans
JavaBeans (Sun Microsystems 1997) es un
estándar sobre Java que define el modelo de
componentes Sun.
 Beans: componentes del modelo
 Componentes software reutilizables que
pueden ser manipuladas de forma visual por
herramientas de desarrollo de aplicaciones
 Granularidad y funcionalidad de las beans
muy distintas: botón, hoja de cálculo, etc.

41
JavaBeans
Interfaz: atributos, métodos y eventos.
 Inspección: a través de las herramientas
visuales.
 Particularización: para adecuar la bean a los
requisitos del usuario o aplicación. Se realiza
mediante la configuración de ciertos parámetros.
 Persistencia: el estado de cada bean debe
almacenarse para ser restaurado con
posterioridad

42
JavaBeans




Inspección y particularización mediante la forma de
acceder a sus atributos o propiedades. Para cada
atributo X de tipo T, la bean debe soportar métodos:
 public T getX();
 public void setX(T x);
Las beans visuales heredan java.awt.Component
Persistencia mediante la secuenciación, proporcionada
gracias al paquete Serialization de Java.
Extensiones: Glasgow, Edinburgh, Enterprise Beans.
43
Ejemplo con JavaBeans (1/2)
// fichero btranslator.java
public class btranslator {
public String translate(String expr) {
.... la implementación iría aquí .....
}
}
44
Ejemplo con JavaBeans (2/2)
// fichero beanscliente.java
import java.beans.Beans;
public class beanscliente extends Beans {
public static void main (String args[]) {
btranslator TX;
String s = new String(args[1]);
ClassLoader cl = null; //system loader by default
try {
TX = (btranslator)Beans.instantiate(cl,"btranslator");
System.out.println(s+"->"+TX.translate(s));
} catch (Exception e) {
e.printStackTrace(); System.exit(1);
}
}
}
45
Component Object Model
Microsoft (Rogerson 1997, Box 1998)
 COM
 DCOM
 OLE
 ActiveX

46
COM



Modelo de componentes de Microsoft, definiendo:
 la creación de dichos componentes,
 la construcción de aplicaciones sobre ellos.
COM establece un estándar binario de interoperabilidad
entre componentes (independencia de los lenguajes y
plataformas).
COM se basa en la noción de interfaz:
 nivel conceptual: conjunto de funciones que
implementa una componente.
 nivel binario: puntero a una estructura en memoria,
compuesta por un puntero (Nodo) a un vector de
punteros a funciones (virtual table -vtable-).
47
COM

La representación binaria de un interfaz COM proviene
de la estructura interna que utiliza el compilador C++
de Microsoft para representar clases base abstractas:
Interfaz
Op1
Op2
Nodo
...
COMPONENTE

OpN
A partir de este concepto de interfaz, COM define un
estándar binario para la invocación de funciones.
48
COM



Las interfaces COM son inmutables.
Si se desea extender la funcionalidad de una interfaz se
debe definir una nueva interfaz.
Cada componente puede tener varias interfaces:
IUnknown
IOleObject
IDataObject
IPersistStorage
IOleDocument
49
COM



Toda interfaz COM posee:
 identificativo global único (IDD)
 nombre simbólico (que debe comenzar por I)
Descripción de interfaces mediante COM IDL.
Todas las componentes deben implementar una interfaz
común IUnknown:
interface IUnknown {
HRESULT QueryInterface([in] const IID id,
[out,iid_is(idd)] IUnknown iid);
unsigned long AddRef();
unsigned long Release();
}
50
COM




Creación de componentes a través de fábricas de clases
(Class Factories)
Un servidor es un objeto binario ejecutable que
empaqueta un conjunto de fábricas de clases, junto con
las implementaciones de sus componentes:
 servidores internos (in-process servers)
.dll
 servidores locales (local servers)
.exe
 servidores remotos (remote servers)
Reutilización: delegación y agregación
Invocación dinámica de funciones (IDispatch)
51
DCOM


Distributed COM: Extensión de COM para soportar
invocación remota de procedimientos entre clientes y
servidores:
 proxies (apoderados)
 stubs (juntas)
Algunos servicios adicionales:
 seguridad,
 aceleración de las operaciones remotas
 detección de fallos en las comunicaciones
 ...
52
Herramientas COM




La programación en COM es laboriosa.
El compilador MIDL genera a partir de descripciones
en COM IDL, la información necesaria para que los
componentes funcionen en un entorno COM.
Necesidad de herramientas:
 Visual C++
Aportación de servicios básicos (IDataObject):
 invocación dinámica, transferencia uniforme de
datos, etc.
53
OLE






Object Linking and Embedding
Estándar para documentos compuestos de Microsoft
OLE es una colección de interfaces que permite el
desarrollo y ejecución de documentos compuestos.
Contenedores: almacenan partes de distinta procedencia
Servidores: modelan el contenido de los documentos
La mayoría de las grandes aplicaciones de Microsoft
son contenedores y servidores a la vez:
 Word es un típico servidor, que permite la inserción
de documentos.
54
Active X



Estándar de Microsoft para sus componentes visuales,
denominados controles.
Granularidad diversa: de botones a hojas de cálculo.
Los controles pueden residir en cualquier tipo de
documento.
Active X
OCX
VBX
55
La nueva arquitectura de MS





MDCA (Microsoft Distributed Component Architecture)
Estructurado en torno a Java, COM y DCOM.
Ofrece servicios similares a los de CORBAservices.
Comunicación asíncrona basada en Microsoft Message
Queue Server.
COM+ es otra extensión de COM que resuelve algunas
deficiencias: recolección, gestión de referencias, ...
56
Bibliografía





S. Baker. “CORBA Distributed Objects”, AddisonWesley, 1997
M. Fayad, D. Schmidt, “Object-Oriented Application
Frameworks”, CACM, Vol. 40, No. 10, Octubre 1997.
Javasoft, “Using the Beans Development Kit”,
September 1997.
Roger Sessions “COM and DCOM: Micrsoft's Vision
for Distributed Objects”, John Wiley & Sons, 1998.
C. Szyperski. “Component Software. Beyond ObjectOriented Programming”, Addison-Wesley. 1998.
57
Enlaces de Interés

Columna Beyond Objects, Software Development Magazine
http://www.sdmagazine.com/features/uml/beyondobjects/

RM-ODP: Open Distributed Processing Reference Model
http://uml.fsarch.com/RM-ODP/index.html

OMG
http://www.omg.org

Douglas Schmidt: Corba Documentation
http://www.cs.wustl.edu/~schmidt/corba.html

Java Beans Spec
http://java.sun.com/products/javabeans/docs/spec.html

.NET de Microsoft
http://www.microsoft.com/net/default.asp
58