Desarrollo de aplicaciones j2ee con mda e hibernate introduccióN



Descargar 1.52 Mb.
Página1/13
Fecha de conversión28.02.2018
Tamaño1.52 Mb.
  1   2   3   4   5   6   7   8   9   ...   13

DESARROLLO DE APLICACIONES J2EE CON MDA E HIBERNATE





INTRODUCCIÓN
En la actualidad los desarrolladores de software dedicados a las aplicaciones sobre la plataforma J2EE tienen que realizar el modelado de la lógica de negocio, con el fin de especificar cuál será la arquitectura para el desarrollo de la aplicación, esto es común para cualquier tipo de aplicación ya que el éxito del proyecto depende de la elección de una arquitectura que brinde la escalabilidad, mantenibilidad y que tenga una rápida conexión a la base de datos.
Para la elección de la arquitectura de la aplicación los desarrolladores deben tener los conocimientos necesarios sobre los patrones de diseño J2EE que existen en la actualidad, los cuales son los encargados de la persistencia de la aplicación como son:


  • DAO, Data Access Object u Objetos de Acceso a Datos, consultas SQL sobre la Base de Datos.

  • EJB, Enterprise Java Beans. Componentes de negocio para que se ejecuten en el servidor.

  • Hibernate, persistencia sobre clases java, enlazador objeto-relacional de código abierto.

El desarrollo de aplicaciones J2EE está limitado para los programadores que tengan los suficientes conocimientos en Patrones de Diseño J2EE, y no están al alcance de los programadores que recién están ingresando en el complicado mundo de las aplicaciones J2EE.


Los desarrolladores tienen que invertir tiempo y recursos en realizar tareas repetitivas como es la conexión con la base de datos, normalmente la capa de persistencia de las aplicaciones tienen sentencias de inserción, actualización, eliminación y consulta de registros, las cuales son del mismo tipo para cada una de las tablas de la base de datos.

CAPITULO I
MODEL DRIVEN ARCHITECT


    1. Antecedentes

La arquitectura dirigida por modelos es un acercamiento al diseño de software, y ha sido creada para dar soporte al modelado de sistemas de software, ésta proporciona un conjunto de guías para estructurar las especificaciones expresadas como modelos.


El principal objetivo de MDA es separar el diseño de la arquitectura y de la tecnología a ser usada en la construcción, la separación es planteada con el objetivo de que cada una de estas facetas de desarrollo puedan ser modificadas o alteradas independientes unas de las otras. Así se podrá modificar el diseño sin alterar la arquitectura [¹].
El diseño alberga lo relacionado con los requerimientos (Casos de Uso), la arquitectura proporciona la infraestructura a través de la cual se hacen efectivos requerimientos no funcionales como la escalabilidad, fiabilidad o rendimiento.

1.2 Panorama Actual del Modelado
Con MDA la funcionalidad del sistema estará definida en primer lugar como un modelo independiente de la plataforma (Plataform-Independent Model o PIM), a través de un lenguaje específico para el dominio del que se trate.
Cuando ya se ha creado un modelo de definición de la plataforma PDM correspondiente a CORBA, NET, WEB, etc. el modelo PIM puede traducirse entonces a uno o más modelos específicos de la plataforma PSM, para las implementaciones correspondientes, las cuales ya son en diferentes lenguajes específicos del dominio como Java que es un lenguaje de propósito general.


[1] http://es.wikipedia.org/wiki/Model_Driven_Architecture

La traducción de un modelo de PIM a un PSM se realiza utilizando herramientas automatizadas como herramientas de transformación de modelos (por ejemplo aquellas herramientas que cumplen con el estándar de OMG)
Los principios de la arquitectura dirigida por modelos pueden aplicarse no solo en el desarrollo de software, sino también en el modelado de procesos de negocio donde el PIM, independiente de la tecnología y de la arquitectura es adaptado tanto a los sistemas como a los procesos manuales.
El modelo MDA está relacionado con múltiples normas:


  • Lenguaje de modelado unificado (Unified Modeling Language o UML): empleado para la definición de los modelos independientes de la plataforma y los modelos específicos de las plataformas de destino. Es un estándar para el modelado introducido por el OMG.




  • MetaObject - Facility (MOF): establece un marco común de trabajo para las especificaciones del OMG, a la vez que provee de un repositorio de modelos y metamodelos [].




  • XMI Metadata Interchange (XMI): define una traza que permite transformar modelos UML en XML para poder ser tratados automáticamente por otras aplicaciones.




  • Enterprise Distributed Object Computing (EDOC): definición de objetos distribuidos mediante la utilización de metamodelos.




  • Software Process Engineering Metamodel (SPEM): software de procesamiento de metamodelos.




  • Common Warehouse Metamodel (CWM): define la transformación de los modelos de datos en el modelo de negocio a los esquemas de base de datos.

