JBossAS: Desarrollo con especificación EJB 3.0

1,144 views

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,144
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

JBossAS: Desarrollo con especificación EJB 3.0

  1. 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. 2. ¿Qué es JNDI?
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 17. EJB 3.0: Ciclo de vida Stateless    
  18. 18. EJB 3.0: Ciclo de vida Stateful    
  19. 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. 20. EJB 3.0: Ciclo de vida MDB    
  21. 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. 22. EJB 3.0: Ciclo de vida Entidad    
  23. 23. EJB 3.0: Entity Manager    
  24. 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. 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. 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. 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. 28. Implementación: Stateless Bean (I) Implementación del stateless session bean: Interface de negocio del bean: Cliente del stateless session bean:    
  29. 29. Implementación: Stateful Bean (I) Clase de implementación del interface de negocio: Interface de negocio:    
  30. 30. Implementación: Stateful Bean (II) Cliente del stateful session bean:    
  31. 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. 32. Implementación: MDB (I) Implementación de un Message Driven Bean:    
  33. 33. Implementación: MDB (II) Definición de la cola dentro de JBoss:    
  34. 34. Implementación: MDB (III) Emisor de los mensajes de la cola:    
  35. 35. Implementación: WebService (I) Interface implementado por el servicio  web:   Servicio Web:  
  36. 36. Implementación: WebService (II) Cliente del Servicio Web:    
  37. 37. Implementación: Interceptor (I) Implementación de un interceptor que devuelve el tiempo consumido en la ejecución del método:    
  38. 38. Implementación: Interceptor (II) Ejemplo de la utilización  de un interceptor en  un stateless session  bean:    
  39. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 51. Glosario (III) URL: Uniform Resource Locator URI: Uniform Resource Identifier JPA: Java Persistence API RPC: Remote Procedure Call    

×