| (Anterior) Otros Conceptos |
| Apéndice "A" (Siguiente) |
|
Ventajas y Necesidades.
Los patrones de diseño son empleados en muchos desarrollos de Software ya que ofrecen una mejor practica entorno al problema que se intenta resolver, de alguna manera son las experiencias continuas que han resultado al enfrentarse a determinado problema; en los diseños de EJB's ya se han documentado diversas practicas que eficientizan y agilizan su funcionamiento en "Application Servers/EJB Containers", estas practicas son denominadas "Patrones de Diseño" ("Design Patterns").
Patrones Generales de Diseño.
Interfase de Negocios ("Business Interface").
Como se ha observado a lo largo de este curso, un EJB esta compuesto por dos interfases ("Home" y "Remote") y la clase de implementación del EJB ("EJB Class"), si recuerda esta última clase debe implementar exactamente los métodos definidos en las interfases ("Home" y "Remote"), este requerimiento ha hecho que surja el patrón de diseño "Interfase de Negocios" o "Business Interface".
Al realizarse la compilación de la clase EJB (aquella que contiene la implementación) no existe ningún mecanismo para revisar que los métodos de ésta coincidan con los métodos definidos en el "Remote Interface"; algunos "Application Servers/EJB Containers" ofrecen esta revisión a través de herramientas de post-compilación y en algunos otros este tipo de errores se descubren muy tarde en el desarrollo o inclusive hasta ser ejecutado ("deployed").
La "Interfase de Negocios" como toda otra interfase en Java define un esqueleto que debe cumplir cualquier clase y/o interfase; al implementar esta "Interfase de Negocios" tanto en el "Remote Interface" y "EJB Class" se están protegiendo que éstas cumplan con ciertas definiciones antes de ser compiladas, en efecto asegurándose que contengan las mismas definiciones antes de iniciar cualquier tipo de compilación.
Fachada de Sesión ("Session Façade").
El patrón de Fachada permite aislar el acceso a otros EJB's mediante un "Session EJB", por eso su nombre Session Façade.
Otra ventaja que otorga el uso "Fechadas de Sesión" es el número de requisiciones necesarias para ser transferida la información entre el Cliente (JSP/Servlet/Applet) y los distintos EJB's, este mismo principio aplica al patrón de diseño "Objeto de Valores" que será ilustrado posteriormente.
Patrones de Solicitudes de Acceso (De JSP/Servlets).
Fábrica de Interfases ("Home Factory").
La búsqueda/localización que realiza un Cliente (JSP/Servlet) por un EJB también puede resultar en una carga excesiva para el "Application Server/EJB Container" si no es diseñado un acceso apropiado. La búsqueda llevada acabo a través de JNDI es una operación repetitiva y cara.
Suponga que ha diseñado acceso "Web" para cierta información residente en EJB's, cada visitante que acceda al sitio ( a través de un JSP/Servlet ) requiere localizar el EJB a través de JNDI, si espera 1000 o 2000 visitantes, esto implica mil o dos mil búsquedas repetitivas, y la situación se agrava aún más si el Cliente (JSP/Servlet) y el EJB residen en diferentes "Application Servers".
Lo anterior trajo como resultado el surgimiento del patrón de diseño "Fabrica de Interfases" ("Home Factory") el cual permite al Cliente (JSP/Servlet) reutilizar el resultado de búsqueda que ya ha sido llevado acabo por el EJB. En si el funcionamiento de esta fábrica es como un "Cache" para el Cliente (JSP/Servlet), a continuación se ilustra su uso:
Objeto de Valores ("ValueObject").
La labor principal de Clientes (JSP/Servlet/Programa de Terminal) para EJB's es invocar métodos presentes en el EJB, sin embargo, como se pudo observar en Interfases Locales estos Clientes no necesariamente residen en el mismo "Application Server/EJB Container" , esta residencia trajo como consecuencia el patrón de diseño Value Object.
El llamar método por método presente en distintos EJB's puede presentar una carga substancial sobre la Red y el "Application Server/EJB Container", cada método que es llamado por el Cliente requiere lo siguiente:
- Serializar la información para ser enviada al "EJB Container"
- Deserializar la información para ser procesada en el "EJB Container"
- Revisar parámetros de Seguridad
- Iniciar una Transacción
- Serializar respuesta para ser procesada por el Cliente.
- Deserializar respuesta para utilizarse en el Cliente.
Imagínese este mismo proceso siendo llevado acabo 5 o 6 veces consecutivamente, atrevés de un Objeto de Valores ("Value Object") es posible reducir esta carga a una sola llamada.
El principio de un Objeto de Valores ("Value Object") es sencillo: agrupar los distintos valores utilizados por el Cliente en un solo método, este tipo de métodos también son conocidos como "Coarse Grained" mientras el uso de métodos individuales es denominado "Fine Grained".