JBossAS: Desarrollo con especificación EJB 3.0 es un curso para introducir la tecnología EJB 3.0 y realizar despliegues en el servidor JBoss AS 4.0.5

1. JBoss Application Server
Curso Práctico
Desarrollo de una Aplicación
EJB 3.0
Neodoo Microsystems S.L.
www.neodoo.es
francisco.solans@neodoo.es
aitor.acedo@neodoo.es

2. ¿Qué es JNDI?

3. JBoss AS: Instalación binario
La 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.

4. JBoss AS: Instalación EJB 3.0
Dependiendo 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.

5. JBoss AS: Configuración EJB3.0
Todas 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.properties: configura la base de datos para todos los entity beans y el
ejb3.deployer/META­INF/persistence.properties
EntityManager en este servidor. La base de datos por defecto de nuestro servidor es HSQLDB.
ejb3­clustered­sfsbcache­service.xml: este fichero contiene la configuración del servicio JBoss Cache que
ejb3­clustered­sfsbcache­service.xml
replica es estado de los stateful beans cuando tenemos la configuración de cluster.
ejb3­entity­cache­service.xml: almacena la configuración del servicio JBoss Cache, el cual guarda en cache y
ejb3­entity­cache­service.xml
replica los entity beans en un arquitectura de tipo cluster.

6. 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 distribuido es aquel que está gestionado por un servidor y sus clientes invocan sus métodos utilizando
objeto distribuido
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 distribuido es un sistema donde sus componentes, ubicados en distintas computadoras conectadas en
sistema distribuido
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 servicio es una parte del sistema de computadores que gestiona una colección de recursos relacionados
servicio
presentando su funcionalidad a usuarios y aplicaciones.
Características de los sistemas distribuidos: heterogéneos y transparentes.

7. Problema: Computación Distribuida
(II)
Tecnologías de desarrollo de sistemas distribuidos basados en objetos:
ANSA (1989­1991): Primer proyecto que intentó desarrollar una tecnología para modelizar sistemas
ANSA
distribuidos complejos con objetos.
DCOM (Distributed Component Object Model): Extiende a COM (Component Object Model) para soportar
DCOM
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.
CORBA (Common Object Request Broker Architecture) Tecnología introducida por el grupo OMG para
CORBA
establecer una plataforma para la gestión de objetos remotos independiente del lenguaje de
programación.
Tecnologías Java de Sun Microsytems:
RMI (Remote Method Invocation): Fue el primer framework para crear sistemas distribuidos de Java.
RMI
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's (Enterprise Java Beans): proporcionan un modelo de componentes distribuidos estándar para
EJB's
el lado del servidor.
Jini.

8. 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)

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

10. 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
invocadores.
invocadores
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.

11. JBoss AS: Interceptores Cliente
Los 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.

12. 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, ...

13. 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.

14. 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.

15. 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 callback utilizaremos anotaciones para designar cuales son los métodos que
callback
implementan el comportamiento que más nos interesa.

16. EJB 3.0: Session CallBacks
Anotaciones de los métodos del ciclo de vida para los session beans:
@PostConstruct: el método anotado así es llamado por el contenedor inmediatamente después de que la
@PostConstruct
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: un método con esta anotación es llamado antes de que el contenedor destruya una instancia
@PreDestroy
del bean que ha expirado o que no está usada de su pila de objetos. (statess, stateful y MDB's)
@PrePassivate: esta anotación en solamente aplicable a los stateful session bean. Si una instancia de un
@PrePassivate
bean de ese tipo es inactiva durante mucho tiempo el contenedor la desactivaría y almacenaría su
estado en una cache.
@PostActivate: cuando un cliente utiliza una instancia desactivada otra vez, una nueva instancia se crea y el
@PostActivate
estado del bean se restablece, este método es invocado cuando una instancia del bean activada está
preparada.
@Init: esta anotación designa a los métodos de inicialización de un stateful session bean. Una instancia de
@Init
este tipo de session beans solamente invoca uno de los métodos anotados con @Init, el contenedor
elige que método invocar.

17. EJB 3.0: Ciclo de vida Stateless

18. EJB 3.0: Ciclo de vida Stateful

19. EJB 3.0: Message Driven Beans
JMS 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.

20. EJB 3.0: Ciclo de vida MDB

21. EJB 3.0: Entity Beans
Entity 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.

22. EJB 3.0: Ciclo de vida Entidad

23. EJB 3.0: Entity Manager

24. EJB 3.0: Entity CallBacks
Al 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: el método anotado se ejecutaría justo antes de que la entidad sea creada en la base de datos.
@PrePersist
@PostPersist: define un método que se ejecutará justo después de la que la entidad sea creada en la base
@PostPersist
de datos.
@PreRemove: anotamos las acciones que realizaremos antes de que la entidad sea eliminada de la base de
@PreRemove
datos.
@PostRemove: un método con esta anotación es llamado después de que una entidad sea eliminada de la
@PostRemove
base de datos.
@PreUpdate: esta anotación designa al método que se invocado antes de la actualización de una entidad en
@PreUpdate
la base de datos.
@PostUpdate: el método anotado con esta marca será ejecutado después de la actualización de una
@PostUpdate
entidad.
@PostLoad: utilizaremos un método marcado con esta anotación una vez que hayamos cargado los datos
@PostLoad
de la base de datos y sean vinculados con una entidad.

25. EJB 3.0: Servicios MBeans
Los 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.

26. EJB 3.0: Servicios Web
Un 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.

27. EJB 3.0: AOP e Interceptores
Denominamos 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.

28. Implementación: Stateless Bean (I)
Implementación del stateless session bean:
Interface de negocio del bean:
Cliente del stateless session bean:

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

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

31. 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:

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

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

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

35. Implementación: WebService (I)
Interface implementado por el servicio
web:
Servicio Web:

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

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

38. Implementación: Interceptor (II)
Ejemplo de la utilización
de un interceptor en
un stateless session
bean:

39. 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 indica al contenedor que es un stateless session bean.
@Stateless
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

40. 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 y @Remote para especificar los
@Local @Remote
interfaces locales y remotos para este bean. También podemos utilizar las anotaciones @LocalBinding y
@LocalBinding
@RemoteBinding para especificar los nombres JNDI para los dos interfaces.
@RemoteBinding
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.

41. Desarrollo: Stateful Session Bean
Interface 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, además de declarar los atributos de las propiedades definidas dentro del interface del bean. Hay
@Stateful
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.

42. 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.

43. 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

44. 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.
Window­>Preferences­>Server­>Installed Runtimes

45. Proyectos Software Necesarios
Descargamos 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).

46. 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.

47. Generación Proyecto Nuevo (II)
Hemos conseguido un esqueleto básico para
comenzar nuestra implementación del proyecto
CaJBPortalWeb.
CaJBPortalWeb
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)
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.
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.

48. 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

49. 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

50. 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

51. Glosario (III)
URL: Uniform Resource Locator
URI: Uniform Resource Identifier
JPA: Java Persistence API
RPC: Remote Procedure Call