![Girasol Editor [English]](http://3.bp.blogspot.com/-dUgoRlc3J_Y/Ub_RlNg8CqI/AAAAAAAAAts/9vQHz55Hp-Q/s1600/GirasolEditorEng.png)
![Girasol Editor [Español]](http://1.bp.blogspot.com/-XoBCgk3TUjw/Ub_RliO1-QI/AAAAAAAAAuA/bnmpUnsm74Q/s1600/GirasolEditorSpa.png)
xfvxdfsdxf
Algunos estilos
Estos son algunos estilos.
Texto Normal
Texto Intenso
Texto con Énfasis
Texto Insertado
Texto Borrado
Definición
Cita
Texto de Ejemplo
Texto con Código
Variable
Texto Teclado
Texto de Máquina de Escribir
Consideraciones de Diseño en Java
Consideraciones de Diseño en Java
Resumen Ejecutivo
Este documento habla de algunas prácticas y consideraciones que deben llevarse acabo a fin de generar un producto de aplicación Java robusto, con un bajo acoplamiento, una alta cohesión etc. Todos elementos deseables en una solución de software. 
A fin de relatar las prácticas encontradas se dividirá la aplicación en capas. Las tiers nos permiten modularizar las aplicaciones reduciendo la complejidad de las mismas. Para este documento disertaremos sobre las tiers de Presentación, Negocio además de un poco sobre la integración entre ambas.
El Framework de Sun
Definición
El Framework de Sun Microsystems provee una vista tridimensional la cual permite expresar la arquitectura de un sistema en términos de:
¿Que es un Tier?
División lógica de las piezas de software que conforman un sistema, acorde a su rol y responsabilidad. Las tiers que Sun maneja en su marco de desarrollo son las siguientes:
Cliente.-Máquina cliente o sistema que provee servicios de interacción con un humano para captura y despliegue de información.
Presentación.- Provee servicios para crear dinámicamente las diferentes vistas que conforman la interfaz de usuario y envia mensajes al tier de negocios
Negocios.- Provee las reglas que soportan las operaciones regulares de un negocio y ejecutan transacciones.
Integración.- Servicios que permiten a un aplicativo abstraerse y de conectarse con recursos externos.
Recursos.- Provee los servicios de almacenamiento de datos en un repositorio permanente (sistemas legados, bases de datos, directorios en línea, servidores mail y máquinas entre otros).
¿Qué es un Layer?
Son una abstracción en las piezas de un software, donde un nivel se comunica solo con el nivel inmediatamente inferior y provee servicios al nivel superior, abstrayendo los detalles de implementación. Las layers sobrepasan el alcance de este documento y solo diré son divididas como: aplicación, plataforma virtual, plataforma superior, plataforma inferior, transporte.
La Capa de Presentación
Consideraciones sobre el estado de la sesión.
Mantener la sesión en el cliente
El guardar la sesión en el cliente significa serializar el estado y adjuntarlo a la respuesta HTML que es enviada al cliente.
Los beneficios de persistir la sesión en el cliente son los siguientes:
Las consideraciones respecto a esta aproximación
Las aproximaciones para lograr esto abarcan los campos ocultos, las cookies, y la reescritura de las URIs. Sus consideraciones particulares se listan a continuación:
Campos Ocultos
Implementar campos ocultos en el código HTML tiene la ventaja de ser una aproximación de fácil implementación, además las restricciones de seguridad de algunos exploradores no afectan el estado en los clientes.
Cookies
La implementación de cookies para guardar el estado en el cliente tiene la ventaja de persistir durante tiempos mayores a la sesión configurada en el servidor. Las limitaciones de esta aproximación incluyen que el tamaño de las cookies es fijo; es decir no se permiten archivos demasiado grandes. Si quieres tener una cookie portable entre diferentes navegadores no puede ser mayor a 4 kilobytes. Además si estos archivos son grandes consumen ancho de banda teniendo que recorrer la red 2 veces cada vez que son utilizados. La otra limitación se encuentra en la seguridad del navegador, el Proxy o firewall que pueden no permitir el paso de cookies.
URIs
La reescritura de URIs tiene la ventaja de permitir el salvar el estado de la sesión en la sección de favoritos del navegador de Internet. El mayor inconveniente que presenta frente a las otras aproximaciones es la limitación de reescritura de direcciones que tienen algunos exploradores de en cuanto al número de caracteres que aceptan. El límite para Internet Explorer 6 es de 2,083 caracteres (Fuente: http://support.microsoft.com/default.aspx?scid=KB;en-us;q208427 , Otro: http://www.aspfaq.com/show.asp?id=2222 ).
Mantener la sesión en la capa de presentación
Cuando una sesión se mantiene en el servidor es localizada mediante un ID de sesión y típicamente se conserva hasta que ocurre alguno de los siguientes casos:
Entre las ventajas de guardar la sesión en la capa de presentación se encuentran:
Las consideraciones que implica esta aproximación incluyen
Estas consideraciones nos llevan a la pregunta de donde vamos a almacenar dicha información.
Memoria
El número de usuarios puede afectar la memoria del servidor, hay que tomar en cuenta que si se ocupan 500ks de memoria para un usuario serán 500 megas para 100 usuarios y 5gb para 1000 usuarios.
Enterprise Java Beans
La plataforma J2EE provee de una solución estandarizada que son los Session Beans para el caso particular sobre el estado de una sesión se utilizan los Stateful Session Beans. Un Bean diseñado específicamente para mantener el estado del cliente en un proceso. El uso de EJBs tiene las siguientes consideraciones.
Porque no utilizar Stateless Session Beans?
Esto se discute mas ampliamente en una parte posterior del documento.
Consideraciones para el control de acceso a la aplicación
Existen muchos motivos para la restricción y control del acceso de un cliente a ciertos recursos. Uno de ellos es cuando no se quiere que un cliente ingrese a una vista particular, caso que se da por ejemplo cuando el cliente no se ha registrado en un sitio que lo exige o cuando de acuerdo a su rol no debe tener acceso a dicha vista.
Proteger un recurso
En algunos casos un recurso se encuentra restringido para ciertos usuarios. Existen varias técnicas para lograr este objetivo se puede restringir el acceso a partir de lógica dentro de la vista, canalizar el acceso a través de un controlador que decide si se puede tener o no, o incluso existen aproximaciones híbridas.
Proteger un recurso desde la vista
El proteger un recurso desde la vista generalmente implica el tener lógica de control en los documentos de vista. Se puede o no hacer referencia a los roles de los diferentes usuarios. Generalmente implica el uso de una etiqueta de control con la lógica embebida para hacer las validaciones correspondientes. Normalmente el uso de esta técnica controla el despliegue de vínculos.
Algunos beneficios respecto a esta aproximación son las siguientes:
Entre las consideraciones de esta aproximación se encuentran:
Para lograr esto regularmente utilizamos en patrón de vista compuesta, documentado en el siguiente vínculo: http://java.sun.com/blueprints/corej2eepatterns/Patterns/CompositeView.html .
Proteger un recurso a través de un controlador
El uso de controladores implica un cambio en el paradigma de diseño. Esta aproximación concentra la lógica de control en un solo repositorio centralizado. Consiste en utilizar una o mas clases controlador como punto de acceso a la aplicación. Entre los beneficios de utilizar un controlador esta un incremento en la modularidad, reusabilidad, mantenibilidad y trazabilidad de la aplicación. El patrón que define como implementar un controlador se encuentra en el siguiente vínculo: http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html .
Esto implica a su vez tener capas de indirección para separar la lógica de negocio de la lógica de presentación. El tener objetos de la capa de presentación en la capa de negocio acrecienta el acoplamiento y por lo tanto esta contraindicado.
Proteger un recurso a través de un contenedor
Se puede configurar un contenedor para que solo permita tener acceso a un recurso a través de otros recursos internos como puede ser un controlador utilizando un despachador de peticiones. La especificación de Servlet nos dice que los parámetros de seguridad son definidos en un archivo descriptor denominado web.xml. La seguridad de un contenedor esta definida en el documento de especificación de servlet en el capítulo SRV.12. http://java.sun.com/products/servlet/reference/api/index.html
Una forma alternativa de proteger un recurso es colocarlo en el directorio WEB-INF del contenedor o cualquiera de sus subdirectorios. Estos archivos solo podrán ser accedidos a través de un controlador y un objeto RequestDispatcher.
Envió Duplicado de Formas
Usuarios trabajando en un ambiente donde se utiliza un navegador pueden inadvertidamente utilizar el botón de “Atrás” posiblemente invocando una transacción duplicada. Similarmente el uso del botón de “Alto” puede dejar el navegador sin pintar lo cual provocaría el uso del botón “Refrescar” logrando el mismo efecto.
Para evitar esto se utiliza una Ficha Sincronizadora. El procedimiento es el siguiente:
- Inicializar una ficha en la información de sesión del cliente.
- Incluir la ficha en la información de la forma.
- Se recibe la forma.
- Se compara la ficha contra la que se encuentra en la sesión.
- Si la ficha es igual se continúa.
- Si la ficha ha cambiado se redirige a una página de error.
- Se aumenta la ficha en uno.
Validación
Suele ser deseable el realizar validaciones tanto en el cliente como en el servidor. La validación del lado del cliente suele ser menor (por ejemplo: que la forma se encuentre llena) mientras que del lado del servidor debe ser más exhaustiva.
Validación en el Cliente
Típicamente incluye el uso de scripts de código que pueden estar en JavaScript. Uno de sus principales beneficios es el de disminuir la carga de transacciones del servidor al evitar el envió de información errónea y el regreso de páginas de error. El inconveniente de esta tecnología es que dichos scripts pueden ser desactivados como parte de la configuración de seguridad del cliente. Es una mala práctica solo tener validación del lado del servidor.
Validación en el Servidor
La validación de la información en el servidor tiene mayores alcances que la validación en el cliente; pues para el servidor la información tiene significado. Además de validaciones de negocio podemos encontrar validaciones que se pueden tipificar en tipos abstractos. De tal manera que el código de validación puede centrarse en la forma o centrarse en el tipo abstracto. Las validaciones centradas en la forma son fáciles de implementar y requieren poco tiempo para llevarse acabo, la desventaja es que se tienen muchos lugares donde el código es validado y esto suele ser poco mantenible, flexible y rehusable. La validación centrada en los tipos abstractos abstrae las validaciones fuera del estado del modelo en un marco genérico, esto tiene la ventaja de reducir el acoplamiento. La desventaja de esta aproximación se encuentra en la reducción de la eficiencia y velocidad.
Clases Helper
Las clases Helper son beans utilizados para mapear las propiedades de una forma de HTML. Utilizan un mecanismo muy simple los campos de la forma será copiados al atributo del helper cuyo nombre coincida con estos. Este mecanismo simplifica mucho el manejo de formas HTML en Java.
El inconveniente viene cuando no se conocen del todo las especificaciones de estos Beans. Cuando se tiene un campo que no contiene datos este no es enviado en el request; por lo tanto no es actualizado en la clase Helper. Como normalmente no se conoce esto se presupone que si un usuario borra la información de un campo el sistema lo llenará con un NULL o una cadena vacía, cuando en realidad el atributo no sufre ningún cambio. Esto lleva consigo una inconsistencia en la información de la clase que pudo ser evitada. Llevando esta situación a otros controles tenemos por ejemplo los check box donde la información no será enviada a menos que se encuentre marcado este. Significa que si se le quita la marca a un check box el Helper no tendrá conciencia de esto. Por lo tanto se creará una inconsistencia en nuestro código. La solución mas simple para evitar esto es resetear las propiedades de la clase antes de setear el código. El como implementar correctamente una clase Helper se encuentra en el siguiente vínculo:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html . Para un ejemplo de implementación esta el siguiente vínculo: http://java.sun.com/products/commerce/tutorial/add_address/helper_class.html .
La Capa de Negocio
Los EJBs de sesión
Los EJBs de sesión con y sin estado.
Los Beans de sesión pueden o no retener el estado de la conversación con el cliente. Las ventajas de utilizar beans con retención de estado (Statefull) son:
Las ventajas de utilizar beans sin retención de estado (Stateless) son:
El patrón del Business Delegate
( http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html ) depende de los EJBs de sesión mediante la fachada provista por el patrón Session Facade ( http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html ).
Guardar el estado del cliente en la capa de negocio
En una parte primera del documento se exploró como almacenar el estado de la sesión en el cliente y en la capa de presentación, se habló también un poco de cuando utilizar los EJBs para almacenar dicho estado. Generalmente se considera que cuando se va a acceder al sistema por diferentes vías, es decir se van a tener diferentes tipos de clientes accesando la capa de negocio es util mantener la sesión en EJBs.
Los EJBs de Entidad – Entity Beans
Los Beans de Entidad estan diseñados para ser objetos de negocio. Son objetos distribuidos y según la especificación EJB tienen las siguientes características:
Las llaves primarias
Los descriptores de los Entity Beans definen un tipo de llave primaria generalmente constituida por un valor primitivo. De no ser así, debe declararse un clase adicional que funja como llave primaria del Bean. La flexibilidad que nos da esta clase es que la llave primaria del EJB puede ser una llave compuesta o constituida por un objeto. Los atributos en la clase llave deben ser públicos así mismo los atributos que componen la llave deben ser públicos en el Bean de Entidad.
Implementar los métodos de HashCode y Equals en la clase primaria le permite al contenedor establecer las diferencias entre dos beans. La manipulación en el contenedor suele hacerse a través de Collections por lo tanto un código de dispersión erroneo puede conducir rápidamente a problemas de rendimiento.
Las transacciones en los Beans de Entidad
Los Beans de Entidad realizan sus transacciones de manera atómica; es decir que una llamada a un método setXXX() implicaría escribir en el sistema de persistencia, siempre que no se abra una transacción para hacer esto. Es decir que si anidamos el uso de varios setXXX() podemos tener varias transacciones anidadas; pero si envolvemos esto en un objeto UserTransaction solo se llevará acabo una transacción.
Utilizar el atributo Required en una transacción para un bean de entidad puede causar problemas de rendimiento. Un programador inexperto puede hacer llamadas a los métodos getXXX individuales lo cual implica una nueva transacción por llamado, utilizar el atributo Mandatory es recomendable dado que este lanza una excepción siempre que se intente llamar un EJB sin una transacción. Otra recomendación sería no exponer todos los atributos mediante métodos setXXX y getXXX para evitarlo es recomendable utilizar el patrón Value Object ( http://java.sun.com/j2ee/patterns/ValueObject.html ).
Lógica de Negocio en los Beans de Entidad
Una de las cosas que es preferible evitar cuando se trata de Entity Beans son las relaciones Entidad contra Entidad, pues estas nos llevan a problemas de rendimiento. En general los EJBs de entidad deben tener solo información auto contenida; es decir deben procesar solo la información que puedan manipular. Un error común sería crear un entity bean de manera que refeja la estructura relacional de nuestra base de datos. Si se requiere la interacción entre dos beans de entidad se debe aplicar el patrón Composite Entity ( http://java.sun.com/blueprints/corej2eepatterns/Patterns/CompositeEntity.html ).
Si el flujo de trabajo entre múltiples EJBs de entidad es identificado este puede ser consolidado utilizado el patrón de Session Facade ( http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html ).
Por último si se quiere persistir estos beans siempre es mejor implementar el acceso a datos afuera de los mismos para ello es útil el patrón Data Access Object ( http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html ).
La búsqueda de los Beans
El código de búsqueda es mejor tenerlo encapsulado mediante el patrón de Service Locator ( http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html ) suele suceder que este código se embebe en los clientes generando una baja trazabilidad y mantenibilidad de la aplicación. Esta separación se asegura al utilizar el patrón de Business Delegates ( http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html ) para toda referencia a la lógica de negocio.
A su vez al utilizar un método finder para devolver una lista amplia de EJBs puede impactar el rendimiento al ser esta lista una serie de referencias remotas a los objetos. A fin de evitar esto es posible utilizar el patrón Value List Handler ( http://java.sun.com/blueprints/corej2eepatterns/Patterns/ValueListHandler.html ).
http://www.informit.com/articles/article.asp?p=100598&rl=1
Glosario
Sesión de usuario
El término sesión de usuario describe una conversación que incluye múltiples solicitudes entre el cliente y servidor.
URI - Uniform Resource Identifier
Las URIs son conocidos por muchos nombres direcciones WWW, Identificadores Universales de Documentos (UDIs), y finalmente una combinación de URL (Uniform Resource Locators) Localizadores Uniformes de Recursos y URN (Uniform Resource Locators Names) Localizadores Uniformes de Nombres. En cuanto a lo que concierne al HTTP los URIs son simplemente cadenas que identifican por nombre, localización o cualquier otra característica un recurso.
EJB – Enterprise Java Bean
Las Características de los EJBs son:
Típicamente operan sobre logica de negocio o información de negocio.
Las instancias de los EJB son creadas y administradas por un contenedor en tiempo de ejecución.
Un EJB puede ser tropicalizado al momento de ser desplegado al editar sus propiedades de ambiente.
Los servicios de información, transacción y seguridad no se encuentran embebidos en estas clases.
El acceso a la clase es mediante el contenedor.
Deben poderse incluir en un archivo de aplicación (EAR) sin necesidad de cambios en el código.
Session Bean – EJB de Sesión
Es una clase de EJB de sesión es creada por un cliente y suele existir únicamente durante lo largo de la sesión de este. Algunas características de estas clases son:
Estan dedicados a un solo cliente o usuario.
No sobreviven si el contenedor se cae.
No son objetos persistentes.
Pueden estar concientes de que una transacción se esta realizando.
Pueden modelar conversaciones reteniendo o no el estado del cliente.
Bibliografía
Lineamientos de Arquitectura y Diseño de Aplicaciones Java 2 Enterprise Edition ( http://www.lucasian.com/documents.htm )
Sun Microsystems, Java Servlet Specification Version 2.4 ( http://java.sun.com/products/servlet/reference/api/index.html )
Designing Enterprise Applications with the J2EE Platform, Second Edition . Rich Green. Sun Microsystems 2002.
http://www.w3.org/ HTML Specification
http://63.240.93.131/articles/article.asp?p=26149 , J2EE Presentation Tier Design Considerations and Bad Practices
http://www.refactoring.com/catalog/index.html Refactoring Home Page.
http://www.it.uu.se/edu/course/homepage/pvarkjava/vt05/OH/lesson16-vt05.pdf J2EE patterns.
http://java.sun.com/products/commerce/tutorial/add_address/helper_class.html Writing a Helper Class. Aquí encontramos un ejemplo de como implementer Clases Helper.
http://java.sun.com/products/ejb/docs.html La especificación de los EJBs
http://www.jguru.com/faq/view.jsp?EID=854006 JGurú Faqs.
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=11&t=010015 Java Rach Forums
http://weblogic.sys-con.com/read/42660.htm Avoiding Performance Pitfalls with Entity EJBs
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/transaction_management/enterprise_beans/index.html 8.7.2 Container-Managed Transaction Demarcation
http://java.sun.com/developer/technicalArticles/releases/j2se15langfeat/index.html Typesafe Enum
Algunos estilos
Texto Normal
Texto Intenso
Texto con Énfasis
Texto Insertado
Texto Borrado
Definición
Cita
Texto de Ejemplo
Texto con Código
Variable
Texto Teclado
Texto de Máquina de Escribir
Subscribe to:
Posts (Atom)
Posts