Fíjese que el término "arquitectura" en los meta modelos no se refiere a la arquitectura del sistema modelizado sino más bien a la arquitectura de los distintos estándares y formas del modelo que sirven de base tecnológica al MDA.


La OMG tiene además otros términos similares a MDA, el conocido como MDD (Model Driver Developer), Model Driver Aplication Developer, esta organización tiene la marca registrada sobre estos y otros productos del mercado.
1.3 MDA
MDA se define como una arquitectura dirigida por modelos, para comprender el principio que plantea esta arquitectura es necesario conocer varios conceptos que definen claramente los elementos que intervienen, su funcionamiento, la forma de uso y su aplicación en el proceso de desarrollo de software.


  1. Conceptos


Sistema
Los conceptos de MDA se definen centrados en la existencia o planteamiento de un sistema, que puede contener un simple sistema informático, combinaciones de componentes en diferentes sistemas informáticos, o diferentes sistemas en diferentes organizaciones, etc.
Modelo
Un modelo de un sistema es una descripción o una especificación de ese sistema y su entorno para desempeñar un determinado objetivo. Los modelos se presentan normalmente como una combinación de texto y dibujos. El texto se puede presentar en lenguaje de modelado, o en lenguaje natural.

Dirigido por modelos
MDA es un acercamiento al desarrollo de sistemas, que potencia el uso de modelos en el desarrollo. Se dice que MDA es dirigido por modelos porque usa los modelos para dirigir el ámbito del desarrollo, el diseño, la construcción, el despliegue, la operación, el mantenimiento y la modificación de los sistemas.
Arquitectura
La arquitectura de un sistema es la especificación de las partes del mismo, las conexiones entre ellos, y las normas de interacción entre las partes del sistema haciendo uso de las conexiones especificadas.
MDA determina los tipos de modelos que deben ser usados, como preparar dichos modelos y las relaciones que existen entre los diferentes modelos.
Puntos de vista
Un punto de vista es una abstracción que hace uso de un conjunto de conceptos de arquitectura y reglas estructurales para centrarse en aspectos particulares del sistema, obteniendo un modelo simplificado.
Vista
Una vista es una representación del sistema desde un determinado punto de vista.
Aplicación
En MDA se define el término aplicación como una funcionalidad que tiene que ser desarrollada. Por tanto podemos definir un sistema en términos de la implementación de una o más aplicaciones, soportadas por una o más plataformas.



  1. Plataforma

Una plataforma es un conjunto de subsistemas y tecnologías que aportan un conjunto coherente de funcionalidades a través de interfaces y determinados patrones de uso, que cualquier aplicación que se construya para esa plataforma puede usarse sin preocuparse por los detalles de la implementación o como se lleva a cabo la misma dentro de la plataforma.


Independencia de la plataforma
La independencia de la plataforma es una cualidad que tienen que presentar los modelos. Lo que significa que un modelo es independiente de las facilidades o características que implementan las plataformas, de cualquier tipo[¹].
Puntos de vista de la plataforma
MDA establece tres puntos de vista que se emplearán a lo largo del proceso de Ingeniería:


  • Modelo Independiente de la computación CIM (Computing -Independent Model). Un modelo CIM es una vista del sistema desde el punto de vista independiente de la computación. En algunos casos, nos referimos al modelo independiente de la computación como el modelo del dominio, y se usa vocabulario propio de los expertos en el dominio para la especificación.

Se centra en el entorno del sistema y los requisitos para el mismo. Los detalles de la estructura y procesamiento del sistema no se muestran, o aún no están especificados.




  • Un modelo independiente de la plataforma (PIM) es una vista del sistema desde el punto de vista independiente de la plataforma. Expone un carácter independiente de la plataforma sobre la que se desplegará, de modo que pudiera ser empleado en diferentes plataformas de carácter similar. Una técnica común para alcanzar el grado de independencia de la plataforma necesario es definir un sistema basado en una máquina virtual que abstraiga los modelos particulares de las plataformas existentes y sea neutral respecto a las mismas.


