Creación de un servicio web con RMI 3Unidad N°. comprende el funcionamiento de un servicio web con RMI de manera eficiente y responsable. Logro.

Slides:



Advertisements
Presentaciones similares
APLICACIONES DISTRIBUIDAS
Advertisements

Common Object Request Broker Architecture
Lenguajes Servicios Web
RMI Remote Method Invocation
Java 2 Platform Enterprise Edition
Sistemas Operativos Centralizados y Distribuidos Carlos David Zepeda.
JAVA RMI The Java Remote Method Invocation ELO330 – Programación de Sistemas Cesar Vásquez I
Haga clic para modificar el estilo de subtítulo del patrón 28/04/09 Por ARLEDY SARRIA MOLINA NAZLY DIAZ ARIZA JHOANNA MARQUELLA DESARROLLO DE SOFTWARE.
1 Capítulo 21: Interacción Cliente Servidor ICD 327: Redes de Computadores Agustín J. González.
MAESTRIA EN CIENCIAS DE LA COMPUTACION Comparación de implementación de sistemas distribuidos usando COM y CORBA Jesús Gil Muñoz Julio 2001.
Patrón de diseño BROKER
Introducción Framework 3.0. Introducción Junto con Windows Vista se libera al mercado una serie de tecnologías para desarrolladores de software que cambiarán.
Sistema de Almacenamiento
Introducción Principios de Programación Web Aplicaciones Web con JSP y Servlets de Java.
1 Universidad Del Caribe Telemática Sistemas Operativos Distribuidos y de Tiempo Real “Modelos de Sistemas” Profesor: Joel Antonio Trejo Sánchez Integrantes:
¡LOS SERVIDORES DE FTP Y NUBE!
San Juan Bautista Tuxtepec, Oaxaca a 01 de Septiembre de 2016 INSTITUTO TECNOLÓGICO de Tuxtepec PROGRAMACION EN AMBIENTE CLIENTE-SERVIDOR CORBA PRESENTA:
Terminal Services Alumno : Juan Noa Saccatoma. ¿Qué es? Es un componente del Sistema Operativo que básicamente me permite dos cosas: Instalar aplicaciones.
UNIVERSIDAD FERMIN TORO CABUDARE ENSAYO TIPOS DE SOFTWARE E IMPORTANCIA JUNIO 2014.
Pruebas de Funcionalidad de Software: Caja Negra y Caja Blanca Curso: Diseño de Sistemas 9no. Semestre.
Java RMI. Entornos orientados a objetos  Tendencia actual hacia sistemas compuestos por un conjunto de objetos que interactúan entre sí.  Un programa.
TECNOLOGÍAS DE LA INFORMACIÓN Y DE LA COMUNICACIÓN (TIC’S)
Conceptos Básicos de Programación
Sistemas Distribuidos
MODELO CLIENTE -SERVIDOR
Clases y Objetos en Java
TECNOLOGÍAS DE LA INFORMACIÓN Y DE LA COMUNICACIÓN (TIC’S)
Introducción a programación web Martin Esses
Modelo OSI.
Actividad 3. HERRAMIENTA TAREAS.
Tarea 3: data warehouse y san
Tema 3. Lenguaje unificado de modelado UML
Modelo de 3 capas. Qué es la arquitectura de una aplicación? La arquitectura se refiere a la forma en la que es diseñada tanto física como lógicamente.
Definición de un Sistema Distribuido
GLOSARIO TIC.
PROVEEDOR DATA WAREHOUSE TERADATA
ACTIVIDAD 3 HERRAMIENTA TAREAS.
Servidor ¿Qué es? ¿Cómo funciona?.
FUNDAMENTOS DE PROGRAMACION EN ENTORNO WEB. Rodrigo Cabello Ing. Informático Director de proyectos Think – Ideas in Motion FUNDAMENTOS.
A RQUITECTURA C LIENTE - SERVIDOR La arquitectura del cliente servidor se divide en dos partes Los promovedores de recursos o servicios llamados servidores.
Page 1. Page 2 Los lineamientos básicos que debe contener las paginas HTML.
Sugiero cambios a lo de Amarillo / lo de azul no tiene expositor aun 1 concepto de transaccion (Tejada) 2. Fundamentos d elos procesos de Transaccion.
ESTRUCTURA DE S.OPERATIVO
ESTRUCTURAS DE LOS SISTEMAS OPERATIVOS INTEGRANTES: -SIAS ALVAREZ -GUTIÉRREZ ROBLES -GELDRES HUAYCOCHEA.
ABSTRACCION DE DATOS   Estructura de Datos Básicos: En programación una estructurad de datos, es una forma particular de organizar datos en una computadora.
Java Enterprise edition
Curso: fundamentos de redes Profesor: Miguel farfan Sesion: 03
TECNOLOGÍAS DE LA INFORMACIÓN Y LA COMUNICACIÓN II
“Conceptos Básicos de Java”
Nuestros canales de comunicación Gestión de la Calidad del Software Modelos y Estándares de Calidad en el Software.
Hecha por los Estudiantes: Pipe Ávila y Pipe Cárdenas Destinada: Para todos ustedes los aprendices y la maestra ingeniera.
Estructura de Sistemas Operativos CAMPOS CHACALTANA, ANTHONY.
Estructura de los sistemas Operativos 1. Componentes de un sistema operativo  Administración de procesos  Administración de memoria  Subsistema de Entrada/Salida.
Estructura de los Sistemas Operativos Alumna:Arratea Almeyda Aracelli.
ESTRUCTURA DE SISTEMAS OPERATIVOS Carbajal Rojas karla.
Construcción de Sistemas Colaborativos (Arquitectura y construcción)
ARQUITECTURA DE UN NAVEGADOR WEB ESTO SE REFIERE AL SOFTWARE O HARDWARE? Un navegador web es un programa que codifica y decodifica una serie de reglas,
GC-F-004 V.01 CENTRO DE INDUSTRIA Y LA CONSTRUCCIÓN REGIONAL TOLIMA.
Tipos de servidores y su uso Lic. David I. López Pérez.
ESTRUCTURA DE LOS SISTEMAS OPERATIVOS
Estructura de Sistemas Operativos
Estructura de los Sistemas Operativos
ESTRUCTURA DE LOS SISTEMAS OPERATIVOS. Estos sistemas no tienen una estructura definida, sino que son escritos como una colección de procedimientos donde.
Estructura de los Sistemas Operativos
SISTEMAS OPERATIVOS Estudiante: Rojas De la Cruz Jesus Manuel. Ciclo: VI. Turno: Noche.
ESTRUCTURA DE LOS SISTEMAS OPERATIVOS By Pachas Garay Bruno.
ING. NANCY BASILIO MARCELO ADMINISTRACIÓN REDES DE COMPUTADORAS.
Transcripción de la presentación:

