Un Enfoque Prctico Basado en Patrones de Diseo para la Enseanza de J2EE

Fernando Bellas Permuy Departamento de Tecnologas de la Informacin y las Comunicaciones Universidad de A Corua Facultad de Informtica. Campus de Elvia. CP/15071. A Corua. Espaa. http://www.tic.udc.es/~fbellas fbellas@udc.es
Resumen. Con el paso del tiempo J2EE se ha convertido en un potente framework para el desarrollo de aplicaciones empresariales. Sin embargo, para el recin llegado aprender a utilizar J2EE de una manera ptima no es una tarea trivial. Por una parte, J2EE ofrece abstracciones que puede ser complicado entender si no se conocen los patrones de diseo a los que pretenden dar soporte tecnolgico. Por otra parte, las descripciones de los patrones de diseo en los distintos catlogos asumen un buen conocimiento de la tecnologa J2EE. Este artculo describe un enfoque para la enseanza de J2EE, que explica la tecnologa de manera integrada con los principales patrones de la capas modelo, vista y controlador de una aplicacin empresarial. El enfoque se apoya en un software que incluye un conjunto de ejemplos muy sencillos para ilustrar el API de las tecnologas, y dos mini-aplicaciones completas que ponen en prctica las tecnologas y los principales patrones de cada una de las capas.

1 Introduccin
A principios de 1998 apareci la primera versin de la especificacin de Enterprise JavaBeans (EJB). En aquel momento me encontraba realizando mi tesis doctoral con CORBA/C++, por lo que sent la necesidad de echar un vistazo a lo que pareca ser un rival de CORBA. Desafortunadamente, en aquel momento no poda existir ningn libro sobre EJB y los pocos artculos que haba eran breves y poco aclaratorios, por lo que inevitablemente tuve que acudir a la siempre spera especificacin. A pesar de que parta de un buen conocimiento de Java y los patrones generales documentados en los libros GoF [1] y POSA [2], recuerdo que los conceptos de Entity Bean y Session Bean me parecan abstracciones demasiado complejas, y slo alcanc a entenderlos medianamente tras una segunda lectura. Todo habra sido distinto si hubiese conocido los patrones de diseo asociados a la capa modelo de una aplicacin empresarial, y en particular, los patrones DAO y Session Facade, sin embargo, todava tendran que pasar ms de tres aos hasta que los principales libros de patrones J2EE viesen la luz [3 y 4], aunque es obvio que los diseadores de EJB s los conocan, y lo que en realidad proponan era una tecnologa que obviase su necesidad (Entity Bean sustituye a DAO) o les diese soporte tecnolgico (Session Bean permite implementar Session Facade). A finales del verano de 1999 empec a trabajar en el diseo e implementacin de un prototipo de un framework J2EE para el desarrollo de portales Mi, es decir, portales de servicios personalizables al estilo my.yahoo.com, y que ahora empiezan a hacerse populares en las intranets de las grandes corporaciones. La intencin era que el framework proporcionase unas capas modelo y controlador genricas y adaptables, de manera que la mayor parte del trabajo para construir un portal Mi particular fuese construir la capa vista con pginas JSP, que precisamente era una tecnologa que surga en aquel momento.

Adems, queramos que el controlador minimizase la cantidad de cdigo Java que sera preciso insertar en las pginas JSP, de manera que stas pudiesen ser escritas por personas sin conocimientos de Java, idealmente diseadores grficos. Desafortunadamente, el resultado no fue tan bueno como pretendamos. Por una parte, JSP todava no ofreca el mecanismo de extensin de tags y Struts [5] todava no haba aparecido. Por otra parte, slo existan descripciones muy incipientes de algunos patrones J2EE (ej.: DAO, uso combinado de servlets y JSP, etc.). Todo ello, nos condujo a un framework con una arquitectura en la que la separacin entre controlador y modelo no era total, lo que sin ser el problema ms grave, resultaba en un software con una arquitectura no suficientemente clara. Lo peor, sin duda, era la construccin de las pginas JSP. En un portal Mi la mayor parte de las pginas JSP corresponden a formularios, en los que es preciso tratar los posibles errores introducidos por el usuario. A pesar de que el framework inclua servlets que usaban la conocida tcnica de insertar objetos Java en la request y hacer un forward a las pginas JSP, y el uso de clases Java para generar os distintos tipos de entradas de un formulario, l todava era preciso insertar una gran cantidad de cdigo Java en las pginas JSP. Todo habra sido distinto si hubisemos conocido el patrn Front Controller (en realidad nuestros servlets eran una versin muy primitiva de esta idea), si JSP ya proporcionase el mecanismo de extensin de tags (nuestras clases Java eran una primera aproximacin), y desde luego, si ya existiese Struts. Durante el 2001 se publicaron los borradores en el web de los que luego fueron los dos libros ms famosos sobre patrones J2EE [3 y 4]. Mi impresin tras leer esos borradores, fue la misma que cuando le el GoF. Realmente existe un antes y despus en la forma de pensar en el diseo de una aplicacin empresarial. Ese mismo ao tambin apareci la versin 1.0 de Struts. De nuevo, existe un antes y despus en la forma de implementar una aplicacin web. Durante ese mismo ao, como parte de mi trabajo en la Universidad de A Corua, decid pensar en un temario para la asignatura Integracin de Sistemas, de quinto curso, que abarcase de una manera integrada la tecnologa J2EE y sus patrones de diseo, dado que: (1) no es posible aplicar la tecnologa de manera acertada si no se dispone de un mtodo de ingeniera que gue con claridad durante el diseo, mediante la aplicacin ordenada de patrones, y (2) es difcil entender algunas tecnologas si no se entienden las ideas de diseo bsicas que es preciso aplicar para atacar el problema para el que las tecnologas han sido concebidas. Para llevar a cabo esta idea, era preciso hacer frente a los siguientes problemas: La mayor parte de las descripciones de los patrones de diseo J2EE de la capa modelo suelen asumir EJB, cuando posiblemente la mayor parte de las aplicaciones actuales usan JDBC. De hecho, el uso de una tecnologa u otra depende de muchos factores, como la naturaleza del proyecto o los conocimientos de los miembros del equipo de desarrollo. Afortunadamente, la mayor parte de los patrones de la capa modelo son aplicables tanto si la aplicacin usa EJB como JDBC, con distinta implementacin, pero siempre la misma idea. Por otra parte, a efectos pedaggicos resulta mucho ms sencillo explicarlos primeramente con JDBC, dado que es una tecnologa que requiere muy poco esfuerzo de aprendizaje, para luego volver a verlos re-implementados con EJB. Esto ltimo tambin permite ver cmo es posible disear una capa modelo que utilice 2

