Sunteți pe pagina 1din 65

DESARROLLO DE APLICACIONES WEB USANDO J2EE Y SERVICIOS WEB

NDICE
1. Introduccin..................................................................3 2. Conceptos bsicos de J2EE............................................6 2.1.................................................................................M odelos multicapa para desarrollo de aplicaciones Web .................................................................................8 2.2.................................................................................Pa trn MVC..................................................................10 3. Servlets.........................................................................12 3.1.................................................................................Ci clo de vida de un servlet..........................................12 3.2.................................................................................Ej emplo simple de servlet...........................................15 3.3.................................................................................Ca ractersticas avanzadas de los Servlets....................15 3.3.1..........................................................................Pa rmetros de inicializacin....................................15 3.3.2..........................................................................Se guimiento de sesin............................................16 3.3.3..........................................................................Re envo de peticiones..............................................18 4. JSP (Java Server Pages).................................................19 4.1.................................................................................Ej ecucin de pginas JSP.............................................20 4.2.................................................................................El ementos de JSP........................................................21 4.2.1..........................................................................El ementos de script................................................22 4.2.2..........................................................................Ob jetos implcitos....................................................23 4.2.3..........................................................................Di rectivas................................................................23 4.2.4..........................................................................Ac ciones..................................................................26 5. EJB (Enterprise Java Beans)...........................................29 5.1.................................................................................La arquitectura Enterprise Java Bean............................30 5.1.1..........................................................................En terprise Java Beans..............................................30 5.1.2..........................................................................Co ntenedor EJB........................................................32

5.2.................................................................................Ti pos de Enterprise Java Beans...................................33 5.3.................................................................................Ve ntajas de la arquitectura Enterprise Java Beans.......34 6. Servicios Web................................................................37 6.1.................................................................................Q u es un servicio Web?.............................................37 6.1.1..........................................................................Ar quitectura de Servicios Web (WSA).....................37 6.2.................................................................................Fu ncionalidad de transporte de WSA: SOAP.................40 6.2.1..........................................................................Ti pos de mensajes SOAP........................................41 6.3.................................................................................Fu ncionalidad de descripcin de WSA: WSDL...............42 6.4.................................................................................Fu ncionalidad de descubrimiento de WSA: UDDI..........45 6.4.1..........................................................................Ti pos de registros UDDI..........................................47 6.5.................................................................................Im plementacin de la arquitectura WSA......................48 7. Otras referencias en Internet........................................51

1. INTRODUCCIN
Las aplicaciones Web son un modelo de desarrollo de aplicaciones distribuidas basadas en el protocolo IP que actualmente centran la atencin empresarial del mundo del software. Actualmente, para implementar este modelo software es necesario usar una plataforma de desarrollo capaz de proporcionar ciertos servicios a los diseadores de soluciones y a los programadores. Estas plataformas de desarrollo deben facilitar y automatizar hasta donde puedan el ciclo de vida completo de las aplicaciones distribuidas y deben tener en cuenta que los usuarios finales no solo son los clientes de las aplicaciones desarrolladas sino otros desarrolladores de soluciones que pueden usar los componentes modulares generados por el desarrollo distribuido y que puede ofrecer a los clientes. Esta ltima caracterstica se engloba dentro del llamado B2B (Business To Business), del cul el mximo exponente son los llamados servicios Web. En la ltima seccin de estos apuntes se analiza con ms profundidad esta tecnologa. Los requisitos de estas plataformas de desarrollo deben ser: 1. Escalabilidad: Ha de ofrecer una buena escalabilidad tanto horizontal como vertical de modo que si aumenta la carga del sistema podamos aadir servidores o ampliar los existentes sin que sea necesario realizar modificaciones. 2. Mantenibilidad: Ha de permitir aadir, modificar o eliminar componentes existentes sin que se modifique el comportamiento del sistema. 3. Fiabilidad: Debe ser capaz de seguir ofreciendo servicios a sus clientes a pesar de posibles fallos de los componentes del sistema. 4. Disponibilidad: Debe tener el soporte de arquitecturas tolerantes a fallos, sistemas de redundancia, etc., que aseguren que los sistemas estar siempre disponible. 5. Extensibilidad: Ha de ser posible aadir nuevos componentes y capacidades al sistema sin que se vean afectados el resto de componentes. 6. Manejabilidad: Los sistemas han de ser fcilmente manejables y configurables. 7. Seguridad: Se ha de proporcionar buenos sistemas de seguridad tanto a nivel de autenticacin, como de autorizacin y como de transporte. 8. Rendimiento: Se ha de ofrecer automticamente soporte de clustering, balanceo de carga, pools de objetos, pools de conexiones, caches, y en general mecanismos que permitan aumentar el rendimiento de manera transparente al usuario. En la actualidad las plataformas ms importantes son aquellas que disponen del apoyo de gran cantidad de empresas, entidades o

asociaciones y que disponen de grupos de estandarizacin que aseguren el futuro de las mismas. Ahora mismo las plataformas ms importantes son tres: CORBA .NET J2EE CORBA Sin duda, el modelo a seguir por cualquier plataforma empresarial. Las ventajas que ofrece CORBA son muy importantes: 1. Soporte de mltiples sistemas operativos. 2. Soporte de mltiples lenguajes. 3. Gran cantidad de servicios: mensajera, eventos, transacciones, persistencia, etc. 4. Controlada por un organismo: el OMG. Las ventajas son realmente muy importantes, an as, CORBA arrastra unos problemas que suponen un verdadero lastre: 1. Complejidad: CORBA es una plataforma de desarrollo muy compleja, aunque existen capas de abstraccin que facilitan el desarrollo de aplicaciones, lo cierto es que desarrollar un simple programa de "Hola Mundo" no es una labor trivial. 2. Burocracia: La evolucin de las especificaciones de CORBA est sujeta a demasiados pasos de burocracia, lo que origina que la evolucin de la plataforma sea lenta. 3. Pocas soluciones libres: Como consecuencia de su complejidad y de la lentitud de su evolucin se deriva que existen pocas soluciones libres. OpenORB es un ejemplo y existen algunos otros pero la cantidad no es demasiado elevada. .NET La plataforma de desarrollo empresarial de Microsoft desemboc en el panorama empresarial hace poco tiempo y ofrece a los desarrolladores algunas ventajas interesantes: 1. Soporte de mltiples lenguajes: Aunque no soporte todas sus caractersticas, lo cierto es que con .NET es posible desarrollar aplicaciones utilizando simultneamente varios lenguajes de programacin. 2. Ideal para entornos Microsoft: Si en nuestra empresa disponemos de gran cantidad de software y hardware dependiente de Microsoft, probablemente la mejor opcin para continuar desarrollando sea esta plataforma, ya que su integracin con los productos de la empresa es perfecta. 3. Visual Studio .NET: La plataforma .NET dispone de esta gran herramienta que adems de su potencia ofrece un entorno homogneo de desarrollo.

4. Requiere desarrolladores poco experimentados: Bajo la plataforma de desarrollo de Microsoft es posible utilizar lenguajes como VB .NET que hacen muy sencilla la creacin de aplicaciones empresariales. De este modo es posible tener un equipo de desarrolladores poco experimentados y sin embargo que stos puedan crear fcilmente aplicaciones. An as, si la lista de ventajas es bastante grande, la lista de desventajas no le tiene nada que envidiar: 1. No soporta mltiples sistemas operativos: El mundo de .NET gira en torno al sistema operativo Windows y aunque se estn intentando trasladar partes importantes de la plataforma, como el CLR (Common Language Runtime) o C#, a otros sistemas operativos, lo cierto es que estas partes forman una parte nfima de la totalidad de la plataforma de Microsoft. 2. Un nico dueo: La plataforma .NET est dominada nica y exclusivamente por Microsoft. Esto supone un grave problema ya que es una nica empresa la que puede aadir y quitar caractersticas segn crea conveniente. Adems esto hace que la competencia sea nula y no se estimula la evolucin de la plataforma. 3. Es una tecnologa inmadura: Con tan poco tiempo en el mercado, apenas ha salido algn proyecto importante desarrollado con esta tecnologa. Su inmadurez hace que probablemente deba pasar algn tiempo hasta que sea realmente productiva. 4. Pocas soluciones libres: No existe una correspondencia exacta entre las partes de la plataforma .NET y soluciones libres. Existen proyectos como Mono o dotGNU que estn portando algunas de sus partes, an as, no se puede crear una arquitectura completa utilizando solamente productos basados en software libre. J2EE J2EE, plataforma creada por SUN en el ao 1997, ofrece entre otras las siguientes ventajas: 1. Soporte de mltiples sistemas operativos: Al ser una plataforma basada en el lenguaje Java, es posible desarrollar arquitecturas basadas en J2EE utilizando cualquier sistema operativo donde se pueda ejecutar una mquina virtual Java. 2. Organismo de control: La plataforma J2EE est controlada por el Java Community Process (http://www.jcp.org) que es un organismo formado por ms de 500 empresas. Entre las empresas que lo forman estn todas las ms importantes del mundo informtico (SUN, IBM, Oracle, SAP, HP, AOL, etc. ) lo que garantiza la evolucin de la misma. 3. Competitividad: Muchas empresas crean soluciones basadas en J2EE y ofrecen caractersticas como rendimiento, precio, etc.,

muy diferentes. De este modo el cliente tiene una gran cantidad de opciones a elegir. 4. Madurez: Creada en el ao 1997 como respuesta a la tecnologa MTS de Microsoft, J2EE tiene ya varios aos de vida y una gran cantidad de proyectos importantes a sus espaldas. 5. Soluciones libres: En la plataforma J2EE es posible crear arquitecturas completas basadas nica y exclusivamente en productos de software libre. No slo eso, sino que los arquitectos normalmente disponen de varias soluciones libres para cada una de las partes de su arquitectura. An as, la plataforma de J2EE tambin tiene desventajas, algunas importantes: 1. Depende de un nico lenguaje: La plataforma J2EE depende exclusivamente del lenguaje Java. Slo se puede utilizar este lenguaje para desarrollar aplicaciones lo que puede suponer un gran problema si nuestro equipo no dispone de los conocimientos suficientes o tiene otras preferencias. 2. Complejidad: Aunque no es una plataforma tan compleja como CORBA, no existe un VB .NET en Java. La creacin de aplicaciones bajo J2EE requiere normalmente desarrolladores ms experimentados que los necesarios para desarrollar bajo .NET 3. Heterogeneidad: Existe una gran heterogeneidad en las soluciones de desarrollo. No existe en J2EE un smil a Visual Studio .NET. La gran cantidad de herramientas disponibles causa confusin dentro de los desarrolladores y puede crear dependencias dentro de las empresas.

2. CONCEPTOS BSICOS DE J2EE


J2EE es un marco de referencia (una especificacin) creada por SUN Microsystems para definir una serie de servicios mnimos que debe suministrar una plataforma empresarial, es decir, no es un producto que se pueda descargar y usar. Como todas las especificaciones del modelo de lenguaje Java, para cualquier propuesta debe crearse un JSR (Java Specification Request) que debe aprobarse por parte del JCP (en la direccin http://gul.uc3m.es/gul/cursos/doc/curso-javaswlibre.pdf hay un documento muy interesante explicando la historia del JCP y los JSRs). Este documento JSR debe describir de forma detallada los componentes y relaciones de la especificacin as como los roles que tendrn las personas involucradas en el desarrollo posterior usando dicha especificacin. Adems de este documento se debe proporcionar un test de compatibilidad y una implementacin de referencia. En este caso la especificacin J2EE est definida en el JSR151 (http://www.jcp.org/en/jsr/detail?id=151) en donde se define: Un conjunto de especificaciones. El CTS (Compatibility Test Suite) de J2EE La implementacin de referencia de J2EE Los J2EE Blueprints, que son un conjunto de guas de desarrollo y prcticas aconsejables.

Este conjunto de especificaciones son los servicios mnimos que debe garantizar la plataforma. Para la especificacin J2EE 1.4, este conjunto est compuesto por las siguientes APIs de java: JSR-109, (Servicios Web) JSR-101, (JAX-RPC, Java API for XML-based RPC) JSR-67, (JAXM, Java API for XML Messaging) JSR-93, (JAXR, Java API for XML Registries) JSR-77, (Configuracin y control de contenedores J2EE) JSR-88, (API de implantacin de aplicaciones J2EE sobre contenedores J2EE) JSR-115, (Java ACC, Interfaz de servicios de autorizacin para contenedores J2EE) JSR-56, (JNLP, Ejecucin remota de aplicaciones) JSR-112, (JCA 2.0, Arquitectura de conectores) JSR-152, (JSP 1.3, Java Server Pages) JSR-152, (Servlets 2.4) JSR-153, (EJB 2.1, Enterprise Java Beans) JSR-9XX, (JAXP 1.2 con soporte de esquemas XML) JSR-914, (JMS 1.1, API de mensajera)

Como se puede observar, el nmero de servicios que debe implementar el contenedor J2EE (o ms comnmente llamado servidor de aplicaciones, que es una implementacin de la

especificacin J2EE) es numeroso y deben estar disponibles para los desarrolladores por el hecho de utilizar la especificacin J2EE. En la Figura 2.1 se puede observar la arquitectura que queda definida con estos servicios. En la Figura 2.1 se puede observar que tpicamente los servidores de aplicaciones proporcionan otros servicios como pueden ser JavaMail o JNDI, adems de los definidos por las especificaciones de J2EE. Desde el punto de vista de arquitectura, se puede apreciar que J2EE define un modelo denominado modelo multicapa, que distribuye las funcionalidades ofrecidas por las aplicaciones en varios componentes distribuidos.

Figura 2.1.- Arquitectura J2EE

Existen un gran nmero de fabricantes que venden servidores de aplicaciones certificados J2EE (es decir, que cumplen el CTS) y se puede obtener una lista completa en: http://java.sun.com/j2ee/compatibility.html. Ejemplos significativos usados en entornos empresariales son: BEA WebLogic Server: http://www.bea.com Borland AppServer: http://www.borland.com IBM WebSphere ApplicationServer: http://www.ibm.com IONA iPortal Application Server: http://www.iona.com Sun ONE Application Server: http://www.sun.com Macromedia JRun Server: http://www.macromedia.com

10

Oracle Application Server: http://www.oracle.com Sun Java 2 SDK Enterprise http://java.sun.com/j2ee/download.html

Edition:

Todos estos servidores de aplicaciones son productos de pago. El nico que no es de pago, es el ltimo de estos, puesto que constituye la implementacin de referencia de Sun y no es eficiente para entornos de produccin. A pesar de ello es especialmente til para los fabricantes de servidores J2EE, para comprobar los test de compatibilidad y el rendimiento, y para los desarrolladores para probar sus aplicaciones sin usar ningn producto especfico. De esta manera se puede aplazar la decisin de implantacin del software de manera conveniente a los intereses del desarrollo y para producir prototipos rpidos para el cliente. Se dispone tambin de servidores de aplicaciones gratuitos (OpenSource), que permiten desarrollar aplicaciones J2EE sin necesidad de aadir cuantiosos gastos al proyecto usando alguno de los servidores anteriores (en general, son bastante caros): Tomcat: http://jakarta.apache.org/tomcat JBoss: http://www.jboss.org Evidan JOnAS: http://www.evidian.com/jonas OpenEJB: http://openejb.org El ms utilizado es, sin duda, Tomcat. La nica pega que se le puede poner es que no tiene soporte para la tecnologa EJB, caracterstica soportada en el resto de servidores de aplicaciones. De hecho, es posible configurar JBoss, JOnAS y OpenEJB para usar como contenedor Web (es decir, el soporte para Servlets y JSP) Tomcat. De todas maneras, existe una iniciativa del grupo apache para implementar el modelo de referencia J2EE completo (no slo los componentes JSP y Servlets) en un nuevo servidor de aplicaciones denominado Jernimo ( http://incubator.apache.org/projects/geronimo.html). Con independencia de qu servidor de aplicaciones se use, cualquier aplicacin J2EE es portable, es decir, debe funcionar igual en cualquiera de los servidores de aplicaciones mencionados antes. Esto se debe al uso de las especificaciones J2EE, que definen un conjunto de APIs estndar, lo que permite que cualquier servidor que cumpla el CTS (o lo que es lo mismo las especificaciones J2EE) es capaz de ser un entorno de produccin para la aplicacin J2EE. Esto quiere decir que las aplicaciones no dependen de un solo fabricante. Por tanto, la eleccin del servidor de aplicaciones se realiza teniendo en cuenta factores de rendimiento, servicios ofrecidos, seguridad y facilidades de administracin. En la direccin http://www.theserverside.com/reviews/matrix.jsp se encuentra una comparativa de distintos servidores de aplicaciones (desde el punto

11

de vista de tecnologas soportadas y tipo) junto con revisiones hechas por www.theserverside.com.

