Universidad Nacional de San Antonio Abad del Cusco

1. Departamento Académico de Informática Universidad Nacional de San Antonio Abad del Cusco PROGRAMACION DISTRIBUIDA Iván Medrano Valencia 2005

2. Introducción • Cuando se necesitaron SI que se fueran ajustando a las necesidades de la empresa, la única solución que podían aportar los primeros sistemas, debido en gran parte al elevado costo del hardware, era una configuración en la que un único equipo gestionaba toda la información. • Los distintos puntos en los que se requería el acceso a esa información eran conectados al gran mainframe

3. Introducción (2) • Todo el código del programa y los datos residian en el computador central. Esto hacía que para empresas relativamente grandes, el SI sea muy grande y complejo, difícil de mantener. • El sistema quedaba muy poco escalable, porque todos los terminales se conectaban a un mismo computador, lo que hacía que al ir añadiendo más terminales, el servicio de las peticiones se hacía mas lento.

4. Introducción (3) Ampliaciones tan básicas como la inclusión de un segundo mainframe, llevaron a que surgieran preguntas bastante importantes y que no estaban resueltas hasta ese momento. ¿cómo reorganizar la aplicación monolítica existente si ahora se tiene dos mainframe?, ¿cómo se redistribuyen los datos de estas aplicaciones?, ¿cómo se logra que ambos computadores trabajen juntos y se distribuyan el trabajo para aprovechar realmente ambas capacidades de trabajo?.

5. Introducción (4) • De otro lado, en la parte de los usuarios, equipos cada vez más potentes podían ser instalados, lo que lleva a la pregunta razonable ¿cómo se puede conseguir que la capacidad de procesamiento de los computadores de los usuarios sea aportada a la del sistema global? • En definitiva ¿cómo distribuir la funcionalidad los datos y los recursos del SÍ de la empresa de una forma que sea escalable y flexible?

6. Introducción (5) La capacidad de procesamiento de las computadoras actuales, dotadas de conexiones a redes y de SO modernos hacen que surjan nuevas preguntas, tales como: ¿Cómo conseguir sistemas abiertos (en el sentido de que permitan la inclusión de herramientas y subsistemas de terceros de forma sencilla) que permitan integrar los sistemas de la empresa (posiblemente en diferentes tecnologías)?

7. Introducción (6) ¿cómo aprovechar los recursos proporcionados por las computadoras y los sistemas operativos de red, incluso en sistemas heterogéneos con distintas plataformas hardware y diferente sistemas operativos? ¿Cómo conseguir que la aplicación distribuya la funcionalidad entre todos los equipos de manera que maximice la productividad, capacidad de procesamiento y utilización de recursos y que ala vez permita un diseño modular, reutilizable, basado en objetos, portable, independiente de la plataforma, etc? ¿Cómo integrar el sistema informático de la empresa con Internet?

8. Cliente / Servidor La respuesta a las preguntas anteriores vino a través de la inclusión del modelo cliente/servidor que separa la funcionalidad de una aplicación en torno a dos roles muy bien definidos: cliente y servidor. De modo abstracto, el servidor ofrece una serie de servicios que pueden ser utilizados por los clientes para completar la funcionalidad de la aplicación. Una interacción básica cliente/servidor implica a un cliente que inicia una petición de algún servicio a un servidor, posiblemente incluyendo algunos parámetros que modifiquen el comportamiento del servidor. El servidor entonces realiza la función especificada por el cliente, devolviendo los posibles resultados que el servicio genera. Servidor Cliente

9. Middleware Los clientes y servidores se implementan como procesos que están ejecutando en máquinas conectadas a una red. La infraestructura que se encarga de conectar de alguna manera los procesos cliente/servidor es llamada Middleware. El término middleware engloba a todos los elementos que hacen posible esta comunicación, desde las líneas físicas de comunicación hasta los protocolos de alto nivel. El soporte estándar del desarrollo de aplicaciones distribuidas es Internet (e intranet a nivel de empresas). MIDDLEWARE CLIENTE SERVIDOR

10. Unidades funcionales de una aplicación: • Típicamente una aplicación consta de: • Una presentación, ya sea en base a un GUI o mediante una terminal de caracteres, que implemente la interacción con el usuario y realiza ciertas comprobaciones sencillas(validez de fechas, etc.)

11. Unidades funcionales de una aplicación: • Una lógica de negocio o funcionalidad, que implementa la funcionalidad de la aplicación. Esta lógica de negocio se encarga de realizar todos los procesos que son requeridos por el sistema de información. Lógica del negocio. Acceso a datos Servidor

12. Unidades funcionales de una aplicación: ·Una lógica de datos, que establece como los datos de la aplicación son estructurados, ya sea a través de bases de datos SQL, o a través de archivos de disco. Base de Datos

13. Clasificación de las aplicaciones • Cada unidad funcional se puede distribuir en un procesador especifico para gestionarla. • Tomando como base la manera en que la funcionalidad se distribuye, las aplicaciones de pueden clasificar en: • Aplicaciones de 1 nivel (1 tier) o monolíticos • Aplicaciones de 2 niveles (2 tier) • Aplicaciones de 3 niveles (3 tier) • Aplicaciones de n niveles (n tier) o distribuidos