JDBC inicialmente, pero que pueda migrarse total o parcia lmente a EJB (ej.: por motivos de escalabilidad, soporte de una amplia variedad de bases de datos, etc.) en un futuro sin impacto en el resto del software. Desafortunadamente, los dos principales libros de patrones J2EE utilizan formatos distintos para documentar los patrones. En [3] se utiliza una plantilla con cierto parecido, pero distinta, a la del GoF. En [4] se documentan los patrones sin utilizar ninguna plantilla formal. Esto representa un problema a la hora de resumir las ideas principales de un patrn. Los libros de tecnologa suelen concentrarse en una descripcin del API, con poco nfasis (o ninguno) en el diseo, mientras que los libros de diseo asumen buenos conocimientos de tecnologa. Esto es un problema para el alumno (quizs ms acostumbrado a tener un nico libro de referencia para seguir una asignatura), dado que el conocimiento se haya disperso en un gran nmero de fuentes bibliogrficas. Es difcil aprender tecnologa y diseo si n se ilustran con cdigo. Java Pet Store ([6 y o 7]) ha sido desde hace tiempo la aplicacin de ejemplo que Sun ha proporcionado como parte de su programa de buenas prcticas de diseo e implementacin con J2EE: J2EE BluePrints [8]. Java Pet Store constituye un ejemplo de una tienda de comercio electrnico de animales de compaa. Sun eligi una tienda de comercio electrnico porque es el tipo de aplicacin ms usual en Internet. Aunque Java Pet Store es un buen ejemplo para el desarrollador avanzado, se trata de un ejemplo excesivamente grande para un estudiante. Por otra parte, las distintas versiones de Java Pet Store mantenidas por Sun no hacen uso de Struts sino de su propio framework MVC (Model-ViewController), no tan potente como aqul ni tan bien documentado, lo que hace que el cdigo sea ms difcil de entender, y quizs no suficientemente representativo, dado que no es realista utilizar el framework MVC de Java Pet Store para aplicaciones reales teniendo la posibilidad de utilizar Struts. Adems, Java Pet Store implementa la mayor parte de la capa modelo con EJB. Durante el 2002 surgi el proyecto OpenSource xPetstore [9], una re-implementacin de Java Pet Store con distintas tecnologas, inclusive Struts. Sin embargo, contina siendo un ejemplo demasiado grande para un estudiante, adems de no ilustrar la combinacin de Struts con JDBC. J2EE es un framework que engloba un buen nmero de tecnologas, en constante crecimiento y mejora. Es obvio que no es posible (y tampoco deseable) intentar abarcar todas ellas en una nica asignatura de Universidad. Por otra parte, la lista de patrones J2EE documentados tampoco para de crecer. Por todo ello, a la hora de pensar en un temario sobre J2EE es vital concentrarse en las tecnologas y patrones ms importantes (ms usados), contando slo lo esencial, pero todava con el suficiente detalle como para que los conocimientos transmitidos sean tiles para la construccin de aplicaciones reales. Por todo lo anterior, decid preparar un conjunto de transparencias y cdigo de soporte que hiciesen frente a esos problemas. Todo este material se encuentra gratuitamente disponible en [10]. Se trata de un material relativamente extenso (actualmente cerca de 1.000 transparencias, 15.000 lneas de cdigo Java, 2.000 lneas de cdigo JSP y ms de

4.000 lneas en XML) que he impartido desde el curso 2001-2002 hasta la actualidad en la Facultad de Informtica de la Universidad de A Corua (as como algunos bloques en otras organizaciones), y que con el paso del tiempo ha estado (y estar) sujeto a numerosas actualizaciones segn ha ido avanzado la tecnologa (ej.: de EJB 1.1 a EJB 2.1, de los tags de Struts a sus contrapartidas en JSTL, etc.). El temario que aqu expongo corresponde al del curso 2003-2004. Es importante destacar que en este artculo no se pretende explicar la tecnologa ni los patrones de diseo, sino la filosofa que subyace detrs del temario. En el apartado 2 se presenta el temario que conforma la asignatura Integracin de Sistemas, cuyas partes principales se van comentando en subsiguientes apartados, a saber, acceso a bases de datos con JDBC (apartado 3), XML (apartado 4), tecnologas web (apartado 5) y componentes EJB (apartado 6). En el apartado 7 se comenta el funcionamiento del laboratorio de prcticas. Finalmente se termina con conclusiones (apartado 8) y referencias (apartado 9).

2 Temario
A continuacin se presenta el temario de la asignatura Integracin de Sistemas. Se trata de una asignatura anual de quinto curso, cuyos prerrequisitos son: (1) conocimiento del lenguaje Java y (2) los patrones de diseo del GoF. La asignatura consta de 150 horas, que he estructurado en 65 horas de teora y 85 de laboratorio (apartado 7). Tema 1 - Introduccin a J2EE 1.1 Caractersticas de las aplicaciones empresariales 1.2 Visin general de la plataforma J2EE 1.3 Patrones arquitectnicos Model-View-Controller y Layers Tema 2 Acceso a bases de datos con JDBC 2.1 Tutorial de JDBC 2.2 Caso de estudio: diseo e implementacin de la capa modelo de MiniBank con JDBC. Patrones usados 2.3 Resumen de patrones para la capa modelo con JDBC 2.3.1 Value Object 2.3.2 Data Access Object 2.3.3 Page-by-Page Iterator 2.3.4 Estrategias de generacin de claves primarias 2.3.5 Session Facade 2.3.6 Business Delegate Tema 3 Introduccin a XML 3.1 Documentos XML 3.2 DTDs 3.3 Casos de estudio Tema 4 - Tecnologas Web 4.1 Tutorial de servlets 4.2 Tutorial de JSP 4.3 Problemas con servlets y pginas JSP. Patrones 4

