JBoss Application Server

Curso Práctico Desarrollo de una Aplicación 

EJB 3.0

francisco.solans@neodoo.esaitor.acedo@neodoo.es

Neodoo Microsystems S.L.www.neodoo.es

¿Qué es JNDI?

   

JBoss AS: Instalación binarioLa instalación del servidor de aplicaciones JBoss es bastante sencilla:

Nos bajamos la distribución binaria de la versión 4.0.5 GA del servidor:

http://labs.jboss.com/jbossas/downloads

Establecemos la variable de entorno JBOSS_HOME en el directorio en el que hayamos descomprimido el fichero .zip.

Creamos una nueva configuración para poder trabajar con las mismas características que default, en nuestro caso denominaremos a la nueva configuración curso_portal y a partir de este momento trabajaremos en todo momento con esta configuración.

Arrancamos JBoss AS con la configuración curso_portal.

$JBOSS_HOME/bin/run.sh -c curso_portal

Si queremos parar el servidor tendremos que ejecutar:

$JBOSS_HOME/bin/shutdown.sh -S

Comprobar la existencia de ejb3.deployer en JBoss Application Server en nuestra configuración  $JBOSS_HOME/server/<CONF>/deploy, si es así, significará que podemos desarrollar aplicaciones con EJB 3.0.

   

JBoss AS: Instalación EJB 3.0Dependiendo de la versión de JBoss AS que utilicemos no tendremos soporte para EJB 3.0 por lo que 

señalaremos los pasos que seguiremos para poder dar soporte a este tipo de componentes. La versión 4.0.5 GA de JBoss no viene con el contenedor de EJB3 instalado.

Lo primero que tendremos que hacer será bajarnos el parche EJB3 RC9 Patch 1 de esta URL y descromprimirlo en cualquier directorio: 

http://labs.jboss.com/jbossejb3/downloads 

Para instalar el parche simplemente tenemos que realizar los siguientes pasos:

cd jboss-EJB-3.0_RC9_Patch1

ant -f install.xml -Djboss.server.config=curso_portal

La variable $JBOSS_HOME indica el directorio donde tenemos instalado la versión de nuestro servidor JBoss.

   

JBoss AS: Configuración EJB3.0Todas las librerías y ficheros de configuración del servidor EJB3 están recogidos en el directorio:

$JBOSS_HOME/server/<CONF>/deploy/

El servidor funciona correctamente con la configuración que viene por defecto, pero en ocasiones puede resultar útil el modificar configuraciones para adaptar las características del servidor a nuestras necesidades dentro de una aplicación o contexto, por ello podremos editar los siguientes ficheros:

ejb3.deployer/META­INF/persistence.propertiesejb3.deployer/META­INF/persistence.properties: configura la base de datos para todos los entity beans y el EntityManager en este servidor. La base de datos por defecto de nuestro servidor es HSQLDB.

ejb3­clustered­sfsbcache­service.xmlejb3­clustered­sfsbcache­service.xml: este fichero contiene la configuración del servicio JBoss Cache que replica es estado de los stateful beans cuando tenemos la configuración de cluster.

ejb3­entity­cache­service.xmlejb3­entity­cache­service.xml: almacena la configuración del servicio JBoss Cache, el cual guarda en cache y replica los entity beans en un arquitectura de tipo cluster.

   

Problema: Computación Distribuida (I)

La extensión de los mecanismos de RPC a una programación orientada a objetos dio lugar a los modelos de objetos distribuidos.

Un objeto distribuidoobjeto distribuido es aquel que está gestionado por un servidor y sus clientes invocan sus métodos utilizando un "método de invocación remota", el cliente invoca el método mediante un mensaje al servidor que gestiona el objeto, se ejecuta el método del objeto en el servidor y el resultado se devuelve al cliente en otro mensaje.

Un sistema distribuidosistema distribuido es un sistema donde sus componentes, ubicados en distintas computadoras conectadas en red, se comunican y coordinan a través de mensajes. Una arquitectura típica dentro de los sistemas distribuidos es la arquitectura cliente­servidor.