2.1 MODELOS MULTICAPA PARA DESARROLLO DE APLICACIONES WEB DISTRIBUIDAS


En la direccin http://www.tic.udc.es/~fbellas/teaching/is/Tema1.pdf existe una presentacin en PowerPoint muy interesante de introduccin a J2EE y los diferentes modelos multicapa que existen. En la Figura 2.2 se puede apreciar el modelo multicapa general que consta de: Capa de presentacin de cliente, que representa la interfaz grfica que utilizar el usuario de la aplicacin. Esta capa de encuentra en dispositivos muy variados que pueden tener mucha (por ejemplo un computador) o poca capacidad de procesamiento (por ejemplo un terminal mvil). Dentro de esta capa aparecen tecnologas como applets (usados dentro de pginas Web y que usan la mquina virtual Java del software navegador usado), y aplicaciones cliente Java, que usan una JVM (Mquina Virtual Java) y no estn restringidas por el modelo de seguridad de Java. Capa de presentacin de servidor, o ms comnmente denominada capa de presentacin web, que se encarga de tratar las peticiones que llegan al contenedor Web (normalmente a travs de peticiones de tipo HTTP y sus variantes) y generar las respuestas dinmicas adecuadas para el dispositivo (definido por la capa de presentacin de cliente). Dentro de esta capa aparecen lo que se denominan componentes Web del modelo J2EE: los servlets y las pginas JSP. Estos dos componentes se encargan de generar la informacin adecuada para las peticiones de la capa de presentacin de cliente. Capa de lgica de negocio, usada para mantener la informacin propia del dominio de la aplicacin (negocio). En el modelo J2EE est representada por los EJB (Enterprise Java Beans), que permiten centrarse slo en los componentes de la lgica de negocio, olvidndose de otros detalles, que sern implementados por la lgica (servicios) del servidor de aplicaciones. Por ejemplo, si la aplicacin representa una tienda de comercio electrnico se puede mantener el stock de la tienda, centrando el desarrollo del EJB en los detalles que definen la tienda, olvidndose de aspectos relativos a la gestin de seguridad, usuarios, persistencia, etc..., que proporcionar por ejemplo el servidor de aplicaciones. Capa de sistemas de informacin (legacy systems), que representa los sistemas ERP, como por ejemplo pueden ser las bases de datos o los sistemas de gestin.

12

Figura 2.2.- Modelo Multicapa General

Si se analiza con ms detalle la Figura 2.2 se pueden presentar muchos casos diferentes dependiendo de la complejidad y/o requerimientos de la aplicacin que se desee desarrollar. En el modelo de aplicacin web tpico (Vase la Figura 2.3) se utiliza una arquitectura de tres capas, donde la capa de presentacin de servidor y la capa de lgica de negocio se funden en una nica que es manejada por el contenedor web.

Figura 2.3.- Modelo de aplicacin Web de tres capas con J2EE.

Analizando el modelo de tres capas se puede observar que: 1. El navegador acta como capa de presentacin de cliente, permitiendo a ste interactuar con el contenedor J2EE a travs de peticiones HTTP o HTTPS (Secured HTTP). En otros entornos es posible que este navegador sea sustituido por dispositivos de otra naturaleza, como pueden ser un PDA o un dispositivo mvil con soporte WAP. 2. El contenedor J2EE maneja las capas de presentacin del servidor y la capa de modelo de negocio. En este modelo es normal usar los componentes Servlet y JSP para acceder a la capa de sistemas de informacin (tpicamente sistemas de

13

bases de datos) que en realidad actan como un servicio de persistencia para los modelos de la capa de negocio. Una vez que se tiene la informacin de la capa de sistemas de informacin se genera una vista (normalmente usando JSP) y se enva como respuesta a la peticin de la capa de presentacin de cliente. 3. Normalmente para acceder a la capa de sistemas de informacin se usa JDBC (API de Java para el acceso a bases de datos) a travs de un servlet. Este modelo de tres capas presenta un problema de escalabilidad, debido a que la lgica de negocio se integra con la capa de presentacin del servidor. Esto produce que no se puedan mover los componentes (clases Java que representan el modelo) a otras ubicaciones. Existe una alternativa que usa el modelo general de cuatro capas e integra las clases del modelo de negocio en los denominados EJB (Enterprise Java Beans), que son componentes Java especficos que implementan el funcionamiento de los llamados Java Beans (son clases normales Java, pero que definen una especificacin de acceso a los miembros de las clases), que se pueden mover a otras ubicaciones (implementan la interface java.rmi.Remote) y que integran los servicios ofrecidos por los servidores de aplicaciones (persistencia sobre una base de datos, seguridad de acceso, etc.). En la Figura 2.4 se muestra esta arquitectura.

Figura 2.4.- Modelo de aplicacin Web de cuatro capas con J2EE.

2.2 PATRN MVC


Las arquitecturas anteriores (tres y cuatro capas) siguen el patrn denominado MVC (Model-View-Controller), que define la comunicacin entre la capa de presentacin y la capa de modelo de negocio como se muestra en la Figura 2.5. En el patrn MVC los datos que maneja la aplicacin, la lgica de negocio y la vista que el usuario recibe estn explcitamente separados en tres objetos (distribuidos en una o dos capas) cada cul especializado en su tarea. La vista producir el aspecto visual que recibe la capa de presentacin del cliente. El

14

controlador interpreta los datos que recibe del usuario (analizando la peticin), coordinando la vista y el modelo para que la aplicacin produzca los resultados esperados. Y finalmente, el modelo maneja los datos y el estado de la aplicacin, respondiendo a las peticiones de informacin sobre su estado que hace la vista y respondiendo a las instrucciones que le da el controlador para que modifique su estado. Las ventajas de este modelo son: Facilidad de desarrollo y distribucin de tareas. Diseo de aplicaciones modulares. Mayor reutilizacin de cdigo. Facilidad para probar cada unidad por separado

Figura 2.5.- Patrn MVC.