4.4 Tutorial de JSTL y Jakarta Struts 4.5 Caso de estudio: diseo e implementacin de las capas controlador y vista de MiniBank con JSTL y Jakarta Struts. Patrones usados 4.6 Caso de estudio: diseo e implementacin de las capas controlador y vista de MiniPortal con JSTL y Jakarta Struts. Patrones usados Tema 5 Componentes EJB 5.1 Introduccin a las tecnologas de objetos distribuidos con Java RMI 5.2 Introduccin a EJB 5.3 Caso de estudio: diseo e implementacin de la capa modelo de MiniBank con EJB. Tipos de EJBs y patrones usados 5.4 Caso de estudio: diseo e implementacin de la capa modelo de MiniPortal con EJB. Tipos de EJBs y patrones usados 5.5 Tutorial de CMP avanzado 5.6 Resumen de patrones para la capa modelo con EJB 5.6.1 Value Object 5.6.2 Data Access Object 5.6.3 Session Facade 5.6.4 Business Delegate 5.6.5 Fast-Lane Reader 5.6.6 Page-by-Page Iterator 5.6.7 Service Locator 5.6.8 Estrategias de generacin de claves primarias 5.7 Conclusiones Como se puede observar, el temario empieza con una introduccin a las aplicaciones empresariales, una visin global de la plataforma J2EE (y su relacin con otras tecnologas, como .NET o LAMP) y los patrones arquitectnicos MVC y Layers [2] como pilares de la arquitectura de una aplicacin empresarial. El resto del temario tiene una orientacin totalmente prctica. Para ello he escrito un software que se compone de 3 partes fundamentales: (1) una coleccin de tutoriales de todas las tecnologas, (2) MiniBank y (3) MiniPortal. MiniBank (una mini-aplicacin bancaria) y MiniPortal (un mini-portal de Internet) son dos aplicaciones web completas, estructuradas segn los patrones arquitectnicos MVC y Layers, y emplean la mayor parte de las tecnologas y patrones de diseo que se explican en la asignatura. Como se coment anteriormente, he hecho especial nfasis en explicar los patrones con JDBC y con EJB, dado que en funcin de la situacin una tecnologa puede ser ms conveniente que otra, as como en hacer que sea posible migrar de una a otra (ej.: de JDBC a EJB). Para dar soporte a esta idea, he escrito varias implementaciones de las capas modelo de MiniBank y MiniPortal. En ambos casos, el API bsico de acceso al modelo viene dado por un interfaz Business Delegate (una operacin por cada caso de uso) y una factora, que en funcin de la informacin de configuracin permite trabajar contra una versin del modelo u otra. De esta manera, el controlador puede acceder a la capa modelo de manera independiente a la tecnologa usada. Este enfoque no pretende ilustrar cmo construir una aplicacin que pueda funcionar con dos versiones de una capa modelo, que por otra parte sera poco til en la vida real. Por el contrario, pretende explicar cmo disear e implementar la capa modelo con JDBC, en un caso, y cmo

hacerlo con EJB en otro, e implcitamente, ver cmo es posible migrar de una tecnologa a otro de una manera ordenada, y sin que esto tenga ningn impacto sobre el resto de capas. En general, cada tecnologa se explica: (1) mediante un tutorial que cubre los aspectos ms esenciales (apoyado en ejemplos muy sencillos), (2) el estudio del diseo (patrones) e implementacin de la capa modelo, vista o controlador (segn proceda) de MiniBank y/o MiniPortal, y (3) un estudio ms detallado de los patrones ms relevantes, que permite resumir y examinar otras opciones de diseo para cada patrn. De esta forma, antes de estudiar en detalle un patrn, ya se ha visto aplicado de manera "natural" en MiniBank o MiniPortal (excepto algn patrn muy especfico), lo que permite asimilarlo mejor, pues se ha visto su utilidad en un caso prctico. En cierta medida, este es un enfoque parecido al que sigue el GoF, que antes de pasar al catlogo de patrones, incluye un captulo en el que se describe el diseo de un procesador de textos, y por cada problema que va surgiendo, introduce de manera natural un patrn (lgicamente, sin comentar todas su opciones de diseo). En lo que se refiere al estudio detallado de los patrones, se ha optado por resumir las ideas principales (por restricciones de tiempo) y por seguir el formato del GoF (por ser ste el formato al que estn acostumbrados los alumnos).

3 Acceso a bases de datos con JDBC

3.1 Tecnologa
Mediante una serie de ejemplos sencillos se introduce el API bsica de JDBC, para posteriormente estudiar los conceptos de DataSource, pool de conexiones y transacciones. Este ltimo punto, por su complejidad, se explica con ms profundidad. Primeramente se describen los tres tpicos problemas (dirty reads, non-repeatable reads y phantom reads) asociados con el nivel de aislamiento, y cmo se pueden evitar seleccionando un nivel de aislamiento especfico (TRANSACTION_NONE , TRANSACTION_READ_UNCOMMITED, TRANSACTION_READ_COMMITED , TRANSACTION_REPEATABLE_READ y TRANSACTION_SERIALIZABLE ), haciendo ver que normalmente los drivers JDBC (y las bases de datos) slo dan soporte para los niveles TRANSACTION_READ_COMMITED y TRANSACTION_SERIALIZABLE . Aunque en muchos libros de JDBC los niveles de aislamiento de las transacciones estn perfectamente explicados, desafortunadamente no suelen explicar el caso de las transacciones que como parte de su ejecucin: (1) leen un dato de la base de datos, (2) lo actualizan en memoria (ej.: le suman una cantidad), y (3) lo vuelven a escribir en base de datos, como ocurre por ejemplo en una transferencia bancaria, al aadir o quitar dinero a una cuenta bancaria, al modificar el stock de un producto, etc. Mediante unos ejemplos prueba, se hace ver cmo el uso de TRANSACTION_READ_COMMITED por si slo no es suficiente para este tipo de transacciones, y cmo solucionarlo. Para ello, es necesario aplicar TRANSACTION_SERIALIZABLE , o TRANSACTION_READ_COMMITED lanzando una SELECT con una clusula FOR UPDATE (si la base de datos la soporta) sobre la fila que se va a actualizar. Ambas estrategias son correctas, causando la primera bloqueos o no (en este caso una de las transacciones se aborta) en funcin de si la base de datos utiliza una estrategia de bloqueos pesimista u optimista, mientras que la segunda siempre causa

bloqueos. Es muy importante entender este concepto, dado que por una parte es vital para el correcto funcionamiento de una aplicacin transaccional, y por otra, porque permite entender mejor el funcionamiento de las transacciones dentro de los contenedores de EJB, que dependiendo de la implementacin, utilizan una estrategia pesimista u optimista (quizs en combinacin con la base de datos), lo que es preciso tener en cuenta para comprender la implementacin de determinados patrones, tales como Sequence Blocks o Versin Number [4].

