Algoritmos y Programación III

1. Algoritmos y Programación III 9. Aplicaciones distribuidas Carlos Fontela, 2005

2. Temario • Aplicaciones distribuidas y J2EE • Componentes web • Servlets • Páginas JSP • Mensajería con JMS • Servicios web con JAX-RPC y JAXR • Componentes EJB • ¡Todo a nivel introductorio!

3. Definiciones • Internet • Red global • TCP/IP • World Wide Web (“la web”) • Aplicación s/ Internet (otras: mail, FTP) • Protocolo HTTP • Páginas vinculadas • HTML • Multiplataforma • No hay mantenimiento de estado entre llamadas

4. Computación distribuida • Caso extremo de concurrencia • Aplicación corriendo sobre varias máquinas • Mayor complejidad • Comunicaciones • Seguridad • Recuperación por fallos • Plataformas

5. Evolución • Grandes máquinas aisladas • Mainframes • Procesamiento centralizado • Terminales bobas • Redes de PCs • Procesamiento descentralizado • Almacenamiento centralizado • Web, primeros años • Primero, como mainframes • Luego, aprovechando capacidad de clientes • Hoy: aplicaciones distribuidas

6. Cambio de paradigma • Aplicaciones distribuidas: • Corren en varias máquinas tipo servidores. • Esquema cooperativo. • Basadas en Internet: • Red global. • Conjunto de protocolos. • Ancho de banda barato. • Sobre la Web: • Multiplataforma. • Actualización automática. • Interfaz conocida.

7. Clientes y servidores • Clientes finales • Ricos • Pobres o Web • Clientes que son servidores • Servidores que son clientes • Siempre hay un cliente y un servidor

8. Elementos (lado del servidor) • Páginas web “estáticas” • HTML, multimedia, guiones, applets y otros. • Componentes para páginas web dinámicas • Se comunican con componentes de negocio. • Componentes de negocio • Dan servicio a componentes web, a otros componentes de negocio y utilizan componentes de acceso a datos • Componentes de acceso a datos • Sistemas de mensajería • Servicios web

9. Cambios en lenguajes • Más fácil desarrollo: • Bibliotecas provistas. • “Administradores” que se ocupan se servicios de sistema. • Portabilidad. • Especificaciones • J2EE (Sun y JCP) • Implementada por IBM, BEA, Apache Jakarta, etc. • .Net (MS) • Implementada por MS, proyecto Mono • Otras menos elaboradas

10. J2EE vs. .NET • J2EE • Más madura • Soportada por muchos actores • Lenguaje Java y APIs en Java • .NET • Mayor comodidad • Varios lenguajes basados en CLR: C#, VB.NET, J#, Delphi.NET, C++ Managed Extensions, etc. • Fuertemente basado en XML y Web Services • Evitar fundamentalismos • Malo vs. bueno, 100% • Ganadores y perdedores, 100%

11. J2EE o .NET vs. el resto • Resto • Trabajar con C, PHP, Python, Perl, Delphi... • Todo se puede • J2EE y .NET • Mayor facilidad de desarrollo • Componentes administrados • Detalles a cargo de la implementación • Se programa funcionalidad de negocio • Hay software libre • Mono, Tomcat, Jboss...

12. Herramientas (I) • Lenguajes para generación de páginas web • HTML, Javascript, Java (applets) y demás. • Lenguajes para páginas del lado del servidor • PHP, JSP, ASP, ASP.NET, SSJS y Java (servlets). • Plataforma para administrar lo anterior • Servidores web: Apache, MS IIS, etc. • Contenedor web de J2EE. • Servidor de aplicaciones .NET. • Componentes de negocio y de acceso a datos • Con su plataforma de servicios básicos. • EJB de J2EE, componentes de Microsoft.

13. Herramientas (II) • Bibliotecas para hacer llamadas de métodos sobre objetos distantes • RMI de Java, Remoting de .NET, CORBA del OMG. • Bibliotecas para mensajería asincrónica • JMS de J2EE, MS Message Queue, IBM MQ . • Facilidades para la construcción de servicios web • Plataformas .NET y J2EE. • Bibliotecas de manejo y rastreo de documentos XML.

14. J2EE (I) • Es una especificación • Desarrollada por el JCP • Multiempresa, abierto • Facilidades para el desarrollo de: • Aplicaciones distribuidas • Basadas en componentes • Arquitectura multicapa • Asiste en el diseño, programación, ensamblado y despliegue • Garantiza interoperabilidad de componentes

