Utilizacion de Los Padrones Parte 2

CASO DE ESTUDIO: PET STORE , UNA APLICACIN DISEADA POR SUN MICROSYSTEMS ................... 4 6.
VISTA GENERAL DE LA APLICACIN DE CASO DE ESTUDIO .............................................................. 4 6.1. EL SITIO WEB DEL PET STORE ........................................................................................................ 6 6.2. UN RECORRIDO POR EL SITIO WEB DEL PET STORE. .......................................................................... 6 6.2.1. PANTALLA INICIAL .............................................................................................................................. 6 6.2.2. PANTALLA DE BIENVENIDA................................................................................................................... 7 6.2.3. PANTALLA DE CATEGORAS .................................................................................................................. 9 6.2.4. PANTALLA DEL PRODUCTO................................................................................................................. 10 6.2.5. PANTALLA DE ITEMS ......................................................................................................................... 11 6.2.6. PANTALLA DEL CARRO DE COMPRAS. ................................................................................................... 11 6.2.7. PANTALLA DE CONEXIN ................................................................................................................... 12 6.2.8. PANTALLA DE INFORMACIN DE LA CUENTA.......................................................................................... 13 6.2.9. PANTALLA DE INFORMACIN DE LA ORDEN ........................................................................................... 15 6.2.10. PANTALLA DE LA ORDEN COMPLETA .................................................................................................... 16 6.3. OPCIONES DE DISEO DE ALTO NIVEL DEL PET STORE. ................................................................................. 16 6.3.1. ESTRUCTURA DEL SITIO WEB DE LA PET STORE. ..................................................................................... 18 6.3.2. DISEO MODULAR DE LA PET STORE. .................................................................................................. 20 6.3.3. COMPONENTES DE APLICACIN DEL SITIO WEB DE LA PET STORE.............................................................. 22 6.3.3.1. ENTERPRISE BEANS DE LA PET STORE. .................................................................................................. 22 6.3.3.2. PGINAS JSP DE LA PET STORE........................................................................................................... 25 6.3.3.3. SERVLET FILTERS DE LA PET STORE. ..................................................................................................... 27 6.3.3.4. ARCHIVOS XML DE LA PET STORE. ...................................................................................................... 27 6.3.3.5. ENVIADOR ASINCRNICO. .................................................................................................................. 28 6.3.3.6. POPULATE SERVLET. ......................................................................................................................... 28 6.4. VISTA DE LA ARQUITECTURA DE LA APLICACIN DESDE UN ALTO NIVEL. ........................................................... 29 6.5. DISEO DE LA APLICACIN DE CASO DE ESTUDIO. ....................................................................................... 30 6.5.1. SELECCIONANDO LAS CAPAS DE LA APLICACIN. ........................................................................ 32 6.5.2. SELECCIONANDO LA ARQUITECTURA LOCAL O DISTRIBUIDA. ...................................................... 34 6.5.2.1. COMPARACIN ENTRE LAS ARQUITECTURAS LOCAL Y DISTRIBUIDA. ............................................................ 34 6.5.2.2. OPCIONES PARA ARQUITECTURAS LOCAL Y DISTRIBUIDA EN LA PLATAFORMA J2EE. ....................................... 35 6.5.3. PATRONES J2EE APLICADOS AL PET STORE ........................................................................................... 36 6.5.4. BUSINESS DELEGATE. ....................................................................................................................... 37 6.5.4.1. EJEMPLO DETALLADO. ................................................................................................................ 37 6.5.4.2. COMPOSITE ENTITY .......................................................................................................................... 40 6.5.4.2.1. EJEMPLO DETALLADO................................................................................................................... 40 6.5.4.3. COMPOSITE VIEW ............................................................................................................................ 44 6.5.4.3.1. EJEMPLO DETALLADO................................................................................................................... 44 6.5.4.4. DATA ACCESS OBJECT (DAO) ............................................................................................................ 48 6.5.4.4.1. EJEMPLO DETALLADO................................................................................................................... 48 6.5.4.4.2. ACCESANDO A UNA BASE DE DATOS CON UN DAO ............................................................................. 48 6.5.4.4.3. ESTRATEGIAS DE IMPLEMENTACIN ................................................................................................ 51 6.5.4.5. FRONT CONTROLLER ........................................................................................................................ 60 6.5.4.5.1. EJEMPLO DETALLADO................................................................................................................... 60 6.5.4.6. INTERCEPTING FILTER ................................................................................................................. 62 6.5.4.6.1. EJEMPLO DETALLADO................................................................................................................... 62
Nelson Salgado Reyes
6.5.4.7. MODELO-VISTA-CONTROLADOR......................................................................................................... 63 6.5.4.7.1. EJEMPLO DETALLADO................................................................................................................... 63 6.5.4.8. SERVICE LOCATOR............................................................................................................................ 64 6.5.4.8.1. EJEMPLO DETALLADO................................................................................................................... 65 6.5.4.9. SESSION FACADE ......................................................................................................................... 70 6.5.4.9.1. EJEMPLO DETALLADO................................................................................................................... 70 6.5.4.10. TRANSFER OBJECT .................................................................................................................. 72 6.5.4.10.1. EJEMPLO DETALLADO................................................................................................................... 72 6.5.4.11. VALUE LIST HANDLER .............................................................................................................. 75 6.5.4.11.1. EJEMPLO DETALLADO................................................................................................................... 75 6.5.4.12. VIEW HELPER ......................................................................................................................... 79 6.5.4.12.1. EJEMPLO DETALLADO................................................................................................................... 79 7. CONCLUSIONES Y RECOMENDACIONES ........................................................................................... 84 7.1. CONCLUSIONES.................................................................................................................................... 84 7.2. RECOMENDACIONES. ............................................................................................................................ 85 8. BIBLIOGRAFIA..................................................................................................................................... 87 9. ANEXOS............................................................................................................................................... 89 9.1. ANEXO A :DIAGRAMAS UML UTILIZADOS ............................................................................................... 89 9.1.1. DIAGRAMA DE CLASES ...................................................................................................................... 89 9.1.1.1. CLASES. ......................................................................................................................................... 89 9.1.1.2. OBJETOS. ....................................................................................................................................... 89 9.1.1.3. ASOCIACIONES ................................................................................................................................ 90 9.1.1.3.1. NOMBRE DE LA ASOCIACIN Y DIRECCIN ............................................................................. 90 9.1.1.3.2. MULTIPLICIDAD ...................................................................................................................... 91 9.1.1.3.3. ROLES ....................................................................................................................................... 92 9.1.1.3.4. AGREGACIN .......................................................................................................................... 92 9.1.1.3.5. CLASES ASOCIACIN .............................................................................................................. 93 9.1.1.3.6. ASOCIACIONES N-ARIAS ......................................................................................................... 93 9.1.1.3.7. NAVEGABILIDAD..................................................................................................................... 94 9.1.1.3.8. HERENCIA ............................................................................................................................... 94 9.1.1.3.9. ELEMENTOS DERIVADOS......................................................................................................... 95 9.1.2. DIAGRAMA DE CASOS DE USO ............................................................................................................ 96 9.1.2.1. ELEMENTOS .................................................................................................................................... 97 9.1.2.1.1. ACTORES ................................................................................................................................... 97 9.1.2.1.2. CASOS DE USO............................................................................................................................ 97 9.1.2.1.3. RELACIONES ENTRE CASOS DE USO ................................................................................................. 97 9.1.3. DIAGRAMA DE SECUENCIAS ............................................................................................................... 99 9.2. ANEXO B : ELEMENTOS LXICOS DEL LENGUAJE DE PROGRAMACIN JAVA................................................... 100 9.2.1. QU ES JAVA? ............................................................................................................................. 100 9.2.2. PALABRAS RESERVADAS .................................................................................................................. 101 9.2.3. IDENTIFICADORES .......................................................................................................................... 101 9.2.4. LITERALES. ................................................................................................................................... 101 9.2.5. OPERADORES. ............................................................................................................................... 102 9.2.6. DELIMITADORES ............................................................................................................................ 103 9.2.7. COMENTARIOS. ............................................................................................................................. 104 9.2.8. APNDICES. .................................................................................................................................. 104
9.3. 10.
ANEXO C : LICENCIA DE USO DE LA PET STORE ....................................................................................... 106 GLOSARIO DE TERMINOS ............................................................................................................ 108
La experiencia es madre de los buenos consejos. Juan de Torres
CASO DE ESTUDIO: PET STORE , UNA APLICACIN DISEADA POR SUN MICROSYSTEMS
6. Vista General de la Aplicacin de Caso de Estudio
La aplicacin de Caso de Estudio es un aplicacin tpica de comercio electrnico: una tienda de mascotas empresarial que vende productos (mascotas) a los clientes. La aplicacin tiene un sitio web a travs del cual presenta un interfaz a los clientes. Los administradores y negociantes externos tales como proveedores usan otras interfaces de aplicacin para mantener el inventario y para tareas de administracin. Cada clase de usuarios tiene acceso a categoras de funcionalidad especfica, y cada usuario interacta con la aplicacin a travs de un mecanismo de interface de usuario especfico. Mientras la aplicacin maneja la mayora de tareas automticamente, algunas de las tareas deben ser realizadas manualmente., tales como manejo de inventarios y embarque de rdenes. Se puede considerar la aplicacin completa como una Tienda de Mascotas Empresarial. La Figura 6.3 provee una vista de alto nivel del negocio o el problema del mundo real que la aplicacin intentar resolver.
Figura 6.1. Negocio del Mundo real.
El sitio web presenta un interface de la tienda de mascotas en lnea al cliente. El cliente compra y pone una orden a travs de la interface. Cuando el cliente completa una orden, la interface enva la orden al centro de atencin de rdenes. Por que la unidad funcional del sitio web maneja el procesamiento de negocios posteriormente cuando enva una orden de adquisicin para el centro de atencin , puede ser pensado como el front-end. El centro de atencin completa las rdenes del cliente. Tiene un componente de completacin de la orden y un componente de proveedor. El centro de atencin procesa las rdenes basado en las reglas del negocio de la empresa, maneja transacciones financieras y arregla para que los productos sean enviados a los clientes. Porque no todos los productos tienen stock en cualquier momento, el procesamiento de la orden podra demorar otro perodo de tiempo adicional. Los administradores y otros proveedores podran interactuar con el centro de atencin. Esta porcin del negocio est referida al back-end , porque su procesamiento es disparado al ingresar la orden ,
una accin que ocurre en una porcin del Sitio Web. Aunque el componente de proveedor es parte de la aplicacin de caso de estudio , podra fcilmente ser un servicio externo a la aplicacin.
6.1. El Sitio Web del Pet Store

El sitio Web del Pet Store es la parte de la aplicacin de caso de estudio que provee a los clientes comprar en lnea, mascotas. A travs del Web Browser , un cliente puede desplegar el catlogo , poner los tems para adquirirlos en un carro de compras virtual , crear una cuenta de usuario para conectarse y adquirir los contenidos del carro de compras creando una orden con una tarjeta de crdito.
6.2. Un recorrido por el Sitio Web del Pet Store.

Esta seccin presenta una vista al sitio Web desde el punto de vista del usuario.Las siguientes subsecciones muestran un camino del comprador individual a travs de una serie de peticiones al Pet Store.
6.2.1. Pantalla Inicial

Si el pet store est instalado en una mquina local el usuario acceder a ste usando un browser de HTML visitando el URL http://localhost:8000/petstore/index.jsp , mostrado en la Figura 6.2. Esta pantalla permite al usuario ejecutar una variedad de tareas , tales como repoblar la base de datos del Sitio Web para compras. Cuando el usuario accesa al enlace rotulado como enter the store la aplicacin popula la base de datos con los datos del catlogo ( a menos que los datos ya existan) y redirecciona la peticin al URL /main.screen. (Todos los URLs listados en esta seccin son relativos al context root o directorio raz de la aplicacin.
Figura 6.2. Pantalla Inicial del Pet Store (/index.jsp).
6.2.2. Pantalla de Bienvenida

Una vez que la base de datos est populada, la pantalla de bienvenida main.screen aparece como muestra la Figura 6.3. Como las otras pantallas del Pet Store, esta pantalla fue ensamblada desde una plantilla y por tanto tiene un modelo Standard. La pantalla permite al usuario desplegar el catlogo, conectarse, configurar la informacin de su cuenta , y seleccionar el idioma y la localidad. La imagen en el centro es una imagen mapa. Seleccionando con el ratn uno de los animales en el mapa se muestran la pgina de categoras para ese tipo de animal. Por ejemplo , la imagen del perro es un enlace al URL /product.screen?product_id=DOGS.
Figura 6.3 Pantalla de Bienvenida (/main.screen)
6.2.3. Pantalla de Categoras

La pantalla de categoras muestra todos los productos para una categora en particular , La pantalla de productos para la categora DOGS es mostrada en la Figura 6.4. La cadena de consulta del GET del URL es usada por custom tags en la pgina JSP para producir el contenido apropiado. Seleccionando el enlace Next en el botn de la esquina derecha de la lista de productos muestra la siguiente lista de un grupo de productos dentro de la categora. En este ejemplo , si se selecciona el enlace Chihuahua se despliega al usuario una pantalla de productos que contiene todos los Chihuahuas.
Figura 6.4.-Pantalla de Categora (/product.screen?category_id=DOGS)
6.2.4. Pantalla del Producto

La pantalla de producto muestra todos los tems de un producto en particular. Por ejemplo la figura 6.5 muestra todos los producto Chihuahua en el Pet Store. Note que la columna derecha de la lista muestra el precio del item e incluye un enlace rotulado como Add to Cart. Este enlace , que tambin aparece en la pantalla para el correspondiente item permite al cliente aadir un item al carro sin mirar los detalles del item. Es a menudo una buena idea proporcionar acceso a la misma funcin en ms de un lugar , proporcionando a los usuarios un acceso directo. Esta tcnica hace que el usuario experimente ms rpido acceso a sus peticiones en la pgina. En este ejemplo el cliente selecciona con el ratn el enlace Adult Male Chihuahua el cual despliega la pgina de item para ese item.
Figura 6.5 Pantalla del Producto
6.2.5. Pantalla de Items

La pantalla de tems muestra la informacin detallada acerca de un item individual para la venta , incluyendo una foto si est disponible. La pantalla de item para un adulto macho Chihuahua aparece en la Figura 6.6. El enlace Add to Cart cuando es seleccionado aade un item para orden en el carro de compras virtual , y entonces muestra los contenidos del carro de compras.
Figura 6.6 Pantalla de Item (/item.screen?item_id=EST-26)
6.2.6. Pantalla del Carro de Compras.

La pantalla del carro de compras , mostrada en la Figura 6.7 lista los tems que actualmente estn en el carro de compras , y permite al cliente cambiar la cantidad de cada item ordenado y muestra un ttulo. Tambin incluye un enlace para quitar un item del carro , y un enlace para proceder con la salida de los artculos Proceed to Ckeckout el cual cuando es seleccionado muestra la pantalla de informacin de la orden si el usuario est conectado. Si el usuario no est conectado la pantalla de conexin aparecer en lugar de la pantalla de informacin de la orden.
Figura 6.7.- Pantalla de Carro de compras (/cart.do?action=purchased&itemId=EST-26)
6.2.7. Pantalla de Conexin

La pantalla de conexin (Figura 6.8) permite a un cliente existente conectarse como usuario existente y a un nuevo cliente crear una cuenta para conectarse. Un cliente existente ingresa el nombre de usuario y la clave y la aplicacin despliega la pantalla de Informacin de Orden como se muestra en la Figura 6.9. Un nuevo cliente ingresa un nombre de usuario y una clave y selecciona con el ratn el born Create New Account. La aplicacin crea un usuario con la clave solicitada. Si la creacin del usuario es exitosa , la aplicacin despliega la pantalla de Informacin de la cuenta.
Figura 6.8.- Pantalla de Conexin (/signon.screen)
6.2.8. Pantalla de Informacin de la Cuenta

La pantalla de Informacin de la cuenta mostrada en la figura 6.9 , muestra la informacin acerca del nuevo cliente , incluye informacin de contacto , tarjeta de crdito , y preferencias personales.
Esta pantalla tambin se despliega cuando el clientes selecciona con el ratn el enlace rotulado como Account en la esquina superior derecha ( debajo de Search) . Seleccionado el botn Update direcciona al browser a la pgina que resume la informacin ingresada.
Figura 6.9 Pantalla de Informacin de la Cuenta (/createuser.do)
6.2.9. Pantalla de Informacin de la Orden