3.2 Caso de estudio. Diseo e implementacin de la capa modelo de MiniBank con JDBC
Esta parte del temario explica de manera prctica las ideas bsicas que es necesario aplicar para abordar el diseo e implementacin de la capa modelo de una aplicacin empresarial con JDBC. Para ello, se utiliza como ejemplo MiniBank, una sencilla aplicacin bancaria con interfaz web que gestiona cuentas y operaciones bancarias, e implementa ocho casos de uso: crear una cuenta bancaria, buscar una cuenta a partir de su identificador, aadir una cantidad de dinero a una cuenta, retirar una cantidad de dinero de una cuenta, buscar todas las cuentas de un usuario, eliminar una cuenta, hacer una transferencia de dinero de una cuenta a otra y buscar todas las operaciones que se han hecho sobre una cuenta entre dos fechas. La capa modelo de MiniBank debe ser independiente del tipo de vista (web, aplicacin standalone, etc.), ofrecer una API sencilla al controlador y ocultar las tecnologas usadas en su implementacin (JDBC en este caso). Primeramente se hacen ver los problemas que es preciso abordar: representacin del estado de los objetos persistentes, persistencia, flujo de control y diseo del API que debe ofrecer el modelo. A continuacin se van resolviendo cada uno de estos problemas mediante la aplicacin ordenada y sistemtica de patrones de diseo, que se van introduciendo as de una manera natural. La Figura 1 resume las principales clases e interfaces de la arquitectura de la capa modelo de MiniBank, que es producto de la aplicacin de los siguiente pasos: Identificacin de los objetos persistentes (objetos del dominio) de la aplicacin y representacin de su estado. En MiniBank existen dos objetos persistentes, cuenta (identificador de cuenta, identificador de usuario y balance) y operacin bancaria (identificador de operacin bancaria, identificador de cuenta, fecha, tipo de operacin y cantidad). Para representar su estado, se crean las clases AccountVO y AccountOperationVO, que corresponden a la aplicacin del patrn Value Object (ltimamente renombrado a Transfer Object) . Por cada uno de los objetos persistentes identificados se disea un interfaz DAO (SQLAccountDAO y SQLAccountOperationDAO) y una factora (SQLAccountDAOFactory y SQLAccountOperationDAOFactory) que permite crear instancias del DAO, leyendo la clase que implementa el interfaz de la informacin de configuracin de la aplicacin. De esta manera, es posible soportar varias bases de

datos con distintos dialectos de SQL1 . Dado que tanto la clave de las cuentas como la de las operaciones bancarias es un identificador numrico que hay que generar automticamente (un problema muy tpico), se proporcionan tres estrategias de implementacin de los interfaces DAO (no ilustradas en la figura): una para bases de datos con soporte para secuencias (ej.: Oracle, PostgreSQL, etc.), otro para bases de datos que disponen de columnas contador (ej.: MySQL, Sybase, etc.) sin posibilidad de usar driver JDBC 3, y finalmente una con driver JDBC 3 para este ltimo tipo de bases de datos. Un aspecto a destacar de los interfaces DAO es que todas las operaciones reciben la conexin a la base datos como uno de sus parmetros (de hecho, el nombre del interfaz deja claro que se asume una base de datos relacional). Esto es necesario, dado que con el API bsico de JDBC, la nica manera de englobar varias operaciones de un mismo DAO o varios DAOs en una transaccin es usar para todas ellas la misma conexin (con el modo auto-commit deshabilitado). En realidad, se podra haber implementado un pequeo gestor de transacciones o usar una implementacin del API de JTA [11] para que ello no fuese necesario, pero no se ha hecho por motivos de sencillez. Finalmente, decir que los interfaces DAO, aparte de incluir las tpicas operaciones de aadir, buscar por clave primaria, eliminar y actualizar, tambin incluyen operaciones de bsqueda conformes al patrn Page-by-Page Iterator, de manera que se puedan implementar los casos de uso correspondientes al recorrido de las cuentas de un usuario o las operaciones bancarias de una cuenta.
<<Interface>> AccountFacadeDelegate (from delegate) AccountFacadeDelegateFactory (from delegate)

PlainAccountFacadeDelegate (from plain)

PlainActionProcessor (from sql)

actions (from plain)

SQLAccountDAOFactory (from dao)

<<Interface>> SQLAccountDAO (from dao)

<<Interface>> SQLAccountOperationDAO (from dao)

SQLAccountOperationDAOFactory (from dao)

AccountVO (from vo)

AccountOperationVO (from vo)

Figura 1. Arquitectura de la capa modelo de MiniBank con JDBC.

El patrn DAO tambin se puede implementar directamente como una clase concreta cuando no es preciso soportar ms de una base de datos.

 Una vez que se dispone de los DAOs, se clasifican los casos de uso en grupos, de manera que cada grupo contenga casos de uso lgicamente relacionados. Por cada grupo, se define un Session Facade, que proporciona una operacin por cada caso de uso que soporta. En el caso de MiniBank, por tratarse de una aplicacin muy pequea, slo se ha definido un Session Facade (que adems acta como Business Delegate), PlainAccountFacadeDelegate, proporcionando ocho operaciones, una por cada caso de uso. Como se explic en el apartado 4, se han hecho dos implementaciones de la capa modelo de MiniBank y de MiniPortal, una con JDBC y otra con EJB. Para ello, ha sido necesario implementar el patrn Business Delegate como un interfaz (AccountFacadeDelegate) y una factora ( AccountFacadeDelegateFactory ), que al igual que las factoras de los DAOs permite crear instancias leyendo la clase que implementa el interfaz de la informacin de configuracin de la aplicacin, siendo PlainAccountFacadeDelegate la implementacin en el caso de JDBC.
PlainActionProcessor - PlainActionProcessor() <<static>> + process(dataSource : DataSource, action : NonTransactionalPlainAction) : void <<static>> + process(dataSource : DataSource, action : TransactionalPlainAction) : void

<<Interface>> PlainAction

+ execute(connection : Connection) : Object

<<Interface>> NonTransactionalPlainAction

<<Interface>> TransactionalPlainAction

Figura 2. Procesador de acciones JDBC. Finalmente, es necesario implementar la clase PlainAccountFacadeDelegate. Todos los casos de uso no transaccionales tienen que: (1) abrir la conexin, (2) invocar operaciones de uno o varios DAOs, y (3) cerrar la conexin. Por otra parte, los casos de uso transaccionales tienen que: (1) abrir la conexin, (2) deshabilitar el modo autocommit, (3) especificar TRANSACTION_SERIALIZABLE como nivel de aislamiento, (4) invocar operaciones de uno o varios DAOs, (5) hacer un commit (si todo ha ido bien) o un rollback (si se han ocurrido errores), y (6) cerrar la conexin. Por tanto, es obvio que existen aspectos comunes en la implementacin de cada uno de los casos de uso. Para ello, el subsistema Util de los ejemplos de la asignatura incluye un muy sencillo framework para ejecutar acciones no transacciones y transaccionales (Figura 2). El interfaz PlainAction ofrece una nica operacin, execute, que recibe la conexin y devuelve el resultado de la accin (ej.: la coleccin de cuentas en el caso de la accin de bsqueda de las cuentas de un usuario), y los interfaces NonTransactionalPlainAction y TransactionalPlainAction actan slo como interfaces marker. La clase PlainActionProcessor incluye dos operaciones, una para ejecutar acciones no transaccionales (implementa los puntos 1 y 3 descritos

anteriormente) y otra para ejecutar acciones transaccionales (implementa los puntos 1, 2, 3, 5 y 6 descritos anteriormente). El paquete actions de la capa modelo de MiniBank (Figura 1) incluye una accin por cada caso de uso (ej.: FindAccountsAction, AddToAccountAction, etc.) que se implementa en trminos de los DAOs SQLAccountDAO y SQLAccountOperationDAO. Cada operacin de PlainAccountFacadeDelegate se implementa creando una instancia de la accin correspondiente (cuyo constructor recibe los parmetros de la operacin) y ejecutndola con PlainActionProcessor.

