La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

APLICACIONES DISTRIBUIDAS HENRY MAURICIO ROMERO QUIROGA 160001428.

Presentaciones similares


Presentación del tema: "APLICACIONES DISTRIBUIDAS HENRY MAURICIO ROMERO QUIROGA 160001428."— Transcripción de la presentación:

1 APLICACIONES DISTRIBUIDAS HENRY MAURICIO ROMERO QUIROGA

2 APLICACIONES DISTRIBUIDAS DCOM RMI CORBA Netremoting

3 ( Common Object Request Broker Architecture arquitectura común de intermediarios en peticiones a objetos) Es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos. ( Common Object Request Broker Architecture arquitectura común de intermediarios en peticiones a objetos) Es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos. CORBA CORBA

4 corba fue definido y está controlado por el Object Management Group (OMG) que define las APIs corba fue definido y está controlado por el Object Management Group (OMG) que define las APIs Envuelve" el código escrito en otro lenguaje en un paquete que contiene información adicional sobre las capacidades del código que contiene, y sobre cómo llamar a sus métodos.

5 Tipos de Implementaciones de corba AdaCC++SmalltalkJavaPythonPerlTCL

6 Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones.

7 EJEMPLOS 02ejemplojava.pdf 02ejemplojava.pdf 02ejemplojava.pdf 02ejemplojava.pdf m/csamples.htm m/csamples.htm m/csamples.htm m/csamples.htm

8 RMI RMI (Java Remote Method Invocation) es un mecanismo ofrecido en Java para invocar un método remotamente. RMI (Java Remote Method Invocation) es un mecanismo ofrecido en Java para invocar un método remotamente.

9 RMI puede darse el lujo de ser muy amigable para los programadores: RMI puede darse el lujo de ser muy amigable para los programadores: Proveyendo pasaje por referencia de objetos. Proveyendo pasaje por referencia de objetos. Recolección de basura" distribuida. Recolección de basura" distribuida. Pasaje de tipos arbitrarios Pasaje de tipos arbitrarios Por medio de RMI, un programa Java puede exportar un objeto.

10 Contexto Contexto A pesar de que RMI es un ORB en el sentido general, no es un modelo compatible con CORBA. A pesar de que RMI es un ORB en el sentido general, no es un modelo compatible con CORBA. RMI es nativo de Java, es decir, es una extensión al núcleo del lenguaje. RMI es nativo de Java, es decir, es una extensión al núcleo del lenguaje. fue diseñada para resolver problemas escribiendo y organizando código ejecutable. fue diseñada para resolver problemas escribiendo y organizando código ejecutable.

11 Arquitectura Primera capa Primera capa Es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Segunda capa Segunda capa Es la capa proxy, o capa stub- skeleton. Esta capa es la que interactúa directamente con la capa de aplicación. Es la capa proxy, o capa stub- skeleton. Esta capa es la que interactúa directamente con la capa de aplicación.

12 Tercera capa Tercera capa Es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. Es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. Cuarta Capa Cuarta Capa Es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una máquina a otra. Es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una máquina a otra.

13 Elementos Toda aplicación RMI normalmente se descompone en 2 partes: Toda aplicación RMI normalmente se descompone en 2 partes: 1. Un servidor 2. Un cliente

14 DCOM Distributed Component Object Model (DCOM), Modelo de Objetos de Componentes Distribuidos, es una tecnología propietaria de Microsoft para desarrollar componentes software distribuidos sobre varios ordenadores y que se comunican entre sí. Distributed Component Object Model (DCOM), Modelo de Objetos de Componentes Distribuidos, es una tecnología propietaria de Microsoft para desarrollar componentes software distribuidos sobre varios ordenadores y que se comunican entre sí.

15 En términos de las extensiones que añade a COM, DCOM tenía que resolver los problemas de: Aplanamiento Aplanamiento Recolección de basura distribuida Recolección de basura distribuida Uno de los factores clave para resolver estos problemas es el uso de DCE/RPC como el mecanismo RPC subyacente bajo DCOM. Uno de los factores clave para resolver estos problemas es el uso de DCE/RPC como el mecanismo RPC subyacente bajo DCOM.

16 DCOM fue uno de los mayores competidores de CORBA. Los defensores de ambas tecnologías sostenían que algún día serían el modelo de código y servicios sobre Internet. DCOM fue uno de los mayores competidores de CORBA. Los defensores de ambas tecnologías sostenían que algún día serían el modelo de código y servicios sobre Internet.