[¹] http://www.modelbased.net/

El PIM se centra en las operaciones del sistema, mientras oculta los detalles necesarios para una determinada plataforma. Muestra aquellas partes de la especificación del sistema que no cambian de una plataforma a otra. En este punto de vista debe emplearse lenguaje de modelado de propósito general, o bien algún lenguaje específico del área en que se empleará el sistema, pero en ningún caso se emplearán lenguajes específicos de plataformas.


  • Modelo específico de la plataforma (Plataform-Specific Models). Combina el punto de vista independiente de la plataforma con un enfoque específico para su uso en una plataforma específica en un sistema. Un modelo específico de la plataforma (PSM) es una vista de un sistema desde el punto de vista dependiente de la plataforma. Combina las especificaciones del modelo independiente de la plataforma con los detalles que especifican el uso de una plataforma específica por parte del sistema.


Modelo de la plataforma
Un modelo de plataforma expone un conjunto de conceptos técnicos que representan las diferentes formas o partes que conforman un sistema, y los servicios que provee. También expone, para su uso en los modelos específicos de la plataforma, conceptos que explican los diferentes elementos que provee una plataforma para la implementación de una aplicación en un sistema.
Un modelo de plataforma incluye también la especificación de requisitos en la conexión y uso de las partes que la integran, asi como la conexión de aplicaciones a la misma.


  1. Transformación de modelos

La transformación de modelos es el proceso de convertir un modelo en otro modelo del mismo sistema.


La Figura 1.1 ilustra la transformación del modelo independiente de la plataforma en un modelo específico para una plataforma mediante el uso de información añadida que permita trazar ambos modelos.



Figura 1.1 Transformación de modelos.
La transformación de un modelo independiente de la plataforma en un modelo dependiente de la plataforma no es necesaria para PIM basados en una máquina virtual. En este caso hay que transformar el PIM correspondiente a la máquina virtual en un modelo de plataforma específico.
Servicios Penetrantes
Los servicios penetrantes son servicios que están disponibles a un amplio catálogo de plataformas. MDA proveerá servicios penetrantes comunes e independientes de la plataforma y dispondrá de trazas para la transformación de los modelos, que permitirá la transformación de los servicios expuestos en los PIM’s a las plataformas de destino.


  1. Usando MDA

Ahora que ya hemos definido los conceptos básicos de MDA ahora es necesario conocer como se relacionan los modelos, como se usan y como interactuar entre un modelo independiente de la plataforma a uno específico de la plataforma.


En el desarrollo de un proyecto el modelo de origen es el modelo independiente de la computación, en este se modelan los requisitos del sistema describiendo las diferentes situaciones en las cuales este puede ser utilizado y que aplicaciones se espera que lleve a cabo, todos los requisitos modelados deben luego servir como ayuda para entender el problema, como una base para la realización de los demás modelos.
Todos y cada uno de los requisitos recogidos en el desarrollo del modelo CIM, deben ser trazables a lo largo de los modelos PIM y PSM que los implementan.
El CIM puede consistir en un par de modelos UML que muestren tanto la distribución de los procesos (ODP, Open Distributed Processing) como la información a tratar. También puede contener algunos modelos UML que especifiquen en más detalle los anteriores.
A partir del CIM, se construye un PIM, que muestra una descripción del sistema, sin hacer referencia a ningún detalle de la plataforma. Debe presentar especificaciones desde el punto de vista de la empresa, información y ODP. Un PIM se puede ajustar a un determinado estilo de arquitectura, o a varios.
Después de la elaboración del PIM, el arquitecto debe escoger una plataforma (o varias) que satisfagan los requisitos de calidad.


  1. Mapas de transformación

Mediante mapas, MDA especifica las reglas de transformación de un PIM a un

PSM para una plataforma en concreto. Estos mapas incluyen la transformación de tipos de valores para la transformación desde el PIM al PSM, los metamodelos y sus reglas para la transformación en tipos de valores existentes en las plataformas [¹].
Cuando se prepara un modelo haciendo uso de un leguaje independiente de la plataforma, especificado en un metamodelo y posteriormente se elige una plataforma para el despliegue, debe existir una especificación de transformación entre el metamodelo independiente de la plataforma y el metamodelo que describe la plataforma. Este requisito se ilustra en la Figura 1.2.


[¹]http://personal.telefonica.terra.es/web/lencorredera/mda_j2me.pdf