4 XML
Mediante un sencillo ejemplo de sindicacin de contenido, que sirve de motivacin de XML, se introduce el concepto de documento XML y sus reglas de formacin, as como un DTD para validarlo. Naturalmente, se podran explicar muchos otros aspectos tecnolgicos, como por ejemplo, parsers SAX y DOM, XSL, servicios web, etc. De hecho, el primer ao inclu ejemplos sobre SAX y DOM mediante el API de JAXP. Sin embargo, el temario resultaba demasiado grande para 65 horas de teora, por lo que f preciso recortar algunas ue partes del temario, entre otras, los parsers SAX y DOM. Finalmente he optado por incluir algunos casos de estudio que motiven algunas de las APIs tpicas de XML. Un primer caso de estudio es el uso de XML para expresar la informacin de configuracin de una aplicacin, que da pie al uso de parsers SAX o DOM, o APIs de ms alto nivel como JAXB [ o Jakarta Commons Digester [ 12] 13]. Un segundo caso de estudio es el de disponer de informacin almacenada en XML que posteriormente se desea mostrar, por ejemplo, en HTML, lo que conduce a XSL. Finalmente, se presenta un tercer caso de estudio centrado en la integracin de aplicaciones heterogneas, que conduce a Servicios Web y CORBA. Mediante el estudio de estos casos de uso, se consigue que el alumno conozca la existencia de estas tecnologas y cul es su dominio principal de aplicacin. La prctica de la asignatura incluye partes opcionales de parsing o XSL en las que se propone el uso de alguna de estas tecnologas para resolver un problema concreto. Actualmente, CORBA y Servicios Web (JAX-RPC) forman parte del temario de otra asignatura cuatrimestral que tambin imparto [14], y que est dedicada a tecnologas de integracin de aplicaciones. Esta asignatura tambin sigue una filosofa similar a la aqu descrita, es decir, se estudian de manera integrada la tecnologa y las tcnicas de diseo ms usuales.

5 Tecnologas web
5.1 Tecnologa
Despus de una revisin de los conceptos bsicos del protocolo HTTP, se introduce el API de servlets mediante dos sencillos ejemplos, uno muy bsico (un servlet que saluda al usuario por su nombre) y otro que representa un muy sencillo portal (sin base de datos) que permite autenticarse mediante el nombre de login, acceder a la primera pgina (que lo saluda por su nombre de login si se ha autenticado, o lo redirige a la pgina de autenticacin en otro caso) y salir. Este ltimo ejemplo sirve para introducir el concepto de 10

sesin (mantiene el nombre de login), la diferencia entre forward y sendRedirect , y el uso de un mapa de errores (una entrada por cada campo errneo) insertado en la request para tratar errores en los campos de formularios (en este caso, en el formulario de autenticacin). Ambos ejemplos tambin dejan claro el principal problema con el uso exclusivo de servlets, es decir, el aspecto visual est mezclado con el cdigo Java, lo que impide una adecuada separacin de roles en el equipo de desarrollo (diseadores grficos e ingenieros), el uso de herramientas de diseo de pginas web y la necesidad de re-arranque del servidor o recarga de la aplicacin web en caso de modificacin del aspecto grfico. Como solucin inicial a estos problemas, se introducen los conceptos b sicos de JSP reimplementando los ejemplos de servlets como pginas JSP. El ejemplo del portal se completa (Figura 3) para que el formulario de autenticacin solicite una contrasea (cuyo valor tiene que ser igual al nombre de login) y d la posibilidad de recordarla (es decir, acceder a la pgina principal del portal sin teclear la contrasea), lo que permite introducir el concepto de cookie para implementar esta funcionalidad (el nombre de login y la contrasea se envan al navegador como cookies). Con los conceptos de sesin y cookie asimilados, resulta sencillo explicar el mecanismo de re-escritura de URLs (URL rewriting), como solucin para aquellas aplicaciones, que trabajando con sesiones, son capaces de funcionar tanto si el navegador acepta cookies como si no.

Figura 3. Formulario de autenticacin del tutorial de JSP. Los ejemplos de JSP tambin permiten observar que todava no es posible una adecuada separacin de roles, dado que las pginas JSP an contienen una gran cantidad de cdigo Java. Para minimizar este cdigo Java, se proponen dos soluciones. La primera de ellas corresponde al uso del patrn View-Helper mediante el mecanismo de extensin de tags de JSP, proponiendo tags para generar enlaces con re-escritura de URLs y generacin de entradas en formularios con control de errores. La segunda solucin comienza proponiendo el uso combinado de servlets y pginas JSP, en un caso reemplazando cada pgina JSP que slo hace procesamiento y redireccin por un servlet, y en otro, cada pgina JSP que hace procesamiento e imprime resultados por un servlet (procesamiento, insercin de resultados en la request y forward a la pgina de resultados) y una pgina JSP para imprimir los resultados. Si bien, esta solucin permite reducir notablemente el cdigo Java en las pginas JSP, se hacen ver sus dos principales problemas: flujo de control difcil de seguir y dificultad para aplicar polticas globales a los servlets. Para hacer frente a estos problemas se introduce el patrn Front Controller como refinamiento de esta solucin. En este momento, sin que el alumno sea consciente, conoce los principios bsicos de funcionamiento de Struts.

11

En el ltimo bloque tecnolgico se introduce un tutorial de JSTL y Struts, como tecnologas que proporcionan una librera de tags para hacer frente a los problemas ms tpicos (campos de entrada en formularios, re-escritura de URLs, internacionalizacin, etc.) y una implementacin del patrn Front Controller (en el caso de Struts). El tutorial reimplementa el anterior portal con JSTL y Struts, de manera que ahora las pginas JSP ya no contienen cdigo Java, y potencialmente, pueden ser escritas por una persona sin conocimientos de Java (idealmente un diseador grfico). Con respecto a los tags JSP, se usan los tags core e i18n de JSTL y los html de Struts (para lo que JSTL no tiene contrapartida).