15. J2EE (II) • Aplicación J2EE distribuida incluye: • Aplicaciones cliente • Componentes web, en el servidor: • Interfaz entre los usuarios web externos y el modelo de la aplicación. • Tipos: servlets y páginas JSP. • Componentes EJB, también en el servidor • Lógica de la aplicación y acceso a datos. • Se programa en Java, más bibliotecas y extensiones.

16. J2EE (III) • Condiciones de los componentes: • Ensamblados en una aplicación J2EE • Desplegados en un servidor J2EE, dentro de contenedores J2EE • Respetar la especificación J2EE • ¿Contenedores? • Aplicaciones que corren en el servidor J2EE • Brindan servicios a los componentes • Cada implementación debe proveer: • Servidor de aplicaciones • Contenedor web • Contenedor EJB

17. Arquitectura J2EE (I)

18. Arquitectura J2EE (II)

19. ¿Jini? • Arquitectura dinámica orientada a servicios • Conjunto de bibliotecas y protocolos de red • Dispositivos ofrecen servicios • Se comunican automáticamente • Servicios “confederados” • Basado en la red • Fracaso: • Lanzado prematuramente • No bien soportado por Sun

20. RMI (Remote Method Invocation) • J2SE: paquete java.rmi y dependientes. • Invocación directa de métodos remotos: • Llamar a un método sobre un objeto en otra máquina y ver los resultados en la nuestra. • Posiblemente modificando un objeto local. • Históricamente siempre ha sido difícil. • Forma de trabajo totalmente orientada a objetos. • Mantiene el encapsulamiento al máximo.

21. RMI: interfaz remota (I) • Interfaz “remota”: • No se obtienen referencias a los objetos. • Sí a una interfaz del espacio de cómputo local. • Copia de la interfaz que implementa el objeto remoto. • Código local que se comunica a través de la red con el objeto verdadero y remoto. • Todo lo maneja la JVM • El cliente sólo utiliza la referencia a la interfaz como si fuera un objeto local. • El proveedor sólo se encargará de implementar la interfaz definida como contrato.

22. RMI: interfaz remota (II) • Condiciones: • Debe ser pública. • Debe extender la interfaz java.rmi.Remote. • Cada método de la misma debe declarar que arroja la excepción java.rmi.RemoteException. • Cualquier objeto remoto pasado como argumento o utilizado como valor devuelto de un método, incluso si está contenido en otro, debe estar declarado como instancia de la interfaz remota, no de la clase que la implementa.

23. RMI: una interfaz remota // archivo Libreria.java import java.rmi.*; import com.libreria.paquetes.*; // aquí está definida la clase Libro public interface Libreriaextends Remote { int stock (Libro l) throws RemoteException; double precio (Libro l) throws RemoteException; }