Existen tres variantes del MVC que se usan en el diseo de aplicaciones web. En primer lugar est el denominado Modelo 1. ste est compuesto por un cliente web (es decir, que usa el protocolo HTTP para realizar peticiones y recibir respuestas) que realiza peticiones a pginas JSP. Las pginas JSP usan unos Java Beans como componente modelo, y se determina la siguiente vista a mostrar con los enlaces que se colocan en el cdigo fuente. Adems, cada pgina JSP (se pueden usar tambin servlets) procesa sus propias entradas (parmetros que vienen con las peticiones GET y POST). La segunda alternativa se denomina arquitectura Modelo 2 y usa un servlet como componente controlador, capturando las peticiones realizadas por el cliente web y redirigiendo las peticiones a la pgina JSP (o Servlet) adecuada. Por tanto, acta como un controlador que centraliza la lgica de seleccin de vistas en funcin de los parmetros recibidos. Las aplicaciones basadas en la arquitectura de Modelo 2 son ms fciles de mantener y ms escalables, dado que las vistas no se relacionan directamente, sino a travs del controlador. Este es el nico punto de acceso a la aplicacin web haciendo as ms fcil mantener la seguridad y los registros de la aplicacin. Un ejemplo de arquitectura Modelo 2 es el marco de trabajo Struts (http://jakarta.apache.org/struts/index.html) que implementa dicho modelo. Por ltimo, el Modelo 3, incorpora como clases que representan el modelo de negocio a los EJBs. En la Figura 2.6 se muestran la arquitectura de los modelos 2 y 3.

15

Figura. 2.6.- Arquitectura de los modelos 2 y 3.

3. SERVLETS
Los servlets, en su definicin ms simple, son clases java que permiten extender las capacidades de los servidores web y que forman parte de la especificacin J2EE. Histricamente surgieron como una respuesta alternativa a los CGI (Common Gateway Interface). El uso de los servlets es un porcentaje elevado en el desarrollo de pginas web dinmicas (en contenido y diseo) apoyndose adems en la potencia que proporciona el lenguaje Java. Se puede desarrollar desde un simple servlet que muestre una pgina web simple escribiendo la fecha y hora en que se realiza la peticin al contenedor Web, hasta uno que se conecte a una base de datos utilizando un pool de conexiones, encriptando la informacin en su envo, accediendo a bases de datos distribuidas y manteniendo su informacin de forma persistente en un EJB. Todo ello permite conseguir informacin de forma dinmica. A partir de aqu las posibilidades son infinitas. Adems de lo comentado anteriormente, los Servlets poseen las siguientes caractersticas: 1. Son independientes del servidor utilizado y de su sistema operativo, lo que quiere decir que a pesar de estar escritos en Java, el servidor puede estar escrito en cualquier lenguaje de programacin. 2. Los servlets pueden llamar a otros servlets, e incluso a mtodos concretos de otros servlets (en la misma mquina o en una mquina remota). De esta forma se puede distribuir de forma ms eficiente el trabajo a realizar. Por ejemplo, se podra tener un servlet encargado de la interaccin con los clientes y que llamara a otro servlet para que a su vez se encargara de la comunicacin con una base de datos. 3. Los Servlets pueden obtener fcilmente informacin acerca del cliente (informacin que se obtiene de las cabeceras del

16

4.

5. 6.

7.

protocolo HTTP), tal como su direccin IP, el puerto que se utiliza en la llamada, el mtodo utilizado (GET, POST), etc. Permiten adems la utilizacin de Cookies y Sesiones, de forma que se puede guardar informacin especfica acerca de un usuario determinado, personalizando de esta forma la interaccin cliente/servidor. Una clara aplicacin es mantener la sesin con un cliente. Los servlets pueden actuar como enlace entre el cliente y una o varias bases de datos en arquitecturas de 3 capas (si la base de datos est en un servidor distinto). Asimismo, pueden realizar tareas de Proxy para un Applet. Debido a las restricciones de seguridad, un Applet no puede acceder directamente a un servidor de datos localizado en cualquier mquina remota, pero s podra hacerlo a travs de un servlet. Al igual que los programas CGI, los servlets permiten la generacin dinmica de cdigo HTML. As, pueden emplearse servlets para la creacin de contadores, banners, etc.

3.1 CICLO DE VIDA DE UN SERVLET


Describir un Servlet es como describir una mquina de estados. Desde el momento que inicializamos el servlet hasta que el servlet es destruido, este, pasar por una serie de estados dependiendo de cada una de las situaciones ante las que se encuentre. El ciclo de vida de un servlet se muestra en la Figura 3.1. Antes de detallar el ciclo de vida de los servlets, es necesario analizar y comprender las clases bsicas y las interfaces usadas en la implementacin del servlet. Por tanto, se hace necesario hacer una revisin de la interfaz Servlet.

17

Figura 3.1.- Ciclo de vida de un Servlet.

Public Interface Servlet Todo servlet debe directa o indirectamente implementar este interfaz. Como cualquier otro interfaz de Java, ste es tambin una coleccin de declaraciones vacas de mtodos. Los siguientes mtodos estn declarados en el interfaz Servlet
public abstract ServletException. void init (ServletConfig config) throws

El mtodo init se usa para inicializar los parmetros proporcionados por el objeto ServletConfig. Se invoca slo una vez, a menos que el servlet sea reiniciado si se destruye y se vuelve a cargar. El mtodo init es el lugar en el que inicializar los parmetros de configuracin como la conexin con una base de datos, la inicializacin de archivos y otros valores de entorno. Ninguno mtodo del servlet puede ser invocado a no ser que el servlet est inicializado mediante el uso del mtodo init().
public abstract ServletConfig getServletConfig ()

Este mtodo proporciona el objeto ServletConfig para la inicializacin de los parmetros del servlet. Se pueden crear parmetros adicionales especificndolos en el archivo servlet.properties. Una vez que hayan sido especificados en este archivo, se puede acceder a ellos usando el objeto ServletConfig.

18

public abstract void service (ServletRequest req, ServletResponse res) throws ServletException, IOException.

El mtodo service es el punto esencial del modelo peticin respuesta del protocolo HTTP. Recibe una peticin del cliente en forma de objeto ServletRequest. Los parmetros del cliente son pasados junto al objeto de peticin, aunque existen otras formas de enviar parmetros desde el cliente al servlet, por ejemplo, usando cookies o por medio de una reescritura del URL. La respuesta resultante se enva al cliente usando el objeto ServletResponse.
public abstract String getServletInfo()

Este mtodo se usa para la extraccin de metadatos del servlet, como por ejemplo el autor, la versin del servlet, y otra informacin concerniente al copyright. El mtodo tendr que ser redefinido dentro del servlet para que devuelva esta informacin.
public abstract void destroy ()

El mtodo destroy se invoca para liberar todos los recursos solicitados como la base de datos, y otros recursos del servidor. Tambin se encarga de la sincronizacin de cualquier hilo pendiente. Este mtodo se llama una sola vez, automticamente, como el mtodo init. La clase GenericServlet proporciona una implementacin bsica del interfaz Servlet. Para escribir un servlet especficamente para el protocolo HTTP, se usa la clase HTTPServlet, que extiende a Generic Servlet (Vase la Figura 3.2)

Figura 3.2.- Herencia de clases para HTTPServlet.

Una vez analizada la interface Servlet, se puede apreciar en la Figura 3.1 que la primera vez que el servidor recibe una peticin hacia el servlet, se ejecutar el mtodo de inicio, init(), en el cual se realizan tareas de inicializacin (por ejemplo, inicializar variables globales del servlet). Una vez que se ha inicializado el servlet y est preparado se ejecuta su mtodo service(). Cada una de las peticiones que se reciban se atendern en hilos de ejecucin diferentes, a no ser que se indique lo contrario (usando la interface SingleThreadModel). Si se usa un servlet de tipo HTTP (HttpServlet), dependiendo del protocolo usado para las peticiones (mediante POST o GET) el servlet ejecutar el mtodo doPost() o el mtodo doGet(), que se

19

corresponden con el mtodo service() del Servlet. Finalmente, cuando el Servlet no sea necesario, se ejecutar el mtodo destroy(), en el cul se podrn realizar operaciones de eliminacin de las variables creadas en la inicializacin, cerrar conexiones con bases de datos, etc. Adems de los mtodos que heredan de la clase GenericServlet, la clase HttpServlet tiene mtodos adicionales para cada uno de los mtodos de respuesta HTTP: 1. 2. 3. 4. 5. 6. doDelete (HttpServletRequest, HttpServletResponse) doGet (HttpServletRequest, HttpServletResponse) doOptions (HttpServletRequest, HttpServletResponse) doPost (HttpServletRequest, HttpServletResponse) doPut (HttpServletRequest, HttpServletResponse doTrace (HttpServletRequest, HttpServletResponse)

3.2 EJEMPLO SIMPLE DE SERVLET


A la hora de escribir el cdigo de un servlet lo primero que se debe saber es que el servlet deber de heredar de la clase HttpServlet la cual contendr todos los mtodos necesarios para generarlo. Dicha clase la podemos encontrar en el paquete javax.servlet. import javax.servlet.*; public class EjemploServlet extends HttpServlet {} Solamente se debern sobrescribir aquellos mtodos que se consideren oportunos implementar en el servlet. Si por ejemplo no se necesita realizar ninguna inicializacin, no hara falta sobrescribir el mtodo init(). Por ejemplo, en el Listado 3.1, se ha implementado un servlet que escribe una pgina Web con el mensaje Hola Mundo.

20

import javax.servlet.*; import javax.servlet.http.*; public class MiPrimerServlet extends HttpServlet { public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { PrintWriter out; out = res.getWriter(); res.setContentType("text/html"); out.println("<html>"); out.println("<head><title>Ejemplo de Servlet </title></head>"); out.println("<body>); out.println("<h1>Hola Mundo/h1"); out.println("</body></html>"); } }

Listado 3.1.- Servlet Hola Mundo

Como se puede apreciar, la salida que se est generando es una pgina web (sus etiquetas). Es decir, se est generando el contenido de una pgina web de forma dinmica.

3.3 CARACTERSTICAS AVANZADAS DE LOS SERVLETS


Como se puede observar, el funcionamiento de un servlet es bastante sencillo, por lo que es relativamente fcil empezar a desarrollar servlets en aplicaciones a medida. Sin embargo, la tecnologa servlet ofrece una serie de caractersticas adicionales que permiten realizar operaciones ms complejas, 3.3.1 Parmetros de inicializacin Los parmetros de inicializacin proporcionan una forma de pasar informacin al servlet sin tener que escribir ni una lnea de cdigo en el programa. De esta manera es posible parametrizar el funcionamiento del servlet, por ejemplo, informacin sobre preferencias o configuracin (es muy habitual usar un parmetro llamado debug para poder realizar depuracin del cdigo de un servlet) que debe poder ser cambiada en tiempo de ejecucin. Normalmente estos parmetros se definen en el fichero web.xml, que es un fichero en formato XML, definido por la especificacin J2EE, usado para definir el comportamiento de la aplicacin web donde se utilizan los servlets (y el resto de componentes de la arquitectura J2EE). Para recuperar el valor de un parmetro de inicializacin se debe usar el mtodo getInitParameter (String nombre_parmetro) del objeto ServletConfig (que se puede recuperar usando el mtodo getServletConfig() del servlet) . Por ejemplo, se puede utilizar un

21

parmetro que defina si se aade un contador de visitas a las pginas generadas por el servlet (vase el Listado 3.2)
<servlet> aqu iran las opciones del servlet, nombre, clase, etc <init-param> <param-name>vercontador</param-name> <param-value>true</param-value> </init-param> . se pueden usar ms parmetros </servlet> Listado 3.2.- Definicin de los parmetros de inicializacin.

3.3.2 Seguimiento de sesin Uno de los problemas que presenta la interaccin mediante el protocolo HTTP se debe a que este protocolo es sin estado de conexin, lo que quiere decir que no almacena el estado o historia de las peticiones hechas. Esta caracterstica se presenta como un inconveniente muy grande por ejemplo en aplicaciones del rea del comercio electrnico, donde se hace necesario realizar un seguimiento de las acciones realizadas por el usuario (el caso tpico de una cesta de la compra). Para resolver este problema, existen dos alternativas que proporciona el conjunto HTML-HTTP: 1. Usar formularios HTML con campos escondidos. Estos permiten enviar datos con las peticiones HTTP, por lo que se pueden utilizar colocndolos en cada pgina que el usuario visite, de tal manera que se puede realizar el seguimiento de sesin del mismo. Esto obliga a que cada pgina debe ser generada dinmicamente y adems al enviar los campos escondidos como parte de la peticin se consume ancho de banda de la conexin, lo cual no es recomendable (especialmente en sitios de comercio electrnico bastante visitados). 2. Reescritura del URL de la peticin HTTP. Antes de realizar la peticin HTTP se codifican como campos de la peticin una secuencia de pares (nombre/valor) que se aaden al URL como una cadena de bsqueda (query). Esto implica que ya no es necesario generar las pginas de forma dinmica, pero sigue existiendo el problema de consumo de ancho de banda. Estas dos alternativas son bastante ineficaces (en el sentido de aprovechamiento del ancho de banda) e influyen negativamente en el rendimiento de la aplicacin Web. Para aliviar esta ineficacia se pueden utilizar dos mecanismos bsicos que soportan el seguimiento de sesin a travs de los servlet : 1. Utilizacin de cookies. Para implementar el seguimiento de las acciones de usuario se le pide al cliente que almacene una serie de piezas de informacin (cookies) que mantiene el estado de

22

las peticiones del usuario. Esto obliga al navegador del cliente a almacenar en alguna ubicacin dichas cookies, lo que aade complejidad al desarrollo del navegador. En una cookie se almacena informacin de la misma manera que en los mtodos anteriores pero una vez que se ha almacenado en el cliente, el servidor no tiene que reenviar dicha informacin en cada peticin, la aade el cliente cuando es necesario. El problema de esta alternativa (adems de la misma sobrecarga en el ancho de banda) es que normalmente la decisin de usar las cookies no depende del servidor de la aplicacin web, sino del usuario, con lo cual este puede decidir deshabilitarlas porque siente vulnerado su derecho a transmitir informacin privada de su configuracin. El API de la especificacin servlet proporciona mtodos para crear, aadir o eliminar las cookies a las peticiones y/o respuestas. 2. Utilizacin del objeto HttpSesion. Se almacena la informacin del usuario utilizando una estructura de datos (objeto) almacenado en el servidor. Este objeto es de la clase HttpSesion y permite recuperar la informacin asociada mediante un identificador de sesin asignado por el contenedor servlet. De esta manera el servidor almacena la informacin que necesita para realizar el seguimiento y elimina la sobrecarga en el ancho de banda en las interacciones peticinrespuesta con el cliente. Este ltimo mtodo es el ms flexible y el que ms opciones proporciona al desarrollador de aplicaciones web. Se puede acceder al objeto sesin (del tipo HttpSesion) del usuario a travs del mtodo getSession() del objeto HttpServletRequest. Se puede crear una sesin en cualquier momento usando una llamada al mtodo anterior pero con el parmetro create con el valor verdadero, getSession(true), de tal manera que si no existe ya, se crea una nueva. Bsicamente el objeto HttpSesion almacena pares de valores de la forma nombre/valor para la sesin. Se pueden almacenar y/o recuperar a travs de los mtodos setAttribute(name,valor) y getAttribute(name) como se muestra en la Tabla 3.1. Adems se puede eliminar cualquier variable de sesin usando el mtodo removeAttribute(name), de tal manera que se eliminan aquellos elementos que ya no son tiles en el seguimiento de sesin. Objeto devuelto Object Enumeration long String long int ServletConte Mtodo y parmetros getAttribute(java.lang.String name) getAttributeNames() getCreationTime() getId() getLastAccessedTime() getMaxInactiveInterval() getServletContext()

23

xt void boolean void void void

invalidate() isNew() removeAttribute(String name) removeValue(String name) setAttribute(String name, Object value) void setMaxInactiveInterval(int interval)
Tabla 3.1 Interface del objeto HttpSession.

Finalmente es posible finalizar una sesin desde un servlet usando el mtodo invalidate(), que adems de terminar la sesin elimina todas las variables asociadas a dicha sesin. 3.3.3 Reenvo de peticiones En el caso de aplicaciones complejas es probable que existan combinaciones diversas de applets, pginas jsp, servlets o pginas HTML. De esta manera es til poder transferir en un momento determinado el control desde un servlet a otro elemento de la aplicacin (servlet, pgina jsp o una pgina html). Por ejemplo en el modelo MVC, normalmente se hace necesario redirigir la peticin procesada por el servlet a la vista correspondiente (una pgina jsp). Esto se consigue usando el objeto RequestDispatcher, lo que proporciona una funcionalidad bastante simple para la transferencia de control. El mecanismo es bastante sencillo: 1. Se crea una URL con el elemento al que se desea transferir el control. 2. Se obtiene el objeto RequestDispatcher del contexto del servlet indicndole que se usar la URL anterior. 3. Se realiza la redireccin usando el mtodo forward(request,response) del objeto RequestDispatcher. El cdigo asociado a estos tres pasos se muestra en el Listado 3.3
URL elemento = new URL(http://servidor/path_to_element); RequestDispatcher dispatcher = getServletContext().getRequestDistpacher(elemento); dispatcher.forward(request,response); Listado 3.3.- Ejemplo de transferencia de control.

24

4. JSP (Java Server Pages)


Analizando la forma de generar el contenido dinmico que se hace con un Servlet surge la pregunta acerca de la conveniencia de utilizar servlets cuando parte del contenido es esttico, es decir, en situaciones normales slo una parte de la generacin del contenido se hace de forma dinmica. Si se analiza detalladamente la forma de generar las pginas, consiste en aadir lneas de texto con las etiquetas adecuadas para formatear en HTML la presentacin de los datos. Es decir, se est mezclando la generacin y/o actualizacin de la informacin con la presentacin de la misma. Sin duda, es ms conveniente separar la parte correspondiente a la actualizacin de la informacin de la presentacin. Adems, normalmente el diseador de pginas web (presentacin de los datos) no tiene porque ser conocedor de las tcnicas de programacin, y esta forma de generarlas obliga a dicho diseador a convertirse en un experto programador en el lenguaje Java. Evidentemente esto no es una buena alternativa en el sentido en que solamente la formacin de los diseadores eleva considerablemente el costo de las aplicaciones. Puesto que un diseador de pginas web conoce la forma de presentar la informacin usando etiquetas, la solucin al problema anterior debe proporcionar un conjunto de etiquetas especficas que permitan al diseador formatear contenido dinmico de manera equivalente a como se hace en HTML generando el contenido de una manera parecida a la usada en los servlets. Aqu surge la tecnologa JSP (JavaServer Pages), que permite incluir cdigo Java en las propias pginas web a travs de etiquetas personalizadas. El denominado contenedor JSP (que sera un componente del servidor web y por tanto del contenedor J2EE) es el encargado de tomar la pgina, sustituir el cdigo Java o la etiqueta personalizada que contiene por el resultado de su ejecucin, y enviarla al cliente. As, se pueden disear fcilmente pginas con partes fijas y partes variables. El Listado 4.1 es un ejemplo muy sencillo de pgina JSP.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <title>Ejemplo de pgina JSP</title> </head> <body> <h1> Bienvenido, hoy es <%= new java.util.Date() %> </h1> </body> </html> Listado 4.1.- Ejemplo de pgina JSP

Para ejecutar la pgina basta con colocarla en una aplicacin web (por ejemplo, usando Tomcat, y colocando la pgina en el directorio webapps/ROOT). No es necesario que sea en un directorio especfico

25

como ocurre con los servlets, sino que puede ir en cualquier directorio en el que se colocara normalmente una pgina HTML. La versin actual de la especificacin JSP es la 1.2. Esta es una especificacin paralela al API de servlets, concretamente a la versin 2.3, ya como se explicar mas adelante las pginas JSP son compiladas y convertidas en servlets. Se puede encontrar ms informacin sobre JSP en http://java.sun.com/products/jsp Aunque JSP y servlets parecen a primera vista tecnologas distintas, en realidad el servidor web traduce internamente el fichero JSP a un servlet, lo compila y finalmente lo ejecuta cada vez que el cliente solicita la pgina JSP. Por ello, en principio, las pginas JSPs y los servlets ofrecen la misma funcionalidad, aunque sus caractersticas los hacen apropiados para distinto tipo de tareas: 1. Las pginas JSP son mejores para generar pginas con gran parte de contenido esttico. Un servlet que realice la misma funcin debe incluir gran cantidad de sentencias del tipo out.println() para producir la salida en formato HTML. 2. Los servlets son mejores en tareas que generen poca salida, datos binarios o pginas con gran parte de contenido variable. En proyectos ms complejos, lo recomendable es combinar ambas tecnologas: los servlets para el procesamiento de informacin y las pginas JSP para presentar los datos al cliente.

4.1 Ejecucin de pginas JSP


Para entender el proceso de ejecucin de una pgina JSP es necesario conocer cul es la arquitectura de un contenedor JSP tal y cmo se muestra en la Figura 4.1. Como se puede apreciar siempre hay asociado al motor JSP un motor servlet. De esta manera cuando se realiza una peticin a una pgina JSP, se reenva el control al motor JSP, que comprueba si la pgina es nueva o ha cambiado. Si ocurre esto ltimo realiza la traduccin de la pgina y compila el resultado. Este proceso de traduccin es la parte principal del funcionamiento de la tecnologa JSP y consiste en traducir la pgina JSP en un servlet Java (su cdigo fuente). Este servlet java se compila mediante el compilador java estndar (por eso el motor JSP debe ejecutarse en una JVM, maquina virtual). Este proceso de traduccin y compilacin es el que ralentiza la ejecucin de las pginas JSP, pero una vez compiladas su velocidad de ejecucin es la misma que la de cualquier servlet.

26

Figura 4.1.- Arquitectura de un contenedor JSP.

El proceso que se desencadena cuando un cliente accede a una pgina JSP es el siguiente: 1. El motor JSP analiza la pgina solicitada. Si esta es nueva o ha cambiado, crea un fichero fuente java que se corresponde con el cdigo del servlet asociado. 2. El cdigo del servlet generado se compila para obtener el archivo de clase (con extensin class) correspondiente y se le pasa el control al motor servlet, de la misma manera que se hara si la peticin hubiese sido a un servlet desarrollado para la aplicacin. 3. El motor servlet carga la clase del servlet generado para poder ejecutarlo. 4. El servlet se ejecuta y devuelve su respuesta en formato HTML al cliente. Una vez servida la primera solicitud, las siguientes solicitudes ejecutan el cdigo compilado (a no ser que cambie el cdigo de la pgina). El servlet generado de manera automtica tiene un mtodo _jspService() que es el equivalente al service() de los servlets codificados manualmente. En este mtodo es donde se genera el cdigo HTML, mediante sentencias out.println y donde se ejecuta el cdigo java insertado en la pgina. Por ejemplo, la pgina del ejemplo del Listado 4.1 podra generar un servlet con estructura similar al siguiente:

27

public void _jspService(HttpServletRequest request, HttpServletResponse response) throws java.io.IOException, ServletException { JspWriter out = null; response.setContentType("text/html;ISO-8859-1"); out.println("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\">); out.println("<html>"); out.println("<head>"); out.println("<title> Ejemplo de pgina JSP</title>"); out.println("</head>"); out.println("<body>"); out.print("Bienvenido, hoy es "); out.println(new java.util.Date()); out.println("</body>"); out.println("</html>"); } Listado 4.2.- Mtodo _jspService()

El directorio donde se coloca el servlet generado, as como su nombre, dependen del contenedor JSP. Por ejemplo, Tomcat utiliza su directorio work/localhost/nombre_aplicacion_web. En caso de que la pgina est en ROOT1, el nombre de la aplicacin se sustituye por un carcter de subrayado (_).

4.2 Elementos de JSP


Existen tres tipos de elementos JSP que podemos insertar en una pgina web a travs de etiquetas personalizadas:

Elementos de script: podemos insertar etiquetas con cdigo Java de distintos tipos (declaraciones de variables y/o mtodos, expresiones, sentencias, etc.) que ser ejecutado en el contenedor JSP. Vase el apartado 4.2.1. Objetos implcitos: el motor JSP dispone de una serie de objetos accesibles por defecto para su uso en cualquier parte del cdigo que se inserte en las propias pginas JSP. Vase el apartado 4.2.2. Directivas: proporcionan informacin global de la pgina y permiten controlar distintos parmetros del servlet que se generar como resultado de la traduccin automtica de la pgina JSP. Vase el apartado 4.2.3. Acciones: proporcionan informacin al motor JSP sobre lo que debe hacerse a la hora de procesar la pgina JSP. Normalmente sirven para alterar el flujo normal de ejecucin de la pgina (p.ej. redirecciones), aunque tienen usos variados. Pueden ser

El contenido del directorio etiquetado como ROOT, situado en el subdirectorio WebApps de Tomcat, se usa como aplicacin web inicial que sirve las peticiones a la raz del sitio donde est instalado el servidor de aplicaciones. Es decir, acta como un fichero index.html en un servidor Web pero para las peticiones a los servlets y pginas JSP del servidor de aplicaciones.
1

28

acciones estndar, definidas en la especificacin JSP, o acciones propias generadas a travs de las llamadas libreras de etiquetas, que son semejantes a las etiquetas usadas en XML/HTML. Vase el apartado 4.2.4. Adems de las etiquetas de comentario en HTML, se pueden poner comentarios en una pgina JSP entre las etiquetas <%-- y --%>. El contenedor JSP ignorar todo lo contenido entre ambos. Dentro de los fragmentos de cdigo Java tambin se pueden colocar comentarios siguiendo la sintaxis habitual del lenguaje. 4.2.1 Elementos de script Hay tres formas de insertar cdigo Java en una pgina JSP: Expresiones, usando las etiquetas <%= expresin %>: en este caso, la expresin se evala, su resultado se convierte a String y se escribe en la salida usando el objeto predefinido out. La forma de traducir una expresin a cdigo del servlet es imprimindola en out (mediante una sentencia out.write(expresin) o similar). Un ejemplo de expresin sera:
<p>La raz cuadrada de 4 es: <%=java.lang.Math.sqrt(4)%></p>

Scriptlets, usando las etiquetas <% cdigo %>: el cdigo se ejecuta dentro del mtodo _jspService() del servlet generado. Esto permite ejecutar cdigo arbitrario, cuyo resultado no es necesario enviar a la salida. Si desde un scriptlet se desea escribir algo en sta, bastar con utilizar el objeto predefinido out (vase la seccin 4.2.2). Un uso normal de los scriptlets es hacer que ciertas partes de cdigo HTML aparezcan o no en funcin de una condicin, por ejemplo el cdigo del Listado 4.3.
<% java.util.Calendar ahora = java.util.Calendar.getInstance(); int hora = ahora.get(java.util.Calendar.HOUR_OF_DAY);

%> <b>Hola mundo, <i> <% if ((hora>20)||(hora<6)) { %> buenas noches <% } else if ((hora>=6)&&(hora<=12)) { %> buenos das <% } else { %> buenas tardes <% } %> </i> </b> Listado 4.3. Ejemplo de uso de un scriplet.

Declaraciones, usando las etiquetas <%! cdigo %>: se insertan en el cuerpo del servlet generado, fuera de sus mtodos. Esto da la

29

posibilidad de sobrescribir los mtodos jspInit() y jspDestroy() que son el equivalente en JSP de los mtodos init() y destroy() de los servlets. Las variables declaradas conservarn su valor entre sucesivas llamadas a la pgina, ya que son variables miembro del servlet generado y no locales al mtodo jspService(). Un ejemplo de declaracin podra ser el mostrado en el Listado 4.4.
<%! int i=0,j=10; %> <%! java.util.Date fecha_ahora = new java.util.Date(); %> <p>La hora actual es <%=fecha_ahora.toString()%></p> Listado 4.4.- Ejemplo de declaraciones

4.2.2 Objetos implcitos Los objetos implcitos son aquellos que estn accesibles al motor JSP, por lo que se puede hacer referencia a ellos cuando el desarrollador JSP los necesite. Estos objetos realmente se corresponden con objetos tiles del API de servlets (peticin, respuesta, ...) y que en realidad son variables instanciadas de manera automtica en el servlet generado a partir del JSP. Los objetos predefinidos en JSP se describen en la Tabla 4.1. Objeto
request respons e out

Significado
Objeto HttpServletRequest asociado con la peticin. Objeto HttpServletResponse asociado con la respuesta. Writer empleado para enviar la salida al cliente. La salida de las pginas JSP emplea un buffer que permite que se enven cabeceras HTTP o cdigos de estado aunque ya se haya empezado a escribir en la salida (out no es un PrintWriter sino un objeto de la clase especial JspWriter). Objeto HttpSession asociado con la peticin actual. En JSP, las sesiones se crean automticamente, de modo que este objeto est instanciado aunque no se cree explcitamente una sesin. Objeto ServletContext, comn a todos los servlets de la aplicacin web. Objeto ServletConfig, empleado para leer parmetros de inicializacin. Permite acceder desde un nico objeto a todos los dems objetos implcitos. Referencia al propio servlet generado (tiene el mismo valor que this). Como tal, en Java no tiene demasiado sentido utilizarla, pero est pensada para el caso en que se utilizara un lenguaje de programacin distinto. Representa un error producido en la aplicacin. Slo es accesible si la pgina se ha marcado como pgina de error (mediante la directiva page isErrorPage). Tabla 4.1.- Objetos implcitos de una pgina JSP.

session applicati on config pageCon text Page

Exceptio n

4.2.3 Directivas Una directiva se usa como informacin para el motor de JSP, de tal forma que ste genera la pgina en funcin de los valores de la directiva. En JSP se definen tres tipos diferentes de directivas que

30

debemos conocer: las directivas de pgina, las directivas de inclusin de ficheros y la directiva de librera de etiquetas. Directiva de pgina Se usa para definir atributos que se aplican a una pgina JSP entera as como a cualquier fichero esttico que se incluya con la directivas include" o <jsp:include>. La directiva page no se aplica sobre los ficheros dinmicos que se puedan incluir (ms adelante se detallar la diferencia entre un fichero esttico y otro dinmico para JSP). La sintaxis que presenta la directiva page es similar a la siguiente: <%@ page atributo="valor" %> La directiva page se puede especificar ms de una vez en una pgina JSP aunque por norma general su situacin siempre suele estar al comienzo del fichero. Aunque se pueden situar varias directivas page a lo largo de una pgina JSP, no se deben asignar diferentes valores para el mismo atributo ms que una sola vez, salvo en el caso del atributo import el cual, dado que su semntica es similar al import de java, s que se permite asignarlo varias veces para los ficheros java que se deseen importar. Los atributos ms importantes que la directiva page permite establecer son los que se muestran a continuacin: language="java": Define el lenguaje de script usado tanto en los scriptles, como en las declaraciones y expresiones del fichero JSP y de cualquier fichero incluido. Actualmente en la especificacin 1.2 de JSP el nico lenguaje permitido es Java por lo que este atributo tendr siempre este valor. session="true|false": Sirve para indicar la disponibilidad del objeto session para un cliente. El valor por defecto es true. buffer="none|8kb|sizekb": Se utiliza para indicar el tamao del buffer (siempre en kilobytes) que se utilizar por el objeto out para manejar la salida enviada desde la pgina JSP compilada hasta el navegador cliente. El valor por defecto es 8kb, aunque se puede indicar ningn valor (none) o un valor cualquiera. import= "{ package.class | package.* }, ...": Con este atributo indicamos una lista (separada por comas) de uno o ms paquetes o clases que el fichero JSP debera importar. De esta manera las clases importadas pueden ser utilizadas por los scriptlets, expresiones, declaraciones y etiquetas del fichero JSP.

31

autoFlush="true|false" : Mediante el autoFlush se indica si la salida ser enviada o no cuando el buffer de salida est lleno. Por defecto, el valor es true, con lo que el buffer ser descargado, si especificamos false, se lanzar una excepcin cuando el buffer se sobrecargue (esta excepcin deber ser manejada). isThreadSafe="true|false" : Indica si la seguridad de threads (hilos) est implementada (soportada) en el fichero JSP. Por defecto el valor asociado a este atributo es el de true lo que significa que el motor puede enviar mltiples solicitudes concurrentes a la pgina o dicho de otro modo varios threads pueden acceder a la pgina JSP y por lo tanto se hace necesario sincronizar nuestros mtodos para proporcionar seguridad de threads. info="text": Este atributo nos permite especificar una cadena de texto que es incorporada en el pgina JSP compilada. Posteriormente se puede recuperar esta cadena con el mtodo getServletInfo(). contentType="mimeType; charset=characterSet ": Se utiliza para indicar el tipo de contenido que se enva como respuesta al cliente as como el juego de caracteres utilizado. errorPage="Url": Sirve para indicar el fichero que se encargara de manipular las excepciones que se produzcan en la ejecucin del a pgina JSP. isErrorPage="true|false": Se utiliza para indicar si el fichero JSP va a mostrar o no una pgina de error. Si el valor que toma este atributo es true, significa que se puede usar el objeto exception, el cul contiene una referencia a la excepcin lanzada. El valor por defecto es false.

Directiva de inclusin de ficheros Se utiliza para incluir ficheros dentro de la pgina JSP cuando sta se traduce a un servlet. La sintaxis que presenta esta directiva es la siguiente: <%@ include file="url relativa del fichero a incluir" %> El contenido del fichero incluido puede ser HTML esttico, elementos de script, otras directivas o incluso acciones. Es interesante hacer una distincin entre includes estticos y dinmicos en JSP. Un include esttico significa que el texto del fichero incluido se aade al fichero JSP como si fuera parte del mismo. Por el contrario un include dinmico siempre acta sobre la solicitud de llamada al mismo, de

32

manera que el fichero dinmico se procesa y el resultado es lo que es incluido en la pgina desde la que se llama. En el caso de incluir un archivo con etiquetas HTML, hay que tener un cuidado especial en la colocacin de las etiquetas <%@ include url>, puesto que el fichero incluido se aade en la posicin donde se haya ubicado la etiqueta en la pgina JSP. Directiva de librera de etiquetas Esta directiva permite declarar una librera de acciones personalizadas identificada mediante su Uniform Resource Identifier (URI). Esta identificacin se hace a travs de un prefijo, lo que permite distinguirla del resto de etiquetas de accin. De esta manera, es posible ampliar el conjunto de etiquetas que el interprete de JSP es capaz de entender de manera que la funcionalidad del mismo puede ser prcticamente ilimitada. La sintaxis de esta directiva es la siguiente: <%@ taglib uri="url de la librera de etiquetas" prefix=prefijoEtiquetas %> El atributo uri especifica la ruta (relativa o absoluta) donde se encuentra el fichero que implementa y describe la librera (y por tanto las nuevas etiquetas). Este atributo esta asociado a un archivo denominado Tag Library Description (TLD), que es un archivo en formato XML que describe la coleccin de acciones implementadas en la librera. El atributo prefijo se usa para referenciar la accin que se desee usar en la pgina JSP, de tal manera que define un identificador de librera nico dentro de la pgina JSP. La forma de usar una accin dentro de la pgina JSP es utilizar la sintaxis <prefijoEtiquetas:nombreAccin>. Por ejemplo, se podra usar una librera de etiquetas llamada ejemplo que define una accin personalizada llamada escribehola que escribe una cadena de texto de valor Hola Mundo: <%@ taglib uri=www.dia.uned.es/taglibraries/ejemplo.tld prefix=uned %> <h1>Esto es un ejemplo <uned:escribehola /></h1> No se pueden usar los siguientes prefijos puesto que estn reservados a las etiquetas JSP del motor bsico del contenedor Web: jsp,jspx,javax,servlet,sun y sunw. 4.2.4 Acciones

33

Las acciones proporcionan informacin necesaria para la fase en que se realiza el proceso de traduccin y compilacin de la pgina JSP. Existen dos tipos de acciones: predefinidas y personalizadas. Las primeras siempre estn disponibles para el desarrollador de pginas JSP, mientras que las segundas se deben incorporar usando la directiva taglib que se ha explicado anteriormente. Hay que destacar que estas etiquetas diferencian entre maysculas y minsculas, adems de seguir la sintaxis de XML, por lo que deben tener una etiqueta de inicio y una etiqueta de fin. A continuacin se describen el conjunto de acciones predeterminadas que estn definidas: jsp:param Se utiliza para proporcionar informacin adicional (en la forma nombre/valor) que puede ser necesaria en las acciones jsp:forward, jsp:include y jsp:puglin, es decir, sirve para pasar parmetros entre invocaciones de pginas JSP. Su sintaxis es la siguiente: <jsp:param name=nombreParametro value={valor | < %=expresion%>} /> El atributo name identifica el nombre del parmetro, mientras que el atributo value permite asociar un valor al parmetro de dos maneras: de forma literal, indicando con una cadena de texto el valor asociado, o bien con una expresin JSP, lo que permite generar parmetros dinmicos. jsp:forward Sirve para reenviar la peticin a otra pgina que se especifica en el nico atributo (page) que esta accin contiene. Hay que indicar que cuando el motor JSP encuentra esta etiqueta, la peticin se pasa directamente a la nueva pgina, sin procesar el resto de la pgina que contiene la accin forward, por lo que el contenido del buffer de salida se pierde. La sintaxis es la siguiente: <jsp:forward page="{url relativa | <%= expresin%>}" /> [<jsp:param name=nombre value=valor | expresin />] </jsp:forward> Como se puede observar es posible incluir parmetros en la transferencia hacia el nuevo recurso, pasndole informacin que pudiera ser necesitada por el nuevo recurso.

34

jsp:include Se utiliza para insertar ficheros en una pgina que est siendo generada en el mismo momento en que la pgina es solicita y no cuando la pgina se transforma en servlet (a diferencia de la directiva include). Es decir, si se necesita incluir contenido dinmico en la pgina JSP es necesario usar esta accin, siendo ms til utilizar la directiva incluye para contenido esttico (por ejemplo, pginas HTML convencionales). La sintaxis de esta accin es la siguiente: <jsp:include page="{url relativa | <%= expresin%>}" flush=true /> [<jsp:param name=nombre value=valor | expresin />] </jsp:include> El atributo page se corresponde con la nueva pgina a incluir (que se puede generar de forma dinmica usando una expresin), mientras que el atributo flush siempre debe aparecer como true para indicar que se enve el vaciado del buffer de lectura a la nueva pgina. jsp:useBean Esta accin permite asociar una instancia de un objeto creado usando el lenguaje Java y definido en un mbito determinado con un identificador que permitir hacer referencia a ese objeto Java en el resto de la pagina JSP. Mediante esta accin se localiza el objeto Java si ya existe se crea uno nuevo en el caso de nos ser encontrado. <jsp:useBean id="name" scope=page|request|session| application class="paquete.clase" /> Los atributos que describen esta accin se detallan a continuacin Atributo id: proporciona un identificador al Bean con el que podr ser referenciado en el resto de la pgina JSP, es decir, podr ser usado en expresiones o scriplets. El nombre que se use sigue las mismas normas que la sintaxis Java. En el caso de haber creado anteriormente un Bean con un id determinado, para poder recuperarlo de nuevo es necesario utilizar el mismo nombre (siempre y cuando se utilice con un mbito de visibilidad de tipo sesin). Atributo scope: define el mbito de visibilidad del Bean definido y limita la existencia de ese Bean al mbito que se indique. El valor por defecto es page, aunque se pueden indicar cualquiera de los valores de la Tabla 4.2.

35

Atributo class: identifica la clase a partir de la cul se crear el objeto Bean correspondiente. Debido a la especificacin JavaBean es necesario que la clase tenga un constructor sin argumentos, ya que es la nica manera de crear el objeto sin conocimiento de la implementacin del mismo.

mbito de visibilidad De pgina (page)

Descripcin Los objetos que se declaran a este nivel son solo accesibles dentro de la pgina en la cual fueron creados. Las referencias de los objetos creados con alcance de pgina se almacenan en otro objeto denominado PageContext. De peticin En este caso los objetos declarados a este (request) nivel son accesibles por todas las pginas que van a procesar la misma peticin (request). Las referencias creadas sobre estos objetos se almacenan en el objeto ServletRequest. De sesin (session) Los objetos con alcance de sesin son accesibles por todas aquellas pginas que estn procesando peticiones dentro de la misma sesin en la cual el objeto fue creado. Las referencias de los objetos creados se almacenan dentro del objeto HttpSession. De aplicacin Es el nivel ms alto en el sentido en que los (application): objetos creados a este nivel son accesibles por todas las pginas que procesan peticiones dentro de la misma aplicacin. Las referencias se almacenan en el objeto
ServletContext Tabla 4.2.- mbitos de visibilidad de las variables Bean en una pgina JSP.

Para poder acceder a los atributos del JavaBean es necesario que este cumpla otra de las normas de la especificacin que indica que un atributo debe tener dos funciones: get() y set() para obtener y fijar el valor del atributo, de tal manera que dichas funciones se deben implementar en la clase con los nombre get<Nombre_Attributo>() y set<Nombre_Attributo>(tipo). De esta manera, desde el punto de vista del desarrollador de pginas JSP, se pueden establecer y modificar los valores de las propiedades (atributos) del Bean usando las acciones jsp:setproperty y jsp:getproperty jsp:getProperty

36

Como se ha dicho anteriormente, se usan para recuperar el valor de una propiedad de un Bean que ha sido creado con la accin jsp:useBean. Para usar esta accin debemos indicar el Bean a usar (atributo name) y la propiedad que queremos recuperar (atributo property), la sintaxis es como sigue: <jsp:getProperty name="nombre property="propiedad a recuperar"/> jsp:setProperty Sirve para establecer el valor de una propiedad de un Bean que ha sido creado con la accin jsp:useBean. Para usar esta accin debemos indicar el Bean a usar (atributo name), la propiedad que queremos establecer (atributo property) y el valor de la misma (atributo value), la sintaxis es como sigue: <jsp:getProperty name="nombre del property="propiedad a recuperar" value=valor/> jsp:plugin Esta accin nos permite insertar un elemento OBJECT o EMBED especfico del navegador utilizado para la ejecucin del Applet o Java Bean usando la tecnologa Java Plugin. Esta tecnologa permite asociar una mquina virtual java (en realidad un JRE, Java RunTime Environment) a la ejecucin de un Applet o JavaBean, salvando as el problema de la no disponibilidad de las nuevas versiones de las JVM en las distribuciones de los navegadores ms comerciales. bean" del bean"

37

5. EJB (ENTERPRISE JAVA BEANS)


La tecnologa Enterprise JavaBeans es la propuesta del mundo Java (Sun y un amplio grupo de empresas colaboradoras entre las que no se encuentra Microsoft) para el desarrollo de aplicaciones de empresa. Se entiende por aplicaciones de empresa las aplicaciones informticas de gestin que se implantan en grandes corporaciones con mltiples oficinas distribuidas por toda la geografa nacional (o internacional). Suelen ser aplicaciones distribuidas, usadas por mltiples clientes, que hacen un uso intensivo de transacciones, bases de datos y polticas de seguridad. La arquitectura Enterprise JavaBeans es el ncleo del modelo de negocio de la arquitectura J2EE y hace uso intensivo de libreras incluidas en esta plataforma. Ejemplos de APIs Java representativos que son usados por la arquitectura EJB son los siguientes: JNDI, API para sistemas de nombramiento de recursos y servicios de directorio. JMS, API para la comunicacin a travs de mensajes (soporta el modelo igual a igual y el modelo de suscripcin). JTA, API para soporte de transacciones. JDBC, API para soporte de acceso a bases de datos.

La tecnologa Enterprise JavaBeans esta siendo apoyada por la mayor parte de las empresas de informtica que se orientan al mundo de la empresa (IBM, ORACLE, SUN,...) y tambin por los clientes de estas empresas, que valoran de forma muy positiva, entre otros aspectos, el carcter abierto de la arquitectura. Por eso, la especificacin EJB debe alcanzar los siguientes objetivos: Definir una arquitectura de componentes estndar con la que construir aplicaciones de gestin (business applications) distribuidas y orientadas a objetos en el lenguaje de programacin Java. Enterprise JavaBeans permitir construir aplicaciones combinando componentes desarrollados por herramientas de distintas compaas.

La arquitectura Enterprise JavaBeans har fcil la construccin de aplicaciones. Los desarrolladores de aplicaciones no tendrn que entender los detalles de bajo nivel referidos al manejo de transacciones, manejo de estado, multithreading, pooling de recursos y otras API's complejas de bajo nivel.

Las aplicaciones Enterprise JavaBeans seguirn la filosofa escribe una vez, ejecuta en cualquier sitio del lenguaje de programacin Java. Un Enterprise Bean puede desarrollarse una

38

vez, y despus desplegado en mltiples plataformas sin necesidad de recompilarlo o modificar su cdigo fuente. Para alcanzar estos objetivos, la arquitectura EJB define seis papeles principales: Desarrollador de Beans: desarrolla los componentes Enterprise Beans.

Ensamblador de aplicaciones: compone los Enterprise Beans y las aplicaciones cliente para conformar una aplicacin completa. Desplegador: despliega la aplicacin en un entorno operacional particular (servidor de aplicaciones).

Administrador del sistema: configura y administra la infraestructura de computacin y de red del negocio. Proporcionador del Contenedor EJB proporcionador del Servidor EJB: un fabricante fabricantes) especializado en manejo de transacciones y aplicaciones y otros servicios de bajo nivel. Desarrollan servidor de aplicaciones. y (o de el

5.1 LA ARQUITECTURA ENTERPRISE JAVA BEANS


La arquitectura de componentes Enterprise JavaBeans (arquitectura EJB) es el ncleo de la plataforma J2EE. Esta arquitectura de componentes combina lo mejor de los monitores de procesamiento de transacciones y de los componentes distribuidos, proporcionando un entorno al estilo de los monitores de transacciones orientado a componentes distribuidos. La arquitectura EJB est constituida por un conjunto de componentes software llamados Enterprise Beans y un contenedor EJB que da soporte de ejecucin a estos componentes. 5.1.1 Enterprise Java Beans Un EJB es un componente software del lado del servidor, que debe ser desplegado sobre un contenedor de EJBs. Un EJB est formado por varios ficheros, que consisten en interfaces y clases Java y un descriptor de despliegue en formato XML. El contenedor consiste en un entorno software sobre el que pueden ejecutarse los EJBs (de la misma manera que ocurre con Servlets y pginas JSP), les proporciona servicios bsicos (seguridad, transacciones, etc) y controla su ciclo de vida. Independientemente del nmero de objetos que formen un EJB, ste siempre es accesible para el cliente a travs de una nica interfaz, que como el resto del EJB, debe cumplir la especificacin. Cumplir la especificacin implica implementar y extender ciertas interfaces, exponiendo unos determinados mtodos. La especificacin

39

EJB 2.0 define tres tipos de EJB's: Session Beans, que modelan procesos de negocio; Entity Beans, que modelan datos del negocio (lo que se conoce como modelo de persistencia); y Message-driven Beans, similares a los Session Beans pero con la diferencia de que slo pueden invocarse mediante el uso de tcnicas de paso mensajes. Una de las principales funciones del contenedor es la de funcionar como un proxy entre el cliente y los EJBs. El contenedor pone a disposicin de los componentes una serie de servicios conocidos como middleware. Estos servicios middleware consisten en aspectos tales como la seguridad, persistencia, o transacciones. Tradicionalmente, como por ejemplo en CORBA, el middleware ha sido explcito. Esto significa que las llamadas a mtodos de APIs que ofrecieran estos servicios tenan que escribirse mezcladas con el resto del cdigo de la lgica de negocio. En las nuevas tecnologas basadas en componentes, el middleware es implcito. Esto significa que el desarrollador de los EJBs slo tiene que preocuparse de escribir cdigo que implemente la lgica de negocio, y puede olvidarse de escribir cdigo para controlar el acceso a datos, la seguridad, o la persistencia. Para obtener estos servicios, es suficiente con declararlo en el descriptor de despliegue, un fichero que se escribe en XML. Cuando despleguemos los EJBs el contenedor leer el descriptor y sabr qu servicios debe poner a disposicin de los EJB's. De esta manera, cuando el cliente invoque mtodos del EJB, el contenedor se interpone asegurndose de que se cumpla todo lo declarado en el descriptor, y es entonces cuando se delega la invocacin al EJB. Como ya se ha dicho un EJB est formado por varios ficheros. El principal es la clase Enterprise Bean, que es donde el desarrollador implementar el cdigo del EJB (mtodos de negocio). Es una clase Java que implementa una interfaz definida en la especificacin. Los mtodos de esa interfaz (mtodos de gestin) permiten al contenedor gestionar el EJB y avisarle cuando suceden eventos importantes. Pero como se ha explicado antes, el cliente no invoca de manera directa a los mtodos de la clase Enterprise Bean. El objeto que se interpone entre el cliente y la clase Bean se llama objeto EJB. Es un objeto inteligente, que entiende de redes, transacciones, seguridad, etc., y que sabe cmo llevar a cabo lgica intermedia que pueda requerirse antes de delegar la invocacin a la instancia de la clase Bean. El objeto EJB expone al cliente los mismos mtodos de negocio que tiene la clase Bean. El objeto EJB es generado por el contenedor, y para que ste sea capaz de hacerlo el desarrollador debe escribir una interfaz especial llamada interfaz remota, que contenga todos los

40

mtodos de negocio de la clase Bean y que extienda la interfaz javax.ejb.EJBObject. Esta interfaz extiende la interfaz javax.ejb.Remote, que es parte de RMI-IIOP (Remote Method Invocation over the Internet Inter-ORB Protocol). Por lo tanto, como el objeto EJB implementa la interfaz remota, esto hace que los objetos EJB sean objetos remotos, es decir, que puedan ser invocados desde otras mquinas virtuales Java. En la Figura 5.1 se puede observar cmo el objeto EJB se interpone entre el cliente y la instancia del Bean, responsabilizndose de los servicios middleware. El cliente invoca un mtodo de negocio que el objeto EJB expone a travs de la interfaz remota. Entonces, antes de llamar al mtodo correspondiente en el Bean, el objeto EJB utiliza los servicios middleware que proporciona el contenedor segn como se haya declarado en el descriptor de despliegue. Despus delega la invocacin al Bean, ese mtodo del Bean le devuelve al objeto EJB un valor de retorno, y el objeto EJB pasa ese mismo valor al cliente.

Figura 5.1.- Llamadas al EJB.

El EJB y el cliente estarn probablemente en mquinas diferentes. Para usar el EJB, el cliente necesitar una referencia al mismo, algo que el cliente no puede ni debe conocer a priori si se pretende garantizar la transparencia de localizacin. Para obtener esa referencia, el cliente pide un objeto EJB a otro objeto llamado objeto home, que instanciar el objeto EJB pedido por el cliente. El objeto home tiene tres funciones bsicas: crear objetos EJB, encontrar objetos EJB existentes, y eliminar objetos EJBs. El objeto home, como el objeto EJB, es generado por el contenedor. Pero necesita informacin para saber cmo inicializar los objetos EJB que crea. Para proporcionar al contenedor esta informacin, el desarrollador debe escribir una interfaz especial que el objeto home implementar, de la misma manera que el objeto EJB implementa la interfaz remota. A esta interfaz se le llama interfaz home y extiende la

41

interfaz javax.ejb.EJBHome. Esta interfaz tambin extiende la interfaz javax.rmi.Remote y por lo tanto los objetos home son objetos remotos. En la Figura 5.2 se observa la creacin de un objeto EJB a travs del objeto home. El proceso comienza cuando el cliente invoca el mtodo de creacin correspondiente en el objeto home. Entonces el objeto home crea el objeto EJB, inicializndolo con los parmetros que ha pasado el cliente tal y como lo defini el desarrollador en la interfaz home. Por ltimo, una vez creado el objeto EJB, el objeto home devuelve una referencia del mismo al cliente, para que ste pueda invocar los mtodos de negocio que expone en la interfaz remota, como se representa en la Figura 5.1.

Figura 5.2. Funcionalidad del objeto home.

5.1.2 Contenedor EJB Como se ha dicho antes, los EJBs se ejecutan en un entorno especial denominado contenedor EJB. El contenedor hospeda y maneja un Enterprise Bean de la misma forma que un servidor Web Java hospeda un servlet o un navegador hospeda un applet. Un Enterprise Bean no puede funcionar fuera de un contenedor EJB. El contenedor EJB maneja cualquier aspecto del bean en tiempo de ejecucin, incluyendo acceso remoto al bean, seguridad, persistencia, transacciones, concurrencia y acceso y pooling de recursos (vase la Figura 5.3). El contenedor EJB tambin suele proporcionar servicios relacionados con la escalabilidad de la aplicacin, como son la definicin de clusters de contenedores, el balanceo de carga o la tolerancia a fallos.

42

Figura 5.3: Servicios del contenedor EJB

El contenedor EJB asla el Enterprise Bean del acceso directo de las aplicaciones cliente. Cuando una aplicacin cliente invoca un mtodo remoto en un Enterprise Bean, el contenedor intercepta la invocacin para asegurar que la persistencia, transacciones y seguridad se aplican correctamente. De esta forma, el desarrollador de beans puede concentrarse en encapsular correctamente la lgica de negocio, mientras que el contenedor se encarga de todo lo dems. El contenedor EJB se ejecuta a su vez en una mquina virtual Java, con lo que tiene acceso a toda la infraestructura proporcionada por este lenguaje de programacin. Los contenedores manejan muchos beans simultneamente, en la misma forma que un servidor web Java maneja muchos servlets. Para reducir el consumo de memoria y el procesamiento, los contenedores almacenan (pool) los recursos y los ciclos de vida de los beans de forma muy cuidadosa. Cuando un bean no est siendo usado, el contenedor lo colocar en un almacn para ser reusado por otro cliente, o lo eliminar de la memoria y slo lo recuperar cuando sea necesario. Debido a que las aplicaciones clientes no tienen acceso a los beans, la aplicacin cliente desconoce completamente las actividades de manejo de recursos del bean. Por ejemplo, un bean que no est siendo usado puede ser eliminado de la memoria, mientras que su referencia remota en el cliente permanece intacta. Cuando el cliente invoca un mtodo sobre la referencia remota, el contenedor simplemente recupera el bean para dar servicio a la peticin. La aplicacin cliente no se da cuenta de todo este proceso. Un Enterprise Bean depende del contenedor para todo lo que necesita. Si un Enterprise Bean tiene que acceder a una conexin JDBC o a otro Enterprise Bean, lo hace a travs del contenedor; si un Enterprise Bean tiene que acceder a la identidad de su llamador, obtener una referencia a l mismo, o acceder a propiedades, lo hace a travs del contenedor.

43

5.2 Tipos de Enterprise Java Beans


Los componentes Enterprise Bean encapsulan tpicamente un proceso o una entidad de negocio. Un Enterprise Bean, por ejemplo, podra calcular los pagos de inters de un prstamo, o encapsular la informacin sobre una cuenta bancaria que se encuentra fsicamente en una base de datos relacional. Un cliente que necesita informacin llama a los mtodos de negocio en el bean y esta llamada provoca una invocacin remota que llega al contenedor EJB. En la especificacin 2.0 de la arquitectura EJB se definen tres tipos de beans: Los beans de sesin (Session EJBs) realizan una tarea a peticin de un cliente, pero no se corresponden con ninguna entidad persistente de negocio (tpicamente bases de datos). Pueden ser a su vez de dos tipos: con estado (statefull) y sin estado (stateless). El estado lo almacenan localmente en la memoria, no en almacenamiento secundario, y dura el tiempo que est activa la sesin con el cliente.

Los beans de entidad (Entity EJBs) representan objetos persistentes de negocio, normalmente datos existentes en alguna o algunas bases de datos del negocio. Tpicamente, un bean de entidad representa una fila de una tabla de una base de datos relacional. Aqu tambin existen dos tipos de EJBs: BMP (Bean Managed Persistence) y CMP (Container Managed Persistence). En el caso del Entity BMP EJB, el modelo de persistencia lo asume el propio Bean (y por tanto el desarrollador del mismo) y normalmente se usa JDBC para la lgica que define cmo y cundo debe ser accedida/actualizada/guardada la informacin. En el caso del Entity CMP EJB, el contenedor genera la lgica de actualizacin y acceso a la informacin usando algn esquema (normalmente en formato XML) que relaciona los atributos del EJB con una o varias tablas de la base de datos.

Los beans dirigidos por mensajes permiten procesar mensajes asncronos generados por otros beans o por aplicaciones externas que necesitamos conectar al sistema.

El cliente que usa los beans es una aplicacin Java independiente, un servlet o una pgina JSP. En cualquier caso se trata de cdigo Java que tiene acceso a las interfaces definidas para cada bean, existiendo dos tipos de acceso a los beans: Acceso remoto. El cliente usa RMI-IIOP para comunicarse con el bean. El desarrollador del bean define dos tipos de interfaces: la mencionada interfaz remota, en la que se definen la interfaz de los procesos de negocio, y la interfaz home, en la

44

que se definen la interfaz de los mtodos de gestin (creacin, borrado, etc.) de las instancias del bean. Acceso local. Si el cliente se ejecuta en la misma mquina virtual Java que el bean, puede acceder a versiones locales de las interfaces. De esta forma no es necesario serializar los parmetros ni los valores devueltos por el bean, mejorndose la eficiencia de las llamadas.

5.3 Ventajas de la arquitectura Enterprise Java Beans


La arquitectura EJB proporciona beneficios a todos los papeles que se han mencionado previamente (desarrolladores, ensambladores de aplicaciones, administradores, desplegadores, fabricantes de servidores). Las ventajas que ofrece la arquitectura Enterprise Java Beans a un desarrollador de aplicaciones se muestran a continuacin: Simplicidad. Debido a que el contenedor de aplicaciones libera al programador de realizar las tareas del nivel del sistema, la escritura de un Enterprise Bean es casi tan sencilla como la escritura de una clase Java. El desarrollador no tiene que preocuparse de temas de nivel de sistema como la seguridad, transacciones, multithreading o la programacin distribuida. Como resultado, el desarrollador de aplicaciones se concentra en la lgica de negocio y en el dominio especfico de la aplicacin.

Portabilidad de la aplicacin. Una aplicacin EJB puede ser desplegada en cualquier servidor de aplicaciones que soporte J2EE.

Reusabilidad de componentes. Una aplicacin EJB est formada por componentes Enterprise Beans. Cada Enterprise Bean es un bloque de construccin reusable. Hay dos formas esenciales de reusar un Enterprise Bean a nivel de desarrollo y a nivel de aplicacin cliente. Un bean desarrollado puede desplegarse en distintas aplicaciones, adaptando sus caractersticas a las necesidades de las mismas. Tambin un bean desplegado puede ser usado por mltiples aplicaciones cliente.

Posibilidad de construccin de aplicaciones complejas. La arquitectura EJB simplifica la construccin de aplicaciones complejas. Al estar basada en componentes y en un conjunto claro y bien establecido de interfaces, se facilita el desarrollo en equipo de la aplicacin.

Separacin de la lgica de presentacin de la lgica de negocio. Un Enterprise Bean encapsula tpicamente un proceso o una entidad de negocio (un objeto que representa datos del negocio), hacindolo independiente de la lgica de presentacin. El programador de gestin no necesita de

45

preocuparse de cmo formatear la salida; ser el programador que desarrolle la pgina Web el que se ocupe de ello usando los datos de salida que proporcionar el bean. Esta separacin hace posible desarrollar distintas lgicas de presentacin para la misma lgica de negocio o cambiar la lgica de presentacin sin modificar el cdigo que implementa el proceso de negocio. Despliegue en muchos entornos operativos. Entendemos por entornos operativos el conjunto de aplicaciones y sistemas (bases de datos, sistemas operativos, aplicaciones ya en marcha, etc.) que estn instaladas en una empresa. Al detallarse claramente todas las posibilidades de despliegue de las aplicaciones, se facilita el desarrollo de herramientas que asistan y automaticen este proceso. La arquitectura permite que los beans de entidad se conecten a distintos tipos de sistemas de bases de datos.

Despliegue distribuido. La arquitectura EJB hace posible que las aplicaciones se desplieguen de forma distribuida entre distintos servidores de una red. El desarrollador de beans no necesita considerar la topologa del despliegue. Escribe el mismo cdigo independientemente de si el bean se va a despleguar en una mquina o en otra (esto se ha modificado un poco con la especificacin 2.0, al introducirse la posibilidad de los interfaces locales).

Interoperabilidad entre aplicaciones. La arquitectura EJB hace ms fcil la integracin de mltiples aplicaciones de diferentes vendedores. El interfaz del Enterprise Bean con el cliente sirve como un punto bien definido de integracin entre aplicaciones.

Integracin con sistemas no-Java. Las API's relacionadas, como las especificaciones Connector y Java Message Service (JMS), as como los beans manejados por mensajes, hacen posible la integracin de los Enterprise Beans con sistemas no Java, como sistemas ERP o aplicaciones mainframes.

Recursos educativos y herramientas de desarrollo. El hecho de que la especificacin EJB sea un estndar hace que exista una creciente oferta de herramientas y formacin que facilita el trabajo del desarrollador de aplicaciones EJB.

Entre las ventajas que aporta esta arquitectura al cliente final, se puede destacar la posibilidad de eleccin del servidor, la mejora en la gestin de las aplicaciones, la integracin con las aplicaciones y datos ya existentes y la seguridad: Eleccin del servidor. Debido a que las aplicaciones EJB pueden ser ejecutadas en cualquier servidor J2EE, el cliente no queda ligado a un vendedor de servidores. Antes de que

46

existiera la arquitectura EJB era muy difcil que una aplicacin desarrollada para una determinada capa intermedia (Tuxedo, por ejemplo) pudiera portarse a otro servidor. Con la arquitectura EJB, sin embargo, el cliente deja de estar atado a un vendedor y puede cambiar de servidor cuando sus necesidades de escalabilidad, integracin, precio, seguridad, etc. lo requieran. Existen en el mercado algunos servidores de aplicaciones gratuitos (JBOSS, el servidor de aplicaciones de Sun, etc.) con los que sera posible hacer unas primeras pruebas del sistema, para despus pasar a un servidor de aplicaciones con ms funcionalidades. Gestin de las aplicaciones. Las aplicaciones son mucho ms sencillas de manejar (arrancar, parar, configurar, etc.) debido a que existen herramientas de control ms elaboradas.

Integracin con aplicaciones y datos ya existentes. La arquitectura EJB y otras APIs de J2EE simplifican y estandarizan la integracin de aplicaciones EJB con aplicaciones no Java y sistemas en el entorno operativo del cliente. Por ejemplo, un cliente no tiene que cambiar un esquema de base de datos para encajar en una aplicacin. En lugar de ello, se puede construir una aplicacin EJB que encaje en el esquema cuando sea desplegada.

Seguridad. La arquitectura EJB traslada la mayor parte de la responsabilidad de la seguridad de una aplicacin del desarrollador de aplicaciones al vendedor del servidor, el Administrador de Sistemas y al Desplegador (papeles de la especificacin EJB). Las personas que ejecutan esos papeles estn ms cualificados que el desarrollador de aplicaciones para hacer segura la aplicacin. Esto lleva a una mejor seguridad en las aplicaciones operacionales.

An siendo grande la lista de ventajas, se le pueden hacer varias objeciones que se consideran desventajas de la arquitectura: Tiempo de desarrollo. El desarrollo de un sistema EJB es bastante complejo, aunque para ciertas empresas puede ser una solucin ideal. Para otras muchas empresas es una solucin que supera las expectativas necesarias para la solucin que se pretende desarrollar (normalmente se puede generar la aplicacin usando Servlets, pginas JSP y JavaBeans).

Nivel de programacin alto. EJB es uno de los principales componentes de la arquitectura J2EE y por tanto est fuertemente relacionada con otras partes del modelo como pueden ser RMI, JDNI o JDBC. Esto hace que el conocimiento del desarrollador se deba ampliar con un conocimiento adecuado de muchas partes del modelo J2EE.

47

Se recomienda al alumno la lectura del artculo sobre la implementacin de un EJB de sesin sin estado en la direccin http://www.programacion.com/java/tutorial/javabeans/. En esta direccin adems hay un apartado sobre Fundamentos de la arquitectura EJB que es muy interesante leer.

48

6. SERVICIOS WEB
De los captulos anteriores se puede deducir que de todos los tipos de desarrollo el modelo Web ha sido el que ms rpidamente y ampliamente ha sido adoptado si se compara con cualquier otra aproximacin de desarrollo de aplicaciones distribuidas. El extraordinario xito del modelo Web puede atribuirse a una caracterstica fundamental: es un modelo ms dbilmente acoplado que los modelos de programacin distribuida tradicionales como RPC, RMI, DCOM y CORBA. Las interacciones entre clientes y servidores Web son sencillas: intercambian mensajes que transportan datos de tipo MIME, y la semntica de un mensaje puede modificarse utilizando cabeceras. El destino de un mensaje se especifica indirectamente utilizando una URL, y este nivel de indireccin puede aprovecharse para implementar balance de carga, seguimiento de sesiones y otras funcionalidades. La simplicidad de las interacciones en el modelo de programacin Web posibilita construir sistemas incrementalmente. A diferencia del acoplamiento fuerte de RPC y de los sistemas de objetos distribuidos, que requieren la implantacin de todas las piezas de una aplicacin de una vez, se pueden aadir tantos clientes y servidores a sistemas basados en Web como se necesiten. Se pueden establecer fcilmente conexiones a aplicaciones nuevas de un modo descentralizado, sin ninguna coordinacin central ms all del registro de nombres DNS, y con un grado de interoperabilidad, escalabilidad y capacidad de gestin extraordinariamente alto. La idea bsica tras los servicios Web es adaptar el modelo de programacin Web dbilmente acoplado a su uso en aplicaciones que no estn basadas en el navegador. El objetivo es proporcionar una plataforma para construir aplicaciones distribuidas utilizando software que se ejecute en distintos sistemas operativos y dispositivos, escrito utilizando distintos lenguajes de programacin y herramientas de mltiples fabricantes, desarrollado e implantado de forma independiente.

6.1 Que es un servicio Web?


Los servicios Web parecen ser la ltima de las nuevas tecnologas que han llegado a la Informtica. Dar una definicin de un servicio web es algo bastante complicado, de hecho si se realizara la pregunta a varios expertos, se obtendran al menos seis respuestas. A pesar de eso, todo el mundo est de acuerdo en que un servicio web representa
un recurso de informacin o un proceso de negocio, al cul otra aplicacin puede acceder a travs de la Web, y con el cul se puede comunicar a travs de protocolos estndares de Internet.

Lo que distingue a los servicios web de otros tipos de aplicaciones basadas en Web es que los servicios web estn diseados para

49

soportar la comunicacin de una aplicacin con otra aplicacin. Otros tipos de aplicaciones Web soportan comunicacin entre personas (mensajera instantnea o correo) o comunicacin persona-aplicacin (navegadores de Internet). Los servicios Web estn diseados para permitir que las aplicaciones se comuniquen si intervencin humana. 6.1.1 Arquitectura de Servicios Web (WSA) Los principios de diseo de las aplicaciones distribuidas basadas en servicios web tienen su origen en lo que se denomina Arquitectura Orientada a Servicios (SOA, Service-Oriented Architecture). Como ejemplos de esta arquitectura se pueden nombrar tecnologas tan conocidas como RPC, RMI, CORBA o DCOM. En la Figura 6.1 se muestra el modelo arquitectnico de SOA. Los tres componentes fundamentales del modelo son: 1. Proveedor del servicio, encargado de hacer que el servicio este disponible. Para ello debe publicar un contrato que describa la interfaz del servicio que ofrece y registrarlo a travs del agente de servicio. 2. Cliente del servicio, que busca el servicio que necesita (operacin find() de la Figura 6.1) o al menos uno compatible con sus necesidades. Esto lo hace a travs del agente de servicio. 3. Agente del servicio, que ofrece a los clientes un mecanismo de bsqueda de los servicios previamente registrados por los proveedores. Una vez que el cliente ha encontrado el servicio que necesita, el agente le da al cliente las direcciones donde puede encontrar el servicio y el contrato del mismo. Con este contrato el cliente puede enlazar la aplicacin con el servicio ofertado.

Figura 6.1.- Arquitectura SOA.

50

Para acompaar a los tres componentes fundamentales del modelo SOA, un sistema que implemente este modelo debe soportar tres funcionalidades bsicas: a) Transporte, es decir como se representan los formatos (tipos de datos y flujos de bytes usados para codificar y decodificar los mensajes) y protocolos usados para comunicarse con un servicio. b) Descripcin, encargada de definir y usar un lenguaje de descripcin adecuado para el servicio. Se deben describir las operaciones soportadas por el servicio (parmetros y formato de los mensajes), as como la manera de enlazar el servicio con las aplicaciones. A partir de este lenguaje de descripcin es posible generar de forma dinmica y esttica el cdigo de comunicacin as como los delegados y esqueletos necesarios. c) Descubrimiento, encargada de representar el mecanismo usado para registrar o encontrar un servicio y su contrato o descripcin. A partir de esta SOA nace lo que se conoce como Arquitectura de Servicios Web (WSA, Web Services Architecture, vase la Figura 6.2) que converge el modelo SOA y el uso de la Web como modelo de comunicacin. La caracterstica principal de WSA es que es independiente de la plataforma y del lenguaje, lo que significa que un servicio web puede ser desarrollado en cualquier lenguaje y puede ser implantado en cualquier plataforma: desde un mvil hasta un supercomputador.

Figura 6.2.- Modelo arquitectnico WSA.

Se puede pensar en WSA como un middleware de Internet, por lo que no se hace necesario crear un nuevo conjunto de protocolos. El protocolo bsico de los servicios Web es XML (eXtended Markup Language), que se usa como formato de los mensajes de datos,

51

adems de usarse como base de otros protocolos de WSA, en concreto SOAP, WSDL y UDDI. La utilizacin de XML garantiza la independencia del lenguaje y de la plataforma, de tal manera que los servicios Web utilizan un lenguaje comn, que adems de ser un estndar, permite describir las interfaces de las operaciones y codificar los mensajes. Pero XML, por si solo, no puede implementar los protocolos de comunicacin puesto que las aplicaciones necesitan formatos estndares y protocolos que permitan interpretar de forma apropiada los datos XML. Para ello, se han desarrollado tres estndares de facto: Protocolo Simple de Acceso a Objeto (SOAP, Simple Object Access Protocol), que define un protocolo estndar de comunicacin para los servicios Web. Lenguaje de Descripcin de Servicios Web (WSDL, Web Services Description Language), que define un mecanismo estndar para describir un servicio Web. Servicio de descripcin universal, descubrimiento e integracin (UDDI, Universal Description, Discovery and Integration), que proporciona un mecanismo estndar para registrar y encontrar servicios Web.

En la Figura 6.3 se muestra la relacin entre las tecnologas que se describen anteriormente y cmo implementa el modelo SOA. El proveedor de servicio describe el servicio usando WSDL y registra el servicio en un registro UDDI. Este registro UDDI mantiene punteros a la descripcin WSDL y al servicio. Cuando un cliente necesita usar el servicio hace una bsqueda en el registro UDDI y cuando encuentra el servicio que satisface sus necesidades, recupera del UDDI la descripcin WSDL y el punto de acceso al servicio Web. Finalmente el cliente usa la descripcin WSDL para construir los mensajes SOAP que se usaran para comunicarse con el servicio.

52

Figura 6.3.- Relacin entre SOAP, WSDL y UDDI.

En la Tabla 6.1 se hace una comparacin de las caractersticas de los distintos modelos SOA comparados con la arquitectura de servicios Web (WSA). Java RMI
Mecanismo de invocacin Formato de los datos Formato de comunicacin Protocolo de transferencia Descripcin de la Interfaz Mecanismo de descubrimiento Tabla 6.1.Java RMI Serializacin Java Flujo de bits JRMP (Java Remote Method Protocol) Interfaces Java

CORBA
CORBA RMI CDR (Common Data Representation) GIOP (General Inter-ORB Protocol) IIOP (Internet Inter-ORB Protocol) CORBA IDL

Web Services
JAX-RPC, .NET, XML SOAP HTTP. SMTP, JMS WSDL

Registro Java Servicio de nombres UDDI (RmiRegistry) (COS naming) Comparacin de formatos y protocolos SOA con WSA.

6.2. Funcionalidad de transporte de WSA: SOAP.


SOAP es un protocolo de mensajera basado en XML extensible que forma la base de los servicios Web. SOAP proporciona un mecanismo simple y consistente que permite a una aplicacin enviar un mensaje XML a otra aplicacin. Fundamentalmente, la comunicacin SOAP es una comunicacin punto a punto. Un mensaje SOAP es enviado por un emisor SOAP a un receptor SOAP, y cualquier aplicacin puede ser o un emisor o un receptor SOAP. Los mensajes SOAP pueden ser combinados para soportar varios tipos de comunicacin, por ejemplo peticin/respuesta, solicitud de respuesta o notificacin.

53

SOAP fue inicialmente desarrollado por las empresas DevelopMentor, Microsoft y UserLand como un RPC basado en XML para Windows. A principios del 2000 se unieron Lotus e IBM y propusieron una especificacin abierta y extensible: SOAP 1.1 (http://www.w3c.org/TR/SOAP/) que fue enviada al Consorcio W3C. ste inicio la estandarizacin de dicha versin y el resultado es la especificacin SOAP 1.2. Bsicamente SOAP est compuesto de cuatro partes: (envelope). Se utiliza para proporcionar un mecanismo de identificacin de los contenidos del mensaje y para decidir cmo se debe procesar el mensaje. Un envoltorio SOAP se compone a su vez de dos partes: la cabecera SOAP y el cuerpo SOAP. La cabecera SOAP proporciona un mecanismo flexible que permite aadir informacin de control o directivas de mensaje. Adems, al ser extensible, una cabecera SOAP se puede usar para implementar la lgica asociada a: Transacciones Seguridad, por ejemplo, con el estndar de seguridad WS-Security Fiabilidad, por ejemplo, con el estndar WSReliableMessaging Redireccionamiento Mecanismos de facturacin. Cuerpo SOAP (body). Transporta la carga til que ser enviada con el mensaje SOAP. Puede corresponder a un documento XML o una invocacin remota. Marco de trabajo de enlace de transporte SOAP. Define el mecanismo de transporte que se puede usar al enlazar un cliente con el servicio Web. SOAP 1.2 define un enlace de transporte por defecto asociado al protocolo HTTP, pero tambin hay especificaciones disponibles para SMTP, JMS y otros. Marco de trabajo de Serializacin SOAP. Puesto que todos los datos de los mensajes SOAP estn codificado con XML, es necesario definir cmo se realiza esta codificacin. El marco de Serializacin define si los datos se pasan como un documento XML normal, se le aplica alguna codificacin especificada por ejemplo en un esquema XML (http://www.w3c.org/XML/Schema) o se usan las reglas originales definidas para SOAP.
Envoltorio SOAP

6.2.1 Tipos de mensajes SOAP Bsicamente se pueden definir dos tipos (estilos) de mensajes SOAP

54

Mensajes de tipo RPC, basados en la representacin SOAP RPC. La representacin SOAP RPC define una convencin de programacin que representa las peticiones y respuestas RPC. Usando RPC, el desarrollador formula una peticin SOAP como un mtodo con cero o ms parmetros. Cuando se construye la carga til (el cuerpo del mensaje SOAP) se representa el mtodo en una estructura simple donde el elemento (etiqueta) ms exterior est representado por el nombre del mismo, y los elementos internos representan los parmetros de la operacin. La respuesta SOAP es similar, de tal manera que el elemento ms externo representa de nuevo el nombre del mtodo y los elementos externos los resultados devueltos. Mensajes de tipo Documento, que permite enviar documentos XML. Esto es posible puesto que el emisor es el que enva el mensaje y el receptor determina qu hacer con el. Realmente el emisor no necesita saber qu hace el receptor con el mensaje ni cmo se implementa el servicio, slo cul es el formato del mensaje y el punto de acceso (normalmente un URI).

Adems de estos dos tipos de mensajes SOAP hay una especificacin de mensaje que permite incluir archivos no XML a los mensajes (http://www.w3c.org/TR/SOAP-attachments). De esta manera se pueden aadir archivos de tipo multimedia que no estn codificados con XML. Esta especificacin obliga a usar tipos MIME (para ser ms exactos, la codificacin) para dichos ficheros.

6.3 Funcionalidad de descripcin de WSA: WSDL


WSDL es un vocabulario XML para describir un servicio Web. Un documento WSDL describe qu funcionalidad ofrece un servicio Web, cmo se comunica y dnde es accesible (es decir, indica el punto de acceso). WSDL proporciona un mecanismo estructurado que describe: Las operaciones que un servicio Web puede realizar. Los formatos de los mensajes que puede procesar. Los protocolos que soporta. El punto de acceso al servicio.

Normalmente cualquier herramienta de desarrollo SOAP puede usar una descripcin WSDL de forma automtica para generar un interfaz que se pueda usar (y enlazar) en una aplicacin cliente. Una descripcin WSDL define una coleccin de puntos de acceso de red o puertos. Cada puerto se define de forma abstracta con su tipo, que soporta un conjunto de operaciones. Cada operacin procesa un conjunto particular de mensajes. Un enlace (binding) relaciona un tipo de puerto con un protocolo y un formato de datos.

55

Puesto que un documento WSDL es un documento XML con la descripcin del servicio, ste contiene los elementos que describen el servicio. En concreto: 1. Tipos (etiqueta <types>). Los elementos de tipo definen los tipos de datos usados dentro de los mensajes. WSDL usa el sistema de tipo de datos definido en la recomendacin del W3C sobre esquemas XML (en concreto, en la parte 2) llamada Recomendacin de tipos de datos (disponible en la direccin http://www.w3.org/TR/xmlschema-2/) como sistema cannico, aunque se puede usar cualquier sistema de tipificacin de datos. El sistema del W3C soporta datos simples y estructuras complejas, que pueden ser relacionados directamente con sus tipos correspondientes en los lenguajes de programacin que soportan la recomendacin. Las herramientas SOAP usan la informacin de tipo para codificar y decodificar los datos de los mensajes SOAP. 2. Mensajes (etiqueta <message>). Un mensaje define el formato de un mensaje particular. Los mensajes se usan como estructuras de entrada o salida para las operaciones soportadas por el servicio Web. Un mensaje puede estar compuesto por una o varias partes, cada una de las cuales est asociado a un tipo. Cuando se usa el estilo RPC para el documento SOAP, cada parte representa un parmetro del mtodo. 3. Tipo de puerto (etiqueta <portType>). Un tipo de puerto representa un conjunto de operaciones. Cada elemento u operacin (etiqueta <operation>) define los mensajes de entrada y salida asociados a la operacin. Cuando se usa el estilo RPC para el documento SOAP, cada parte operacin representa un mtodo. 4. Enlace (etiqueta <binding>). Un elemento enlace relaciona las operaciones y mensajes definidos por un tipo de puerto a un protocolo concreto y una especificacin de formato de datos. Por ejemplo, el enlace puede asociar un tipo de puerto a una interfaz especfica SOAP RPC que usa el protocolo HTTP para el transporte y el sistema de codificacin de datos SOAP. 5. Servicio (etiqueta <service>). Define una coleccin de puertos relacionados. Un elemento puerto (etiqueta <port>) relaciona un enlace con la localizacin (una direccin URL) de una instancia del servicio Web. Usando estos elementos para la definicin del documento WSDL se puede dividir en tres partes (vase la Figura 6.4): 1. Interfaz abstracta. Se denomina parte qu del documento WSDL y describe la interfaz abstracta del servicio Web. Esencialmente describe un tipo de servicio, es decir, el conjunto de operaciones que implementa el servicio (es decir, usa los elementos tipo de puerto, mensajes y tipos).

56

2. Enlace concreto. Se denomina parte cmo del documento WSDL y describe la asociacin de la interfaz abstracta con un conjunto concreto de protocolos. Se usa el elemento enlace (binding). La parte cmo incluye o importa la parte qu del documento WSDL asociado. 3. Implementacin. Se denomina parte dnde del documento WSDL y describe la implementacin del servicio. Para ello se utiliza el elemento servicio. Un proveedor de servicio siempre debe publicar la parte dnde del documento WSDL con el servicio Web.

Figura 6.4.- Partes de un documento WSDL

En la Figura 6.5 se puede ver la descripcin de un servicio Web disponible en la direccin web de la empresa XMethods Inc. (http://www.xmethods.org) que mantiene un listado de servicios web accesibles. En este caso se presenta el servicio Web que define el cambio de moneda (Currency Exchange Rate) para diferentes pases. En la direccin http://www.xmethods.org/ve2/ViewListing.po;jsessionid=4Sam-9mxlt92gXGB8WRsD0u(QhxieSRM)?key=uuid:D784C184-99B2-DA25ED45-3665D11A12E5 se puede ver la descripcin completa del servicio, as como los diferentes clientes que se han creado para usar este servicio.

57

Figura 6.5.- Descripcin WSDL del servicio de cambio de moneda.

En esta direccin se puede apreciar adems cmo son los mensajes SOAP RPC que se transmiten durante el funcionamiento del servicio Web. Como se puede ver en la Figura 6.5 hay dos tipos de mensajes SOAP RPC: uno de peticin (<message name=getRateRequest>) y uno de recepcin (<message name=getRateResponse>) que usan el estilo de documento RPC con las reglas de codificacin dadas por el esquema de tipos del W3C (representadas por las etiquetas xsd:string y xsd:float). Para cada mensaje definido en la descripcin WSDL se generan dos mensajes SOAP RPC, uno para el de peticin (vase Listado 6.1) y otro para la respuesta (vase Listado 6.2). Como se puede apreciar en los dos listados se sigue el estilo de documento RPC definido para el funcionamiento de SOAP RPC. En el caso del mensaje de peticin el cuerpo tiene un elemento ms externo con el

58

nombre del mtodo (getRate) y dos elementos ms externos (country1 y country2) con los parmetros del mtodo y sus valores (Euro y Usa).
<SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/ xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:getRate xmlns:ns1="urn:xmethods-CurrencyExchange" SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"> <country1 xsi:type="xsd:string">euro</country1> <country2 xsi:type="xsd:string">usa</country2> </ns1:getRate> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Listado 6.1.- Mensaje SOAP RPC de peticin del valor de cambio de moneda.

En el mensaje de respuesta (getRateResponse) slo es necesario devolver un valor (return) con el valor del dato pedido.
<SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/ xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:getRateResponse xmlns:ns1="urn:xmethods-CurrencyExchange" SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"> <return xsi:type="xsd:float">1.14</return> </ns1:getRateResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Listado 6.2.- Mensaje SOAP RPC de respuesta del servicio web de cambio de moneda.

Resumiendo todo lo anterior, se puede decir que los elementos tipo, mensaje y tipo de puerto definen un servicio de forma abstracta (de hecho, una descripcin WSDL con slo esos tres elementos constituye la descripcin del servicio Web). El elemento enlace permite relacionar el servicio con un protocolo especfico mientras que el elemento servicio relaciona el tipo de servicio y el enlace a una instancia especfica del servicio. Los elementos enlace y servicio pueden ser mantenidos en documentos WSDL distintos a fin de obtener ms flexibilidad y reutilizacin.

6.4 Funcionalidad de descubrimiento de WSA: UDDI


UDDI proporciona un mecanismo para registrar y categorizar los distintos servicios Web que se pueden ofertar a los clientes y que stos deben poder localizar a travs de dicho mecanismo. UDDI es tambin un servicio Web, por lo cual se pueden usar mensajes SOAP para usar este servicio.

59

Un registro UDDI contiene la informacin sobre los negocios (empresas) y servicios que ofrecen. La informacin se puede organizar de la siguiente manera:
Entidad de negocio.

Contiene informacin sobre el negocio incluyendo su nombre, una descripcin corta y alguna informacin bsica de contacto. Cada negocio tiene asociado un identificador nico y una lista de categoras que describen el negocio. En la versin 2 de UDDI es posible adems aadir nuevas categoras. Servicio de negocio. Asociado a la entidad de negocio existe una lista de servicios ofertados por dicha entidad. Cada servicio de negocio contiene una descripcin del servicio, una lista con las categoras asociadas y una lista de patrones de enlace contienen informacin tcnica sobre el servicio. Patrones de enlace. Proporcionan informacin sobre cmo usar el servicio y dnde encontrarlo (por ejemplo, un patrn de enlace puede contener el punto de acceso a la implementacin del servicio). Adems el patrn de enlace asocia el servicio de negocio con un tipo de servicio. Tipo de servicio. Define un servicio de forma abstracta, a travs de una estructura llamada tModel. Varias entidades de negocio pueden ofrecer el mismo tipo de servicio, soportando la misma interfaz de servicio. Una estructura tModel especifica informacin como el nombre del tModel, el nombre de la organizacin que publica la estructura tModel, la lista de categoras que describen el tModel y los punteros a las especificaciones tcnicas del tModel. Por ejemplo, un tModel puede apuntar al documento WSDL que describe el tipo de servicio de forma abstracta.

El funcionamiento de UDDI es bastante sencillo: cuando se necesita utilizar un servicio web, un desarrollador hace una bsqueda en el registro UDDI, especificando el tipo de servicio que se desea. De la entrada para el tipo de servicio del tModel, el desarrollador puede obtener una descripcin WSDL que describe la interfaz del servicio. De la entrada (o entradas) del patrn de enlace puede obtener el enlace al servicio y el punto de acceso. Finalmente usando la descripcin WSDL obtenida antes, es posible construir una interfaz de cliente SOAP que se puede comunicar con el servicio Web. En la Figura 6.6 se puede apreciar qu existen dos entradas de patrones de enlace a dos entidades de negocio (A y B) que implementan el mismo tipo de servicio (tModel). De esta manera es posible realizar el enlace con la aplicacin cliente de dos maneras: a) De forma esttica. Se puede usar la parte cmo (es decir, el enlace concreto) del documento WSDL y generar una interfaz de cliente SOAP o un delegado (proxy) que implemente el enlace requerido para comunicarse con

60

una implementacin de servicio especfica. Este delegado est ya precompilado y se puede incluir en la aplicacin cliente. El punto de acceso se puede indicar en tiempo de ejecucin. b) De forma dinmica. Debido a que el documento WSDL se puede interpretar por parte de un programa se puede usar el enlace dinmico. De esta manera usando la parte qu del documento WSDL (obtenida del tModel) se puede generar la interfaz abstracta de cliente SOAP que puede trabajar con cualquier implementacin de un tipo de servicio especfico. En tiempo de ejecucin la aplicacin cliente puede compilar la parte dnde del documento WSDL (qu contiene la parte cmo, es decir, el enlace concreto) y generar un delegado dinmico que implemente el enlace (a esto se le llama dynamic binding). Por lo tanto, el cliente puede ver el registro UDDI como un servidor de nombres (igual que RMI y CORBA tienen uno). La diferencia est en la flexibilidad y la alta escalabilidad que puede ofrecer UDDI, sobre todo en cuanto a la disponibilidad de los servicios ofrecidos. A ms servicios ofertados para el mismo tModel, mayor es la fiabilidad que se obtendr del servicio. Adems de esto, UDDI permite localizar servicios no solo por el nombre sino por otras caractersticas como pueden ser versiones, informacin geogrfica, etc...

Figura 6.6.- Descripcin de un tipo de servicio con sus patrones de enlace.

61

El proceso de estandarizacin de UDDI es gestionado por OASIS (http://www.oasis-open.org/home/index.php), siendo la versin 3 la ltima aceptada. En esta ltima versin se ha aadido la capacidad de notificacin y suscripcin, de tal manera que aquellos clientes que se suscribieron para el uso de un servicio web, recibirn notificaciones de cualquier cambio en el servicio web que usan. Finalmente hay que decir que UDDI es un registro de propsito general, que puede ser usado para registrar cualquier tipo de servicio, no slo los servicios Web. UDDI no requiere que los servicios definan interfaces de tipo SOAP o que estn descritos por documentos WSDL. De hecho, no existen dependencias entre las tres tecnologas, aunque funcionan mejor si se utilizan conjuntamente. 6.4.1 Tipos de registros UDDI El soporte de registro UDDI puede estar gestionado de dos maneras muy diferentes. En la primera se puede considerar los denominados registros privados, que permiten a las organizaciones individuales (o una comunidad privada) soportar los requerimientos de fiabilidad y seguridad adaptados a sus necesidades. La segunda aproximacin de gestin define los denominados registros B2B (Business To Business), que permiten que un grupo de empresas gestionen dicho registro, de tal manera que permite una integracin entre compaas de productos y servicios. Entre estos registros pblicos cabe destacar los de IBM (https://uddi.ibm.com/ubr/registry.html) y Microsoft (http://uddi.microsoft.com), aunque ambos necesitan una cuenta de registro. Los registros privados pueden imponer restricciones de control de la seguridad para proteger la integridad de los datos del registro y prevenir el acceso a usuarios no autorizados. En tiempo de diseo, el registro privado UDDI puede ser usado por uno de los equipos de desarrollo de la organizacin para localizar un servicio y usarlo para el proyecto en el que se est trabajando. Esto facilita la colaboracin y la reutilizacin de software entre distintos grupos, lo que facilita y acelera la tarea de produccin de software.

6.5 Implementacin de la arquitectura WSA


Vistas ya las tres funcionalidades (tecnologas) bsicas que implementan la arquitectura de servicios web, se puede decir que existen bsicamente se puede utilizar los servicios Web para construir una aplicacin haciendo bsquedas sobre UDDI, interpretar documentos WSDL y construir peticiones SOAP (vase la Figura 6.7). Todo ello utilizando analizadores XML estndares. Obviamente esto constituye un trabajo considerable que no justifica la flexibilidad e

62

independencia de las tecnologas de los servicios Web. Por ello, las compaas de desarrollo y las comunidades de software libre han implementado productos que ofrecen la implementacin de estas tecnologas de forma rpida y eficiente. Llamaremos a estos productos plataformas de servicios Web.

Figura 6.7.- Arquitectura de una plataforma de servicios web.

Una plataforma de servicios web generalmente est compuesta de herramientas de desarrollo, un servidor de ejecucin de servicios y un conjunto de servicios de gestin de la plataforma: Las herramientas de desarrollo se usan para crear los servicios Web, generar las descripciones WSDL asociadas a los servicios y generar los delegados (proxies) que permiten que los clientes puedan usar el servicio, enviando mensajes al servicio. Las herramientas de desarrollo pueden proporcionar asistentes para registrar o buscar servicios en un registro UDDI. El servidor de ejecucin de servicios procesa los mensajes SOAP y proporciona un contenedor para los servicios Web. Para cada peticin, el procesador SOAP analiza el mensaje SOAP, traduce los datos XML del mensaje a datos en el lenguaje nativo e invoca el servicio. Cuando el servicio termina su trabajo, el servidor traduce los resultados obtenidos al formato XML adecuado, lo empaqueta y lo enva en un mensaje de respuesta SOAP, que se enva a la aplicacin cliente. Las herramientas de gestin proporcionan un mecanismo para desplegar, arrancar, parar, configurar y administrar el servicio Web. Obviamente se hace necesaria una consola de administracin y otras facilidades como pueden ser un registro

63

privado UDDI, un repositorio de documentos WSDL, un servicio de autentificacin (SSO) y herramientas de monitorizacin de los servicios. La plataforma de servicios web adems puede proporcionar o extender nuevas capacidades a travs de las cabeceras SOAP (vase la Figura 6.7), por ejemplo soporte de transacciones o fiabilidad en el reparto de mensajes SOAP. En la Figura 6.8 se muestra un diagrama con las posibles capacidades que podra soportar la plataforma de servicios web.

Figura 6.7.- Mecanismo de extensin de cabeceras SOAP.

Dadas estas caractersticas de la plataforma, slo se debe seleccionar la implementacin concreta. Esta eleccin depender de factores como: 1. 2. 3. 4. 5. 6. 7. 8. 9. Lenguaje usado para construir los servicios Web. Lenguaje usado para construir las aplicaciones cliente. El control que se tenga sobre el entorno del cliente. Plataforma usada para desplegar los servicios Web. Capacidad de ofrecer otras tecnologas como J2EE (es decir, integrar un servidor de aplicaciones con la plataforma de servicios). Requerimientos de rendimiento de la plataforma. Nivel de escalabilidad. Nivel de seguridad necesitado. Otras capacidades o requerimientos adicionales que se necesiten o sean proporcionados por la plataforma.

64

Figura 6.8.- Capacidades proporcionadas por la plataforma de servicios Web

Entre las plataformas ms populares se pueden destacar las soluciones aportadas por IBM (http://www128.ibm.com/developerworks/webservices/) Microsoft (en su plataforma .NET, http://msdn.microsoft.com/vstudio/) o Sun (con el Java Web Services Developer Pack, disponible en http://java.sun.com/webservices/). Como herramientas gratuitas cabe destacar el API SOAP de Apache (disponible en http://ws.apache.org/soap/) y el servidor AXIS (http://ws.apache.org/axis/) de servicios Web. De todas formas se recomienda consultar las direcciones http://www128.ibm.com/developerworks/views/webservices/downloads.jsp y http://www.uddi.org/solutions.html para un listado completo de posibles soluciones ofertadas por otros fabricantes.

65

7. OTRAS REFERENCIAS EN INTERNET


Tutorial sobre J2EE http://www.programacion.com/java/tutorial/j2ee/ Servlets http://programacion.com/tutorial/servlets_basico/ JSP http://www.di.uniovi.es/~marian/jsp/transparenciasjsp.pdf Servlets y JSP http://www.cyberlatino.com.mx/tutoriales/download/servletsjsp.pdf Instalar nuevas aplicaciones en Tomcat. http://www.javahispano.org/articles.article.action?id=21 Comparativa entre J2EE y .NET http://www.ciberteca.net/articulos/programacion/net/default.asp Libreras de etiquetas http://www.programacion.com/java/articulo/customtags/ Servicios web http://www.programacion.com/java/tutorial/servic_web/