Figura 1.2 Especificaciones de transformación.
Una forma de facilitar la transformación de modelos es la identificación de elementos en el PIM que deben transformarse de una manera concreta para la plataforma de destino, y marcarlos como tal. Una marca expresa un concepto del PSM en el PIM; las marcas alejan el PIM de la independencia de la plataforma, por lo que un arquitecto debe mantener un PIM limpio, marcarlo para su adaptación a una plataforma en concreto. Las marcas deben concebirse como una capa transparente que se pone sobre el modelo.
La Figura 1.3 ilustra el uso de marcas como ayuda para la transformación, y su situación intermedia entre la independencia y la dependencia de la plataforma. Una vez que es elegida la plataforma, existe un mapa para la transformación de modelos. Este mapa incluye un conjunto de marcas, que se usa para marcar los elementos del PIM como guía para la transformación del modelo.
Las marcas pueden definir tipos del modelo, especificación de clases, asociaciones, roles, estereotipos,… las marcas también pueden especificar características cualitativas que después en la transformación se convertirá en el objetivo apropiado para el cumplimiento de los requisitos.



Figura 1.3 Marcas en la transformación de modelos.
Las marcas deben tener un modelo y una estructura que permita mantener la coherencia, que impida el marcado de un elemento con marcas mutuamente excluyentes [¹].
Los mapas de transformación pueden mantener también plantillas, que son modelos parametrizados que especifican tipos concretos de transformaciones. Podemos asociar un conjunto de marcas a una plantilla para identificar instancias en un modelo que deben ser transformados de acuerdo a las indicaciones de la plantilla.
Un elemento en un modelo puede ser marcado varias veces, empleando marcas procedentes de diferentes plantillas, y de distintos mapas de transformación, por lo que esos elementos serán transformados tantas veces como marcas tengan, siguiendo las reglas que especifican los mapas y las plantillas para los que fueron marcados [²].

[¹] [²] http://personal.telefonica.terra.es/web/lencorredera/mda_j2me.pdf.


Existe la posibilidad de incluir información relativa a patrones que extienda las características y tipos de los metamodelos y el lenguaje de la plataforma específica elegida para el despliegue. Como muestra la Figura 1.4, el uso de información adicional para la transformación implica la necesidad de información de los patrones para la transformación, que serán específicos para la plataforma de destino.


Figura 1.4 Información de patrones para transformación de modelos.


  1. Transformaciones

El siguiente paso al establecimiento de las marcas en los modelos y la selección de mapas de transformación es aplicar la transformación desde el PIM marcado al PSM. Este proceso puede ser manual, asistido por computador, o automático.


La transformación es el proceso que toma como entrada el PIM marcado y da como resultado el PSM del sistema, y el registro de transformación.
Algunas herramientas pueden hacer una transformación del PIM directamente a código desplegable en la plataforma de destino o incluso conceptos como MDR (Model-Driven Runtime Environment) que propone el uso de un entorno de ejecución para los PIM, directamente, sin generación de PSM ni código para la plataforma. En cualquier caso el OMG sostiene que la transformación debe permitir un PSM para ayudar al entendimiento del código y la depuración del mismo.

El registro de transformación incluye una traza desde cada elemento del PIM a los elementos correspondientes en el PSM, especificando que parte de los mapas de transformación fueron empleados para derivar los elementos del PSM desde los elementos del PIM. Una herramienta que mantenga los registros de transformación debe ser capaz de sincronizar de forma automática los cambios producidos en un modelo al otro [¹].


El PSM producido por una transformación es un modelo del mismo sistema que ha sido especificado en el PIM. También especifica como el sistema hace uso de una determinada plataforma.
Un PSM será una implementación del sistema si proporciona toda la información necesaria par construir el sistema y ponerlo en marcha [²].


[¹] IBM Corporation, Rational Application Developer V6 Programming Guide

[²] Philip Heller y Simon Roberts. Model Driven Architecture Fundations and Aplications

CAPITULO II
J2EE



    1. Definición

Java 2 Enterprise Edition (J2EE) es una arquitectura multicapa para implementar aplicaciones de tipo empresarial y aplicaciones basadas en la Web. Esta tecnología soporta una gran variedad de tipos de aplicaciones desde aplicaciones Web de gran escala a pequeñas aplicaciones cliente-servidor. El objetivo principal de la tecnología J2EE es crear un simple modelo de desarrollo para aplicaciones empresariales utilizando componentes basados en el modelo de aplicación. En este modelo dichos componentes utilizan servicios proporcionados por el contenedor, que de otro modo tendrían que estar incorporados en el código de la aplicación. Podría no ser lo ideal para todos los escenarios: por ejemplo, una pequeña aplicación se cubriría mejor utilizando una solución de la tecnología Java de peso ligero (por ejemplo Servlets, JSPs, etc.).





    1. Tecnologías J2EE