Creación de un servicio web con RMI 3Unidad N°

comprende el funcionamiento de un servicio web con RMI de manera eficiente y responsable. Logro

La programación de hilos forma una base fundamental en la programación concurrente. Permite utilizar de forma eficiente los recursos más valiosos de un computador : memoria, disco de almacenamiento y el CPU. Mediante sus primitivas y algoritmos, se pudieron solucionar complejos problemas de concurrencia y de disponibilidad. Importancia

Interfaz RMI Servidor RMI Cliente RMI Problema 3 en raya distribuido Cuenta bancaria distribuida Paint corporativo distribuido Contenido

Interfaz RMI

RMI RMI es una tecnología desarrollada por Sun para permitir la colaboración de objetos que están localizados remotamente. Esta tecnología se enmarca en la idea de permitir colaboración entre Objetos Remotos. La idea no es que los objetos se comuniquen a través de la programación del usuario de protocolos estándares de red. La idea es tener un objeto cliente, donde podamos podamos completar un requerimiento de datos. El cliente luego prepara el requerimiento que envía a un objeto ubicado en un servidor. El objeto remoto prepara la información requerida (accediendo a bases de datos, otros objetos, etc). Finalmente el objeto remoto envía la respuesta al cliente. En lo posible esta interacción debería ser lo más semejante posible a requerimientos hechos localmente. En principio se puede anhelar la colaboración de objetos escritos en cualquier lenguaje (no es el caso de RMI). Esta idea no es simple de lograr, corresponde al esfuerzo del grupo OMG (Object Management Group, los cuales propusieron CORBA (Common Object Request Broker Architecture), el cual define un mecanismo común para descubrir servicios e intercambiar datos. CORBA usa Object Request Broker (ORB) como traductores universales para la comunicación entre objetos. Los objetos remotos hablan a través de estos ORB. El protocolo de comunicación entre objetos y ORB es llamado Internet Inter-ORB Protocol o IIOP. La opción propuesta por Microsoft para comunicar objetos remotos es COM (Component Object Model). Hoy este modelo parece haber sido superado por la tecnología.NET. Cuando el cliente y servidor son escritos en Java, la generalidad y complejidad de CORBA no es requerida. En este caso Sun desarrolló RMI, un mecanismo más simple especialmente pensado para comunicación entre aplicaciones Java.

RMI – invocación remota La idea suena simple, si tenemos acceso a objetos en otras máquinas, podemos llamar a métodos de ese objeto remoto. RMI maneja los detalles de enviar los parámetros, el objeto remoto debe ser activado para ejecutar el método y los valores deben ser retornados de regreso al llamador, ver Figura 1.

RMI Terminología Objeto cliente: objeto cuyo método hace el llamado remoto. Objeto servidor: Objeto remoto llamado Notar que los roles de cliente y servidor aplican sólo a un llamado. Un objeto servidor luego puede ser cliente al hacer un llamado remoto.Marshalling: es el proceso de codificación de los parámetros. Stub: es un objeto que encapsula el método que deseamos invocar remotamente. Así el llamado remoto es semejante a un llamado local. Éste prepara información con la identificación el objeto remoto a invocar, el método a invocar y codificación de los parámetros (Marshalling). Skeleton: es el objeto del lado del servidor que decodifica los parámetros, ubica el objeto llamado, llama el método deseado, codifica el valor retornado, y envía la información de regreso al stub.

RMI Terminología Aún cuando el proceso de la Figura 2 es completo, RMI lo hace en gran medida automático y en gran media transparente para el programador. La sintaxis de llamados remotos es la misma de los llamados locales. RMI posee posee un mecanismo para cargar clases dinámicamente desde otro lugar. Esto es requerido, por ejemplo, cuando el valor retornado corresponde a una instancia de una clase derivada de la clase conocida por el cliente. Aquí se ocupa un mecanismo similar al usado por applets.

RMI Arquitectura Skeleton y Stub Dota a clientes y servidores de una interfaz que les permite localizar objetos remotos para invocar sus métodos como si fueran locales. El API java RMI Es una interfaz de programación de aplicaciones provistas por los creadores del lenguaje java, y que da a los programadores los medios para desarrollar aplicaciones Java. LA API de Java provee un conjunto de clases utilitarias para efectuar toda clase de tareas dentro de un programa. Interfaces y Clases RMI Implementa 5 paquetes. Java.rmi: contiene Clases, Interfaces y Excepciones vistas por los clientes. Java.rmi.server: Contiene clases, Interfaces y Excepciones vistas por los servidores. Java.rmi.registry: Contiene Clases, Interfaces y Excepciones útiles para localizar y registrar objetos remotos. Java.rmi.dgc: Contiene Clases, Interfaces y Excepciones para la recolección de basura. Java.rmi.activation: Contiene Clases, Interfaces y Excepciones para la activación de objetos remotos.

RMI Arquitectura

La primera capa es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicación que quiera que sus métodos estén disponibles para su acceso por clientes remotos debe declarar dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa básicamente para «marcar» un objeto como remotamente accesible. Una vez que los métodos han sido implementados, el objeto debe ser exportado. Esto puede hacerse de forma implícita si el objeto extiende la clase UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de forma explícita con una llamada al método exportObject() del mismo paquete.. La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa directamente con la capa de aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y retorno de objetos tienen lugar en esta capa. La capa 3 es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. También es responsable de la gestión de la replicación de objetos y realización de tareas específicas de la implementación con los objetos remotos, como el establecimiento de las persistencias semánticas y estrategias adecuadas para la recuperación de conexiones perdidas. En esta capa se espera una conexión de tipo stream (stream-oriented connection) desde la capa de transporte. La capa 4 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. El protocolo de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que solamente es «comprendido» por programas Java.

RMI Arquitectura La primera capa es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicación que quiera que sus métodos estén disponibles para su acceso por clientes remotos debe declarar dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa básicamente para «marcar» un objeto como remotamente accesible. Una vez que los métodos han sido implementados, el objeto debe ser exportado. Esto puede hacerse de forma implícita si el objeto extiende la clase UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de forma explícita con una llamada al método exportObject() del mismo paquete.. La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa directamente con la capa de aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y retorno de objetos tienen lugar en esta capa. La capa 3 es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. También es responsable de la gestión de la replicación de objetos y realización de tareas específicas de la implementación con los objetos remotos, como el establecimiento de las persistencias semánticas y estrategias adecuadas para la recuperación de conexiones perdidas. En esta capa se espera una conexión de tipo stream (stream-oriented connection) desde la capa de transporte. La capa 4 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. El protocolo de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que solamente es «comprendido» por programas Java.

Aplicando lo aprendido Revisar los ejercicios dirigidos de RMI JAVA

La programación distribuida mejora exponencialmente la eficacia de los recursos como la memoria el procesamiento. No obstante, se debe tener cuidado en evitar caer en lso problemas de sincronización y de inconsistencia Conclusiones

Gracias