17 Versiones alternativas e implementaciones El Open Group tiene una implementación DCOM llamada COMsource, cuyo código fuente está disponible, así como la documentación completa, suficiente para su uso y suficiente también para implementar una versión interoperable de DCOM. El Open Group tiene una implementación DCOM llamada COMsource, cuyo código fuente está disponible, así como la documentación completa, suficiente para su uso y suficiente también para implementar una versión interoperable de DCOM.

18 El equipo de Wine también está implementando DCOM. Lo hacen para conseguir la interoperabilidad binaria, y no están interesados en la parte de distribución sobre la red de DCOM, que es proporcionada por MSRPC El equipo de Wine también está implementando DCOM. Lo hacen para conseguir la interoperabilidad binaria, y no están interesados en la parte de distribución sobre la red de DCOM, que es proporcionada por MSRPC

19 NETREMOTING Microsoft®.NET Remoting proporciona el marco que permite a los objetos interactuar entre sí desde distintos dominios de aplicaciones e incluye servicios como la activación y la compatibilidad con la duración de los objetos, junto con los canales de comunicación responsables del transporte de mensajes a y desde aplicaciones remotas Microsoft®.NET Remoting proporciona el marco que permite a los objetos interactuar entre sí desde distintos dominios de aplicaciones e incluye servicios como la activación y la compatibilidad con la duración de los objetos, junto con los canales de comunicación responsables del transporte de mensajes a y desde aplicaciones remotas

20 Los formateadores se emplean para codificar y descodificar los mensajes antes de que éstos se envíen por el canal. Los formateadores se emplean para codificar y descodificar los mensajes antes de que éstos se envíen por el canal. Las aplicaciones pueden hacer uso de la codificación binaria en los casos en los que el rendimiento es un factor fundamental, o bien, la codificación XML, en aquellos otros en los que el aspecto esencial es la interoperabilidad con otros marcos remotos. Las aplicaciones pueden hacer uso de la codificación binaria en los casos en los que el rendimiento es un factor fundamental, o bien, la codificación XML, en aquellos otros en los que el aspecto esencial es la interoperabilidad con otros marcos remotos.

21 CANALES Los canales se utilizan para transportar mensajes a y desde objetos remotos. Cuando un cliente llama a un método en un objeto remoto, los parámetros, así como otros detalles relacionados con la llamada, se transportan a través del canal al objeto remoto. Los canales se utilizan para transportar mensajes a y desde objetos remotos. Cuando un cliente llama a un método en un objeto remoto, los parámetros, así como otros detalles relacionados con la llamada, se transportan a través del canal al objeto remoto.

22 La selección del canal está sujeta a las siguientes reglas: Al menos un canal debe estar registrado con el marco de servicios remotos para poder llamar a un objeto remoto. Los canales deben registrarse antes que los objetos. Al menos un canal debe estar registrado con el marco de servicios remotos para poder llamar a un objeto remoto. Los canales deben registrarse antes que los objetos. Los canales se registran por dominio de aplicación. En un único proceso pueden existir varios dominios. Cuando el proceso termina, todos los canales que éste registra se destruyen automáticamente. Los canales se registran por dominio de aplicación. En un único proceso pueden existir varios dominios. Cuando el proceso termina, todos los canales que éste registra se destruyen automáticamente.

23 No se puede registrar el mismo canal que escucha en el mismo puerto más de una vez. No se puede registrar el mismo canal que escucha en el mismo puerto más de una vez. Los clientes se pueden comunicar con el objeto remoto utilizando cualquier canal registrado. El marco de servicios remotos garantiza que el objeto remoto se conecta al canal adecuado cuando el cliente intenta realizar la conexión. Los clientes se pueden comunicar con el objeto remoto utilizando cualquier canal registrado. El marco de servicios remotos garantiza que el objeto remoto se conecta al canal adecuado cuando el cliente intenta realizar la conexión.

24 EJEMPLOS doc/Remoting/quickstart.aspx doc/Remoting/quickstart.aspx doc/Remoting/quickstart.aspx doc/Remoting/quickstart.aspx


Descargar ppt "APLICACIONES DISTRIBUIDAS HENRY MAURICIO ROMERO QUIROGA 160001428."

Presentaciones similares


Anuncios Google