24. RMI: un cliente import java.rmi.*; import java.rmi.registry.*; import com.libreria.paquetes.*; public class ConsultaLibreria { public static void main(String[ ] p) throws Exception { System.setSecurityManager(new RMISecurityManager()); Libreria lr = (Libreria)Naming.lookup("//servidor_libreria/ConsultasLibreria"); Libro libro = new Libro(”La Celestina"); System.out.println("Stock de La Celestina " + lr.stock(libro)); } }

25. RMI: clase servidora • Aspectos de bajo nivel: • Instalar un administrador de seguridad que soporte RMI • Crear una o más instancias del objeto remoto. • Arrancar el servicio de registro de RMI • Registrar por lo menos uno de los objetos remotos con el registro de objetos de RMI • Establecer el nombre del servicio • Al mismo tiempo, se debe proporcionar el nombre del servidor y el puerto del servicio • Correr generadores de stubs y skeletons (rmic) • Hay funcionalidades superiores en J2EE.

26. J2EE y tecnologías (I) • JNDI (Java Naming and Directory Interface) • Especificaciones para componentes web: • Servlets • JSP (JavaServer Pages) • JavaServer Faces • Especificaciones para componentes distribuidos: • EJB (Enterprise JavaBeans) • JMS (Java Message Service) • JAX-RPC (XML Remote Procedure Call)

27. J2EE y tecnologías (II) • Java API for XML Registries (JAXR) • JDBC (extensiones sobre JDBC de J2SE) • Java Transaction API y Java Transaction Service (JTA/JTS) • JavaMail API • JavaBeans Activation Framework (JAF) • SOAP with Attachments for Java (SAAJ) • J2EE Connector Architecture • Java Authentication and Authorization Service (JAAS)

28. Servlets (I) • Clases que sirven para actuar en el típico esquema de solicitud y respuesta que utiliza el protocolo HTTP. • Se comportan como programas que reciben una solicitud, arman la respuesta y se la mandan al cliente. • Reemplazan los antiguos guiones CGI con una solución usando Java. • Todo esto se maneja dentro del servidor web mediante el contenedor web.

29. Servlets (II) HttpServlet maneja el protocolo HTTP

30. Servlets (III)

31. Servlets: funcionamiento (I) • Cuando llega una solicitud HTTP: • El contenedor la intercepta. • La envía al método service. • Hay también métodos doGet y doPost. • service elabora la respuesta y la escribe en un OutputStream. • El OutputStream viaja hasta el cliente. • Las variables mantienen valor entre llamadas • Se pierden al cerrar el contenedor. • Pero tenemos init y destroy.

32. Servlets: funcionamiento (II) • El contenedor controla el ciclo de vida: • Si no hay una instancia existente de la servlet cuando llega una solicitud, el contenedor carga la clase, crea una instancia y llama al método init, y luego a service; cuando se cierra el contenedor, se llama a destroy. • Una servlet sencilla: • Crear una clase que herede de HttpServlet. • Redefinir service para que convierta solicitudes en respuestas. • Eventualmente redefinir init y destroy de modo de persistir datos entre arranques del servidor.

33. Servlets: ejemplo import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import libreria.*; public class ServletLibreria extends HttpServlet { private int visitas = 0; // se mantiene entre llamadas public void synchronized service(HttpServletRequest s, HttpServletResponse r) throws IOException { visitas++; s.setContentType("text/html"); Libro libro = new Libro(s.getParameter("Libro")); PrintWriter out = s.getWriter(); out.print("<h1>Precio y stock de libros:</h1>"); out.print("<p>Precio: $" + precio(libro) + "</p>"); out.print("<p>Visitada Nº" + visitas + " </p><br>"); out.close(); } }

34. Servlets: sesiones y cookies (I) • HTTP no maneja sesiones. • Solución más conocida: cookies. • Par de valores: clave - valor asociado. • Por ejemplo, ("nombre", "Carlos Fontela"). • Se guarda en el equipo del cliente y permite reconocerlo entre solicitudes sucesivas. • Se puede guardar cualquier tipo de información y hacer que ésta viaje con cada solicitud y respuesta.

35. Servlets: sesiones y cookies (II) • Java cuenta con una clase Cookie. • Cada vez que se quiera enviar una cookie a un cliente se la agrega al objeto HttpServletResponse: respuesta.addCookie(new Cookie("libro consultado",s)); • Método getCookies en la interfaz HttpServletRequest: Cookie[ ] cookiesCliente = s.getCookies; for (i = 0; i < cookiesCliente.length; i++) valor = cookiesCliente[i].getValue(); // trabajo con el valor }

36. Servlets: sesiones y cookies (III) • Interfaz HttpSession. • Para manejar datos de sesiones de clientes almacenados del lado del servidor. • Información sobre lo que se hace en el sitio. • Se va a desechar cuando deje el sitio. • Desde el método service se llama a getSession. • devuelve un objeto Session. • getAttribute y setAttribute permiten consultar y establecer el valor de un objeto de sesión • No es más que otro par (nombre, valor), pero almacenado del lado del servidor.

37. Páginas JSP (I) • Extensión de servlets para creación y manejo de páginas web dinámicas. • Más orientadas a mostrar también las partes estáticas de una página web. • Sintaxis más parecida al HTML que usualmente utilizan los programadores web. • La tecnología JSP incluye: • Un lenguaje para generar páginas dinámicas. • Construcciones para acceder a objetos en el servidor. • Mecanismos para definir extensiones al propio lenguaje JSP.

38. Páginas JSP (II) • Son páginas HTML con código Java para generar contenido en forma dinámica del lado del servidor. • Este código se indica al navegador rodeándolo de etiquetas especiales, entre <% y %>. • El contenedor web: • Busca las etiquetas en el texto HTML. • Genera servlets utilizando el código allí escrito. • Las ejecuta.

39. Páginas JSP (III) • La primera vez que algún cliente pide una página JSP al servidor web: • Se deriva al contenedor. • Éste verifica si ya se han generado y compilado las servlets que la soportan. • Si así fuera, se ejecutan las servlets, se genera la página HTML de resultado y se le envía al cliente. • Si las servlets no estuvieran generadas o fueran antiguas, se generan y se compilan antes de ejecutarlas. • Todo lo administra el contenedor web.

40. Páginas JSP (IV) - elementos • Scriptlets <% %> • Fragmentos de código Java totalmente libre. • Las variables declaradas en una scriptlet se pueden usar en cualquier parte de la página. • Expresiones <%= %> • Una porción de código que tiene como resultado un String y que se enviará directamente al cliente. • Las expresiones se vuelcan a un objeto PrintWriter predefinido que se llama out. • Directivas y declaraciones <%! o <%@ %> • Controlan la forma en que se traduce y ejecuta la página. • Comentarios <%-- --%> • No se envían al cliente.

41. JSP: ejemplo 1 <%-- Este comentario no aparece en el HTML del cliente --%> <%@ page import="java.util.*" %> <%! Date fecha = new Date(); int cuentaClics = 0; %> <html><body> <H1>Esta página se cargó a las <%= hora %> </H1> <H1>¡Hola! Hoy es <%= new Date() %></H1> <H3>La página ha sido accedida <%= ++cuentaClics %> veces desde el <%= fecha %></H3> <% System.out.println("Adiós"); out.println("Adiós"); %> </body></html>

42. JSP: ejemplo 2 <%@ page import="libreria.*" %> <% int visitas = 0; %> <html><body> <H1>Precio de libros</H1> <% String s = solicitud.getParameter("Libro"); Libro libro = new Libro(s); visitas++; %> <p>Precio: $ <%= precio(libro) %> </p> <p>Esta página fue visitada <%= visitas %> veces</p> <% response.addCookie(new Cookie("libro consultado",s)); %> </body></html>

43. JSP: otros elementos • Varios objetos y métodos predefinidos: • jspInit y jspDestroy, equivalentes a init y destroy de servlets • session, la sesión activa • application • out • page • Inclusión de archivos • <jsp:include page = "paginaIncluida.jsp" %>

44. Extensiones a JSP • Un lenguaje de expresiones <c:if condicion="${sesion.carro.cantItems > 0}"> ... </c:if> • Etiquetas definidas por el programador • “Custom Tags” • Struts, del proyecto Jakarta • Etiquetas en bibliotecas estándar. • JSTL • paquetes core, xml, sql, fmt

45. Contenedores web comerciales • Incluyen servlets y servidores de páginas JSP. • IBM WebSphere, BEA WebLogic, SunOne. • Proyecto Jakarta, del Apache Group: • Tomcat • ver http://jakarta.apache.org/ • Libre

46. Mensaje • Paquete de información que un sistema provee y otro está interesado en recibir, y que se envía asincrónicamente. • Email es asincrónico pero al menos un extremo es una persona. • RMI es entre sistemas, pero es sincrónico. • La comunicación es débilmente acoplada. • El receptor y el emisor de los mensajes son pares, sin una relación jerárquica, y ambos son servidores de aplicaciones. • Asincronismo significa que los mensajes se envían sin importar que haya quien los reciba.

47. Mensajería • Un software o biblioteca que provee la funcionalidad necesaria para enviar y recibir mensajes. • Permite asegurar al remitente que un mensaje enviado se recibió correctamente. • Por su naturaleza asincrónica, no se puede chequear la recepción en el momento en que se envía. • El acuse de recibo llega mediante otro mensaje. • En J2EE, JMS.

48. Tipos de mensajería (I) • Punto a punto • Trabaja con colas de mensajes. • Emisor envía un mensaje a la cola que le corresponde según alguna regla. • Receptores retiran mensajes de las colas a las cuales deben atender. • Los mensajes tienen un único consumidor, y una vez atendidos nadie más los recibe. • En algunos casos, se definen tiempos de expiración. • El receptor debe avisar que recibió el mensaje y lo está procesando, todo en forma asincrónica.

49. Tipos de mensajería (II) • Publicación-suscripción • Emisores y receptores son anónimos, en el sentido de que no necesariamente se conocen. • Receptores se subscriben por temas de interés. • Emisores envían los mensajes, también por tema, a los receptores que están en línea para recibirlos. • Cada mensaje puede tener muchos consumidores. • Puede ser recibido por ninguno, uno o muchos. • La recepción debe ser sincrónica, pues el receptor tiene que estar en línea para recibir el mensaje. • Responde al patrón de diseño Observador.

50. JMS (I) • Con J2EE pueden enviar mensajes JMS asincrónicos: • las aplicaciones cliente • los componentes EJB y web • Pero recibir mensajes asincrónicos, sólo: • aplicaciones cliente • EJB dirigidos por mensajes (message-driven beans) • todo otro componente sólo puede recibir mensajes síncronos