5.2 Caso de estudio. Diseo e implementacin de las capas controlador y vista de MiniBank
El objetivo de este apartado es poner en prctica los conocimientos de tecnologas web adquiridos para la construccin de las capas controlador y vista de MiniBank (Figura 4), completando de esta manera esta aplicacin de ejemplo.

Figura 4. Aspecto grfico de MiniBank (transferencia bancaria). En primer lugar se hace ver que todas las pginas de MiniBank tienen la misma estructura (layout), compuesta por: ttulo (barra del navegador), cabecera (parte superior), lista de enlaces (parte central izquierda), contenido (parte central derecha) y pi de pgina (parte inferior), variando el ttulo y el contenido entre pginas distintas (como mnimo). Inicialmente se propone una solucin que pasa por aislar las partes comunes (cabecera, lista de enlaces y pie de pgina) en pginas JSP y hacer que todas las pginas JSP usen la directiva include para incluir estas partes comunes. Se hace ver que esta solucin, aunque eficiente, no facilita cambios futuros a la estructura de las pginas (ej.: se decide que la zona central se organice como una parte superior para la lista de enlaces y una parte inferior para el contenido), dado que todas las pginas JSP contienen el formato de la estructura. Para solucionar este problema, se introduce el sistema plantillas que proporciona Struts (caso particular del patrn Composite View), que permite definir la estructura una nica

12

vez de manera parametrizada, e instanciar dinmicamente el resto de pginas a partir de ella. Con respecto a la implementacin de los casos de uso, se ilustra la implementacin de tres casos representativos: Transferencia bancaria. Su implementacin consta de una pgina JSP para el formulario, un ActionForm para recoger los valores introducidos en el formulario y una accin de Struts, que lee los datos del ActionForm, invoca la operacin correspondiente sobre la fachada de la capa modelo y termina con un sendRedirect a una pgina que indica que la operacin se ha realizado con xito. En caso de errores de tipo lgico (ej.: campos errneos en el formulario), se hace un forward al formulario. La Figura 5 ilustra las principales clases involucradas en este caso de uso. El subsistema Util de los ejemplos incluye las clases DefaultAction y DefaultActionForm, que son especializaciones de las clases Action y ActionForm de Struts. La primera implementa el patrn Template Method, redefiniendo el mtodo execute en trminos del mtodo abstracto doExecute (que recibe los mismos parmetros) y capturando la excepcin de error interno (ej.: fallo en la conexin a la base de datos) que pueden devolver las operaciones de la fachada del modelo, y en ese caso, escribiendo una traza en el log mediante el API de servlets. La segunda proporciona, por comodidad, el mtodo getLocale, similar al que proporciona la clase Action, y que permite acceder al Locale cmodamente desde los ActionForm que lo precisen.
ActionForm (from action)

Action
(from action)

DefaultActionForm (from action)

DefaultAction (from action)

AccountFacadeDelegateFactory
(from delegate)

TransferForm
(from actionforms)

TransferAction <<Interface>> AccountFacadeDelegate

(from delegate)

Figura 5. Caso de uso Transferencia (MiniBank). Bsqueda de cuentas por identificador de cuenta o de usuario. Similar al anterior, pero con la diferencia de que la accin, tras invocar la operacin homloga sobre la fachada del modelo, deja los resultados en la request, y termina con un forward a la pgina de resultados. Seleccin de idioma. Este caso de uso no invoca ninguna operacin del modelo, sino que cambia el valor del Locale que mantiene Struts en la sesin. Las pginas de JSP de 13

MiniBank usan los tags i18n de JSTL para imprimir mensajes, nmeros y fechas en funcin del Locale seleccionado. MiniBank, por tanto, permite ilustrar dos ideas claras: En general, cada caso de uso se traduce en: (1) una pgina JSP para el formulario de entrada de datos (si lo requiere), (2) un ActionForm para recoger a los parmetros del caso de uso, (3) una accin de Struts en el controlador, (4) una clase accin en el modelo que implementa la lgica de negocio del caso de uso (que es invocada por la clase accin del controlador a travs de una fachada) en trminos de uno o varios DAOs y (5) una pgina JSP para imprimir los resultados (si lo requiere). Cada una de las acciones del controlador conecta la vista con la implementacin del caso de uso en el modelo.

5.3 Caso de estudio. Diseo e implementacin de las capas controlador y vista de MiniPortal
Esta seccin presenta otro ejemplo completo, MiniPortal (Figura 6), un sencillo portal que nicamente implementa los casos de uso: registrar usuario, autenticacin, mostrar y actualizar la informacin de registro, y cambiar la contrasea.

Figura 6. Pgina principal de MiniPortal para un usuario autenticado. A diferencia de MiniBank, MiniPortal, representa un ejemplo de aplicacin orientada a Internet que necesita encargarse explcitamente del registro y autenticacin de usuarios, como sera el caso de una tienda de comercio electrnico o un portal personalizable. MiniBank, por el contrario, representa una aplicacin web orientada a una intranet, en la que en caso de requerir autenticacin, los usuarios ya estaran dados de alta (posiblemente en un servidor LDAP), y en ese caso, se usara el soporte que ofrecen los contenedores web para autenticacin proporcionada por el contenedor.

14

La capa modelo de MiniPortal (Figura 7) slo utiliza un objeto persistente, la informacin de registro (nombre de login, contrasea, nombre, apellidos, direccin de correo electrnico, idioma y pas), y su diseo sigue el mismo enfoque que el mostrado en el caso de MiniBank, con la diferencia de que (1) para este objeto no se precisa generar la clave dinmicamente (el propio nombre de login acta como clave) y (2) se ha modelado la fachada del modelo como un Session Facade que mantiene el nombre de login como estado, establecindose ste despus de invocar la operacin de registro o autenticacin, de manera que el resto de operaciones no reciben el nombre de login. De esta forma se podr ilustrar claramente el concepto de Stateful Session Bean posteriormente (apartado 6.3). Por el contrario, la fachada del modelo de MiniBank permitir ilustrar el concepto de Stateless Session Bean (apartado 6.2).
<<Interface>> UserFacadeDelegate (from delegate)

UserFacadeDelegateFactory (from delegate)

PlainUserFacadeDelegate (from plain) - loginName : String

PlainActionProcessor (from sql)

actions (from plain)

SQLUserProfileDAOFactory (from dao)

<<Interface>> SQLUserProfileDAO (from dao)

UserProfileVO (from vo)