Las aplicaciones J2EE están compuestas de diferentes componentes. Un componente J2EE es una unidad de software funcional auto-contenido que se ensambla dentro de una aplicación J2EE con sus clases de ayuda y ficheros y que se comunica con otros componentes de la aplicación. La especificación J2EE define los siguientes componentes J2EE:

  • Las Aplicaciones Clientes y los Applets son componentes que se ejecutan en el lado del cliente.

  • Los componentes Java Servlet, la tecnología JavaServer Pages son componentes Web que se ejecutan en el lado del servidor.

Los Enterprise JavaBeans (beans enterprise) son componentes de negocio que se ejecutan en el servidor de aplicación.

Figura 2.1 Componentes de una aplicación J2EE.
Todos esos componentes se ensamblan en una aplicación J2EE, se verifica que están bien formados y que cumplen la especificación J2EE, y se despliegan en el entorno de producción, donde se ejecutan y son controlados por el servidor de aplicaciones J2EE.
Además de estos componentes principales, J2EE incluye servicios estándar y tecnologías de soporte como:
Java Database Connectivity (JDBC) tecnología que proporciona acceso a sistemas de bases de datos relacionales.
Java Transaction API (JTA) o Java Transaction Service (JTS) proporciona soporte para transacciones a los componentes J2EE.
Java Messaging Service (JMS) para comunicación asíncrona entre componentes J2EE.
Java Naming y Directory Interface (JNDI) proporcionan accesos a nombres y directorios.



  1. Clientes J2EE

Normalmente hay dos tipos de clientes J2EE: clientes Web y aplicaciones cliente como vimos en la figura anterior.


Un cliente Web consta de dos partes, páginas Web dinámicas que contienen distintos tipos de lenguajes de marcas (HTML, XML, y otros), que son generados por los componentes Web que se ejecutan en la capa Web, y un navegador Web, que dibuja las páginas recibidas desde el servidor. Otra categoría de clientes Web son los conocidos como clientes thin (pequeños). Este tipo de pequeños clientes normalmente no hacen cosas como consultas a bases de datos o ejecutar complejas reglas de negocio. Cuando se utilizan clientes pequeños, las operaciones de peso pesado las manejan los beans enterprise que se ejecutan en el servidor J2EE donde pueden tratar con la seguridad, los servicios y el rendimiento de las tecnologías del lado del servidor J2EE.
Una página Web recibida desde la capa del cliente puede incluir un applet embebido. Un appelt es una pequeña aplicación cliente escrita en Java que se ejecuta en la máquina virtual Java instalada en el navegador Web. Sin embargo, los sistemas cliente necesitarán el Plug-in Java y posiblemente un fichero de política de seguridad para poder ejecutar con éxito los applets en el navegador Web.
Normalmente los componentes Web son el API preferido para crear programas clientes Web porque no necesitan plug-ins ni ficheros de política de seguridad en los sistemas clientes. Además esto permite un diseño más claro y modular de la aplicación porque proporciona un significado a la separación de la lógica de la aplicación del diseño de la página Web.
Una aplicación cliente se ejecuta sobre una máquina cliente y proporciona una forma para que los usuarios puedan manejar tareas que requieren un interface de usuario más rico que el que puede proporcionar un lenguaje de marcas. Normalmente tienen un interface gráfico de usuario (GUI) creado con los APIs Swing o Abstract Window Toolkit (AWT). Las aplicaciones cliente acceden directamente a los beans enterprise que se ejecutan en la capa de negocio. Pero si se necesita un cliente Web pueden abrir una conexión HTTP para establecer comunicación con un servlet que se ejecute en la capa Web.


  1. Componentes Web

Los componentes Web de J2EE pueden ser servlets o páginas JSP. Los servlets son clases Java que procesan dinámicamente las peticiones y construyen las respuestas. Las páginas JSP son documentos basados-en-texto que se ejecutan como servlets pero permiten una aproximación más natural para crear contenido estático. Las páginas HTML y los applets se juntan con los componentes Web durante el ensamble de la aplicación, pero la especificación J2EE no los considera como componentes J2EE. De forma similar, las clases de utilidades del lado del servidor también se unen a los componentes Web como páginas HTML, pero tampoco se consideran como componentes J2EE. En la figura 2.2 podemos ver la comunicación entre componentes Web:




Figura 2.2 Comunicación entre componentes Web.
La capa Web podría incluir componentes Java Beans para manejar la entrada del usuario y enviar esta entrada a los beans enterprise que se ejecutan en la capa de negocio para su procesamiento como se observa en la figura anterior.


  1. Componentes de Negocio

El código de negocio, que es la lógica que resuelve o cumple las necesidades de un negocio particular, como la banca, la venta, o la financiación, se maneja mediante beans enterprise que se ejecutan en la capa de negocio.




Figura 2.3 Comunicación entre componentes de negocio.
La figura 2.3 muestra la comunicación entre los componentes de negocio, donde un bean enterprise recibe datos de los programas clientes, los procesa (si es necesario), y los envía a la capa del sistema de información empresarial para su almacenamiento. Un bean enterprise también recupera datos desde el almacenamiento, los procesa (si es necesario), y los envía de vuelta al programa cliente.
Hay tres tipos de beans enterprise: beans de sesión (con o sin estado), beans de entidad (manejados por el bean o por el contenedor) y beans dirigidos a mensaje. Un bean de sesión representa una conversación temporal con un cliente. Cuando el cliente finaliza su ejecución, el bean de sesión y sus datos desaparecen. Por el contrario, un bean de entidad representa datos persistentes almacenados en una fila de una tabla/relación de una base de datos.
Si el cliente se termina o si se apaga el servidor, los servicios subyacentes se aseguran de grabar el bean. Un bean dirigido-a-mensaje combina las características de un bean de sesión y de un oyente de Java Message Service (JMS), permitiendo que un componente de negocio reciba asincrónicamente mensajes JMS.
La especificación J2EE no considera como componentes J2EE a los Java Beans ya que son diferentes de los Beans Enterprise. La arquitectura de componentes Java Beans se pueden utilizar tanto en la capa de cliente como de servidor para manejar la comunicación entre una aplicación cliente o un applet y los componentes que se ejecutan en el servidor J2EE o entre los componentes del servidor y una base de datos, mientras que los componentes Enterprise Java Beans sólo se utilizan en la capa de negocio como parte de una capa de servidor. Los Java Beans tienen variables de ejemplar y métodos accesores y mutadores para acceder a las propiedades del bean o digamos, acceso a los datos en las variables de ejemplar lo que simplifica el diseño y la implementación de los componentes Java Beans.
La Capa del Sistema de Información Empresarial
La capa del sistema de información empresarial maneja el software del sistema de información empresarial e incluye la infraestructura del sistema así como los planings de recursos (ERP), procesamiento de transacciones a mainframes, sistemas de bases de datos y otros sistemas de información legales (personalizados). Los componentes de aplicaciones J2EE podrían necesitar acceder a estos sistemas de información empresariales para conectividad con sus bases de datos.


  1. Contenedores J2EE

Los contenedores J2EE proporcionan acceso a los servicios subyacentes del entorno del Servidor J2EE mediante contenedores para diferentes tipos de componentes. Tradicionalmente, los desarrolladores de aplicaciones tenían que escribir código para el manejo de transacciones, manejo del estado, multi-threads, almacenamiento de recursos, etc. Ahora el contenedor J2EE proporciona estos servicios permitiendo que te puedas concentrar en resolver los problemas de negocio.


Los contenedores son el interface entre un componente y la funcionalidad de bajo nivel específica de la plataforma que soporta el componente. Por ejemplo, antes de poder ejecutar un componente Web, un bean enterprise o un componente de una aplicación cliente, debe ensamblarse dentro de una aplicación J2EE y desplegarse dentro de su contenedor.
El proceso de ensamble implica especificar las configuraciones del servidor para cada componente de la aplicación J2EE y para la propia aplicación J2EE. Estas configuraciones personalizan el soporte subyacente proporcionado por el servidor J2EE, que incluye servicios como JNI, JNDI, seguridad, control de transacciones, etc.
El servidor J2EE proporciona contenedores para Enterprise Java Beans (EJB) y para componentes Web. El contenedor EJB maneja la ejecución de los beans enterprise de las aplicaciones J2EE, mientras que el contenedor Web maneja la ejecución de las páginas JSP y los componentes servlets de la aplicación J2EE. Otros contenedores distintos a estos son el contenedor de aplicaciones clientes y el contenedor de applets, que no son parte del servidor J2EE porque residen en la máquina del cliente, como se muestra en la figura 2.4.
Un contenedor de aplicaciones cliente maneja la ejecución de los componentes de la aplicación cliente mientras que un contenedor de Applets maneja la ejecución de los applets. Normalmente están en el JRE (Java Runtime Environment) y el navegador Web compatible con Java, respectivamente.