Los recursos pueden ser administrados por servidores y accedidos por clientes o encapsularse como objetos y accedidos por objetos clientes.

Un  servicioservicio  es  una  parte  del  sistema  de  computadores  que  gestiona  una  colección  de  recursos  relacionados presentando su funcionalidad a usuarios y aplicaciones.

Características de los sistemas distribuidos: heterogéneos y transparentes.

   

Problema: Computación Distribuida (II)

Tecnologías de desarrollo de sistemas distribuidos basados en objetos:ANSAANSA (1989­1991): Primer proyecto que intentó desarrollar una tecnología para modelizar sistemas 

distribuidos complejos con objetos.

DCOMDCOM (Distributed Component Object Model): Extiende a COM (Component Object Model) para soportar comunicación entre objetos en ordenadores distintos, en una LAN, WAN, o incluso en Internet. Con DCOM una aplicación puede ser distribuida en lugares que dan más sentido al cliente y a la aplicación.

CORBACORBA (Common Object Request Broker Architecture) Tecnología introducida por el grupo OMG para establecer una plataforma para la gestión de objetos remotos independiente del lenguaje de programación.

Tecnologías Java de Sun Microsytems:

RMIRMI (Remote Method Invocation): Fue el primer framework para crear sistemas distribuidos de Java. El sistema de Invocación Remota de Métodos (RMI) permite, a un objeto que se está ejecutando en una Máquina Virtual Java (VM), llamar a métodos de otro objeto que está en otra VM diferente. Esta tecnología está asociada al lenguaje de programación Java, es decir, que permite la comunicación entre objetos creados en este lenguaje.

EJB'sEJB's (Enterprise Java Beans): proporcionan un modelo de componentes distribuidos estándar para el lado del servidor.

Jini.

   

Problema: Computación Distribuida (III)

El último enfoque para el desarrollo de aplicaciones distribuidas ha sido la especificación EJB 3.0.

Los EJB's son componentes del lado del servidor, que están desarrollados en el lenguaje de programación Java, en los cuales se encuentra encapsulada la lógica de negocio de la aplicación.

Con las nuevas especificaciones EJB3, se simplifican al máximo el desarrollo de los componentes.

La utilización de un componente tanto de forma local como distribuida es bastante sencilla.

Intercalar el protocolo de comunicación a través de Web Services es muy cómodo.

Existen diferentes tipos de EJB's que están encargados de diferentes partes dentro de una aplicación empresarial:

Session Beans que a su vez se dividen en:

Stateless Session Bean (Bean de sesión sin estado)

Stateful Session Bean (Bean de sesión con estado)

Entity Beans (Bean de entidad)

Message Driven Beans (Beans dirigidos a mensaje)

   

JBoss AS: Arquitectura JMXLa comunicación entre los diferentes servicios MBeans se realiza a través del bus JMX, también conocido como 

el Microkernel JBoss.

   

JBoss AS: Interceptores e Invocadores

Por defecto, no es posible realizar llamadas remotas a los servicios MBean.

Un cliente puede acceder remotamente a un servicio MBean gracias a los invocadoresinvocadores.

Al estar separados del componente el mecanismo de comunicación es independiente del servicio que se va a ejecutar.

El primer interceptor del servicio MBean y el primero del lado del cliente relacionado se encargan de la capa de comunicación.

   

JBoss AS: Interceptores ClienteLos interceptores son implementados utilizando AOP puesto que esta metodología permite fácilmente añadir 

funcionalidades.

El orden de los interceptores en el lado del cliente es inverso al orden en el lado del servidor.

   

JBoss AS: Contenedor EJB 3.0

Es  un servicio MBean (EJB3Deployer) orientado a dar soporte a los componentes EJB/EJB3.

Como todo servicio MBean, pueden configurarse interceptores.