Figura 7. Arquitectura de la capa modelo de MiniPortal con JDBC. Las capas vista y controlador de MiniPortal siguen los mismos principios de diseo que los ilustrados en MiniBank. Sin embargo, por la naturaleza intrnseca al tipo de aplicaciones que representa MiniPortal es preciso usar la sesin para resolver dos problemas muy comunes. Por una parte, dado que todas las pginas de MiniPortal saludan al usuario por su nombre, se cachea ste en la sesin por motivos de eficiencia. De hecho, muchas aplicaciones de este tipo utilizan la sesin como cach de objetos persistentes frecuentemente utilizados. Por otra parte, dado que la fachada del modelo mantiene estado, es preciso guardar una referencia a sta en la sesin. Finalmente, la capa controlador de MiniBank tambin ilustra como proteger las URLs que requieran autenticacin (e.j: modificacin de informacin de registro), redirigiendo el navegador a la pgina de autenticacin cuando un usuario no autenticado intenta acceder a ellas. Una solucin elegante a este problema consiste en la aplicacin del patrn Intercepting Filter [ que se 3], puede implementar mediante el sistema de filtros introducido en la versin 2.3 de la

15

especificacin de Servlets, o redefiniendo el procesador de peticiones de Struts. En MiniPortal se ha seguido este segundo enfoque, y su explicacin queda fuera del mbito del presente artculo.

6 Componentes EJB
6.1 Tecnologa
En esta ltima parte se aborda el diseo e implementacin con componentes EJB. Primeramente se explica Java RMI como tecnologa de objetos distribuidos mediante un sencillo ejemplo, para as facilitar el paso a EJB. Tambin se presenta una implementacin de la capa modelo de MiniBank con Java RMI, que se apoya sobre la versin JDBC (apartado 3.2), de manera que la arquitectura de MiniBank pasar a ser en cuatro capas (como la versin EJB). Esta versin ofrece un objeto remoto que acta como Session Facade (implementado por delegacin en PlainAccountFacadeDelegate) y una implementacin de AccountFacadeDelegate que acta como Business Delegate (Proxy del objeto remoto). En este momento el alumno conoce los principales patrones de la capa modelo de una aplicacin empresarial, as como las tecnologas JDBC y Java RMI, de manera que resulta muy sencillo explicar (y entender) las principales abstracciones de EJB. En primer lugar, EJB se presenta como una tecnologa que permite desarrollar ms fcilmente la capa modelo, permitiendo hacer uso de los conceptos de seguridad, transacciones y persistencia de manera sencilla (declarativa). A continuacin se introducen los Entity Beans y Session Beans, recurriendo a las capas modelo de MiniBank y MiniPortal. Los primeros representan objetos persistentes, normalmente con interfaz local, y potencialmente sustituyen a los DAOs. Los segundos representan fachadas del modelo, es decir, materializaciones del patrn Session Facade, con interfaz local o remota, eligindose este ltimo tipo de interfaz para la implementacin de las capas modelo de MiniBank y MiniPortal (arquitectura en 4 capas). En la capa modelo de MiniBank se identifican dos Entity Beans: cuenta y operacin bancaria, que se modelan como Entity Beans BMP (Bean-Managed Persistence). Tambin se podran haber modelo como Entity Beans CMP (Container-Managed Persistence), pero desde un punto de vista pedaggico puede resultar ms interesante modelarlos como BMP, dado que: (1) al generarse sus claves dinmicamente se tendra que recurrir al patrn Sequence Blocks (que complicara la explicacin), (2) permite entender fcilmente el concepto de Entity Bean como objeto persistente dado que sus implementaciones hacen uso de los DAOs desarrollados anteriormente y (3) permite explicar este tipo de Entity Beans. Finalmente, se identifica un Stateless Session Bean (SLSB), la fachada del modelo, dado que no guarda estado especfico al cliente. De manera similar, en la capa modelo de MiniPortal se identifica un Entity Bean, informacin de registro, que se puede modelar fcilmente como un Entity Bean CMP. Finalmente, se identifica un Stateful Session Bean (SFSB), la fachada del modelo, que antes guardaba el nombre de login del usuario, y ahora guardar una referencia al Entity Bean que representa su informacin de registro.

16

El estudio detallado del API de EJB se va presentando progresivamente como parte de los dos casos de estudio correspondientes al diseo e implementacin de las capas modelo de MiniBank y MiniPortal (apartados 6.2 y 6.3).

6.2 Caso de estudio. Diseo e implementacin de la capa modelo de MiniBank con EJB
La Figura 8 presenta las principales clases e interfaces de la capa modelo de MiniBank con EJB, y su diseo es conceptualmente similar al visto con JDBC ( Figura 1), siendo sus principales diferencias: La implementacin de los casos de uso usan Entity Beans (AccountLocal y AccountOperationLocal) en lugar de DAOs.
<<Interface>> AccountFacadeHome (from ejb) <<Interface>> AccountFacadeDelegate (from delegate) <<Interface>> AccountFacade (from ejb) EJBAccountFacadeDelegate (from ejb) <<static>> - accountFacadeHomeJNDIName : String - accountFacade : AccountFacade AccountFacadeEJB (from ejb) AccountOperationVO (from vo)

AccountVO (from vo)

EJBHomeLocator (from ejb)

actions (from ejb)

EJBLocalHomeLocator
(from ejb)

<<Interface>> AccountLocalHome (from ejb)

<<Interface>> AccountLocal (from ejb)

<<Interface>> AccountOperationLocal (from ejb)

<<Interface>> AccountOperationLocalHome (from ejb)

Figura 8. Arquitectura de la capa modelo de MiniBank con EJB. La fachada del modelo (patrn Session Facade) se modela como un SLSB (AccountFacade). Tal y como aconseja [ 15], los casos de uso sencillos se implementan directamente en AccountFacadeEJB , y el resto en clases accin que son invocadas desde aquella, para as evitar que se convierta en una clase potencialmente demasiado grande. Ahora los casos de uso se implementan en trminos de Entity Beans, excepto los correspondientes a bsquedas que devuelven una coleccin de objetos (ej.: bsqueda de las operaciones bancarias sobre una cuenta), en los que se aplican los patrones FastLane Reader y Page -by-Page Iterator.

17

 La finalidad de los objetos valor AccountVO y AccountOperationVO es transferir datos de la capa cliente a la servidora y viceversa. Aparece una distincin entre el patrn Business Delegate (EJBAccountFacadeDelegate ) y el patrn Session Facade (AccountFacade), actuando el primero como Proxy del segundo. Se utiliza el patrn Service Locator para obtener cmoda y eficientemente referencias a interfaces Home de EJBs locales y remotos, mediante EJBLocalHomeLocator y EJBHomeLocator (proporcionados por el subsistema Util de los ejemplos).