Figura 2.4 Contenedores de aplicaciones cliente.


  1. Empaquetado

Para poder desplegar una aplicación J2EE, después de desarrollar los diferentes componentes, se empaqueta en ficheros de archivo especiales que contienen los ficheros de las clases relevantes y los descriptores de despliegue XML. Estos descriptores de despliegue contienen información específica de capa componente empaquetado y son un mecanismo para configurar el comportamiento de la aplicación en el momento del ensamble o del despliegue. Estos se empaquetan en diferentes tipos de archivos según los distintos componentes.


Los componentes Web se empaquetan en un archivo Web (.war) que contiene los servlets, las páginas JSP y los componentes estáticos como las páginas HTML y las imágenes. El fichero .war contiene clases y ficheros utilizados en la capa Web junto con un descriptor de despliegue de componentes Web.
Los componentes de negocio se empaquetan en un archivo Java (.jar) que contiene los descriptores de despliegue EJB, los ficheros del interface remoto y del objeto junto con ficheros de ayuda requeridos por el componente EJB.
Los ficheros de clases del lado del cliente y los descriptores de despliegue se empaquetan en un fichero Java (.jar) que crea la aplicación cliente. Una aplicación J2EE se empaqueta en un archivo enterprise (.ear) que contiene toda la aplicación junto con el descriptor de despliegue que proporciona información sobre la aplicación y sus componentes, como se puede apreciar en la figura 2.5.

Figura 2.5 Archivos que conforman una aplicación J2EE.

  1. Roles de la Plataforma J2EE

La construcción de los diferentes componentes de una aplicación J2EE implica a varios roles en el desarrollo, despliegue y control de una aplicación empresarial.

  • El proveedor de componentes de aplicación desarrolla componentes J2EE reutilizables, que pueden ser componentes Web, beans enterprise, applets, o aplicaciones clientes para utilizar en aplicaciones J2EE.

  • El ensamblador de aplicaciones toma todos los bloques de los diferentes proveedores de componentes y los combina en aplicaciones J2EE.

  • El desarrollador es el responsable de la instalación/despliegue de los componentes en un entorno o servidor J2EE.

  • El administrador del sistema es el responsable de configurar y administrar los sistemas informáticos en una empresa.

  • El proveedor de herramientas es un vendedor utilizado para desplegar, empaquetar y desplegar aplicaciones J2EE.

  1. La Arquitectura Distribuida en J2EE

Todas las aplicaciones J2EE implementan una arquitectura distribuida. En ésta un objeto está asociado con un nombre, donde los nombres los proporciona un servicio de nombres, notificando a distintos componentes y resolviendo las referencias de clientes para estos componentes de servicio como se muestra en la siguiente figura:




Figura 2.6 Arquitectura distribuida de las aplicaciones J2EE.

Como resultado de esto, las referencias de objetos se obtienen buscando un objeto por su nombre notificado, una vez encontrado, se obtiene la referencia, y se llevan a cabo las operaciones necesarias sobre ese objeto utilizando los servicios del host. Un objeto remoto notifica su disponibilidad en el servicio de nombres utilizando un nombre lógico y el servicio de nombres lo traduce a la localización física del objeto en el entorno J2EE. Una vez que la petición del cliente obtiene una referencia a un componente remoto, puede enviarle peticiones. El sistema de ejecución maneja la comunicación distribuida entre objetos remotos, lo que incluye la serialización y des-serialización de parámetros.


Algunos de los sistemas de nombres utilizados en los sistemas distribuidos son RMI (sólo para implementaciones Java), CORBA, LDAP, DNS, NIS. El servidor de aplicaciones JBOSS utiliza RMI como su servicio de nombres.


  1. La Arquitectura Java Naming Directory Interface (JNDI)

J2EE utiliza el API JNDI para acceder genéricamente a servicios de nombrado y directorio utilizando la tecnología Java. El API JNDI reside entre la aplicación y el servicio de nombres y hace que el servicio de nombres subyacente sea transparente para los componentes de la aplicación, como se puede ver en la figura siguiente.