Seguridad, transacción, seguridad, cache, conexión, sincronización, relación, llamada, ...

   

EJB 3.0: Conceptos previos (I)EJB 3.0 es un nuevo enfoque para el desarrollo de aplicaciones empresariales distribuidas. Además mejora la 

arquitectura y reduce la complejidad de las versiones anteriores (EJB 2.1).

EJB 3.0 se basa en el uso de POJOs (Plain Old Java Objects), anotaciones Java y el patrón de diseño Dependency Injection para facilitar el desarrollo de las aplicaciones.

Anotaciones Java: es una nueva característica introducida en la JDK 1.5, la cual nos permite asociar atributos de código (metadatos) y opciones de configuración directamente con clases, métodos, y campos dentro del código fuente. 

En EJB 3.0 la interacción entre las clases POJO y el contenedor se especifica a través de las anotaciones Java.

Una de las funcionalidades más importantes de un contenedor EJB es gestionar los objetos de servicio, el contenedor instanciará estos objetos, gestionará sus ciclos de vida, mantendrá colas (pools) de objetos y proporcionará los medios para acceder a estos objetos desde otras partes de la aplicación.

   

EJB 3.0: Session Beans (I)Session Bean: Es un POJO gestionado por el contenedor de EJB3, Generalmente sirven a los clientes como una 

fachada de los servicios proporcionados.

Existen dos tipos de session beans:

Stateless: el estado tiene que ser gestionado por el cliente ya que no puede ser gestionado por el bean.

Este tipo de EJB's proporciona un servicio a los clientes.

La asociación que se produce entre el cliente y el session bean es corta ya que solamente existe durante la ejecución de uno de los métodos del bean.

Puede mantener información del estado global como por ejemplo el contexto JNDI, ...

Este tipo de session bean's son usados para proporcionar acciones en procesos de negocios, como por ejemplo “Procesar un pedido”.

Stateful: el estado es gestionado dentro del bean para evitarle la gestión del mismo al cliente.

Se ejecuta en nombre de un único cliente.

Este tipo de componente conserva información del estado entre diferentes llamadas de métodos, conocido como estado de la conversación con el cliente. No representa los datos compartidos en la base de datos, aunque puede acceder a ellos y actualizarlos. 

Es eliminado cuando el contenedor EJB falla, entonces el cliente tiene que re­establecer un nuevo objeto de sesión para continuar con la ejecución.

   

EJB 3.0: Session Beans (II)Ciclo de vida de los session bean: el contenedor de EJB crea y gestiona las instancias de los beans, pero en 

ocasiones nos puede interesar personalizar el proceso de gestión.

Para poder modificar el proceso estándar de gestión de instancias necesitamos proporcionar métodos callback en la clase que implementa el bean, para que el contenedor pueda llamarlos en la etapa del ciclo de vida del bean que corresponda.

Para implementar estos métodos callbackcallback utilizaremos anotaciones para designar cuales son los métodos que implementan el comportamiento que más nos interesa.

   

EJB 3.0: Session CallBacksAnotaciones de los métodos del ciclo de vida para los session beans:

@PostConstruct@PostConstruct: el método anotado así es llamado por el contenedor inmediatamente después de que la instancia del bean sea instanciada. Podemos aplicar esta anotación tanto a los stateless como a los stateful session beans y a los MDB's. Un método @PostConstruct es llamado después de un método @Init.

