1 / 58

3ª Parte: Programación Orientada a Componentes

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

gyan
Download Presentation

3ª Parte: Programación Orientada a Componentes

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

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

  15. 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 • Corredor de servicios

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

  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. Cliente Implementación Servidor DII IDL Stub DSI IDLSkel Estructura básica de un ORB Adaptador de Objetos Interfaz ORB Object Request Broker

  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. Facilidades Verticales Facilidades Horizontales Arquitectura OMA Objetos y Aplicaciones Object Request Broker Servicios comunes (CORBAservices)

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

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

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

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

  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) Una interfaz para generar el string “Hello ...”: public interface InterfaceHello extends java.rmi.Remote { public String hello() throws java.rmi.RemoteException }

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

  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. Component Object Model • 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. Op1 Interfaz Nodo Op2 ... OpN COMPONENTE 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.

  49. IUnknown IOleObject IDataObject IPersistStorage IOleDocument 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:

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

More Related