14. Aplicaciones de 1 nivel Son aquellas en las que todas las unidades funcionales de la aplicaciones son gestionadas en un solo computador. Interfaz con el usuario Lógica del negocio Lógica de datos

15. Aplicaciones de 2 niveles Fueron el primer paso en el desarrollo de aplicaciones Cliente/servidor. Típicamente, la lógica de presentación, la de negocio y la de datos quedaban en la parte Cliente, dejando a los servidores encargados solo de guardar los datos, es decir, como servidores de bases de datos. Esta organización Cliente Servidor Presentación Lógica del negocio Acceso a datos Lógica de datos

16. Aplicaciones de 3 niveles Aquí, el cliente se encarga de mantener el interfaz gráfico del usuario mientras que existen una serie de componentes intermedios en el sistema que se encargan de implementar la lógica de la aplicación. Finalmente hay un ultimo nivel que se encarga de la lógica de datos, típicamente SGBDs. En el momento en el que los componentes de este último nivel se conviertan en clientes de otros componentes, se convierte en una estructura multinivel o distribuido. Presentación o interfaz con el usuario Lógica del negocio Lógica de datos

17. Sistema de Información Distribuido Son el último paso en el modelo cliente/servidor. En vez de diferenciar entre las distintas partes de la aplicación,los sistemas distribuidos ofrecen toda la funcionalidad en forma de objetos. No existen los roles explícitos de cliente y servidor, sino que toda la funcionalidad esta ahí para ser utilizada. Los procesos que componen la aplicación y que se están ejecutando en las distintas máquinas de la red son clientes y servidor y cooperan para conseguir la funcionalidad total de la aplicación. Esto da una máxima flexibilidad.

18. Sistema de Información Distribuido (2) En general, un sistema distribuido es un sistema cliente/servidor multinivel con un número potencialmente grande de entidades que pueden desempeñar roles de clientes y servidores según sus necesidades. El hecho de ofrecer una serie de servicios en forma de objetos hace que el diseño y desarrollo de haga en base a interfaces bien definidos que facilitan y apoyan la modularidad y reutilización, a la vez que permiten un diseño mucho mas flexible.

19. Modelo de Objetos Distribuidos • Cada proceso contiene un conjunto de objetos, algunos de los cuales pueden recibir tanto invocaciones locales como remotas, mientras que los otros objetos pueden recibir invocaciones locales. Los dos conceptos fundamentales siguientes son el corazón del modelo de objetos distribuidos. • Interfaz remota Espedifica cuales de sus métodos pueden invocarse remotamente • Referencia de objeto remoto Otros objetos pueden invocar los métodos de un objeto remoto si tienen acceso a su referencia

20. C A B E F D Invocación remota Invocación Local Modelo de Objetos Distribuidos Los objetos involucrados en una cadena de invocaciones relacionadas pueden estar ubicados en procesos o computadores diferentes. Cuando una invocación cruza los límites de un proceso o computador, se emplea invocación remota, y la referencia remota al objeto se hace disponible para hacer posible la RMI.

21. Teconologías de objetos distribuidos • Java RMI • CORBA • .NET • ICE (Internet Communication Engine)

22. RMI: Introducción • RMI -> Remote Method Invocation • Diseñado para trabajar con objetos remotos • RMI integra un modelo de objetos distribuido en Java ( Distributed Object Programming) • Diseñado específicamente para el entorno Java

23. Objetivos de Java Rmi • Semántica similar para objetos locales y remotos • Llamadas de retorno del servidor al cliente • Integración natural del modelo distribuido en el modelo Java • Preservar la seguridad y seguridad proporcionadas por el entorno de ejecución Java

24. Cliente Java RMI Registry Objeto Remoto Stub Skeleton (Descargado de la JVM remota) JVM Cliente JVM Remota Esquema de componentes Network

25. Qué es CORBA? (surge OMG) Finales años 80: se vislumbran cambios importantes en la computación: Http Ethernet ATM Html Internet Pthreads UDP Sockets Java TCP C++ RPC

26. Qué es CORBA? (surge OMG) Grandes compañías intentan conseguir el mercado Microsoft HP Sun IBM Oracle Abril de 1989: se funda la Object Management Group (800 empresas)

27. Qué es CORBA?: 1º factor clave Interface Definition Languaje (IDL) C++ Smalltalk Implementación oculta por un interfaz Java OLE (Visual Basic, Delphi, Builder) Ada Vista de los servicios mediante el interfaz Cobol, C, etc.

28. Qué es CORBA?: 2º factor clave Internet Inter-Object Protocol (IIOP) Sistema de Objetos distribuido Smalltalk Java Corba Software Bus: ORB C++ Cobol C Protocolo de Comunicaciones: IIOP Interface definition Language

29. Qué es CORBA?: 3º factor clave • Corba Services • Naming • Events • Transactions • Security • Trader • Notifications • Persistence • Concurrency • Query • Licensing • (más otros de menor importancia) CORBA Services Smalltalk Java Naming Corba Software Bus: ORB C++ Cobol Security IDL estándar para los servicios

30. El núcleo CORBA. Cliente Objeto Implementación Control Control Implementation Repository Interfaz ORB Interface Repository DII Stubs IDL Skeleton IDL DSI OA Object Request Broker