La pantalla de Informacin de la Orden permite al usuario ingresar las direcciones de envio y embarque. Los valores predeterminados para las direcciones vienen de la informacin de contacto del cliente actualmente conectado. Esta informacin es transmitida a la aplicacin cuando el usuario presiona Submit, La aplicacin crea una nueva orden , y la envia para el centro de procesamiento de rdenes y depliega la pantalla de Orden Completa.
Figura 6.10.- Pantalla de la Informacin de la Orden
6.2.10.
Pantalla de la Orden Completa
La pantalla de la Orden Completa verifica al usuario que la orden ha sido receptada. La pantalla incluye el nmero de Orden.
Figura 6.11.- Pantalla de Orden Completa
6.3. Opciones de Diseo de alto nivel del Pet Store.

El sitio Web del Pet Store refleja varias opciones de diseo que tienen un impacto global en el comportamiento y rendimiento de la aplicacin. Entre estas opciones tenemos:
Uso de un Framework de aplicacin. Aplicaciones ms pequeas a menudo no usan un framework de aplicacin o manejan las peticiones usando mecanismos simples de despacho y pierden las convenciones de codificacin. Aplicaciones ms grandes a menudo se benefician de un framework de aplicacin MVC como WAF (Web Application Framework) que es mostrada en la aplicacin de caso de estudio. La estructura consistente y separacin funcional de MVC impuesta por el framework crea las aplicaciones ms fiables y fciles mantener y extender. Los componentes de la aplicacin desarrollados por un framework son a menudo ms reusables como buenas. Por estas razones el sitio web del Pet Store est diseado en base a un framework de aplicacin de MVC.
La lgica del negocio en la capa web versus componentes de enterprise beans. Muchas aplicaciones implementan toda su lgica de negocio en clases de la capa web. Para aplicaciones a gran escala y complejas a menudo se escoge la tecnologa de enterprise beans para proveer escalabilidad , fiabilidad , un modelo de desarrollo basado en componentes , y servicios horizontales comunes como persistencia , comunicacin
asincrnica , transacciones declarativas y control de seguridad. El sitio web del Pet Store usa enterprise beans por todos estos beneficios. Arquitectura local versus Arquitectura distribuida. Los clientes enterprise beans en una arquitectura distribuida accede a los componentes enterprise beans a travs de interfaces remotas. Mientras los enterprise beans remotos mejoran la escalabilidad y la disponibilidad el alto costo de la comunicacin remota los hace mayormente apropiadas para operaciones de grano grueso. Los enterprise beans locales residen en el mismo JVM (Java Virtual Machine) que sus clientes, por tanto estos evitan las costosas llamadas a procedimientos remotos. Los enterprise beans locales proveen de alto rendimiento accediendo a la lgica de negocio de grano fino , mientras mantiene el alto nivel de servicios de un contenedor de enterprise beans. El sitio web del Pet Store usa la vista de cliente local de los enterprise beans para mejorar el rendimiento y simplificar el desarrollo. Control de transacciones declarativa versus control de transacciones programtica. Las transacciones J2EE pueden ser controladas programticamente en cdigo o
declarativamente en descriptores de implementacin. Las transacciones declarativas son ms fciles para crear y administrar , mientras que las transacciones programticas
ofrecen un alto nivel de control. El Sitio Web del Pet Store usa un control de transacciones programtica para asegurar la consistencia de los datos cuando genera vistas ,y usa control de transacciones declarativas cuando actualiza datos en la capa EJB. Comunicacin sincrnica versus comunicacin asincrnica. La comunicacin sincrnica es la ms til cuando una operacin puede producir un resultado en una cantidad razonable de tiempo. La comunicacin asincrnica es ms compleja para implementar y manejar, pero es til para integrar alta latencia , desconfianza u operaciones paralelas. La mayora de aplicaciones usan una combinacin de las comunicaciones sincrnica y asincrnica. Por ejemplo el sitio web del Pet Store accede sincrnicamente a su catlogo , por que accede a un catlogo en una operacin rpida. El sitio web transmite rdenes de compra
asincrnicamente porque las rdenes podran tomar un perodo de tiempo largo para completarse , y el centro de procesamiento de rdenes podra no siempre estar disponible
6.3.1. Estructura del Sitio Web de la Pet Store.