6.3 Caso de estudio. Diseo e implementacin de la capa modelo de MiniPortal con EJB
La Figura 9 ilustra las principales clases e interfaces de la capa modelo de MiniPortal con EJB, y al igual que en el caso de MiniBank, se trata de una mera traduccin del diseo de la versin JDBC (Figura 7), que ahora hace uso de un Entity Bean CMP (UserProfileLocal ) y un SFSB ( UserFacade) que mantiene una referencia al Entity Bean UserProfileLocal del usuario.
<<Interface>> UserFacadeHome <<Interface>> UserFacadeDelegate (from delegate) (from ejb)

<<Interface>> UserFacade EJBUserFacadeDelegate (from ejb) <<static>> - userFacadeHomeJNDIName : String - userFacade : UserFacade UserFacadeEJB (from ejb) (from ejb)

UserProfileVO (from vo)

UserFacadeState 1
(from ejb)

- userProfileLocal : UserProfileLocal

EJBHomeLocator (from ejb) actions (from ejb) EJBLocalHomeLocator

(from ejb)

<<Interface>> UserProfileLocalHome (from ejb)

<<Interface>> UserProfileLocal (from ejb)

Figura 9. Arquitectura de la capa modelo de MiniPortal con EJB.

18

7 Laboratorio
En el laboratorio de la asignatura se realiza un proyecto (en grupos de tres personas) a lo largo del todo el ao, que consiste en la implementacin de una versin reducida de una tienda de comercio electrnico o un portal de servicios personalizables (ej.: my.yahoo.com). Para facilitar el comienzo de la prctica, se aconseja tomar como punto de partida el cdigo de MiniPortal. La prctica se estructura en iteraciones, donde en cada iteracin se debe producir cdigo ejecutable y realizar una entrega. En particular, se estructura en tres iteraciones: Iteracin 1: implementacin de una capa modelo que incluya los casos de uso ms bsicos con JDBC , y desarrollo de pruebas de unidad para las fachadas del modelo. Iteracin 2: inclusin de algn caso de uso ms e implementacin de las capas controlador y vista para la capa modelo, de manera que es posible obtener ya una aplicacin completa. Iteracin 3: inclusin de los restantes casos de uso y migracin de la capa modelo a EJB, que normalmente tambin hace uso de JDBC para aquellas situaciones en las que los patrones Fast-Lane Reader y Page-by-Page Iterator representan una opcin ms eficiente. Este enfoque presenta las siguientes ventajas: Un mes despus del comienzo del curso, se han adquirido los conocimientos necesarios para empezar con la primera iteracin de la prctica. De hecho, la secuencia temporal es tal que el comienzo de una nueva iteracin ocurre casi simultneamente con la finalizacin del bloque tecnolgico y de diseo que se necesita para abordarla. Esto permite que el alumno desarrolle el proyecto desde un primer momento, y de manera continua, lo que le permite asimilar mejor los conceptos que se trasmiten en las clases tericas. El alumno aprende a disear e implementar la capa modelo tanto con JDBC como con EJB, lo que le permitir tener ms elementos de juicio para decantarse por una u otra en un proyecto real en funcin de la situacin. El alumno se acostumbra a un desarrollo incremental, como el que aconseja el Proceso de Desarrollo Unificado [ 16], en el que en cada iteracin se lleva acabo anlisis, diseo, implementacin y pruebas. El alumno se acostumbra a trabajar en grupo. La prctica tambin propone como partes opcionales el uso de algunas tecnologas introducidas, pero no explicadas como parte del temario, tales como XSL y DOM/SAX, en el caso de XML, o los ActionForm dinmicos, el Validator y Tiles en el caso de Struts.

19

8 Conclusiones
A lo largo de este artculo se ha expuesto un enfoque para la enseanza de J2EE que se apoya en el uso de patrones de diseo. Este enfoque presenta dos ventajas claras. Por una parte, facilita la compresin de tecnologas como Struts o EJB, que ofrecen un conjunto de abstracciones ligadas ntimamente a los patrones de diseo ms importantes que es preciso aplicar en las capas de una aplicacin empresarial. Por otra parte, el conocimiento de los principales patrones, permite disponer de un mtodo de ingeniera, muy orientado a casos de uso, que gua con claridad en el diseo de las capas modelo, vista y controlador de una aplicacin empresarial, permitiendo adems hacer un uso ptimo de la tecnologa. Adems, el enfoque tiene una fuerte orientacin prctica, apoyndose en un buen nmero de ejemplos sencillos, as como en dos mini-aplicaciones completas. No obstante, un enfoque como ste conlleva una gran cantidad de esfuerzo de actualizacin, dado que tanto el API de J2EE como del entorno de desarrollo usado (base de datos, contenedores de JSP y EJB, etc.) estn sujetos a mejoras y ampliaciones constantes, lo que ha significado (ej.: de EJB 1.1 a EJB 2.x, de los tags de Struts a sus contrapartidas en JSTL, etc.) y significar (ej.: de Struts a JavaServer Faces, etc.) cambios importantes, tanto en el temario como en el cdigo en el que se apoya.

9 Referencias
1. E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addisson-Wesley, 1994. 2. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns, John Wiley and Sons, 1996. 3. J. Crupi, D. Alur, D. Malks, Core J2EE Patterns (first edition), Prentice Hall, 2001. 4. F. Marinescu, EJB Design Patterns, John Wiley & Sons, 2002. 5. Jakarta Struts, http://jakarta.apache.org/struts/index.html. 6. Java Pet Store, http://java.sun.com/blueprints/code. 7. I. Singh, B. Stearns, M. Johnson, Designing Enterprise Applications with the J2EE Platform, Second Edition, Addison-Wesley, 2002. 8. J2EE BluePrints, http://java.sun.com/blueprints/enterprise. 9. xPetstore, http://xpetstore.sourceforge.net. 10. F. Bellas, Material de la asignatura Integracin de Sistemas (Diseo e Implementacin con J2EE), http://www.tic.udc.es/~fbellas/teaching/is. 11. Java Transaction API (JTA) Specification, http://java.sun.com/products/jta.

20

12. Java Architecture for XML Binding (JAXB) Specification, http://java.sun.com/xml/jaxb. 13. Jakarta Commons Digester, http://jakarta.apache.org/commons/digester.html. 14. F. Bellas, Material de la asignatura Anlisis y Diseo Orientado a Objetos (Diseo e Implementacin con Tecnologas de Integracin de Aplicaciones: CORBA y Servicios Web), http://www.tic.udc.es/~fbellas/teaching/adoo. 15. K. Brown, Rules and Patterns for Session Facades, http://www7b.software.ibm.com/wsdd/library/techarticles/0106_brown/sessionfacades. html, 2001. 16. I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software Development Process, Addison-Wesley, 1999.

21