Java RMI-MiniProyectoI

INTRODUCCIÓN:

En este trabajo se revisaron: el procedimiento y las consideraciones a realizarse durante la construcción de una aplicación RMI. Dicha aplicación fue desarrollada en base a la siguiente especificación:

Don Chente el de la tienda de la esquina quiere modernizar su changarrito y desea poner en línea sus servicios: consulta de su catálogo, administración de órdenes por Internet, ventas del día. Para poder lograrlo le solicita implementar una aplicación cliente servidor que ofrezca las siguientes funciones: consulta de catálogo por tipo de producto, recuperación de órdenes de compra considerando la disponibilidad de los productos, vista consolidada de las ventas del día (suma de las ventas). Don Chente le agradece de antemano la aplicación y cuenta con usted para montar su e-changarrito.

OBJETIVO:

Estudiar los pasos a seguir y las consideraciones que hay que tomar en cuenta durante la construcción de una aplicación con Java RMI.

DESCRIPCIÓN TÉCNICA:

Modelado

Se utilizó el patrón de diseño MVC (Model, View, Controller) mismo que indica la separación del código en:

Vista: Se centra en la interfaz de usuario.

Controlador: Recibe eventos que se generan en la interfaz y basándose en ellos, los dirige al modelo.

Modelo: Encapsula el estado de la aplicación e implementa la lógica aplicativa.

Basándonos en estos principios, nuestra aplicación incluye las siguientes clases:

Interfaz.java Interfaz que sirve de contrato entre el cliente y el servidor

Servidor.java Del lado del Servidor: clases que definen los métodos

Base de Datos miniproyecto (modelo) e incluye la conexión a la base de datos

Producto.java

Venta.java

Cliente.java De lado del cliente, tenemos la vista y su controlador

Diagrama de componentes

Diagrama de Clases

Diagramas de Secuencia:

-Conexión -Consulta de catálogo y orden de compra

-Visualizar Lista de ventas

LECCIONES APRENDIDAS:

-El cliente envía mensajes representados en solicitudes SQL hacia el servidor de bases de datos. -Los resultados de cada orden de SQL son devueltos al cliente.

-El cliente invoca procedimientos remotos que residen en el servidor, por lo tanto se intercambia un solo mensaje de solicitud/respuesta.

- El DBMS se encarga de recolectar los datos desde su base de datos.

-Luego de terminada una transacción en forma exitosa (commit) los cambios se vuelven permanentes.

-Para que la aplicación se pueda comunicar con la Base de Datos debe tenerse habilitado un driver, en este caso JDBC (Java DataBase Conectivity).

-JDBC es realmente un conjunto de clases que representan conexiones con bases de datos, sentencias SQL, conjuntos de datos y metadatos entre otras cosas. El API definido por JDBC permite enviar sentencias en SQL al motor de bases de datos, y procesar los resultados.

Integrantes del equipo:

Paola González Pérez 127418

paola.gonzalezpz@gmail.com

Víctor Madrigal Barón

José Eduardo Santos Contreras 129762

Key.bearer@gmail.com

Héctor Manuel Gutiérrez Rubio 129202

hekmont@hotmail.com

Java RMI: Práctica I

INTRODUCCIÓN:

En esta práctica se revisó el procedimiento y las consideraciones que deben realizarse, durante la construcción de una aplicación con Java RMI. Tomando como objeto de estudio, una aplicación simplificada de soporte a un sitio dedicado a la venta de artículos, dicha aplicación se basa en un modelo de subastas cuyo escenario típico es el siguiente:
- Un usuario (con rol de vendedor) se conecta y ofrece un producto, estableciendo un precio inicial
- Los compradores potenciales, se conectan como cualquier usuario y tienen la opción de visualizar el catálogo de productos disponibles a la compra. Aunado a que al seleccionar un producto, pueden realizar una oferta. Cada comprador puede conectarse y realizar ofertas sobre un producto varias veces, siempre y cuando su oferta sobrepase el monto actual del producto.
- Finalizando el periodo de subasta, el producto es asignado al mejor postor.

OBJETIVO:

Estudiar los pasos a seguir y las consideraciones que hay que tomar en cuenta durante la construcción de una aplicación con Java RMI.

DESCRIPCIÓN TÉCNICA:

Modelado

Se utilizó el patrón de diseño MVC (Model, View, Controller) mismo que indica la separación del código en:

Vista: Se centra en la interfaz de usuario.
Controlador: Recibe eventos que se generan en la interfaz y basándose en ellos, los dirige al modelo.
Modelo: Encapsula el estado de la aplicación e implementa la lógica aplicativa.


Basándonos en estos principios, nuestra aplicación incluye las siguientes clases:

Subasta.java Interfaz que sirve de contrato entre el cliente y el servidor

SubastaServer.java (Modelo) Del lado del Servidor, tenemos al modelo y las clases que
InformaciónProducto.java ocupa
InformaciónOferta.java

SubastaClient.java De lado del cliente, tenemos la vista y su controlador
SubastaVista.java
SubastaControlador.java

LECCIONES APRENDIDAS:

- RMI (Remote Method Invocation) habilita un objeto en la máquina virtual de java para invocar métodos en un objeto sobre otra máquina virtual. (cliente-servidor)

- La relación que se establece entre los diferentes objetos, es definida por una interfaz que extiende la interfaz remota (Subasta en nuestro caso).

- El stub o talón es utilizado para enviar mensajes (aunado a los parámetros) de la máquina local al objeto remoto e implementa todos los métodos de la interfaz remota.

-Los argumentos y los tipos de retorno de los métodos remotos, tienen que ser de tipo primitivo, objetos remotos o un objeto serializable (implementa java.io.Serializable), para que puedan ser pasados y/o devueltos por un método remoto.

DEMOSTRACIONES:

En la siguiente imagen se observan tres clientes distintos que juegan diferentes roles, ya sea de vendedor y/o comprador; a su vez, uno de ellos únicamente obtiene la lista de los objetos disponibles. De manera que podemos darnos cuenta que al modificar el precio de los productos, al dar de alta a uno nuevo y/o hacer una nueva oferta, la vista de los otros clientes no es actualizada, o sea la información no está sincronizada para todos los clientes.

Para resolver este problema, se puede hacer que el servidor sea capaz de notificar los cambios en el modelo a cada uno de los clientes.

Integrantes del equipo:
Paola González Pérez 127418 paola.gonzalezpz@gmail.com
Víctor Madrigal BarónJosé Eduardo Santos Contreras 129762 Key.bearer@gmail.com
Héctor Manuel Gutiérrez Rubio 129202 hekmont@hotmail.com