Este documento resume los conceptos clave de la programación orientada a componentes. Explica las deficiencias de la programación orientada a objetos y cómo la programación orientada a componentes extiende este paradigma permitiendo la composición tardía, reutilización e interoperabilidad de componentes. También describe modelos de componentes como COM, CORBA y JavaBeans, así como plataformas que implementan estos modelos para el desarrollo de aplicaciones basadas en componentes.

1. Raúl Monge Departamento de Informática Universidad Técnica Federico Santa María Valparaíso - Chile [email_address] 3ª Parte: Programación Orientada a Componentes

2. Contenido: Programación, Modelos y Plataformas de Componentes RM-ODP Corba de OMG Java, Java/RMI y JavaBeans de Sun DCOM de Microsoft

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

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

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

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

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

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

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

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

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

12. Servicios y Facilidades Comunicaciones remotas Servicios de Directorios Seguridad Transacciones Gestión y Administración

13. Ejemplos de Modelos y Plataformas de Componentes RM-ODP CORBA Java/RMI, JavaBeans y Enterprise Beans COM, DCOM, OLE, ActiveX

14. O pen D istributed P rocessing 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

15. O pen D istributed P rocessing 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 Corredor de servicios

16. CORBA: C ommon O bject R equest B roker A rchitecture 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

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

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

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

20. Estructura básica de un ORB Adaptador de Objetos Object Request Broker Interfaz ORB DII IDL Stub IDLSkel DSI Cliente Implementación Servidor

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

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

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

24. Arquitectura OMA Object Request Broker Servicios comunes (CORBAservices) Objetos y Aplicaciones Facilidades Verticales Facilidades Horizontales

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

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

27. Implementaciones de CORBA Existen más de 25 implementaciones de CORBA Orbix (Iona) Object Broker (Digital) Visibroker (Visigenic -Netscape) Component Broker (IBM)

28. Ejemplo de CORBA (1/4) $ idl translator.idl // fichero translator.idl interface Translator { string translate(in string frase); }; //fichero Translator.java //Generated by the OrbixWeb IDL compiler public interface Translator extends org.omg.CORBA.Object { public String translate (String frase); }

29. Ejemplo de CORBA (2/4) public class TranslatorImplementation extends _TranslatorImplBase { public String translate(String s) { ...código interno de la función... } } 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:

30. Ejemplo de CORBA (3/4) 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..."); } } El código para arrancar el servidor podría ser:

31. Ejemplo de CORBA (4/4) $ putit orbixtranslator -java orbixtranslator.class Para registrar el sirviente en el repositorio CORBA: 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])); } }

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

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

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

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

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

37. Ejemplo de Java/RMI (1/3) public interface InterfaceHello extends java.rmi.Remote { public String hello() throws java.rmi.RemoteException } Una interfaz para generar el string “Hello ...”:

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

39. 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(); } }

40. 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. RMI JDBC Servidores Aplicaciones Applets Cliente: Interfaces de usuario B.D. Almacenamiento persistente de datos

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

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

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

44. Ejemplo con JavaBeans (1/2) // fichero btranslator.java public class btranslator { public String translate(String expr) { .... la implementación iría aquí ..... } }

45. 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); } } }

46. C omponent O bject M odel Microsoft (Rogerson 1997, Box 1998) COM DCOM OLE ActiveX

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

48. 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: A partir de este concepto de interfaz, COM define un estándar binario para la invocación de funciones. COMPONENTE Interfaz Nodo ... Op1 Op2 OpN

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

50. 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(); }

51. 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 ) servidores locales ( local servers ) servidores remotos ( remote servers ) Reutilización: delegación y agregación Invocación dinámica de funciones ( IDispatch ) .dll .exe

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

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

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

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

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

57. Bibliografía S. Baker. “ CORBA Distributed Objects ”, Addison-Wesley, 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 Object-Oriented Programming ”, Addison-Wesley. 1998.

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