El sitio web de la Pet Store es construdo encima de otros servicios, como se muestra en la figura 6.12. El cdigo de sitio web de la Pet Store est construdo encima del WAF (Web Application Framework) , un framework de aplicacin que est includo en la aplicacin de caso de estudio. Las aplicaciones J2EE pueden usar las facilidades WAF para controlar el flujo de navegacin de la aplicacin , generar vistas y activar componentes de negocio que ejecutan las funciones de negocio de la aplicacin. Ambos los componentes de negocio y los WAF en s mismos dependen de las tecnologas de la plataforma J2EE.
Figura 6.12 La Pet Store est construda encima de los otros servicios.
El WAF provee un nmero de servicios que la mayora de las aplicaciones Web requieren, incluyendo solicitudes de despacho y filtrado , generacin de vistas de plantillas , un conjunto de custom tags reusables , y el control de flujo de la interfaz . El cdigo que implementa las funciones especficas para el sitio web de la Pet Store (mostrada al inicio de la Figura 6.12 , usa enlaces en el WAF para extender el comportamiento predeterminado del WAF. Como la lgica de la aplicacin , las mayor parte de componentes mostrados en la Figura 6.12 son aplicaciones especficas: ests representan datos y operaciones en estos datos. Los beans de entidad representan entidades de negocio tales como Customer , Address y Account,. Los beans de Sesin manejan tales funciones de aplicacin como conexin y desconexin de un usuario al sistema y manejo del carro de compras virtual. Otros beans de sesin proveen funciones utilitarias tales como generacin de identificadores nicos. Los componentes Java Beans tradicionales sirven como clases value object para comunicar entre componentes dentro de la aplicacin, y las clases de documentos XML son usadas para interoperar con el coordinador del procesamiento de la orden. El cdigo especfico de la aplicacin mostrada en la figura 6.12 consiste mayormente de cdigo goma que une los eventos de la interface del usuario a las operaciones de los componentes de negocio del back-end. Por ejemplo cuando un usuario solicita que la aplicacin de la Pet Store aada un item al carro de compras , el WAF activa el cdigo de la aplicacin que aade el item al componente del carro de compras.
6.3.2. Diseo Modular de la Pet Store.

La Pet Store fue desarrollada como una coleccin de mdulos funcionales separados con interfaces bien definidas. El desarrollo modular acopla componentes de un mdulo a otro. Este acoplamiento facilita el mantenimiento, simplifica el desarrollo paralelo y provee oportunidades para incorporar componentes de terceros. La Pet Store est compuesta de los siguientes mdulos: Mdulo de Control: El mdulo de control despacha las peticiones a la lgica del negocio , controla el flujo en la interfaz , coordina las interacciones de los componentes , y activa la conexin y el registro de los usuarios. El mdulo de control es implementado por el WAF y por extensiones WAF especficos de la aplicacin. Mdulo de Carro de Compras: El carro de compras lleva una cuenta de los tems que un usuario ha seleccionado para comprarlos. Mdulo de Autenticacin: El mdulo de autenticacin requiere que un usuario se conecte antes de acceder a ciertas interfaces y maneja los procesos de autenticacin. Mdulo de mensajera: El mdulo de mensajera transmite asincrnicamente las rdenes de compra desde la Pet Store al OPC (Order Processing Center). Mdulo de Catlogo: El mdulo del catlogo provee una vista basada en pgina del catlogo basado en un criterio de bsqueda del usuario. Mdulo del Cliente: El mdulo del cliente , representa la informacin del cliente: direcciones , tarjetas de crdito , informacin de contacto , etc.
La Figura 6.13 muestra estos mdulos.
Figura 6.13 Mdulos Funcionales de la Pet Store.
La figura muestra que el usuario accede a la Pet Store usando un browser como interfaz de usuario. El mdulo de control se encarga de toda la comunicacin y ejecucin en la Pet Store. Cada sesin de usuario tiene un objeto carro de compras que usa para llevar cuenta de cualquier compra.
6.3.3. Componentes de Aplicacin del Sitio Web de la Pet
Store.
La Pet Store compromete varios tipos de cdigo especfico de aplicacin y datos.:
Enterprise beans: que representan los datos del negocio y ejecutan la lgica del negocio.
Pginas JSP : que define una plantilla de la vista de la aplicacin ( template.jsp) y los contenidos de las reas de la plantilla. Tambin incluye varios archivos grficos usados por las pgina JSP.
Archivos XML : que definen interfaces , control de flujo de interfaces , peticiones de enlaces de URLs en acciones HTML , define autenticacin de usuarios y define los contenidos de la base de datos de ejemplo ; tambin los descriptores de implantacin J2EE estndar.
Servlet filters : que coordinan la autenticacin del usuario y forzan la respuesta encriptada.
Un componente enviador asincrnico: que construye y transmite mensajes XML representando rdenes al OPC.
Un programa de populacin : que pobla la base de datos de ejemplo.
6.3.3.1.
Enterprise beans de la Pet Store.
La Pet Store usa beans de sesin para implementar los procesos del negocio , y beans de entidad para representar y manipular datos del negocio. Todos los beans en la Pet Store proveen solamente una interfaz local a sus clientes. La Pet Store requiere productos que sean compatibles con J2EE 1.3. Tambin no se ejecutar en productos J2EE que no provean interfaz local que
accedan desde la capa Web , por que algunos componentes de capa Web usan interfaces locales de enterprise beans.
Beans de Sesin Los beans de sesin usados por la Pet Store son: AsyncSenderEJB- (Stateless) covierte los contenidos del carro de compras y los datos del cliente a un mensaje XML representando una orden, y enva el mensaje al OPC. CatalogEJB(Stateless) prove una interfaz programtica para el catlogo. ShoppingCartEJB(Stateful) mantiene los contenidos de un carro de compras de un usuario individual ShoppingControllerEJB(Stateful) prove acceso al Facade del cliente que est de compras ; extiende el controlador EJB del WAF (EJBControllerLocalEJB) ShoppingClientFacadeEJB(Stateful) almacena en cache las referencias y prove acceso unificado al cliente , al carro de compras y a la identificacin del usuario. SignOnEJB(Stateless) crea y autentica los usuarios del sistema UniqueIdGeneratorEJB(Stateless) crea identificadores de objetos nicos globales
Beans de Entidad La Pet Store usa los siguientes beans de entidad. Todos los beans usan CMP contenedor manejado por persistencia. CustomerEJBguarda el identificador del cliente (primary key), cuenta y perfil AccountEJBguarda el estado de la cuenta, la tarjeta de crdito y la informacin de contacto. ProfileEJBguarda el lenguaje preferido , la categora , la lista de preferencias y el banner de preferencia. ContactInfoEJBguarda los nombres , telfono , correo electrnico y direccin CreditCardEJBguarda el nmero de tarjeta de crdito , el tipo de tarjeta y la fecha de expiracin
AddressEJBguarda dos lneas de las direccin de la calle , cdigo postal y pas UserEJB representa a un usuario que puede conectarse al sistema : guarda el nombre de usuario y la clave. CounterEJBrepresenta un contador con un prefijo especfico UniqueIdGeneratorEJB oara manejar series de nmeros nicos. usado solo por
Figura 6.14. Beans de Entidad locales que guardan informacin del cliente.
Todos los beans de entidad en la Pet Store con excepcin de CounterEJB . guardan informacin del cliente. Un diagrama de clases involucrado en la identidad del cliente en la Pet Store aparece en la Figura 6.14.
6.3.3.2.
Pginas JSP de la Pet Store.
La pet store define las pginas JSP mostradas en la tabla 6.1. Nombre de la Pgina JSP advice_banner.jsp Descripcin Despliega los tips al final de la pantalla si los tips estn en encendido banner.jsp Despliega el banner al principio de la pantalla si el banner estn en encendido cart.jsp cart_empty_order_error.jsp Despliega los contenidos del carro de compras Pgina de error cuando el usuario intenta comprar contenidos de un carro vaco create_customer.jsp customer.jsp Formulario para crear un cliente Despliega informacin del cliente.
Nombre de la Pgina JSP duplicate_account.jsp
Descripcin Mensaje de error reportando que el usuario a intentado crear una cuenta con un nombre existente
edit_customer.jsp footer.jsp general_error.jsp
Formulario para editar informacin del cliente Despliega un mensaje al pie de la pgina Despliega errores miscelneos no cubiertos por otras pginas de error
index.jsp item.jsp
Pgina principal de la aplicacin Despliega los detalles del item del catlogo.
items.jsp
Despliega la lista de los tems desde una bsqueda o despliegue del catlogo
main.jsp
La pantalla inicial que tiene el grfico que tiene loro grande y tiene enlaces a las categoras
mylist.jsp order_completed.jsp
Despliega las mascotas favoritas del usuario. Mensaje que notifica la orden de un cliente y reporta el nmero de orden
product.jsp
Despliega una lista de productos para una categora particular
advice_banner.jsp
Despliega los tips al final de la pantalla si los tip estn en encendido.
search.jsp sidebar.jsp signoff.jsp signon.jsp
Formulario de bsqueda Menu Bar de un lado Mensaje que indica al usuario ha sido desconecto Permite a la autenticacin del sistema como un usuario existente o como una cuenta nueva
signon_failed.jsp
Reporta que la autenticacin ha fallado y provee una razn
template.jsp
Define un diseo de pgina para una aplicacin entera Tabla 6.1 Pginas JSP usadas en la aplicacin de la Pet Store
6.3.3.3.
Servlet Filters de la Pet Store.
La Pet Store define dos servlet filters:
SignOnFilter : Coordina la autenticacin del usuario y el registro del cliente. EncodingFilter : Asegura que toda pgina de la Pet Store sirva para que los browser tengan su apropiada codificacin.
6.3.3.4.
Archivos XML de la Pet Store.
Varios archivos XML soportan operaciones de la Pet Store.Entre esos tenemos:
application.xml : Es el descriptor de instalacin de J2EE estndar para la aplicacin J2EE del sitio web de la Pet Store. web.xml : Es el descriptor de instalacin de J2EE estndar para componentes de la capa Web de la Pet Store. ejb-jar.xml: Son los descriptores de instalacin de J2EE estndar para componentes de la capa EJB de la Pet Store. Existen varios de estos , uno por cada unidad de instalacin de los enterprise beans.
sun-j2ee-ri.xml: El descriptor de instalacin de un proveedor especfico , que contiene especficamente la informacin de instalacin para la implementacin de la referencia J2EE. Cada implementacin de la plataforma necesita un descriptor tal que contenga la informacin especfica de la instalacin que se va a implementar.
Otros archivos XML en la pet store que son especficos para la aplicacin de la Pet Store son: populate-UTF8.xml: contiene los datos usados para poblar la base de datos de ejemplo populateSQL.xml : contiene las sentencias de Cloudscape y Oracle SQL para crear la base de datos de ejemplo. Cloudscape es una base de datos relacional instalada con la implementacin de referencia J2EE.
catalogDAOSQL.xml :contiene las sentencias de Cloudscape y Oracle SQL que son usadas por el Catalogado para acceder a los datos en la base datos de ejemplo. mappings.xml: Define ambos el mapa de solicitudes de la Pet Store y el mapa de flujo de la interfaz de la pet store. screendefinitions_en_US.xml: define las pantallas para la aplicacin localizadas para el idioma Ingls de Estados Unidos. screendefinitions_ja_JP.xml : define las pantallas para la aplicacin localizadas para el idioma Japons . signon-config.xml: Configura el SignOnFilter.
6.3.3.5.
Enviador asincrnico.
La Pet Store usa el componente AsyncSender para crear rdenes en el OPC. El componente AsyncSender es un bean de sesin stateless que transforma los contenidos del carro de compras de la pet store y la informacin de la factura en un documento XML y enva el documento al OPC como un mensaje JMS. La Aplicacin del OPC comienza el proceso de cumplimiento en la recepcin del mensaje.
6.3.3.6.
Populate Servlet.
El Populate Server crea la base de datos para la aplicacin de ejemplo. Est diseado para ser portable a travs de las implementaciones de la plataforma J2EE. Crea un esquema persistente usando DDL desde PopulateSQL.xml , y entonces crea instancias de los beans de entidad usando datos desde el archivo Populate-UTF8.xml. Cuando el populate servlet se ejecuta por primera vez un usuario accede a la pet store despus de la instalacin. Tambin podra ser ejecutada forzadamente desde la pgina principal de la pet store.
6.4. Vista de la Arquitectura de la aplicacin desde un alto
nivel.
Las versiones de la aplicacin de caso de estudio anteriores a la 1.3 fueron ejemplos de aplicaciones monolticas que manejaban interacciones de los clientes en el sitio web , un historial de las rdenes y su administracin. Las aplicaciones empresariales del mundo real, son raramente solamente sistemas monolticos. La mayora de las aplicaciones empresariales deben cooperar con mltiples fuentes de datos y sistemas de informacin empresariales (EISs). Estos sistemas externos podran ser conjuntos de informacin interna , tales como bases de datos de legado o sistemas de planeacin de recursos de la empresa (ERP). Otros sistemas externos podran ser los servicios web de los socios de negocios. Por ejemplo , el centro de satisfaccin de rdenes es interno a la empresa ,el servicio de tarjeta de crdito es externo a la empresa , y los proveedores podran ser internos ( en un almacen de datos empresarial , por ejemplo) o externo a la empresa. La aplicacin de caso de estudio versin 1.3 refabrica la pet store en mdulos separados y tambin aade nueva funcionalidad tal como la habilidad de interactuar con mltiples proveedores. El resultado es un desacople de la arquitectura empresarial que puede interoperar con fuentes de datos existentes y sistemas de socios de negocios , todo construido sobre la plataforma J2EE. La aplicacin de caso de estudio compromete cuatro subaplicaciones separadas que cooperan para completar las necesidades de negocio de la empresa. , cada una de las cuales es una aplicacin J2EE: Sito web de comercio electrnico de la pet store: una aplicacin web la cual los compradores usan para adquirir mercadera a travs del web browser. La aplicacin de administracin de la Pet store (petstoreadmin): una aplicacin web que los administradores empresariales usan para ver las estadsticas de ventas y en la cual manualmente aceptan o rechazan rdenes. Mientras la petstoreadmin es una aplicacin web su interfaz de usuario es un cliente rico que usa mensajera XML , en lugar de un web browser con HTML. Centro de procesamiento de rdenes (OPC) : un proceso orientado a la aplicacin que maneja el cumplimiento de la orden proveyendo los siguientes servicios a otros participantes empresariales:
Recibe y procesa documentos XML, va JMS , conteniendo rdenes desde las petstore. Provee a la aplicacin petstoreadmin con datos de una orden usando mensajera XML sobre HTTP. Enva correos a los clientes para confirmacin de sus rdenes usando JavaMail. Enva documento de rdenes con XML para los proveedores va JMS. Mantiene la base de datos de las rdenes de adquisiciones Proveedor (supplier) : una aplicacin orientada a proceso que maneja el envo de los productos a los clientes proveyendo los siguientes servicios: Recibir documento de rdenes XML desde el opc va JMS. Enviar los productos a los clientes. Proveer un manejo del inventario manual a travs de la interfaz basada en web Mantiene la base de datos del inventario.
6.5. Diseo de la aplicacin de Caso de Estudio.

El diseo de una aplicacin comienza con el levantamiento de los requerimientos funcionales y entonces se determina una implementacin de software ptimo para cumplir esos requerimientos. Hay numerosas herramientas para anlisis para reunir y evaluar los requerimientos de la aplicacin. El anlisis de casos de uso es una de esas herramientas. El anlisis de casos de uso identifica los actores en un sistema y las operaciones que podran ejecutar. La aplicacin de la pet store es un tpico sitio de comercio electrnico. El cliente selecciona los tems de un catlogo , los pone en un carro de compras , cuando est listo compra los contenidos del carro de compras. Previo a la compra , la aplicacin despliega la orden: los tems seleccionados , la cantidad y el precio de cada item y el costo total. El cliente puede revisar o actualizar la orden. Para completar la compra el cliente ingresa un direccin de envo y un nmero de tarjeta de crdito. La Figura 6.15 muestra en un alto nivel el diagrama de casos de uso para la aplicacin de caso de estudio. Se muestran los actores del sistema potenciales y sus acciones:
Figura 6.15 Diagrama de casos de uso para la aplicacin de caso de estudio
Un cliente compra , pone ordenes , maneja su cuenta de usuario y recibe correos. Un gerente de administracin maneja reportes de datos financieros de la empresa Un sistema bancario procesa las tarjetas de crdito Un trabajador del almacen empaca y enva ordenes
Una vez que se ha determinado los requerimientos del sistema , se puede comenzar a disear la aplicacin. Se ha diseado la aplicacin usando dos diferentes modelos de arquitectura. La arquitectura MVC trabaja bien para la parte interactiva del sitio web , tal como el sitio web de la pet store. Ya que el centro de satisfaccin no es una aplicacin interactiva , su diseo est basado en la arquitectura orientada a procesos.
6.5.1. Seleccionando las capas de la aplicacin.

Un importante paso en el diseo es decidir las capas que la aplicacin usar. La plataforma J2EE est diseada para aplicaciones multicapa y ofrece flexibilidad en la funcionalidad de aplicaciones distribuidas a travs de las capas. Ciertas capas estn siempre presentes en una aplicacin webenabled como la aplicacin de nuestro caso de estudio ests son: La capa del cliente proveda por el browser La capa Web proveda por el servidor La capa EJB proveda por el servidor La capa de base de datos o de sistemas de informacin empresarial que sostiene los datos persistentes de la aplicacin. Es importante escoger si un componente de la capa web accede a los recursos de los sistemas de informacin de la empresa directamente o a travs de la capa EJB. La decisin depende en la funcionalidad, la complejidad y los requerimientos de escalabilidad de la aplicacin. Un buen diseo toma en cuenta la posibilidad de cambiar y construir con facilidad una migracin a un enfoque centrado en EJB. La capa EJB ofrece ventajas para sus componentes , tales como manejo de seguridad , transacciones , procesamiento distribuido , etc. Usando componentes EJB , los desarrolladores pueden reducir el nivel de programacin requerida para las aplicaciones y en lugar de eso concentrarse en la lgica del negocio de la aplicacin. Lo siguiente es decidir como distribuir la funcionalidad de la aplicacin a travs de las capas. Tal distribucin sigue la divisin de la aplicacin en objetos y debera ser emprendida cuidadosamente. En un diseo centrado en el web , los componentes de la capa web usan servicios en el contenedor tales como el API JDBC que puede directamente comunicar los recursos de los sistemas de informacin empresarial que sostienen los datos de la aplicacin. Los componentes de la capa web son responsables de casi toda la funcionalidad de la aplicacin. Estos manejan la generacin de contenido dinmico , la presentacin del contenido y las peticiones del usuario. Estos deben implementar la funcionalidad central de la aplicacin , tal como el procesamiento s de las rdenes y el cumplimiento de las reglas de negocio de la aplicacin. Finamente los
componentes de la capa web deben manejar tambin transacciones , tales como el uso del JTA , y la conexin comn para el acceso a los datos. Ya que se debe manejar muchas funciones, el software de la aplicacin centrada el web puede fcilmente convertirse en monoltica. Como resultado , a menos que sean tomados esfuerzos especiales , la apliacacin no escalar bien incrementando la complejidad en el software. En un diseo centrado en EJB , los enterprise beans corren en servidores EJB , encapsulando los recursos de los sistemas de informacin empresariales y el ncleo de la lgica de la aplicacin. Los componentes de la capa web se comunican con los componentes de la capa EJB en lugar de directamente acceder a los recursos de los sistemas de informacin empresariales. Este enfoque mueve la mayor parte de la funcionalidad central de la aplicacin a los componentes de la capa EJB , usando los componentes de la capa web solamente como un front-end para recibir las peticiones de los clientes web y para presentacin HTML como respuesta al cliente. La principal ventaja del enfoque centrado en EJB es que los enterprise beans tiene acceso a un amplio conjunto de servicios de nivel empresarial. Estos servicios hacen ms fcil el manejo de aspectos de seguridad y transacciones de la aplicacin. El contenedor EJB maneja los detalles del nivel del sistema y provee un medioambiente administrado por sus componentes , permitiendo a un desarrollador enforcarse enteramente en aspectos del dominio de la aplicacin. Estos servicios provedos por el contenedor estndares se traducen en una mejor fiabilidad del software. Estos tambin hacen ms fcil para una aplicacin soportar mltiples tipos de clientes. La arquitectura EJB soporta un paradigma de programacin que promueve la encapsulacin y uso de los componentes, resultando en un software que permanece manejable como aplicaciones que crecen en complejidad. Hay una interconexin entre estos dos enfoques. El enfoque centrado en el Web puede habilitar un inicio rpido para pequeas aplicaciones con pocas necesidades transaccionales , mientras en e enfoque centrado en EJB es mejor para construir aplicaciones empresariales a gran escala donde el cdigo , el rendimiento y la escalabilidad son factores primarios. El enfoque centrado en el Web , mientras ms prevalezca , tiene limitaciones para construir aplicaciones complejas a gran escala. Las aplicaciones construidas con un enfoque centrado en el Web pueden rpidamente hacerse demasiado complejas y difciles de mantener.
Hay fortalezas en ambos enfoques, y se requiere un buen diseo para seleccionar el correcto balance para cada aplicacin. La aplicacin de caso de estudio demuestra un enfoque diseado para crecer. Este diseo puede ser considerado una arquitectura centrada en EJB. Mientras todos los mdulo de la aplicacin usan el diseo centrado en EJB en teora le modelo centrado en el Web podra haber sido usado en al menos un caso para los mdulos que leen el catlogo.
6.5.2. Seleccionando la arquitectura local o distribuida.

La mayor parte de aplicaciones empresariales son distribuidad a travs de la red , por que el cliente y los recursos de almacenamiento de datos estn usualmente localizados en diferentes mquinas de la aplicacin de en s misma. Un enfoque centrado en EJB , con la lgica del negocio residiendo en la capa intermedia da a los arquitectos la flexibilidad para disear la aplicacin como una aplicacin local o distribuida. ( aplicaciones distribuidas son las que interactan a travs de mecanismos de comunicacin remota). La plataforma J2EE provee las facilidades para ayudar a crear aplicaciones distribuidas , pero tambin permite a los desarrolladores de la aplicacin aplicar un modelo local a su aplicacin. Un desarrollador necesita pesar las ventajas y desventajas de los modelos de las arquitecturas local y remota , y balancear estas contra los requerimientos de la aplicacin.
6.5.2.1.
Comparacin entre las arquitecturas Local y
distribuida.
Un consideracin clave para los desarrolladores es si usar enterprise beans con vista de cliente local o con vista de cliente remota. Con sumo cuidado los desarrolladores pueden usar los enterprise beans con ambas vistas de clientes remota y local. Las aplicaciones implementadas con un modelo de arquitectura local tienen sus componentes residiendo en el misma mquina virtual de Java (JVM). Ya que su colocalizacin en la mismo espacio de direccin est garantizado , estos componentes pueden comunicarse entre s sin causar los cuello de botella de las llamadas remotas a la red , por tanto permite ms eficiencia en acceso de grano fino entre estas. Como resultado estas aplicaciones usualmente exhiben mejor rendimiento.
Una arquitectura distribuida es en la que la aplicacin es potencialmente implementada a travs de mltiples JVMs , aunque una aplicacin distribuida podra ser instalada en un nico JVM. Una arquitectura distribuida es ms compleja por que existen asuntos adicionales de nivel de sistema tales como comunicacin remota , seguridad , etc. Estn inmersos. Al mismo tiempo , podra ser modlar , mantenible , y reusable por que hay menos dependencia entre componentes individuales. Mientras este enfoque ofrece ms flexibilidad a la aplicacin , resulta usualmente en el decrecimiento del rendimiento debido al acceso a componentes remotos desencadenando un significativo cuello de botella en la red. Tal cuello de botella incluye el costo de la serializacin y la deserializacin , tambin con los parmetros de marshalling y demarshalling.( aunque mucho del cuello de botella podra ser optimizado si la aplicacin es instalada en un solo JVM , algn cuello de botella todava persistir). Las aplicaciones en una arquitectura distribuida debe pasar parmetros por valor , lo cual a menudo necesita excesiva copias de datos. Una arquitectura distribuida es tambin tpicamente ms escalable que un diseo de aplicacin local. A pesar del alto rendimiento de una arquitectura de aplicacin local sus componentes deben residir en el mismo direccin del espacio, por lo que no se puede escalar ms all de una nica mquina. Mientras es posible particionar los clientes de una aplicacin local a instancias separadas corriendo en la misma aplicacin , esto puede llegar a ser ms difcil lograrlo ya que a menudo se necesita acceder y actualizar datos compartidos. Un sistema distribuido es generalmente ms escalable que una aplicacin local ya que los componentes son diseados desde el inicio para ejecutarse en diferentes direcciones de espacio. Las aplicaciones distribuidas son generalmente ms altamente disponibles que las las aplicaciones locales. Ya que los componentes distribuidos no dependen de un particular JVM , es ms fcil migrar un componente enterprise bean distribuido a un diferente JVM en el caso de un fallo de hardware.
6.5.2.2.
Opciones para arquitecturas local y distribuida
en la plataforma J2EE.
A menudo una aplicacin distribuida est diseada con componentes o aplicaciones locales mltiples. Los componentes locales son usados por las porciones de la aplicacin que requieren un alto nivel de traspaso de datos y acceso de granularidad fina , mientras que los componentes remotos permiten mayor escalabilidad y acceso a la red.
Los enterprise beans , los cuales ofrecen vistas de los clientes locales o remotas , dan a las aplicaciones la habilidad de usar una arquitectura local o distribuida. Los enterprise beans dentro del mismo JVM pueden acceder a otra vista de cliente local y por tanto tomar ventaja del modelo arquitectural local. Los componentes web que residen en el mismo JVM podran opcionalmente tener acceso a una vista de cliente local de un enterprise bean y tomar ventaja de los mismos beneficios de los servicios del contenedor EJB. Usando una vista de cliente remota de un enterprise bean se da a la aplicacin la ventaja de un modelo de arquitectura distribuida. Las aplicaciones que requieren una arquitectura distribuida pueden estar diseadas para reducir la complejidad y las implicaciones de rendimiento del acceso a objetos remotos. Los detalles de la localizacin objetos de negocio remotos pueden ser encapsulados en un objeto Service Object Locator, por tanto esconder estos detalles del resto de la aplicacin mientras que el acceso a los objetos del negocio puede ser encapsulado en un Business Delegate. El acceso a los datos de granularidad fina para objetos distribuidos puede reducirse usando un nico value object para recuperar un conjunto de datos relacionados en una llamada remota. Despus que el value object recupere sus datos , estarn disponibles localmente para una aplicacin , la cual puede entonces acceder a tems individuales.
6.5.3. Patrones J2EE aplicados al Pet Store

La tabla 6.2 muestra un resumen de los patrones usados en la pet store con una breve descripcin los mismos que sern explicados ms en detalle como fueron utilizados en la aplicacin en las siguientes secciones.
Patrn usado Business Delegate Composite Entity Composite View
Descripcin Reduce el acoplamiento entre las capas web y EJB Modela una red de entidades de negocio relacionadas Maneja separadamente el diseo y el contenido de mltiples vistas compuesta
Data Access Object Front Controller Intercepting Filter Modelo-Vista-Controlador
Abstrae y encapsula mecanismos de acceso a datos Centraliza el procesamiento de peticiones de la aplicacin. Peticiones de la aplicacin de pre y post proceso Desacopla la representacin de los datos , el
comportamiento de la aplicacin y la presentacin Service Locutor Simplifica el acceso del cliente a los servicios de negocios empresariales Patrn usado Session Facade Descripcin Coordina operaciones entre mltiples objetos del negocio en un flujo de trabajo Transfer Object Value List Handler View Helper Transfiere los datos del negocio entre capas Hace iteraciones eficientemente en una lista virtual Simplifica el acceso al estado del modelo y la lgica del acceso a los datos Tabla 6.2 Resumen de los patrones J2EE aplicados en la Pet Store.
6.5.4. Business Delegate.

Para una explicacin detallada del patrn revisar el captulo 5 la seccin 5.2.1
6.5.4.1.
Ejemplo Detallado.
La clase business delegate de la aplicacin de caso de estudio es AdminRequestBD la cual maneja bsquedas y atrapa y trata con las excepciones en el OPC (Order Processing Center) de la aplicacin.. -La clase business delegate AdminRequestBD maneja bsqueda de componentes distribuidos y maneja excepciones.
El diagrama de la estructura en la Figura 6.16 mumestra el servlet ApplRequestProcessor usando la clase AdminRequestBD para encontrar y suar componentes de negocio distribuidos.
Figura 6.16 AdminRequestBD localiza y adapta otros componentes de negocio.
El cdigo de ejemplo muestra el constructor para AdminRequestBD. Esta usa la clase ServiceLocator para adquirir la interfaz del home remoto del session facade OPCAdminFacade (Ver apartado 5.2.7). Esta usa el interfaz del home remoto para crear un interfaz de componente component remoto OPCAdminFacade. , el cual se mantiene en un campo privado. El bloque que localiza y crea la referencia al enterprise bean coge las excepciones relacionadaas para encontrar el interfaz home y para crear la interfaz del componente. Cualquier excepcin que ocurre es entonces excepcin manejada en un AdminBDException , la cual efectivamente esconde los detalles de implementacin del business delegate de sus clientes.
public AdminRequestBD() throws AdminBDException { try { OPCAdminFacadeHome OPCAdminFacadeHome home = (OPCAdminFacadeHome) ServiceLocator.getInstance().getRemoteHome(OPC_ADMIN_NAME, OPCAdminFacadeHome.class); opcAdminEJB = home.create(); } catch (ServiceLocatorException sle) { throw new AdminBDException(sle.getMessage()); AdminBDException(sle.getMessage()); } catch (CreateException ce) { throw new AdminBDException(ce.getMessage());
} catch (RemoteException re) { throw new AdminBDException(re.getMessage()); } }
-El procesador de peticiones de OPC usa AdminRequestBD para acceso simple a los componentes del negocio La clase ApplRequestProcessor del servlet ded OPC , recibe las peticiones de servicio desde el cliente admin en la forma de mensajes XML transmitidos usando HTTP. Uno de estos pedidos es para sacar estadsticas acerca de las rdenes de un determinado estado. El mtodo ApplRequestProcessor.getOrders recibe partte de un rbol XML DOM representando una peticin de un servicio web. Este extrae el cdigo del estado desde el documento y usa AdminRequestBD.getOrdersByStatus para recuperar una lista de informacin ordenada. La interfaz que realiza la lista es la interfaz transfer object OrdersTO. (Ver apartado 5.2.2) El cdigo en el procesador de la peticin que recupera la informacin ordenada aparece en el siguiente cdigo ejemplo:
public class ApplRequestProcessor extends HttpServlet { ... String getOrders(Element root) { try { AdminRequestBD bd = new AdminRequestBD(); NodeList nl = root.getElementsByTagName("Status"); String status = getValue(nl.item(0)); OrdersTO orders = bd.getOrdersByStatus(status); ... }
Ya que ha sido creada la referencia a un OPCAdminFacadeEJB , el objeto AdminRequestBD puede simplemente reenviar la llamada al mtodo getOrdersByStatus del enterprise bean como sigue:
public class AdminRequestBD { ...
public OrdersTO getOrdersByStatus(String status) throws AdminBDException { try { return opcAdminEJB.getOrdersByStatus(status); } catch (RemoteException re) { throw new AdminBDException(re.getMessage()); } catch (OPCAdminFacadeException oafee) { throw new AdminBDException(oafee.getMessage()); } } ... }
Hay que observar nuevamente que el mtodo coge cualquier excepcin que el enterprise bean pueda arrojar y rearroja un tipo de excepcin que es especfica a la interfaz del business delegate. Esto oculta los detalles de implementacin del business delegate del cliente.
6.5.4.2.
Composite Entity
6.5.4.2.1.
Ejemplo Detallado.
Es importante notar que este patrn es todava viable con EJB 2.0 y Beans de Entidad Locales. En ambos medioambientes local y distribuido, existen inconvenientes para usar beans de entidad remotos para modelos de granularidad fina u objetos de negocio dependientes, ya que el patrn composite entity es aplicable en ambos casos. Antes de que EJB 2.0 exista, una estrategia comn era usada una relacin para implementaciones de composite entity. Esto tambin significaba que el padre usualmente usaba persistencia manejada por bean (BMP) por lo que haba que escribir tambin el cdigo para manejar otros objetos. Pero con la introduccin de los beans de entidad locales en EJB 2.0 la estrategia de usar bean de entidad locales para modelar entidades de granularidad fina y objetos dependientes es recomendada. Un beneficio adicional de sta
estrategia es que desde que todos los objetos en esta estrategia son beans de entidad , se puede eficientemente usar CMP persistencia manejada por contenedor y evitar escribir cdigo para
manejar las relaciones. El siguiente ejemplo de la aplicacin de caso de estudio : la pet store ilustra estudio sta estragia recomendada. Las siguientes interfaces simplifican grandemente la implementacin de un composite entity como se muestra en el siguiente ejemplo. Las interfaces locales de enterprise beans eliminan la mayora de los costos de rendimiento asociadoscon interfaces remotas , hacindolas prcticas os para modelamiento de entidades de negocio de granularidad fina y objetos dependientes.
La aplicacin de caso de estudio modela la clase Customer de la aplicacin y variso objetos obj relacionados como un composite entity. Esta usa interfaces de beans de entidad locales para modelar objetos de granularidad fina que son dependientes en el objeto Customer. La figura 6.17 muestra la entidad Customer y sus objetos dependientes asociados : Profile , Account , ContactInfo , CreditCard , y Address.
Figura 6.17 El Customer del composite entity y sus objetos dependientes.
La figura anterior muestras las entidades involucradas en la composite entity Customer. Varias clases representan los enterprise beans usados para implementar estas entidades. Las clases sentan escritas por el desarrollador aparecen en la tabla 6.3:
Entidad
Clase EJB
Interface del Componente
Interface Home
Customer Profile Account CreditCard ContactInfo Address
CustomerEJB ProfileEJB AccountEJB CreditCardEJB ContactInfoEJB AddressEJB
CustomerLocal ProfileLocal AccountLocal CreditCardLocal ContactInfoLocal AddressLocal
CustomerLocalHome ProfileLocalHome AccountLocalHome CreditCardLocalHome ContactInfoLocalHome AddressLocalHome
Tabla 6.3 Clases implementadas en composite entity Customer.
La composite entity Customer padre provee acceso las entidades dependientes hijas, como se muestra en la siguiente excerpt ded la interface CustomerLocal.
public interface CustomerLocal extends javax.ejb.EJBLocalObject { public String getUserId(); public AccountLocal getAccount(); public ProfileLocal getProfile(); }
Usando un bean de entidad local en vez de antiguo plan de objetos java para implementar objetos dependientes en un composite entity se mejora un diseo de las siguientes maneras: -Mejora en el rendimiento: Las interfaces locales mejoran el rendimiento por que estas eliminan el parmetro y el valor de retorno de la serializacin y los costos de transmisin de datos incurridos en las llamadas a mtodos remotos. Adicionalmente , las interfaces locales son diseadas para permitir al contenedor EJB optimizar la representacin del estado , las llamadas a los mtodos , y las relaciones con otros beans locales.
-Modelo de programacin ms claro. Las interfaces remotas deben usualmente ser gruesas para ser prcticas . Las interfaces locales permiten a un diseador escoger una granularidad que es ms apropiada para la aplicacin. Las interfaces locales minimizan el nmero de clases utilitarias , tales como data access objects , session facades , y transfer objects que son usadas para facilitar un medioambiente distribuido y las interfaces remotas. -Control de integridad y relacin automtica. Usando relaciones manejadas por contenedor (CMR) con interfaces locales simplifica la implementacin y reduce problemas de mantenimiento. Con CMR el contenedor maneja las relaciones entre las entidades locales y forza la integridad de los constraints definida por el desarrollador o instalador. El siguiente segmento de cdigo muestra la definicin de la relacin entre las entidades Customer y Profile en el descriptor de instalacin EJB de la aplicacin:
<ejb-relation> ... <ejb-relationship-role> <ejb-relationship-role-name>ProfileEJB</ejb-relationship-rolename> <multiplicity>One</multiplicity> <cascade-delete/> <relationship-role-source> <ejb-name>ProfileEJB</ejb-name> </relationship-role-source> </ejb-relationship-role> </ejb-relation>
El instalador o programador de la aplicacin define la multiplicidad de uno a entre un Customer y un Profile. En la ejecucin , el contenedor asegurar que exactamente un Profile est asociado con cada Customer. Adems , el desarrollador no necesita escribir cdigo para manejar la relacin , por que esto es automticamente implementado por el contenedor. -Borrados en cascada: El elemento <cascade-delete/> en el cdigo de ejemplo anterior indica cuando una instancia Customer es borrada , el contenedor siempre borra automticamente borra
las instancia Profile asociada tambin. Nuevamente , no se necesita escribir o mantener cdigo para tales borrados: el contenedor lo maneja automticamente.
Finalmente una nota acerca del modelo. Todos los beans de entidad que Customer usa para formar un composite entity son objetos dependientes , lo que significa que estos tienen un pequeo significado en la aplicacin aparte de que ellos pertenecen al objeto Customer. En la relacin padre-hijo entre el customer y sus objetos dependientes tales como Profile , Address , etc , no puede existir si la clase padre Customer no existe.Adicionalmente las entidades y objetos dependientes accesadas en una manera de granularidad fina podran ser accesados por un composite entity , sean ellos o no dependientes de un composite entity. Por ejmplo , aadiendo una funcin para historial de adquisicin de clientes a la entidad Customer podra requerir un acceso de granularidad fina al catlogo de productos. En tal caso las entidades relacionadas con el catlogo podran ser agregadas con el composite entity Customer , inclusive aunque el catlogo no sea dependiente de Customer.
6.5.4.3.
Composite View
6.5.4.3.1.
Ejemplo Detallado.
Existen varias estrategias para aplicar el patrn Composite View . Como todas las estrategias tienen en comn que las sub-vistas definidas separadamente , y son reusables individualmente. El diseo de un composite view en la aplicacin de la pet store es controlada por una pgina JSP llamada template.jsp. Los contenidos de un composite view especfico son controlados por otro archivo llamado screendefinitions.xml , que une las pginas JSP para rea rotuladas del template. El siguiente bloque de cdigo muestra un extracto del archivo de definiciones de las pantallas del sitio web de la aplicacin de caso de estudio la Pet Store que define la pantalla principal , uniendo pginas JSP para reas rotuladas del template.
<screen name="main"> <parameter key="banner" value="/banner.jsp" />
<parameter key="sidebar" value="/sidebar.jsp" /> <parameter key="body" value="/main.jsp" /> <parameter key="footer" value="/footer.jsp" /> </screen>
El ejemplo mostrado en la figura 6.19 es la pantalla que resulta de la definicin anterior. Cada rea de la pgina es poblada con datos desde una pgina JSP separada.
Figura 6.18 Mltiples pginas JSP forman un composite view
La aplicacin de caso de estudio controla el ensamble del composite view usando un administrador de vista centralizado llamado TemplateServlet. Para crear un composite view , el desarrollador de la aplicacin primero define un template file , el cual controla el diseo de la vista. El desarrollador usa los tags template:insert en varios puntos en el template file para incluir contenido generado dinmicamente.
El desarrollador entonces crea un screen definitions file , el cual asocia cada insert tag con el URL de las sub-vista para ser includa en ese punto. Por tanto el template controla el diseo del composite view , y la definicin de la pantalla controla las selecciones del grupo de las subvistas para ser includas dentro del diseo.Cada definicin de la pantalla selecciona un diferente
conjunto de subvistas , por tanto los contenidos de cada vista podran diferir , mientras el diseo de todas las vista remains el mismo. La figura 6.20 muestra como el template servlet ensambla un composite view.
Figura 6.19 Diagrama de Bloques del ensamble del composite view
Despus del servicio brindado a una peticin del cliente , el Front Controller selecciona la siguiente vista a desplegar y reenva la peticin a sta. (En la figura anterior , esta vista es /main.screen)- Un servlet mapping rutea la peticin a un TemplateServlet el cual lee el screen definitions definido por el desarrollador de la aplicacin , encuentra la pantalla apropiada , y almacena en un atributo HttpSession. El TemplateServlet entonces reenva la peticin al template definido en el screen defitions file (/template.jsp). El screen definition asocia los nombres simblicos con los recursos Web a ser usados como subvistas en el composite view. El ejemplo en la figura muestra el tag <parameter key=banner value=/banner.jsp/> , el cual define /banner.jsp como el contenido para el banner de la pntalla llamada main.
El template file contiene el diseo de la pgina , adems de cualquier texto que aparece en toda pgina de la aplicacin.Este adems contiene tags template:insert, cada uno de los cules indica el contiene nombre de la subsista a ser includa en las respuesta. Por ejemplo <template:insert parameter=banner/> inserta la pgina del banner para la actual pantalla en ese punto. Cuando el servidor ejecuta la pgina template , el tag template:insert usa la pantalla (recuperadas ecuta desde HttpSession) para buscar del contenido a ser includo. En el ejemplo en la figura 6.21, muestra los contenidos de /banner.jsp son insertadas en ese punto en el template donde el tag do template:insert aparece. La pgina resultante de la ejecucin del template de la pgina JSP es mostrada al cliente como una respuesta http. Se presenta un detalle del diagrama de secuencia de este proceso en la figura 6.21. Cada item en la siguiente lista de la figura describe el correspondiente transicin del numeral en el diagrama ente
Figura 6.20.Diagrama de secuencia del ensamble del composite view. .Diagrama
1.-El cliente solicita un servicio El 2.-Despus Despus de captar la solicitud,MainServlet (el Front Controller) Controller) direcciona el
ScreenFlowManager para que seleccione la siguiente vista. 3.-El ScreenFlowManager determina el nombre de la pantalla a desplegar El
4.-La solicitud es reenviada al TEmplateServlet 5.-El TemplateServlet identifica el objeto Screen solicitado y lo almacena en un HttpSession. 6.-La solicitud es reenviada al template de la pgina JSP 7.-El template de la pgina JSP ejecuta un tag insert 8.-El ag insert recupera el objeto screen del HttpSession 9.-El tag insert inserta el contenido desde el URL correspondiente al valor de su atributo parameter 10-12 .-El template de la pgina JSP ejecuta otro tag insert, el cial inserta el contenido como en los pasos del 7 al 9 13.-La ejecucin del Template es completa y el servidor retorna la respuesta generada al cliente.
6.5.4.4.
Data Access Object (DAO)
6.5.4.4.1.
Ejemplo Detallado.
La aplicacin de caso de estudio usa el patrn DAO para ambas opciones para acceso a datos de proveedores neutrales de base de datos y para representar fuentes de datos XML como objetos.
6.5.4.4.2.
Accesando a una base de datos con un DAO
Una clase DAO puede proveer acceso a una particular fuente de datos sin acoplamiento del API del recurso a la lgica del negocio. Por ejemplo las clases de la aplicacin de caso de estudio accesan al catlogo de categoras de productos e tems usando la interface DAO CatalogDAO. La reimplementacin del CatalogDAO para un mecanismo de acceso de datos diferente ( para usar un conector , por ejemplo) , podra tener poco o ningn impacto en cualquier clase que usa el CatalogDAO , porque solamente la implementacin cambiara. Cada implementacin alterna potencial del CatalogDAO accesara a los datos para los tems en el catlogo en su propia forma , mientras presentara el mismo API a la clase que lo usa.
Los siguientes extractos de cdigo ilustran como la aplicacin de caso de estudio usa el patrn DAO para separar la lgica del negocio de los mecanismos de acceso a los recursos de datos: -La interface CatalogDAO define el API DAO. Note que los mtodos en la interface que se muestra posteriormente no hacen referencia a un mecanismo de acceso de datos especficos. Por ejemplo ninguno de los mtodos especifica una consulta SQL , solamente arrojan excepciones del tipo CatalogDAOSysException. Evitando la informacin especfica del mecanismo en la interface DAO , incluyendo excepciones lanzadas , es esencial para ocultar los detalles de la implementacin.
public interface CatalogDAO { public Category getCategory(String categoryID, Locale l) throws CatalogDAOSysException; public Page getCategories(int start, int count, Locale l) throws CatalogDAOSysException; public Product getProduct(String productID, Locale l) throws CatalogDAOSysException; public Page getProducts(String categoryID, int start, int count, Locale l) throws CatalogDAOSysException; public Item getItem(String itemID, Locale l) throws CatalogDAOSysException; public Page getItems(String productID, int start, int size, Locale l) throws CatalogDAOSysException; public Page searchItems(String query, int start, int size, Locale l) throws CatalogDAOSysException; }
-La clase CloudscapeCatalogDAO implementa esta interface para la base de datos relacional Cloudscape , como se muestra en el siguiente extracto de cdigo. Note que el SQL para acceder a la base de datos Cloudscape es cdigo duro.
public class CloudscapeCatalogDAO implements CatalogDAO { ... public static String GET_CATEGORY_STATEMENT = "select name, descn " + " from (category a join category_details b on a.catid=b.catid) " + " where locale = ? and a.catid = ?"; ... public Category getCategory(String categoryID, Locale l) throws CatalogDAOSysException { Connection c = null; PreparedStatement ps = null; ResultSet rs = null; Category ret = null;
try { c = getDataSource().getConnection(); ps = c.prepareStatement(GET_CATEGORY_STATEMENT, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY); ps.setString(1, l.toString()); ps.setString(2, categoryID);
rs = ps.executeQuery(); if (rs.first()) { ret = new Category(categoryID, rs.getString(1), rs.getString(2)); }
rs.close(); ps.close(); c.close(); return ret; } catch (SQLException se) { throw new CatalogDAOSysException("SQLException: " + se.getMessage()); } } ... }
6.5.4.4.3.
Estrategias de Implementacin
Diselar un interface DAO y su implementacin es intercambio entre la simplicidad y la flexibilidad. La aplicacin provee ejemplos de varias estrategias para implementar el patrn DAO. -Implementar la interface directamente como una clase. La ms simple forma( pero menos flexible) para implementar un objeto DAO es escribirlo como una clase. La clase ScreenDefinitionsDAO , descrita abajo , es un ejemplo de una clase que directamente implementa la interface DAO. Este enfoque separa la interface de acceso a los datos de los detalles de cmo est su implementada , proveyendo la misma interface y cambiando el cdigo del cliente para usar la nueva clase. Todava este enfoque es inflexible porque requiere que el cdigo cambie para modificar el mecanismo de acceso a los datos.
-Mejorar la flexibilidad haciendo DAOs conectables. Un DAO conectable permite que el Mejorar desarrollador de la aplicacin o instalador seleccione un mecanismo de acceso a los datos sin icacin cambiar el cdigo en el programa. En este enfoque , el desarrollador accesa a la fuente de datos solamente en trminos de un interface DAO abstracta. Cada interface DAO tiene una o ms clases concretas que implementar , que interface para un particular tipo de fuente de datos. La aplicacin usa un objeto factory para seleccionar la implementacin de DAO en tiempo de ejecucin , basado en la informacin de la configuracin.
Por ejemplo la aplicacin de caso de estudio usa una clase factory CatalogDAOFactory para a seleccionar la clase que implementa la interface DAO para el catlogo. La figura 6.22 presenta un diagrama de estructura del patrn de diseo DAO usando un factory para seleccionar la selecciona implementacin DAO.
Figura 6.21.Un DAO conectable
En tiempo de ejecucin el CatalogHelper usa el CatalogDAOFactory para crear un objeto que implementa el CatalogDAO.El factory busca el nombre de la clase que implementa la interface DAO en la entrada del medioambiente param/CatalogDAOClass.El CatalogHelper accesa a la fuente de datos del catlogo exclusivamente usando el objeto creado por factory. En el ejemplo mostrado en la figura , la entrada del medioambiente fue configurada para el nombre de la clase CloudscapeCatalogDAO. Esta clase implementa la interface del catlogo DAO en trminos de fuentes de datos JDBC , accesando a la base de datos relacional Cloudscape. Este enfoque es ms flexible que usar la clase con cdigo duro.Para aadir un nuevo tipo de fuente de datos, un desarrollador de aplicacin simplemente creara un clase que implemente el
CatalogDAO en trminos del nuevo tipo de fuente de datos , especficamente el nombre de la clase implementada en la entrada del medioambiente y reinstalarla.El factory creara un instancia de la nueva clase DAO , en la aplicacin usara el tipo de la nueva fuente de datos. -Reduce la redundancia por SQL externo. Escribiendo una clase separada para los tipos de fuentes de datos que tienen similares APIs pueden crear un gran tratamiento con el cdigo redundante. Por ejemplo las fuentes de datos JDBC difieren una de otra primariamente en el SQL usado para accesarlas. Las nicas diferencias entre el DAO de Cloudscape y el DAO para una base de datos SQL diferente son el string de conexin y el SQL usado para acceder a la base de datos. La aplicacin de caso de estudio reduce el cdigo redundante usando un DAO genrico que externaliza el SQL para una fuente de datos JDBC diferente. La Figura 6.23 muestra como la aplicacin usa un archivo XML para especificar el SQL para para una fuentes de datos JDBC diferentes.
Figura 6.22.Externalizando el SQL DAO 6.2 En la figura el CatalogDAOFactory ha seleccionado un objeto del tipo GenericCatalgoDAO como el DAO para acceder al catlogo. Un archivo XML llamado CatalogDAOSQL.xml especifica el SQL para ra cada operacin soportada en cada tipo de base de datos. GenericCatalogDAO se autoconfigura para seleccionar un grupo de sentencias SQL desde un archivo XML que corresponde al tipo de correspo base de datos nombrada por la entrada de medioambiente param/CatalogDAODatabase. El ejemplo de cdigo mostrado a continuacin , muestra la definicin del XML para la operacin getCategory del CatalogDAO. Un SQL diferente cloudscape y oracle.
<DAOConfiguration> <DAOStatements database="cloudscape"> <SQLStatement method="GET_CATEGORY"> <SQLFragment parameterNb="2"> select name, descn from (category a join category_details b on a.catid=b.catid) where locale = ? and a.catid = ? </SQLFragment>
es especificado para los tipos de base de datos
</SQLStatement> ... <DAOStatements database="oracle"> <SQLStatement method="GET_CATEGORY"> <SQLFragment parameterNb="2"> select name, descn from category a, category_details b where a.catid = b.catid and locale = ? and a.catid = ? </SQLFragment> </SQLStatement> ... </DAOConfiguration>
El mtodo GenericCatalogDAO.getCategory escoge el correspondiente SQL para el tipo de base de datos configurada , y lo usa para extraer una categora desde la base de datos va JDBC. El siguiente extracto de cdigo muestra la implementacin del mtodo.
public Category getCategory(String categoryID, Locale locale) throws CatalogDAOSysException { Connection connection = null; ResultSet resultSet = null; PreparedStatement statement = null; try { connection = getDataSource().getConnection();
String[] parameterValues = new String[] { locale.toString(), categoryID }; statement = buildSQLStatement(connection, sqlStatements, XML_GET_CATEGORY, parameterValues); resultSet = statement.executeQuery(); if (resultSet.first()) { return new Category(categoryID, resultSet.getString(1), resultSet.getString(2)); } return null; } catch (SQLException exception) { throw new CatalogDAOSysException("SQLException: " + exception.getMessage()); } finally { closeAll(connection, statement, resultSet); } }
Note que el mtodo coge cualquier posible SQLException y la convierte a una CatalogDAOSysException , ocultando los detalles de implementacin que el DAO usa en una base de datos JDBC. Esta estrategia soporta mltiples bases de datos JDBC con una nica clase DAO. Ambas decrementan el cdigo redundante y hacen ms fcil aadir un nuevo tipo de base de datos. Para soportar un nuevo tipo de base de datos , un desarrollador simplemente aade sentencias SQL para el tipo de base de datos para el archivo XML , actualiza la entrada de medioambiente para usar el nuevo tipo y reinstala. Las estrategia de DAO acoplable y el DAO genrico pueden ser usadas separadamente. Si se sabe que una clase DAO solamente se usar alguna vez bases de datos JDBC (por ejemplo) la clase DAO
genrica puede ser puesta dentro de la aplicacin , en lugar de seleccionarla por una factory. Para mxima flexibilidad , la aplicacin de caso de estudio usa ambas un mtodo factory y una DAO genrico. -Encapsulando los recursos de datos que no son de base datos como clases DAO. Encapsulando Un DAO puede representar datos que no esten almacenados en una base de datos. La aplicacin una de caso de estudio usa el patrn DAO para representar fuentes de datos XML como objetos. Las pantalla de la aplicacin son definidas en un archivo XML el cual es interpretado por la clase ScreenDefinitionDAO. El especificar las definiciones de las pantallas externamente hace el acceso a las las deficiones de las pantallas ms flexible.por ejemplo , si los diseadores de la aplicacin (o quienes dan mantenimiento) deciden cambiar la aplicacin a descripciones de pantalla almacenadas en la base de datos , en lugar de un archivo XML , ellos necesitara solamente s implementar una nueva nica clase (ScreenFlowCloudscapeDAO , por ejemplo ). El cdigo que usa ScreenDefinitionDAO quedara sin cambiarse , pero los datos vendran desde la base de datos via bas la nueva clase. El mecanismo de definiciones de pantalla en la aplicacin de caso de estudio provee un ejemplo de un DAO concreto representando un recurso subyacente que no es de base de datos ( un archivo XML).
Figura 6.23.- DAO proveyendo acceso a un recurso de datos XML
La Figura 6.24 muestra el diagrama de estructura de ScreenDefinitionDAO manejando la carga e interpretacin de datos XML que define las pantallas de la aplicacin. -El TemplateServlet usa el ScreenDefinitionDAO para cargar las definiciones de la pantalla:
Screens screenDefinitions = ScreenDefinitionDAO.loadScreenDefinitions(screenDefinitionURL);
-El ScreenDefinitionDAO representa las definiciones de la pantalla en un archivo XML instalado con la aplicacin.Este usa APIs XML para leer las definiciones de la pantalla desde el archivo XML.Solamente esta clase necesitara ser reemplazada para soportar las definiciones de pantalla almacendas si fuera el caso. El mtodo que carga las definiciones de la pantalla es similar a esto:
public static Screens loadScreenDefinitions(URL location) { Element root = loadDocument(location); if (root != null) return getScreens(root); else return null; } ... public static Screens getScreens(Element root) { // get the template String defaultTemplate = getTagValue(root, DEFAULT_TEMPLATE); if (defaultTemplate == null) { System.err.println("*** ScreenDefinitionDAO error: " + " Default Template not Defined."); return null;
} Screens screens = new Screens(defaultTemplate); getTemplates(root, screens); // get screens NodeList list = root.getElementsByTagName(SCREEN); for (int loop = 0; loop < list.getLength(); loop++) { Node node = list.item(loop); if ((node != null) && node instanceof Element) { String templateName = ((Element)node).getAttribute(TEMPLATE); String screenName = ((Element)node).getAttribute(NAME); HashMap parameters = getParameters(node); Screen screen = new Screen(screenName, templateName, parameters); if (!screens.containsScreen(screenName)) { screens.addScreen(screenName, screen); } else { System.err.println("*** Non Fatal errror: Screen " + screenName + " defined more than once in screen definitions file"); } } } return screens; } ...
El fragmento de cdigo anterior muestra como loadScreenDefinitions carga las definiciones de pantalla usando interfaces DOM , mientras se oculta esta situacin de los clientes de la clase. Un cliente de esta clase puede esperar recibir un objeto Screens sin importar como estas pantallas sin son cargadas desde el almacenamiento persistente. El mtodo getScreens maneja todos los detalles del DOM especfico para la carga de un pantalla desde un archivo XML.
6.5.4.5.
Front Controller
Para una explicacin detallada del pat patrn revisar el captulo 5 la seccin 5.1.2
6.5.4.5.1.
Ejemplo Detallado.
-Centralizando el procesamiento de la solicitud y la seleccin de la vista Centralizando Un servlet es utilizado como el punto principal de entrada de peticiones del web. La clase MainServlet es el Front Controller para el sitio web de la aplicacin de caso de estudio. Todas las roller peticiones que finalizan con *.do son mapeadas para ir a travs del MainServlet para ser procesadas. El siguiente extracto de cdigo forma el ncleo del controller. Un diagrama de secuencia delimita las acciones tomadas por MainServlet en respuesta a la peticin del usuario , se encia presenta a continuacin:
Figura 6.24 Diagrama de secuencia del MainServlet en accin.
El cdigo fuente de MainServlet es simple: -Los mtodos que procesan los http POST y GET ambos usan el mtodo doProcess , mostrado en este ejemplo.El mtodo recibe la peticin y la respuesta y pasa la peticin al RequestProcessor , el cual despacha la peticin a la lgica del negocio (representada por Model en la figura anterior) que la maneja. El procesador de peticin ejecuta una funcin de aplicacin que corresponde al URL de la peticin. (En la figura 2:dispatch). El mapa desde los URLs de las peticiones a las funciones de la aplicacin es definido en un archivo XML , mappings.xml.
private void doProcess(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { ... try { getRequestProcessor().processRequest(request);
Despus del despacho de la peticin a la lgica del negocio, el controlador entonces pasa la peticin al ScreenFlowManager , el cual escoge la siguiente pantalla a desplegar , otra vez basada en los contenidos de mapping.xml (3: select view en la figura). Las excepciones tambin pueden ser mapeadas a las pantallas en mappings.xml: si la lgica del negocio arroja una excepcin , la excepcin es almacenada en la peticin , y la siguiente pantalla es escogida basada en el tipo de excepcin . Si la siguiente pantalla no est definida , una pantalla default ser usada.
getScreenFlowManager().forwardToNextScreen(request, response); } catch (Throwable ex) { String className = ex.getClass().getName(); nextScreen = getScreenFlowManager().getExceptionScreen(ex); // put the exception in the request request.setAttribute("javax.servlet.jsp.jspException", ex); if (nextScreen == null) { // send to general error screen ex.printStackTrace(); throw new ServletException("MainServlet: unknown exception: " +
className); } }
-Finalmente el front controller reenva la peticin a la siguiente pantalla (4: present view en la figura anterior). El componente ( usualmente el servicio del template) en el URL para la siguiente pantalla recibe el nombre de la pantalla y cualquier estado definido del lado del servidor por operaciones previas. Esta funcionalidad es delegada al ScreenFlowManager , el cual reenva a la siguiente pantalla.
6.5.4.6.
Intercepting Filter
6.5.4.6.1.
Ejemplo Detallado.
La interface Servlet Filter en la plataforma J2EE es una implementacin directa del patrn Intercepting Filter. La aplicacin de caso de estudio define dos filtros servlet: uno que media la autenticacin del cliente y otro que forza la codificacin de la peticin. -El filtro de autenticacin del usuario La clase SignOnFilter de la aplicacin de caso de estudio es un intercepting filter que intercepta todas las peticiones al front controller de la pet store. El servlet filter SingOnFilter detecta las peticiones para las pginas que requieren autenticacin de usuario , y redirecciona tales peticiones a la pgina de autenticacin de usuario si el usuario no est actualmente conectado. -El filtro de codificacin. La clase EncodingFilter de la aplicacin de caso de estudio es un intercepting filter que modifica las respuestas desde el front controller de la pet store , asegurando que la codificacin de la respuesta est siempre configurada consistentemente. El cdigo de ejemplo a continuacin de clase EncodingFilter muestra como el servlet filter configura la codificacin de la respuesta de cada respuesta , y entonces para la peticin al siguiente filtro abajo en la cadena. El mecanismo de la cadena del filtro hace tales filtros compuestos , cuantos mltiples intercepting filtres puedan envolver en un recurso simple.
public void doFilter(ServletRequest srequest, ServletResponse sresponse, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest)srequest; request.setCharacterEncoding(targetEncoding); // move on to the next chain.doFilter(srequest,sresponse); }
-El extracto de abajo de la descripcin del web.xml de la aplicacin de caso de estudio , muestra como el filtro de codificacin es configurado para envolver todos las peticiones emparejando el patrn /* (relativo al directorio de contexto de la raz de la aplicacin)
 <filter-mapping> <filter-name>EncodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
6.5.4.7.
Modelo-Vista-Controlador
Para una explicacin detallada del patrn revisar el captulo 3 la seccin 3.4
6.5.4.7.1.
Ejemplo Detallado.
La arquitectura del sitio web de la aplicacin de caso de estudio Pet Store aplica el patrn de diseo Modelo-Vista-Controlador. Otros patrones de diseo estn combinados en el diseo de la arquitectura MVC.
A menudo la funcionalidad MVC es capturada en un framework que es reusada por diferentes aplicaciones. El WAF (Web Application Framework) de la aplicacin de caso de estudio es un framework extensible para crear las aplicaciones MVC. Es una
implementacin de de MVC al cual podran ser aadidos nuevas fuentes de datos , lgica del negocio , y vistas de datos.
Figura 6.25 Diagrama de clases mostrando los componentes arquitecturales de la aplicacin Pet Store
6.5.4.8.
Service Locator
6.5.4.8.1.
Ejemplo Detallado.
La aplicacin de caso de estudio Pet Store , versin 1.3.1 tiene dos service locators: una clase ServiceLocator en la capa Web y una clase en la capa EJB tambin llamada ServiceLocator. Ambas clases manejan la bsqueda y el almacenamiento de las interfaces home de los enterprise beans , el JMS y los factory de conexin de la base de datos , y las entradas de medioambiente dentro de sus respectivas capas. La nica diferencia entre ellas es que la clase de la capa Web es una singleton , y almacena los objetos que busca. La clase de la capa EJB no es singleton , y no se almacena. La siguiente discusin de cdigo usa ejemplos del ServiceLocator de la capa Web:
-Los clientes usan ServiceLocator para acceder a los servicios. La clase AdminRequestBD de la aplicacin es un business delegate que usa el ServiceLocator de la capa web para acceder al enterprise bean del OPC llamadp OPCAdminFacade.La figura 6.27 es un diagrama de estructura que demuestra como AdminRequestBD usa ServiceLocator para encontrar interface home remota del enterprise bean OPCAdminFacade. El ServiceLocator retorna una interface enterprise bean remota OPCAdminFacadeHome , ya sea usando la recuperacin desde cach o buscando usando una instancia de InitialContex interna. El cliente entonces usa el OPCAdminFacade para encontrar o crear una interface de componente remoto a un OPCAdminFacade.
Figura 6.26 Diagrama de estructura de cdigo de ejemplo del ServiceLocator. cdigo
En el siguiente extracto de cdigo , AdminRequestBD llama al mtodo esttico de ServicLocator llamado getInstance para obtener una instancia singleton de service locutor ,entonces llama a getRemoteHome para obtener la interface home remota de enterprise bean OPCAdminFacade. interface Note que el que llama debe asignar el tipo de dato de la interface remota OPC
AdminFAcadeHome porque getRemoteHome retorna el tipo EJBHome.
public class AdminRequestBD { ... public AdminRequestBD() throws AdminBDException { try { OPCAdminFacadeHome home = (OPCAdminFacadeHome) ServiceLocator.getInstance().getRemoteHome(OPC_ADMIN_NAME, OPCAdminFacadeHome.class); opcAdminEJB = home.create(); } catch (ServiceLocatorException sle) {
... } }
El service locutor simplifica grandemente la bsqueda de una interface home de un eneterprise bean. Las estrategias singleton y caching tambin mejoran el rendimiento , ya que ellas evitan la construccin innecesaria de InitialContext e interfaces home de enterprise beans.
-Mtodos Pblicos buscan recursos distribuidos. Los mtodos pblicos del service locutor buscan recursos distribuidos por sus nombres JNDI. Existen mtodos que encuentran y retornan interfaces home locales de enterprise beans , recursos de datos JDBC , tpicos y colas JMS , y factorias de conexin de tpicos y colas JMS. Existen tambin mtodos convenientes que buscan y ejecutan conversiones de tipo en entradas de medioambiente. Como un ejemplo el mtodo getLocalHome(para encontrar retornan interfaces home locales de enterprise beans) aparece a continuacin .Cada mtodo que localiza un tipo particular de recurso retorna o una referencia almacenada a un recurso solicitado o usa JNDI para encontrar el recurso , colocando una referencia en el cache antes de retornarlo.
// Enterprise bean lookups public EJBLocalHome getLocalHome(String jndiHomeName) throws ServiceLocatorException { EJBLocalHome home = null; try { if (cache.containsKey(jndiHomeName)) { home = (EJBLocalHome) cache.get(jndiHomeName); } else { home = (EJBLocalHome) ic.lookup(jndiHomeName); cache.put(jndiHomeName, home);
} } catch (NamingException ne) { throw new ServiceLocatorException(ne); } catch (Exception e) { throw new ServiceLocatorException(e); } return home; }
Los mtodos que retornan las referencias a interfaces home de enterprise beans son solamente del tipo seguro al nivel de la interface de la plataforma ; por ejemplo getLocalHome retorna un EJBLocalHome , pero el cliente debe cambiar el tipo al resultado. El mtodo getRemoteHome es similar a getLocalHome , excepto que este retorna un enterprise bean remoto , en lugar de un interface home local . Este tambin requiere una referencia a un objeto de clase para la interface home remota especfica , porque el home remoto busca usar el mtodo PortableRemoteObjec.narrow para ejecutarla conversin de tipo desde el objeto retornado desde la bsqueda JNDI al tipo de interface home actual. El cliente que llama a getRemoteHome debe todava cambiar el tipo al resultado al tipo de la interface home remota , como se mostr primero en el ejemplo anterior.
public EJBHome getRemoteHome(String jndiHomeName, Class className) throws ServiceLocatorException { EJBHome home = null; try { if (cache.containsKey(jndiHomeName)) { home = (EJBHome) cache.get(jndiHomeName); } else { Object objref = ic.lookup(jndiHomeName); Object obj = PortableRemoteObject.narrow(objref, className);
home = (EJBHome)obj; cache.put(jndiHomeName, home); } } catch (NamingException ne) { throw new ServiceLocatorException(ne); } catch (Exception e) { throw new ServiceLocatorException(e); }
return home; }
Como se mencion anteriormente , el service locator retorna los recursos JMS , los recursos de datos JDBC , y ejecuta la conversin de tipo en los valores de la variables de medioambiente. La tabla siguiente resume los nombres y tipos de retorno de estos mtodos. Nombre del Mtodo Tipo de Retorno Tipo del Recurso
getQueueConnectionFactory QueueConnectionFactory JMS
getQueue
Queue
JMS
getTopicConnectionFactory TopicConnectionFactory JMS
getTopic
Topic
JMS JDBC env-entry env-entry
getDataSource
DataSource
getUrl
URL
getBoolean
boolean
getString
String
env-entry
Tabla 6.4. Mtodos ServiceLocator adicionales.
6.5.4.9.
Session Facade
6.5.4.9.1.
Ejemplo Detallado.
-El Facade Administador. La aplicacin de Administracin del ejemplo del Pet Store es responsable por el manejo de las funcionalidades del Flujo de Trabajo del procesamiento de las rdenes del Pet Store. La aplicacin de la Administracin es un cliente Swing con Java Web Start que se comunica con la aplicacin del OPC en el backend para aprobar rdenes de adquisicin grandes y ver los datos financieros. Para interactuar con la aplicacin del OPC , la aplicacin de administracin usa el patrn Session Facade en la interface OPCAdminFacade , cuya interface es mostrada a continuacin:
public interface OPCAdminFacade extends EJBObject { public OrdersTO getOrdersByStatus(String status) throws RemoteException, OPCAdminFacadeException; public Map getChartInfo(String request, Date start, Date end, String requestedCategory) throws RemoteException, OPCAdminFacadeException; }
La clase de implementacin del administrador de facade es OPCAdminFacadeEJB. La aplicacin de administacin es un cliente de OPCAdminFacade en la aplicacin del procesamiento de la orden. Un diagrama de estructura de cmo interacta el Session Facade con otras clases en la aplicacin del procesamiento de la orden apaarece en la figura 6.28. Las clases en gris en el diagrama indican el transfer object creador por la clase facade (Ver Patrn Transfer Object en seccin 5.2.2)
Figura 6.27 El OPCAdminFacade provee un interface para interacciones complejas entre para componentes. El punto clave a notar aqu , es que el cliente solamente interacta con el OPCAdminFacade y los otros Enterprise Beans estn ocultos detrs el facade. Por tanto el cliente tiene una interface simple y no es expuesto a la complejidad de la lgica de la aplicacin que ocurre para procesar la xpuesto solicitud. Uno de los mtodos de OPCAdminFacade , getOrdersByStatus , construye un resumen de la informacin de adquisiciones para desplegar por el cliente de administracin de la aplicacin de caso de estudio.Este mtodo usa un bean de sesin stateless ProcessManagerLocal y un bean de entidad local ManagerLocal e itera sobre la coleccin de los beans de entidad PurchaseOrderLocal del estado solicitado. El mtodo crea un Collection de OrderDetails serializable de transfer objects Collection que describen los beans PurchaseOrderLocal encontrados.EL mtodo entonces retorna la coleccin de objetos al cliente. -El Facade de Compras de la aplicacin del sitio web de la Pet Store. El -La aplicacin del sitio web de la Pet Store tambin usa el patrn Session Facade. n ShoppingClientFacadeLocal es un bean de sesin stateful local que centraliza los servicios que el sitio web proporciona para los compradores. Su interface local aparece a continuacin:
public interface ShoppingClientFacadeLocal extends EJBLocalObject { public ShoppingCartLocal getShoppingCart(); public void setUserId(String userId);
public String getUserId(); public CustomerLocal getCustomer() throws FinderException; public CustomerLocal createCustomer(String userId); }
El facade de compras provee un interface nica al cliente para toda la funcionalidad de compras del cliente: El carro de compras , la identificacin del usuario almacenada , la bsqueda y creacin de los datos Customer asociados con el usuario. Facade es un bean de sesin stateful porque almacena informacin (tal como la identificacin del usuario) que es especfica para un usuario individual en el contexto de una sesin
6.5.4.10.
Transfer Object
6.5.4.10.1. Ejemplo Detallado.

-Los transfer objets OrderDetails y OrdersTO. -La clase OPCAdminFacade de la aplicacin tiene un mtodo getChartInfo que retorna una inmutable serializable coleccin de objetos OrderDetails , cada uno de los cuales es un transfer object que representa datos desde una orden. La coleccin retornada por el mtodo getChartInfo es tambin un transfer object , por que los valores que contiene son siempre accedidos juntos donde estos sean usados. Este transfer object jerrquico es implementado por la clase OrdersTO. La figura 6.29 muestra la estructura del transfer object OrdersTO . La clase MutableOrdersTO , la cual extiende un ArrayList serializable ,contiene una coleccin de objetos OrderDetails . Pero ya que MutableOrdersTO extiende ArrayList , esta es mutable. Los transfer objects deberan ser inmutables ya que los clientes no intenciolmente cambian sus contenidos.La interface ORdersTO adapta la coleccin MutableOrdersTO , permitiendo el acceso de solo lectura a la coleccin mientras previene modificaciones.
Figura 6.28 El transfer Object OrdersTO es una coleccin inmutable y serializable. La definicin de la interface OrdersTO se muestra a continuacin:
public interface OrdersTO extends Serializable { ce public Iterator iterator(); public int size(); public boolean contains(Object o); public boolean containsAll(Collection c); public boolean equals(Object o); public int hashCode(); public boolean isEmpty(); oolean public Object[] toArray(); public Object[] toArray(Object[] a); static class MutableOrdersTO extends ArrayList implements OrdersTO { } }
La interface OrdersTO es claramente una coleccin , ya que esta define los mtodos de la coleccin Java. La coleccin es inmutable , porque sta no tiene mtodos que permitan cambiar los contenidos de la coleccin. Un ejemplo del uso de OrdersTO aparece en el mtodo
OPCAdminFacadeEJB.getOrdersByStatus mostrado en el siguiente segmento de cdigo.El
mtodo construye un objeto OrdersTO.MutableOrdersTO y lo popula con instancias de OrderDetails. Hay que notar que el tipo de retorno de getOrdersByStatus es OrdersTO , ya que los invocadores tienen acceso solo a los mtodos que leen contenidos de la coleccin y no existen mtodos que la cambien.
public OrdersTO getOrdersByStatus(String status) throws OPCAdminFacadeException { OrdersTO.MutableOrdersTO retVal = new OrdersTO.MutableOrdersTO(); PurchaseOrderLocal po; ProcessManagerLocal mgr = getProcMgr(); try { PurchaseOrderLocalHome pohome = getPO(); Collection orders = mgr.getOrdersByStatus(status); Iterator it = orders.iterator(); while((it!= null) && (it.hasNext())) { ... // Access and format data retVal.add(new OrderDetails(po.getPoId(), po.getPoUserId(), podate, po.getPoValue(), status)); } } catch (FinderException fe) { ... // process exception } return(retVal); }
-Los detalles para una orden simple son contenidos en un transfer object inmutable y serializable del tipo OrderDetails.. Este es un tpico transfer object para un valor compuesto sencillo ,
conteniendo campos privados y pblicos , accesores de propiedad de solo lectura , como se muestra en el siguiente cdigo de ejemplo:
public class OrderDetails implements java.io.Serializable { private String orderId; private String userId; private String orderDate; private float orderValue; private String orderStatus; public OrderDetails(String oid, String uid, String date, float value, String stat) { orderId = oid; userId = uid; orderDate = date; orderValue = value; orderStatus = stat; } public String getOrderId() { return(orderId); } // ... }
6.5.4.11.
Value List Handler

El catlogo de la aplicacin de caso de estudio es una coleccin ordenada de categoras. Cada categora contiene una coleccin ordenada de productos , y cada producto contiene un lista ordenada de tems. El catlogo tambin puede buscar los tems por un determinado criterio de bsqueda. Porque sera poco prctico descargar todo el catlogo cada vez que el usuario seleccione una categora , producto o item o ejecute una bsqueda , la aplicacin maneja la bsqueda y
despliegue del catlogo con el patrn de diseo Value List Handler. El cliente so solicita informacin a una pgina y al mismo tiempo le indica donde debe comenzar la coleccin y cuantos tems retornar.El cliente usa el value list handler como un iterador sobre la coleccin resultante y despliega la lista de resultados en una interfaz de usuario. La figura 6.30 muestra un diagrama de estructura del value list handler CatalogHelper de la aplicacin.
Figura 6.29 Diagrama de estructura del value list handler CatalogHelper de la aplicacin. El CatalogHelper acta como value list handler para el cliente. Client mostrado en la figura anterior para es una pgina JSP accedida a travs del web browser , que accesa a una instancia de CatalogClientHelper usando un tag useBean como se muestra en el siguiente extracto de category.jsp:
<jsp:useBean id="catalog" class="com.sun.j2ee.blueprints.catalog.client.CatalogHelper" scope="session" />
Una instancia de CatalogHelper , mantenida en un atributo de sein http guarda lo siguiente: 1.-La actual consulta que est siendo ejecutada ( si la pgina representa a una bsqueda) La 2.-La posicin inicial de las lista de elementos que est siendo solicitada La 3.-El nmero de tems de la lista a recuperar a la vez. El 4.-La localizacin a ser usada para desplegar los tems. La El CatalogHelper delega la responsabilidad de acceder a los datos a un objeto que implementa la responsabilidad interface CatalogDAO.El CatalogDAO recupera un rango de categoras , productos, tems o resultados de consulta desde el catlogo y los retorna como un objeto Page.Page es un transfer object que es una coleccin de transfer object.Esto representa la lista de elementos solicitados del a catlogo(categoras ,productos o tems) El CatalogHelper retorna una Page de entradas del catlogo al cliente para desplegar.
La figura 6.31 es un diagrama de colaboracin de cmo el CatalogHelper usa el CatalogDAO para colaboracin acceder un subrango de los resultados de la consulta.
Figura 6.30 El diagrama de colaboracin para el value list handler CatalogHelper.
1.-Un tag en la pgina JSP solicita las categoras desde CatalogHelper . El tag pertenece a JSTL. Un CatalogHelper
2.-El CatalogHelper el cual est guardando un registro de la posicin de la lista actual , tamao y localizacin , solicita una lista de las categoras desde CatalogDAO.getCategories. 3.-El CatalogDAO , el cual en este escenario es implmentado por la clase GenericCatalogDAO , ejecuta la consulta mostrada , produciendo un ResultSet. 4.-El GenericCatalogDAP entonces construye un nuevo objeto Page que contiene el subrango solicitado de la lista ms grande en el ResultSet. Page es retornada al CatalogHelper , donde sta es usada para desplegar por una pgina JSP.
Esta implementacin ilustra varios puntos interesantes acerca del patrn Value List Handler:
-Usando un Data Access Object maximiza la flexibilidad. El patrn DAO usado por el Value List Handler es un API abstracto que encapsula y oculta el mecanismo de acceso a los datos. En tiempo de ejecucin , la aplicacin usa un objeto factory para seleccionar y cargar la clase que implementa la interface CatalogDAO. Esto permite al mecanismo de acceso a los datos cambiar ( y a nuevos mecanismos nuevos) sin cambiar cdigo del cliente. -Un Value List Handler podra proveer un iterador externo o interno. El CatalogHelper provee una interface de iterador externo porque guarda la posicin y tamao de la pgina del catlogo. El iterador podra tambin haber sido interno , proporcionando solamente los mtodos nextPage y prevPage mientras se guarda la posicin y el tamao internamente.La opcin de una interface de iterador externo o interno es una decisin de diseo que depende de los requerimientos de la aplicacin. -El caching puede mejorar el rendimiento. El rendimiento de la aplicacin puede a menudo ser mejorada por value lists en cache. La aplicacin de caso de estudio puede haber puesto en cache listas del catlogo , pero estos datos no estn en cache en la actual implementacin. El CatalogHelper puede mejorar el redimiento por mantener un cache de listas solicitadas previamente. Sin embargo la Pet Store hace cache de pginas de vistas usando un custom tag llamado CacheTag.
-El patrn Value List Handler es apropiado para ambas arquitecturas remota y local.Mientras el patrn Value List Handler fue originalmente creado para maximizar el rendimiento en arquitecturas remotas , es apropiado tambin para arquitecturas locales. El modelamiento de pginas de informacin como sublistas de listas virtuales ms grandes es un concepto de diseo natural , y est dirigido a una implementacin limpia.Donde existen muchas bsquedas de la misma informacin , los value lists son candidatos naturales para objetos de cache. Finalmente , el patrn Value List Handler proporciona ms flexible funcionalidad en consultas que las que se usan en un mtodo de bsqueda EJB. Todos estos beneficios se aplican a ambas arquitecturas local y remota.
6.5.4.12.
View Helper

La recomendacin de programa java BluePrints para la presentacin en los clientes browser es usar pginas JSP como componentes view. Dos estrategias comunes para la implementacin de los View Helpers es la estrategia JavaBean helper y la estrategia custom tag helper. Las pginas JSP ofrecen tecnologas que son tiles para implementar View Helper: el tag useBean y los custom tags. El sitio web de la Pet Store usa un view helper llamado CatalogHelper como un view helper para varias vistas. Tambin usa la tecnologa JSTL (JavaServer Pages Standard Tag Library) para adapatar los mtodos CatalogHelper para las necesidades de las pginas JSP. -Usando el View Helper CatalogHelper desde una pgina JSP La clase CatalogHelper maneja y oculta la complejidad del acceso al catlogo de la aplicacin de caso de estudio la Pet Store y presenta una interface simplificada a sus clientes. El CatalogHelper es un ejemplo de la estrategia JavaBean Helper. El diagrama de secuencia de la figura 6.33 muestra como el View Helper accesa a los recursos de datos a travs de la vista. En el diagrama el componente de la vista es una clase pgina JSP,
generada desde el cdigo fuente de la pgina JSP por el compilador de pginas JSP.En este ejemplo la pgina JSP accesa al CatalogHelper en dos formas: directamente usando el tag useBean e indirectamente va tags JSTL.
Figura 6.3 Diagrama de Estructura del patrn View Helper 6.31 El view component de la aplicacin category.jsp define una instancia del CatalogHelper en un mbito de sesin con el tag useBean como sigue: l
<jsp:useBean id="catalog" class="com.sun.j2ee.blueprints.catalog.client.CatalogHelper" scope="session" />
El Tag anterior define un atributo HttpSession catalog del tipo CatalogHelper. Los tags posteriores crean una variable llamada pageResults la cual es el resultado de una llamada al mtodo CatalogHelper getProducts:
<c:choose> <c:when test="${param.count != null}"> <c:set value="${param.start}" target="${catalog}" property="start"/> <c:set value="${param.count}" target="${catalog}" property="count"/> value="${param.count}" </c:when> <c:otherwise> <c:set value="0" target="${catalog}" property="start"/>
<c:set value="2" target="${catalog}" property="count"/> </c:otherwise> </c:choose> <c:set value="en_US" target="${catalog}" property="locale"/> <c:set value="${param.category_id}" target="${catalog}" property="categoryId"/> <c:set value="${catalog.products}" var="pageResults" />
El bloque de tags anteriores inicializa los argumentos de la llamada al mtodo por la invocacin del mtodo CatalogHelper getProducts (accesando al atributo catalog.prodcuts en la ltima lnea). Este entonces invoca al mtodo en el objeto View Helper y pone Page de resultados en una variable llamada pageResults. El CatalogHelper maneja y oculta la complejidad del proceso de seleccin de fuente de datos , recuperando los datos del producto desde una fuente de datos y encapsulando estos datos como un objeto Page. El cdigo que accede a los datos desde el CatalogDAO aparece en el ejemplo de cdigo a continuacin:
Page getProductsFromDAO(String categoryId, int start, int count, Locale locale) throws CatalogClientException { try { if (dao == null) dao = CatalogDAOFactory.getDAO(); return dao.getProducts(categoryId, start, count, locale); } catch (CatalogDAOSysException se) { System.out.println("Exception reading data from dao " + se); throw new CatalogClientException(se.getMessage()); } }
El cdigo DAO anterior obtiene los productos directamente usando una consulta JDBC , como se muestra a continuacin:
public Page getProducts(String categoryID, int start, int count, Locale l)
throws CatalogDAOSysException { Connection c = null; PreparedStatement ps = null; ResultSet rs = null; Page ret = null; try { c = getDataSource().getConnection(); // Select ps = c.prepareStatement("select a.productid, name, descn " + "from (product a join " + "product_details b on " + "a.productid=b.productid) " + "where locale = ? " + "and a.catid = ? " + "order by name", ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY); ps.setString(1, l.toString()); ps.setString(2, categoryID); rs = ps.executeQuery(); // ... and so on ...
Finalmente otra vez en products.jsp , el siguiente bloque de tags formatea los contenidos del objeto Page ( el cual fue creado por el cdigo anterior y guardado en el mbito de la sesin). Los tags JSTL( en XML el namespace c:) itera la coleccin Page y extrae y formatea los datos de los productos del catlogo en la pgina resultante:
<c:forEach var="item" items="${pageResults.list}" > <tr> <td class="petstore_listing"> <c:url value="/product.screen" var="productURL"> <c:param name="product_id" value="${item.id}"/> </c:url> <a href='<c:out value="${productURL}"/>'> <c:out value="${item.name}"/> </a> <br> <c:out value="${item.description}"/>
</td> </tr> </c:forEach>
El punto clave a entender en este ejemplo es que todo el cdigo que maneja la seleccin de la fuente de datos y el acceso a los datos est en el View Helper y no en los scriptlets en la pgina JSP. Tambin hay que notar que el patrn View Helper podra ser combinado con otros patrones. Por ejemplo el View Helper podra usar un Business Delegate o Service Locutor para ayudar a manejar el acceso a los datos. La aplicacin de caso de estudio ilustra el uso del patrn View Helper con otros patrones como parte del diseo total.
7. CONCLUSIONES Y RECOMENDACIONES
7.1. Conclusiones.
-Definitivamente la adopcin de los patrones en las aplicaciones multicapa mejora el tiempo de anlisis, diseo y desarrollo ya que no hay reinventar la rueda sino aplicar la experiencia y conocimientos plasmados en patrones que son soluciones a problemas que se repiten recurrentemente dentro del desarrollo de sistemas.
-Los patrones son una ayuda en todas las etapas del ciclo de vida del software desde el anlisis hasta la implementacin.
-Los patrones son perfectibles, es decir susceptibles de ser perfeccionados en el transcurso del tiempo. Con esto nos aseguramos de los conceptos y/o experiencias que sirvieron en el pasado para resolver un problema especfico van mejorando con el tiempo.
-Los patrones son acoplables unos con otros dependiendo la situacin del problema , con esto no creamos soluciones nicas , si no mas bien soluciones que pueden ser combinadas con otras para problemas ms grandes.
- Evitan muchas fases de prueba/error en la fase de diseo, pues se tienes a disposicin soluciones probadas para muchos de los problemas que se va ha encontrar.
- Facilitan la programacin, dado que en la bibliografa usada en esta tesis (y en muchos sitios en el Internet y otras fuentes bibliogrficas) se puede encontrar cdigo de ejemplo y adems muchas herramientas son capaces de generar gran parte del cdigo automticamente si se usa patrones.
- Facilitan la comunicacin entre profesionales, al utilizar un lenguaje comn para describir las partes del sistema software.
- Facilitan la adopcin de nuevo personal a un proyecto, porque cuando llega "el nuevo", en lugar de ver una maraa de clases, ve un conjunto de piezas de ms alto nivel que implcitamente describen el problema que solucionan. - Facilitan el mantenimiento del software, porque en general presentan soluciones extensibles a los problemas, que dejan cabos en los que enganchar futuras funcionalidades.
-Una de las mayores ventajas es que aceleran mucho la fase de diseo, permitiendo empezar antes a programar y ensearle cosas a los interesados de los proyectos.
- El uso de patrones de diseo de J2EE previene errores, interpretaciones individuales. Sin embargo, su existencia no asegura por completo que se ejecuten implementaciones fiables.
-La implementacin de patrones J2EE no es trivial en los desarrollos de aplicaciones empresariales. Los desarrolladores necesitan conocer implementacin de los patrones. -Los patrones no son las respuestas nicas a un problema, sino ms bien representan una solucin estructural y de comportamiento para un problema de diseo recurrente. propuestas metodolgicas para una correcta
7.2. Recomendaciones.
-Se recomienda el uso de los patrones en aplicaciones medianas y grandes ya que para aplicaciones pequeas la soluciones podran simplificarse sin embargo no hay que perder de vista que partes de los patrones o estrategias de los mismos podran tomarse para aplicarlos en sistemas de poca envergadura.
-Se debera realizar un estudio de carcter general para familiarizarse con las estructuras bsicas de los patrones, su terminologa y sus aplicaciones dentro de sistemas tipo en los diseos orientados a web
-Se recomienda aplicar estos patrones en los proyectos de aplicaciones multicapa no rgidamente como reglas sino mas bien como sugerencias de expertos que ya han resuelto muchos de los problemas que se encuentran comunes en tales proyectos. -En cuanto a la aplicacin de patrones dentro del diseo de aplicaciones para el Internet se recomienda usar el Composite View , dado que ayudar en el manejo de varias vistas de forma dinmica generadas por varios autores ( programadores , diseadores , arquitectos) pero consolidadas en una sola vista que es usada por el usuario final
-Adems se recomienda el uso del patrn Data Access Object en los casos que la aplicacin necesite acceder a diferentes fuentes de datos y estas sean manejadas de manera centralizada y estndar.
-Utilizar el patrn Value List Handler para el manejo de listas de valores de datos , para optimizar recursos de la red y presentar al usuario los datos necesarios para sus bsquedas y consultas solicitadas.
-Despus de analizar la utilidad de los patrones a nivel de diseo y desarrollo se recomienda incorporar el estudio de los mismos como parte del pensum de estudios de los ltimos niveles de la Escuela de Sistemas de la Universidad Cristiana Latinoamericana ya que su anlisis pondra al corriente de las ltimas tcnicas y estrategias del mundo informtico en los aspectos de desarrollo multicapa.
8. BIBLIOGRAFIA
[Zaman,2002] KHAWAR ZAMAN AHMED ,CARY E. UMRYSH. Developing Enterprise Java Applications with J2EE and UML. 2nd Edition. Indianapolis, U.S.A. Addison Wesley 2002 . [LARMAN,1999] CRAIG LARMAN , UML y Patrones Introduccin al anlisis y diseo orientado a objetos. 1ra Edicin Mxico Prentice Hall 1999. [Schmuller] JOSEPH SCHMULLER , Aprendiendo UML en 24 Horas , Prentice Hall Mxico 2000. [LEMAY,2000] LAURA LEMAY , Java en 21 das , Prentice Hall Mxico 2000. [Alur,2002] DEEPAK ALUR , Core J2EE Patterns Best Practices and Design Strategies , Sun Microsystems 2002 [MARTINEZ,2000] FRANCISCO JAVIER MARTNEZ JUAN , Gua de construccin de Software en Java con Patrones de Diseo , Universidad de Oviedo , Escuela Universitaria De Ingeniera Tcnica En Informtica De Oviedo. Julio 2000.
[GoF,1995] ERICH GAMMA RICHARD HELM RALPH JOHNSON JOHN VLISSIDES Design Patterns:Elements of Reusable Object-Oriented Software, Addison Wesley, 1995.
[Grand,1998] MARK GRAND , Patterns in Java (volume 1) Wiley Computer Publishing, 1998 .
[POSA1] FRANK BUSCHMANN REGINE MEUNIER HANS ROHNERT PETER SOMMERLAD MICHAEL STAL ,Pattern-Oriented Software Architecture-A System of patterns, Wiley Press,1996-2000.
[POSA2] DOUGLAS SCHMIDT MICHAEL STAL HANS ROHNERT FRANK BUSCHMANN, PatternOriented Software Architecture-Volume 2: Patterns for Concurrent and Networked Objects, Wiley Press, 2000.
[Vlissides,1996] JOHN M. VLISSIDES, JIM O. COPLIEN, AND NORMAN L. KERTH (EDITORS), Pattern Languages of Program Design 2, Addison Wesley, 1996.
[Vlissides2,1998] JOHN VLISSIDES, Pattern Hatching: Design Patterns Applied, Addison Wesley, 1998.
[Broemmer,2003] DARREN BROEMMER, J2EE Best Practices: Java Design Patterns, Automation, and Performance , Wiley Publishing, Inc., 2003.
Referencias del Internet:
[PALOS] JUAN ANTONIO PALOS. Catlogo de Patrones de Diseo J2EE . http://www.programacion.com/java/tutorial/patrones [PALOS].
[Sun] SUN MICROSYSTEMS. Java 2 Enterprise Edition (J2EE) Home Page, http://java.sun.com/j2ee/
[Wikipedia] WIKIMEDIA FOUNDATION. Wikipedia Home Page , http://www.wikipedia.org
9. ANEXOS
9.1. ANEXO A :Diagramas UML utilizados 9.1.1. Diagrama de Clases 9.1.1.1.
Clases.
Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el nombre de la clase, en la media los atributos y en la inferior las operaciones. Una clase puede representarse de forma esquemtica, con los atributos y operaciones suprimidos, siendo entonces tan solo un rectngulo con el nombre de la clase. En la Figura 9.1 se ve cmo una misma clase puede representarse a distinto nivel de detalle segn interese, y segn la fase en la que se est.
Figura 9.1 Ejemplos de Clases
9.1.1.2.
Objetos.
Un objeto se representa de la misma forma que una clase. En el compartimento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados, segn la siguiente sintaxis:
nombre_del_objeto: nombre_de_la_clase Puede representarse un objeto sin un nombre especfico, entonces slo aparece el nombre de la clase.
Figura 9.2 Ejemplos de Objetos
9.1.1.3.
Asociaciones
Las asociaciones entre dos clases se representan mediante una lnea que las une. La lnea puede tener una serie de elementos grficos que expresan caractersticas particulares de la asociacin. A continuacin se vern los ms importantes de entre dichos elementos grficos.
9.1.1.3.1.
Nombre de la Asociacin y Direccin
El nombre de la asociacin es opcional y se muestra como un texto que est prximo a la lnea. Se puede aadir un pequeo tringulo negro slido que indique la direccin en la cual leer el nombre de la asociacin. En el ejemplo de la Figura 9.3 se puede leer la asociacin como Director manda sobre Empleado.
Figura 9.3 Ejemplo de Asociacin Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado abundante la informacin que se presenta, con el consiguiente riesgo de saturacin. En ese caso se puede suprimir el nombre de las asociaciones consideradas como suficientemente conocidas. En las asociaciones de tipo agregacin y de herencia no se suele poner el nombre.
9.1.1.3.2.
Multiplicidad
La multiplicidad es una restriccin que se pone a una asociacin, que limita el nmero de instancias de una clase que pueden tener esa asociacin con una instancia de la otra clase. Puede expresarse de las siguientes formas: Con un nmero fijo: 1. Con un intervalo de valores: 2..5. Con un rango en el cual uno de los extremos es un asterisco. Significa que es un intervalo abierto. Por ejemplo, 2..* significa 2 o ms. Con una combinacin de elementos como los anteriores separados por comas: 1, 3..5, 7, 15..*. Con un asterisco: * . En este caso indica que puede tomar cualquier valor (cero o ms).
Figura 9.4 Ejemplos de Multiplicidad
9.1.1.3.3.
Roles
Para indicar el papel que juega una clase en una asociacin se puede especificar un nombre de rol.
Figura 9.5 Ejemplos de Roles
Se representa en el extremo de la asociacin junto a la clase que desempea dicho rol.
9.1.1.3.4.
Agregacin
El smbolo de agregacin es un diamante colocado en el extremo en el que est la clase que representa el todo.
Figura 9.6 Ejemplo de Agregacin
9.1.1.3.5.
Clases Asociacin
Cuando una asociacin tiene propiedades propias se representa como una clase unida a la lnea de la asociacin por medio de una lnea a trazos. Tanto la lnea como el rectngulo de clase representan el mismo elemento conceptual: la asociacin. Por tanto ambos tienen el mismo nombre, el de la asociacin. Cuando la clase asociacin slo tiene atributos el nombre suele ponerse sobre la lnea (como ocurre en el ejemplo de la Figura 9.7). Por el contrario, cuando la clase asociacin tiene alguna operacin o asociacin propia, entonces se pone el nombre en la clase asociacin y se puede quitar de la lnea.
Figura 9.7 Ejemplo de clases de asociacin
9.1.1.3.6.
Asociaciones N-Arias
En el caso de una asociacin en la que participan ms de dos clases, las clases se unen con una lnea a un diamante central. Si se muestra multiplicidad en un rol, representa el nmero potencial de tuplas de instancias en la asociacin cuando el resto de los N-1 valores estn fijos. En la Figura 12 se ha impuesto la restriccin de que un jugador no puede jugar en dos equipos distintos a lo largo de una temporada, porque la multiplicidad de Equipo es 1 en la asociacin ternaria.
Figura 9.8 Ejemplos de Asociacin Ternaria
9.1.1.3.7.
Navegabilidad
En un extremo de una asociacin se puede indicar la navegabilidad mediante una flecha. Significa que es posible "navegar" desde el objeto de la clase origen hasta el objeto de la clase destino. Se trata de un concepto de diseo, que indica que un objeto de la clase origen conoce al (los) objeto(s) de la clase destino, y por tanto puede llamar a alguna de sus operaciones.
9.1.1.3.8.
Herencia
La relacin de herencia se representa mediante un tringulo en el extremo de la relacin que corresponde a la clase ms general o clase padre.
Figura 9.9 Ejemplo de Herencia
Si se tiene una relacin de herencia con varias clases subordinadas, pero en un diagrama concreto no se quieren poner todas, esto se representa mediante puntos suspensivos. En el ejemplo de la Figura 13, slo aparecen en el diagrama 3 tipos de departamentos, pero con los puntos suspensivos se indica que en el modelo completo (el formado por todos los diagramas) la clase Departamento tiene subclases adicionales, como podran ser Recursos Humanos y Produccin.
9.1.1.3.9.
Elementos Derivados
Figura 9.10 Ejemplo de Elementos Derivados
Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros elementos presentes en el modelo, pero que se incluye en el modelo por motivos de claridad o como decisin de diseo. Se representa con una barra / precediendo al nombre del elemento derivado
9.1.2. Diagrama de Casos de uso
Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interaccin externa. En el diagrama de casos de uso se representa tambin el sistema como una caja rectangular con el nombre en su interior. Los casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada actor est unido a los casos de uso en los que participa mediante una lnea. En la Figura 9.11 se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automtico.
Figura 9.11 Diagrama de Casos de Uso para un cajero automtico
9.1.2.1.
Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso.
9.1.2.1.1.
Actores
Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organizacin, y que realiza algn tipo de interaccin con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representacin sirve tanto para actores que son personas como para otro tipo de actores.
9.1.2.1.2.
Casos de Uso
Un caso de uso es una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especfica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea llevar a cabo usando el sistema.
9.1.2.1.3.
Relaciones entre Casos de Uso
Un caso de uso, en principio, debera describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es til describir una interaccin con un alcance menor como caso de uso. La razn para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicacin en el equipo de desarrollo, el manejo de la documentacin de casos de uso. Para el caso de que queramos utilizar estos casos de uso ms pequeos, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos:
Incluye (<>): Un caso de uso base incorpora explcitamente a otro caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial comn a varios casos de uso. En la Figura 9.12 se muestra cmo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso Autorizacin.
Figura 9.12 - Ejemplo de Relacin include
Extiende (<>): Cuando un caso de uso base tiene ciertos puntos (puntos de extensin) en los cuales, dependiendo de ciertos criterios, se va a realizar una interaccin adicional. El caso de uso que extiende describe un comportamiento opcional del sistema (a diferencia de la relacin incluye que se da siempre que se realiza la interaccin descrita) En la Figura 9.13 se muestra como el caso de uso Comprar Producto permite explicitamente extensiones en el siguiente punto de extensin: info regalo. La interaccin correspondiente a establecer los detalles sobre un producto que se enva como regalo estn descritos en el caso de uso Detalles Regalo.
Figura 9.13. - Ejemplo de Relacin extend
Ambos tipos de relacin se representan como una dependencia etiquetada con el estereotipo correspondiente (<> o <>), de tal forma que la flecha indique el sentido en el que debe leerse la
etiqueta. Junto a la etiqueta <> se puede detallar el/los puntos de extensin del caso de uso base en los que se aplica la extensin.
Generalizacin ( ): Cuando un caso de uso definido de forma abstracta se particulariza por medio de otro caso de uso ms especfico. Se representa por una lnea continua entre los dos casos de uso, con el tringulo que simboliza generalizacin en UML (usado tambin para denotar la herencia entre clases) pegado al extremo del caso de uso ms general. Al igual que en la herencia entre clases, el caso de uso hijo hereda las asociaciones y caractersticas del caso de uso padre. El caso de uso padre se trata de un caso de uso abstracto, que no est definido completamente. Este tipo de relacin se utiliza mucho menos que las dos anteriores.
9.1.3. Diagrama de Secuencias

Un diagrama de Secuencia muestra una interaccin ordenada segn la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interaccin y los mensajes que intercambian ordenados segn su secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interaccin, sin un orden prefijado. Cada objeto o actor tiene una lnea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren.
Figura 9.14.-Diagrama de Secuencia
9.2. ANEXO B : Elementos Lxicos del Lenguaje de
Programacin Java
9.2.1. Qu es Java?
Java es toda una tecnologa orientada al desarrollo de software con el cual podemos realizar cualquier tipo de programa. Hoy en da, la tecnologa Java ha cobrado mucha importancia en el mbito de Internet gracias a su plataforma J2EE. Pero Java no se queda ah, ya que en la industria para dispositivos mviles tambin hay una gran acogida para este lenguaje. La tecnologa Java est compuesta bsicamente por 2 elementos: el lenguaje Java y su plataforma. Con plataforma nos referimos a la mquina virtual de Java (Java Virtual Machine). Una de las principales caractersticas que favoreci el crecimiento y difusin del lenguaje Java es su capacidad de que el cdigo funcione sobre cualquier plataforma de software y hardware. Esto significa que nuestro mismo programa escrito para Linux puede ser ejecutado en Windows sin ningn problema. Adems es un lenguaje orientado a objetos que resuelve los problemas en la complejidad de los sistemas, entre otras.
9.2.2. Palabras Reservadas

En la figura 9.15 se presentan las palabras reservadas del lenguaje Java
Figura 9.15 Palabras reservadas de Java
9.2.3. Identificadores
-El primer smbolo del identificador ser el caracter alfabtico (a,,z,A,,Z,_,$) pero no un El identificador dgito. Despus de ese primer caracter , podremos poner caracteres alfanumricos (a,,z) y (0,1,,9) ,signos de dlar $ o guines de subryado _. -Los identificadores no pueden coincidir con las palabras reservadas. Los co -Las maysculas y las minsculas se consideran diferentes y no se pueden usar indistintamente. Las -El signo de dlar y subrayado se interpretan como una letra ms. El Ejemplos vlidos: a , pepe , r456 , tu_re_da , AnTeNa , antena , usd$ usd Ejemplos no vlidos: 345abc , mi variable , Nombre.largo , caada , camin
9.2.4. Literales.
Especificacin de un valor concreto de un tipo de dato.
Nmeros Enteros: 21(int) , 21L (long) , 077 (en octal), 0Xdc00 (en Hexadecimal).
Numeros Reales: 3.14 (double) , 3.14f(flota) , 3.14d(double) , 2e12 , 3.1E12.
Valores Bolanos true (verdadero) , false (falso)
Caracteres p,\u???? (cdigo UNICODE en hexadecimal) , \t (tabulador)
Cadenas de caracteres mensaje . (cadena vaca)
9.2.5. Operadores.
Igual que en matemticas, realizan una accin especfica: -Suelen estar definidos en el ncleo del compilador (aunque tambin pueden estar definidos en bibliotecas externas) -Suelen representarse con cualquiera de los componentes lxicos formados por smbolos -Suelen utilizar notacin infija. -Pueden aplicarse a uno o varios operancod (argumentos).
-Suelen devolver un valor.
Figura 9.16.-Operadores Java en orden de precedencia
9.2.6. Delimitadores
Smbolos usados como separadores de las distintas construcciones de un lenguaje de programacin (esto es, puntuacin de un lenguaje de programacin). ( ) Parntesis: Listas de parmetros en la definicin y llamada a mtodos , precedencia en expresiones , expresiones para control de flujo y conversiones de tipo. { }Llaves: Inicializacin de arrays , bloques de cdigo , clases , mtodos y mbitos locales. [ ] Corchetes: Arrays. ; Punto y com: Separador de Sentencias , Coma: Identificadores consecutivos en una declaracin variables y sentencias
encadenadas dentro de una sentencia for. . Punto Separador de nombres de paquetes , subpaquetes y clases ; separador entre
variables y mtodos miembros.
9.2.7. Comentarios.
Aclaracin que el programador incluye en el texto del programa para mejorar su inteligibilidad. En Java hay tres tipos de comentarios: // Comentario de una sola lnea /* Comentario de una o ms lineas */ /** Comentario de documentacin , una o ms lneas */ La herramienta javadoc genera automticamente en HTML la documentacin del cdigo a partir de los comentarios /** */
9.2.8. Apndices.
En las Figuras 9.17 y 9.18 se resumen la precedencia de operadores y un resumen de elementos del lenguaje
Figura 9.17.- Precedencia de operadores
Figura 9.18.- Resumen de elementos del lenguaje
9.3. ANEXO C : Licencia de uso de la Pet Store

Copyright 1999-2001 Sun Microsystems, Inc. ALL RIGHTS RESERVED Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: -Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
-Redistribution in binary form must reproduct the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Sun Microsystems, Inc. or the names of contributors may be used to endorse or promote products derived from this software without specific prior written permission. > > This software is provided "AS IS," without a warranty of any kind. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES,HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > > You acknowledge that Software is not designed,licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility.
10. GLOSARIO DE TERMINOS

Trmino BMP Definicin Persistencia manejada por Bean: una estrategia para beans de entidad donde el desarrollador del bean implementa la lgica de la persistencia para los beans de entidad CMP Persistencia manejada por Contenedor: una estrategia para los beans de entidad donde los servicios del contenedor manejan transparentemente la persistencia de los beans de entidad Composite Un objeto complejo que sostiene otros objetos. Tambin relacionado con el patrn Composite descrito en el Libro de GoF Controller Interacta con un cliente controla y administra el manejo de cada peticin Data Access Object Un objeto que encapsula y abstrae el acceso a los datos desde un almacenamiento persistente o un sistema externo Delegate Un objeto sustituto de otro componente ; una capa intermedia. Un delegate tiene cualidades de proxy y facade Depend Object Un objeto que no existe por s mismo y cuyo ciclo de vida es administrador por otro objeto Dispatcher Algunas de las responsabilidades de un Controller incluyen manejo de la opcin y despacho para una Vista apropiada. Este comportamiento podra ser particionado dentro de componentes separados , referido como un despachador Enterprise Bean Se refiere a un componente Enterprise JAvaBean; puede ser una instancia de bean de entidad o de sesin . Cuando este trmino es usado , significa que la instancia del bean puede ser o un bean de entidad o un bean de sesin
Facade
Un patrn para ocultar las complejidades subyacentes ; descrito en el libro de GoF
Factory (Abstract Factory o Factory Method)
Patrones descritos en el Libro de GoF para crear objetos o familias de objetos
Trmino Iterator
Definicin Un patrn para proveer accesotes a facilidades de la coleccin subyacente ; descrito en el Libro de GoF
GoF
Gang of Four ( La pandilla de los cuatro) Se refiere a los autores del popular libro de patrones de diseo , Design Patterns: Elements of reusable Object-Oriented Software por Erich Gamma , Richard Helm , Ralph jonson y John Vlissides.
Helper
Responsable por la ayuda al Controller o View. Por ejemplo e l controller View podran delegar lo siguiente a un Helper : recuperacin de contenidos , validacin , almacenamiento del modelo o adaptarlo a un despliqgue
Independent Object
Un objeto que puede existir por s mismo y podra administrar los ciclos de vida de sus objetos dependientes
Middleware
Capa de software intermedio entre el cliente y el servidor. Es la capa de software que nos permiten gestionar los mecanismos de comunicaciones. Ejemplo si se hace la peticin de una pgina web desde un browser en el cliente, el middleware determina la ubicacin y enva una peticin para dicha pgina. El servidor Web, interpreta la peticin y enva la pgina al software intermedio, quien la dirige al navegador de la mquina cliente que la solicit.
Model
Una representacin lgica o fsica del sistema o su subsistema
MOM
Siglas de Message Oriented Middleware (Middleware orientado a mensajes) es una categora de software de comunicacin inter-aplicacin que depende en mensajes asicrnicos pasados como opuestos a la metfora solicitud/respuesta
Persistent Store
Representa un sistema de almacenamiento persistente tal como un RDBMS u ODBMS, sistemas de archivos , etc
POJO
Es un acrnimo de Plain Old Java Object . Este nombre es usado para enfatizar que el objeto en cuestin no es nada ms que un objeto Java ordinario.
Proxy
Un patrn que provee un contenedor para un objeto que controla el acceso a este; descrito en el libro de GoF Trmino Definicin La lgica de una aplicacin embebida directamente en una JSP Se refiere a un bean de sesin Stateless o stateful. Podra tambin referirse colectivamente al home de un bean de sesin , a un objeto remoto o una implantacin de un bean
Scriptlet Session Bean
Singleton
Un patrn que provee una nica instancia de un objeto , como est descrita en el libro de GoF
Template
El texto de una plantilla se refiere al texto literal encapsulado dentro de una Vista JSP. Adems una plantilla se podra referir a un diseo especfico de los componentes en una pantalla
Transfer Object
Un POJO serializable que es usado para traer datos desde un objeto/capa a otro(a). Este no contiene ningunos mtodos de negocio
View
La Vista maneja el texto y los grficos que componen la pantalla. Esta interacta con los Helpers para obtener valores de datos los cuales son populados en la pantalla.Adems sta podra delegar actividades tales
como recuperacin de contenido a sus Helpers WAP Wireless Application Protocol es un estndar internacional abierto para aplicaciones que usan comunicacin inalmbrica por ejemplo acceso al Internet desde un telfono mvil XML Es un lenguaje de propsito general que utiliza marcas y facilita el compartir datos entre diferentes sitemas , particularmente sistemas conectados va Internet

Utilizacion de Los Padrones Parte 2

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Utilizacion de Los Padrones Parte 2

Caricato da

Copyright:

Formati disponibili

CASO DE ESTUDIO: PET STORE , UNA APLICACIN DISEADA POR SUN MICROSYSTEMS ................... 4 6.

Nelson Salgado Reyes

Nelson Salgado Reyes

Nelson Salgado Reyes

La experiencia es madre de los buenos consejos. Juan de Torres

Nelson Salgado Reyes

Figura 6.1. Negocio del Mundo real.

Nelson Salgado Reyes

6.1. El Sitio Web del Pet Store

6.2. Un recorrido por el Sitio Web del Pet Store.

6.2.1. Pantalla Inicial

Nelson Salgado Reyes

Figura 6.2. Pantalla Inicial del Pet Store (/index.jsp).

6.2.2. Pantalla de Bienvenida

Nelson Salgado Reyes

Figura 6.3 Pantalla de Bienvenida (/main.screen)

Nelson Salgado Reyes

6.2.3. Pantalla de Categoras

Figura 6.4.-Pantalla de Categora (/product.screen?category_id=DOGS)

Nelson Salgado Reyes

6.2.4. Pantalla del Producto

Figura 6.5 Pantalla del Producto

Nelson Salgado Reyes

6.2.5. Pantalla de Items

Figura 6.6 Pantalla de Item (/item.screen?item_id=EST-26)

6.2.6. Pantalla del Carro de Compras.

Nelson Salgado Reyes

Figura 6.7.- Pantalla de Carro de compras (/cart.do?action=purchased&itemId=EST-26)

6.2.7. Pantalla de Conexin

Nelson Salgado Reyes

Figura 6.8.- Pantalla de Conexin (/signon.screen)

6.2.8. Pantalla de Informacin de la Cuenta

Nelson Salgado Reyes

Figura 6.9 Pantalla de Informacin de la Cuenta (/createuser.do)

Nelson Salgado Reyes

6.2.9. Pantalla de Informacin de la Orden

Nelson Salgado Reyes

Figura 6.10.- Pantalla de la Informacin de la Orden

Pantalla de la Orden Completa

Figura 6.11.- Pantalla de Orden Completa

6.3. Opciones de Diseo de alto nivel del Pet Store.

Nelson Salgado Reyes

Nelson Salgado Reyes

6.3.1. Estructura del Sitio Web de la Pet Store.

Nelson Salgado Reyes

Nelson Salgado Reyes

6.3.2. Diseo Modular de la Pet Store.

Nelson Salgado Reyes

La Figura 6.13 muestra estos mdulos.

Figura 6.13 Mdulos Funcionales de la Pet Store.

Nelson Salgado Reyes

6.3.3. Componentes de Aplicacin del Sitio Web de la Pet

Un programa de populacin : que pobla la base de datos de ejemplo.

Enterprise beans de la Pet Store.

Nelson Salgado Reyes

Nelson Salgado Reyes

Nelson Salgado Reyes

Pginas JSP de la Pet Store.

Nombre de la Pgina JSP duplicate_account.jsp

edit_customer.jsp footer.jsp general_error.jsp

Nelson Salgado Reyes

Despliega una lista de productos para una categora particular

Despliega los tips al final de la pantalla si los tip estn en encendido.

search.jsp sidebar.jsp signoff.jsp signon.jsp