@PreDestroy@PreDestroy: un método con esta anotación es llamado antes de que el contenedor destruya una instancia del bean que ha expirado o que no está usada de su pila de objetos. (statess, stateful y MDB's)

@PrePassivate@PrePassivate: esta anotación en solamente aplicable a los stateful session bean. Si una instancia de un bean de ese tipo es inactiva durante mucho tiempo el contenedor la desactivaría y almacenaría su estado en una cache.

@PostActivate@PostActivate: cuando un cliente utiliza una instancia desactivada otra vez, una nueva instancia se crea y el estado del bean se restablece, este método es invocado cuando una instancia del bean activada está preparada.

@Init@Init: esta anotación designa a los métodos de inicialización de un stateful session bean. Una instancia de este tipo de session beans solamente invoca uno de los métodos anotados con @Init, el contenedor elige que método invocar.

   

EJB 3.0: Ciclo de vida Stateless

   

EJB 3.0: Ciclo de vida Stateful

   

EJB 3.0: Message Driven BeansJMS es un servicio fundamental proporcionado por los servidores de aplicaciones de J2EE. Este servicio permite 

realizar invocaciones de servicios asíncronamente a través de mensajes. Como resultado JMS es idóneo para la implementación de sistemas empresariales altamente escalables y fiables.

Los clientes JMS envían mensajes a colas de mensajes gestionadas por el servidor (una cola de mensajes podría ser una buzón de entrada de correo electrónico). 

Las colas de mensajes son monitorizadas por un tipo especial de EJBs que son los, Message Driven Beans (a partir de ahora MDB).

El MDB procesa los mensajes entrantes y realiza los servicios solicitados por el mensaje.

Una de las maneras más frecuentes de utilizar un MDB es pasando en los mensajes enviados al buzón los parámetros de los cálculos que se utilizarán por el MDB para la realización de la tarea que indique el mensaje.

   

EJB 3.0: Ciclo de vida MDB

   

EJB 3.0: Entity BeansEntity Beans: su objetivo es encapsular los objetos de lado de servidor que almacenan los datos (persistencia).

Persistencia gestionada por el bean (BMP): el propio objeto entidad se encarga, mediante una BD u otro mecanismo, de almacenar y recuperar los datos a los que se refiere.

La responsabilidad de implementar los mecanismos de persistencia recae en los hombros del programador.

Atributos para la persistencia, contexto EJB y propiedades.

Constructor de inicialización

Métodos de creación localización, borrado, sincronización, ...

Persistencia gestionada por el contenedor (CMP): el contenedor se encarga de almacenar y recuperar los datos del objeto de entidad mediante un mapeado en una tabla de una base de datos.

Todo lo relativo a la persistencia se indica declarativamente en ficheros de configuración y a través de ficheros de configuración.

Modelo ideal cuando desarrollamos el sistema de información desde el principio.

   

EJB 3.0: Ciclo de vida Entidad

   

EJB 3.0: Entity Manager

   

EJB 3.0: Entity CallBacksAl igual que ocurre en el caso de los session beans también en el caso de los entity beans podemos extender la 

gestión del ciclo de vida que el contenedor realizar de este tipo de objetos utilizando callbacks.

@PrePersist@PrePersist: el método anotado se ejecutaría justo antes de que la entidad sea creada en la base de datos.

@PostPersist@PostPersist: define un método que se ejecutará justo después de la que la entidad sea creada en la base de datos.

@PreRemove@PreRemove: anotamos las acciones que realizaremos antes de que la entidad sea eliminada de la base de datos.

@PostRemove@PostRemove: un método con esta anotación es llamado después de que una entidad sea eliminada de la base de datos.

@PreUpdate@PreUpdate: esta anotación designa al método que se invocado antes de la actualización de una entidad en la base de datos.

@PostUpdate@PostUpdate: el método anotado con esta marca será ejecutado después de la actualización de una entidad.

@PostLoad@PostLoad: utilizaremos un método marcado con esta anotación una vez que hayamos cargado los datos de la base de datos y sean vinculados con una entidad.

   

EJB 3.0: Servicios MBeansLos servicios JMX MBeans son el corazón de los bloques de construcción dentro del servidor de aplicaciones 

JBoss.

Muchos de los servicios internos de JBoss son implementados como MBeans, además podemos comunicar cada uno de estos MBeans entre sí utilizando el bus interno JMX, también conocido como JBoss Microkernel JMX.

A diferencia de los servicios EJB3, que son proporcionados a través de un pool de objetos gestionados por el servidor, un servicio MBean es proporcionado como una instancia Singleton dentro del servidor.

El desarrollo de un servicio MBean no es sencillo pero ya que en un entorno de un servidor JMX se necesitan extender un gran número de clases de diferentes frameworks (marcos de trabajo) y trabajar con API del tipo reflection. Aunque dentro de JBoss podemos desarrollar este tipo de servicios al estilo EJB3, es decir, con POJO's y anotaciones.

El problema es que estas anotaciones no están definidas dentro de la especificación oficial EJB3 pero para el desarrollo de servicios dentro de un servidor JBoss AS EJB3 serán útiles.

   

EJB 3.0: Servicios WebUn servicio web (Web service) es una colección de protocolos y estándares que sirven para intercambiar datos 

entre aplicaciones.

Distintas aplicaciones desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes como Internet.

Podemos desarrollar servicios web a través de la capa EJB, lo que hacemos es desplegar el servicio en el contenedor EJB3 y se utiliza un invocador que permita la comunicación en XML.

Lo único que se hace en realidad es señalar que llamada al componente EJB se realiza en XML incorporando un protocolo de comunicación distinto.

Los servicios web también hacen uso del mismo modelo de programación visto para los EJB's, así que bastará con una clase POJO y la etiqueta @WebService.@WebService.

   

EJB 3.0: AOP e InterceptoresDenominamos AOP a la programación orientada a aspectos.

La idea esencial detrás de la AOP es que para muchas aplicaciones, el código repetido a través de los módulos que constituyen el sistema, no necesariamente los usados para la implementación del proceso de negocio son considerados como cuestiones de infraestructura.

Uno de los ejemplos clásicos que hace posible la AOP es el caso en que queremos que todos los métodos de  las clases EJB's saquen información durante su ejecución, si estos componentes tienen que generar una información simular el problema puede solucionarse facilmente utilizando la AOP.

Además de este hay otro tipos de contextos a los que la AOP también se adapta bastante bien como por ejemplo revisiones (auditing), perfilaciones (profiling), y estadísticas.

Existen muchas implementaciones especificas de AOP (AspectJ, JBoss­AOP, etc.)

Las construcciones AOP se definen en Java y están vinculadas a una aplicación vía XML o por anotaciones.Aunque no todo son ventajas ya que muchos desarrolladores piensan que esta técnica dificulta el desarrollo del 

código.

   

Implementación: Stateless Bean (I)

Implementación del stateless session bean: Interface de negocio del bean:

Cliente del stateless session bean:

   

Implementación: Stateful Bean (I)Clase de implementación del interface de negocio:

Interface de negocio:

   

Implementación: Stateful Bean (II)Cliente del stateful session bean:

   

Implementación: Stateful Bean (III)Implementación de los métodos callbacks para la gestión personalizada del ciclo de vida del stateful 

session bean:

   

Implementación: MDB (I)Implementación de un Message Driven Bean:

   

Implementación: MDB (II)Definición de la cola dentro de JBoss:

   

Implementación: MDB (III)Emisor de los mensajes de la cola:

   

Implementación: WebService (I)

Interface implementado por el servicio web:

Servicio Web:

   

Implementación: WebService (II)Cliente del Servicio Web:

   

Implementación: Interceptor (I)Implementación de un interceptor que devuelve el tiempo consumido en la ejecución del método:

   

Implementación: Interceptor (II)Ejemplo de la utilización 

de un interceptor en un stateless session bean:

   

Desarrollo: Stateless Session Bean (I)

Definir el interface del session bean: dentro de este interface de servicio estarán todos los métodos de negocio que queremos definir dentro de nuestro session bean.

La anotación @Stateless@Stateless indica al contenedor que es un stateless session bean.

Implementación del cliente del session bean: una vez que hemos desplegado el session bean en el contenedor de EJB3.0 un objeto stub es creado y registrado en el registro JNDI del servidor. El cliente obtiene el stub del bean a través del JNDI usando el nombre por defecto formateado de la siguiente manera:

Si la aplicación es desplegada en un fichero EAR, el nombre JNDI por defecto para el interface local del stub es:

NOMBRE­FICHERO­EAR/NOMBRE­CLASE­EJB/local

Para el interface remoto es:

NOMBRE­FICHERO­EARNOMBRE­CLASE­EJB/remote

Si el bean es desplegado en un fichero JAR, los nombres JNDI serán:

NOMBRE­CLASE­EJB/local  y  NOMBRE­CLASE­EJB/remote

   

Desarrollo: Stateless Session Bean (II)

Un session bean puede implementar múltiples interfaces, cada interface está enfocado a un tipo de cliente. Por defecto, un interface es para un cliente local que se ejecuta en la misma JVM del contenedor de EJB3.0. Cuando el cliente busca un stub del bean a través de un interface local el contenedor devuelve una referencia del objeto del session bean.

Un interface remoto se utilizará por los clientes remotos. Cuando un cliente busca el stub del session bean a través de un interface remoto, el contenedor devuelve un objeto stub serializado que implementa el interface remoto. El stub remoto sabe como realizar las llamadas remotas (RPCs) al servidor.

El interface remoto contiene exactamente los mismos métodos que el interface local. Aunque en muchas ocasiones querríamos exponer diferentes métodos en un tipo de interface o en otro.

En la implementación de un session bean, podemos usar las anotaciones @Local@Local y @Remote@Remote para especificar los interfaces locales y remotos para este bean. También podemos utilizar las anotaciones @LocalBinding@LocalBinding y @RemoteBinding@RemoteBinding para especificar los nombres JNDI para los dos interfaces.

Las anotaciones @Local y @Remote también pueden ser utilizadas para etiquetar los interfaces de session en vez de la clase que implementa el bean.

   

Desarrollo: Stateful Session BeanInterface con propiedades de estado para la implementación de este tipo de session bean hemos añadido varios 

métodos en el interface local de servicio para poder accerder a la propiedades de estado del bean.

Para la implementación del stateful session bean tenemos que anotar la clase de la implementación con @Stateful@Stateful, además de declarar los atributos de las propiedades definidas dentro del interface del bean. Hay que señalar que en la clase que implemente el stateful session bean deberá implementar el interface Serializable, de esta manera el contenedor será capaz de almacenar el estado del bean cuando una instancia no esté en uso.

En un cliente JSP el stub del bean es recibido y asociado con el objeto HttpSession así que todas las peticiones HTTP desde la misma sesión utilizarán el mismo stub y por lo tanto también estarán trabajando con la misma instancia del bean dentro del contenedor.

   

Configuración de Eclipse (I)Para desarrollar la aplicación CaJBPortalWeb, 

utilizaremos el IDE Eclipse y los plugins de entorno web:

Eclipse SDK 3.2.2

Disponible en: www.eclipse.org/downloads/

Web Tools Platform (WTP).

Desde Eclipse accediendo a Help ­> Software Updates > Find and Install... seleccionando Search for new features to install 

Lista de mirrors: Callisto Discovery Site

Seleccionar Web and J2EE Development, presionar Select Required.

Web Tools Platform (WTP) Updates.

   

Configuración de Eclipse (II)Instalación del plug­in Subclipse, utilizado para 

trabajar con Subversion dentro de Eclipse

Desde Eclipse accediendo a Help ­> Software Updates > Find and Install... seleccionando Search for new features to install. Elegir New Remote Site...

Aceptamos la licencia y confirmamos la instalación en nuestra versión de Eclipse

   Window­>Preferences­>Server­>Installed Runtimes

Configuración de Eclipse (III)Los servidores más comunes en las arquitecturas J2EE están embebidos en el IDE Eclipse por lo que es posible 

tanto visualizar las trazas de log como controlar el servidor.

La configuración de un servidor externo a Eclipse es la solución más adecuada para realizar depuraciones.

   

Proyectos Software NecesariosDescargamos los siguientes proyectos para insertar las librerías necesarias en nuestro desarrollo web:

Añadir el driver JDBC de la base de datos (en nuestro caso Oracle XE) si no está ya en el servidor de aplicaciones, en el CLASSPATH del sistema o <JAVA_HOME>/jre/lib/ext. El conector JDBC aparece dentro del directorio <ORACLE_HOME>/jdbc/lib/.

Implementación JavaServer Faces (Elegir una de las dos):

MyFaces (Apache): MyFaces Core 1.1.5 Distributions de http://myfaces.apache.org/download.html

JSF RI (Sun): Descargar de https://javaserverfaces.dev.java.net

Descargar las Jarkarta Taglibs http://www.apache.org/dist/jakarta/taglibs/standard/

Añadir al proyecto standard.jar (Es una implementación Open Source de JSP Standard Tag Library (JSTL), versión 1.1.2).

   

Generación Proyecto Nuevo (I)

Desde el IDE Eclipse, ir a File > New... > Project y en la ventana seleccionar Web > Dynamic Web Project.

Crear un proyecto denominado CaJBPortalWeb.

Seleccionar como Target Runtime Apache Tomcat v5.5

Seleccionar JavaServer Faces v1.1 Project en Configurations.

Posteriormente, seleccionar Dynamic Web Module, Java 5.0 o 6.0 (para uso de extensiones del lenguaje y anotaciones) y JavaServer Faces 1.1.

Context Root: : CaJBPortalWeb, , Content Directory: WebContent y Java Source Directory: src

En la ventana JSF capabilities, si no existe ningún Implementation Library, crearla importando las librerías del proyecto MyFaces o similar.

En nuestro caso, utilizamos MyFaces Core 1.1.5. agregamos también la librería standard.jar del proyecto Jakarta Taglibs.

   

Generación Proyecto Nuevo (II)Hemos conseguido un esqueleto básico para 

comenzar nuestra implementación del proyecto CaJBPortalWebCaJBPortalWeb.

Lo primero que vamos a desarrollar será la vista utilizada para entrar en el sistema así como las páginas jsp, que pueden ser el resultado de introducir correctamente, o no, los datos dentro del formulario.

Existe un esqueleto ubicado en el servidor de Subversion.

Es necesario instalar el plugin  Subclipse para tener soporte SVN (seguir las instrucciones de la ficha Configuración de Eclipse (III)Configuración de Eclipse (III))

Ir a File > New Project > SVN > Checkout Projects from SVN e introducir los datos del repositorio.

Nos podremos bajar las soluciones de los ejercicios propuestos.

   

Bibliografía

Oracle 10g XE Documentation ­ http://www.oracle.com/pls/xe102/homepage

Data Access Object ­ http://es.wikipedia.org/wiki/Data_Access_Object

CallBack ­ http://en.wikipedia.org/wiki/Callback_(computer_science)

Dependency Injection ­ http://en.wikipedia.org/wiki/Dependency_injection

Singleton ­ http://en.wikipedia.org/wiki/Singleton_pattern

   

Glosario (I)

JMS: Java Message Service

MOM: Message Oriented Middleware, Enterprise Messaging Systems

JSR: Java Specification Request

JCP: Java Community Process

JNDI: Java Naming and Directory Interface

J2EE: Java Enterprise Edition

JVM: Java Virtual Machine

QoS: Quality of Service

   

Glosario (II)JMX: Java Management Extensions

WSRP: Web Services for Remote Portlets

CMS: Content Management System

RSS (v 2.0): Really Simply Sindication

*.WAR: Web Application Archive

*.SAR: Service Archive

*.EAR: Enterprise Archive

*.HAR: Hibernate Archive

LDAP: Lightweight Directory Access Protocol

   

Glosario (III)

URL: Uniform Resource Locator

URI: Uniform Resource Identifier

JPA: Java Persistence API

RPC: Remote Procedure Call