Figura 2.7 Utilización de JNDI en las aplicaciones J2EE.

Un cliente puede buscar referencias a componentes EJB u otros recursos en un servicio de nombres como el mencionado arriba. El código del cliente no se modifica, sin importar el servicio de nombres que se esté utilizando o en qué tecnología esté basado, y esto no crea ninguna diferencia en el modo en que los clientes localizan los objetos remotos mediante el API JNDI.




  1. Lectura de clases DTO

Un objeto DTO es un POJO, que nos va a servir para el transporte de datos entre las capas de una aplicación, de allí sus iniciales DTO (Data Transfer Object).





    1. Patrones de Diseño

Los analistas/diseñadores con gran experiencia aplican, de forma mayormente intuitiva y automática, criterios precisos que, de forma global, solucionan de forma elegante y efectiva los problemas de modelado de software de sistemas reales.


Usualmente estos diseñadores utilizan métodos, estructuras y subsistemas que son, a la vez, herramientas del diseño y partes de la solución final, de una manera que difícilmente puede transmitirse, en un sentido formal, a especialistas menos expertos.
Los “ingenieros de software” se enfrentan cada día a multitud de problemas de distinto calibre. La “efectividad” de un “ingeniero” se mide por su rapidez y acierto en la diagnosis, identificación y resolución de tales problemas. El mejor “ingeniero” es el que más reutiliza la misma solución -matizada- para resolver problemas similares.
La Orientación-a-Objetos propugna “no reinventar la rueda” en la pura codificación respecto de la resolución de problemas. ¿Por que, entonces, reinventarla para el ataque genérico a problemas comunes de análisis, diseño e implementación? Debe existir alguna forma de comunicar al resto de los “ingenieros” los resultados encontrados tras mucho esfuerzo por alguno(s) de ellos. Se necesita, al fin, algún esquema de documentación que permita tal comunicación.
La mera documentación de líneas de código resulta insuficiente, pues únicamente fomenta el uso de la técnica de “cut & paste”.

El tipo de los problemas y soluciones a documentar es muy variado:




  • PROGRAMACIÓN

  • ANÁLISIS

  • ARQUITECTURA

  • GESTIÓN, ETC.

Se necesita un formato de documentación único que aúne conceptualmente estos distintos tipos.


Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, para describir después el núcleo de la solución a ese problema, de tal manera que esa solución pueda ser usada más de un millón de veces sin hacerlo siquiera dos veces de la misma forma”.
Un patrón de diseño es “Una solución a un problema en un determinado contexto”. Tal solución es, empero, a la vez parte del “qué” y del “cómo” del sistema completo a construir: esto es, la pieza que conforma el patrón software es como la pieza patrón del sastre que se utiliza para confeccionar vestidos y trajes, pues tal pieza, aparte de contener las especificaciones de corte y confección del producto final, representa a la vez, en apariencia, una parte de tal producto textil [¹].
“Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.” En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares. Debemos tener presente los siguientes elementos de un patrón: su nombre, el problema (cuando aplicar un patrón), la solución (descripción abstracta del problema) y las consecuencias (costos y beneficios).

Los patrones de diseño se clasifican como se muestra a continuación:

[¹]http://java.ciberaula.com/articulo/diseno_patrones_j2ee/


  • Patrones Creacionales: Inicialización y configuración de objetos.

  • Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.

  • Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.

Veamos un poco en qué consisten los distintos tipos de patrones, cuáles son sus fines y qué beneficios nos aportan.

    1. Patrones Creacionales


Fábrica Abstracta (Abstract Factory)

El problema a solucionar por este patrón es el de crear diferentes familias de objetos, como por ejemplo la creación de interfaces gráficas de distintos tipos (ventana, menú, botón, etc.).


Método de Fabricación (Factory Method)

Parte del principio de que las subclases determinan la clase a implementar, como se muestra en el código siguiente.




public class ConcreteCreator extends Creator {
protected Product FactoryMethod(){
return new ConcreteProduct();
}}
public interface Product{}
public class ConcreteProduct implements Product{}
public class Client{
public static void main(String args[]){
Creator UnCreator;
UnCreator = new ConcreteCreator();
UnCreator.AnOperations();
} }



Compartir con tus amigos:
  1   2   3   4   5   6   7   8   9   ...   13


La base de datos está protegida por derechos de autor ©bazica.org 2019
enviar mensaje

    Página principal