JBoss Developer Framework

Recientemente Jboss ha liberado JBoss Developer Framework o JDF para los amigos.  El Framework en realidad es un centro de documentación central para todas las tecnologías relacionadas con JBoss y JBoss AS. Este esfuerzo de consolidación permite a los desarrolladores centrarse en un recurso único de documentos en lugar de tomar varias guías individuales de las diferentes tecnologías de JBoss (por ejemplo, una guía de Hibernate y otra para Seam).

JDF incluye más de 50 quickstarts  que son proyectos Maven que se generan con archetypes. Lo interesante es que la mayoría de los quickstarts generan los proyectos con varias capas,  Estos pueden servir ya sea como tutoriales o como la base para las aplicaciones más complicadas. Algunas de las tecnologías que incluyen: EJB, JAX-RS, JPA, JSF, CDI, HTML5, JTA, Apache Wicket...

Dejo links:
http://in.relation.to/Bloggers/AnnouncingJdfJBossDeveloperFramework
http://www.jboss.org/jdf/news/2012/06/05/welcome/

@EJB

En un post anterior hicimos un proyecto con maven y JEE 

Pero en ese caso hicimos un lookup pero podríamos haber usado @EJB de la siguiente manera:

@EJB(mappedName="HolaMundoImpl/remote")

private HolaMundo holaMundo = null;

Y con esto nos ahorrábamos el lookup.

Cuales son los atributos de @EJB y para que se usan?

@EJB indica la dependencia de un ejb tanto local como remoto. Esta anotación tiene diferentes atributos los cuales analizaremos luego de revisar el concepto de ENC. Todos los EJB tienen un ENC (Enterprise Naming Context ) es como un registro interno donde fue deployeada esta aplicación.

Por ejemplo:

@Stateless(name="MyEJB")

public class MyEJBBean implements MyEJBRemoteBusiness, MyEJBLocalBusiness

{

...

}

Si nosotros asumimos que este EJB esta en myejb.jar y dentro de myapp.ear se puede tener una referencia a este bean de la siguiente manera:

javax.naming.Context jndiContext = new InitialContext(); // Assume we have this

// Define the contracted value

final String jndiName = "java:global/myapp/myejb/MyEJB!" +

MyEJBRemoteBusiness.class.getName();

MyEJBRemoteBusiness bean = (MyEJBRemoteBusiness)jndiContext.lookup(jndiName);

Cada bean contiene su JNDI ENC. La registración a JNDI ENC puede ser registrado bajo el contexto java:comp/env comp es porque es un componente. Cuando hacemos el lookup se resuelve la dependencia de diferentes contextos.

@EJB tiene los siguientes atributos:

name: atributo el cual indica conque nombre acedemos a una referencia EJB en JNDI ENC.

BeanName: este es el nombre de una referencia.

MappedName : es especifico del vendor; es una key dentro de la registración global. Es una forma de acceder a la referencia en el JNDI global. Por medio de mappedName varios vendors introducen características particulares. 

Esto fue una reseña general de @EJB. 

EJB 3 + Maven 2 + JBoss 6 + Eclipse

Vamos a crear un proyecto Jee con maven y que use como servidor Jboss con la siguiente estructura:

pom parent _
                     |__ ejb
                     |__ war

Bueno creamos el proyecto parent:

mvn archetype:create -DgroupId=com.ejemplos -DartifactId=EjemploJEE

Y modificamos el pom para que quede de la siguiente manera:

  4.0.0

  org.assembly
  ExampleJEE
  1.0-SNAPSHOT
  pom

  ExampleJEE
  http://maven.apache.org

  
    UTF-8
  

   
  
   
   maven-compiler-plugin 
    
    1.6 
    1.6 
    
   
   
   org.apache.maven.plugins 
   maven-eclipse-plugin 
   2.7      
    
    2.0 
    true 
    
   
   
   org.apache.maven.plugins   
      maven-javadoc-plugin    
   
   
   org.apache.maven.plugins   
       maven-project-info-reports-plugin    
   
  
  

  
        
            jboss-repository
            JBoss Repository
            https://repository.jboss.org/nexus/content/groups/public/
            default
        
    


  
     
    
      jboss
      jboss-ejb-api
      4.2.0.GA
      provided
    

    
      junit
      junit
      4.10
      test
    

  

Creamos el proyecto ejb:

cd ExampleJEE
mvn archetype:create -DgroupId=org.assembly -DartifactId=ExampleEJB

Y cambiamos el pom de la siguiente manera:

  4.0.0

  
    ExampleJEE
    org.assembly
    1.0-SNAPSHOT
  

  org.assembly

  ExampleEJB

  1.0-SNAPSHOT

  ejb

  ExampleEAR

  http://maven.apache.org

  
   
       
            javax.persistence
            persistence-api
            1.0
            provided
           
        
  
  
  
    UTF-8
  

 
    
    
      
        org.apache.maven.plugins
        maven-ejb-plugin
        2.1
        
          3.0
        
      

    
  

Ahora vamos a generar el proyecto war siempre dentro de ExampleJEE:

mvn archetype:create -DarchetypeArtifactId=maven-archetype-webapp -DgroupId=org.assembly -DartifactId=ExampleWAR

Y cambiamos el pom de la siguiente manera:

  
  4.0.0
  
  
    ExampleJEE
    org.assembly
    1.0-SNAPSHOT
  
  
  org.assembly
  
  ExampleWAR

  1.0-SNAPSHOT

  war

  ExampleWAR Maven Webapp

  http://maven.apache.org

  
    ExampleWAR
  

  
 
   
            org.assembly
            ExampleEJB
            1.0-SNAPSHOT
            provided
        
 
     
            javax.servlet
            servlet-api
            2.5
            provided
        

  

Pongo la dependencia a ExampleEJB como provided dado que no quiero que maven agregue el jar dentro del war después hago deploy del proyecto EJB y del WAR.

Ahora mvn clean install parados en el proyecto parent (ExampleJEE) y mvn eclipse:eclipse (si usan eclipse).

Bueno ahora importamos el proyecto a eclipse: file-> import-> Existing Projects into Workspace … Elegimos el path donde se encuentra el proyecto ExampleJEE y importamos.

Vamos a crear las siguientes clases en ExampleEJB:

La interfaz del servicio:

package org.assembly.service.api;

import javax.ejb.Remote;

@Remote
public interface HolaMundo {
 
 String decirHola();

}

La implementación :

package org.assembly.service.impl;

import javax.ejb.Stateless;

import org.assembly.service.api.HolaMundo;

@Stateless
public class HolaMundoImpl implements HolaMundo {

 /* (non-Javadoc)
  * @see org.assembly.service.api.HolaMundo#decirHola()
  */
 @Override
 public String decirHola() {
  return "Hola";

 }

}

Además agregamos este archivo en src/main/resources (si no existe la carpeta la crean) y lo nombramos jndi.properties

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=localhost:1099

Y en el Proyecto web agregamos este servlet:

package org.assembly.web;

import java.io.IOException;
import java.io.PrintWriter;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.assembly.service.api.HolaMundo;

public class HolaMundoServlet extends HttpServlet {

 private static final long serialVersionUID = 7819040755879233852L;

 private HolaMundo holaMundo = null;

 
 public HolaMundoServlet() {
  final Context context;
  try {
   context = new InitialContext();
   holaMundo = (HolaMundo) context.lookup("HolaMundoImpl/remote");

  } catch (NamingException e) {
   e.printStackTrace();
  }
 }


 @Override
 protected void doGet(HttpServletRequest req, HttpServletResponse resp)
   throws ServletException, IOException {
  final PrintWriter out = resp.getWriter();

  try {
   out.println(holaMundo.decirHola());
  } catch (Exception e) {
   out.println(e.getStackTrace().toString());
  }

 }

}

Por ultimo modificamos el web.xml para que escuche el servlet:

  Archetype Created Web Application
  
  
    
        hola
        org.assembly.web.HolaMundoServlet
    

    
        hola
        /hola.html
    
  
  

Ahora lo que hacemos es instalar el plugin Jboss Tools en eclipse lo podemos hacer desde el Marketplace de eclipse.

Ahora bajar Jboss 6 desde http://download.jboss.org/jbossas/6.1/jboss-as-distribution-6.1.0.Final.zip

Instalar el Jboss desde el panel de Servers menú contextual new. Luego importamos nuestros proyectos. Si todo fue bien debería verse el entorno así:

Corremos Jboss y en http://localhost:8080/ExampleWAR/hola.html deberíamos ver un “hola”

Seguridad con JEE

JEE y EJB proveen un conjunto de servicios que los desarrolladores pueden integrar de forma declarativa o programática. Estos servicios incluyen autorización y autenticación.

Autenticación e identificación

La autenticación es comprobar que el usuario sea quien dice ser. En un sistema EJB un usuario es asociado con una identidad segurizada, esta esta lista para ser usada por los EJB. Cuando un cliente invoca un método de un EJB, el servidor pasa la identidad del cliente con la invocación del método. Cuando el contenedor de EJB recibe la invocación valida la identidad del usuario y si este puede invocar el método invocado.

La especificación EJB no indica como se autentica. Aunque esta definido como la seguridad se propaga del cliente al servidor, no esta definido como el cliente obtiene la identidad y la credencial con una invocación EJB, tampoco define como el servidor guarda y obtiene las autenticaciones.

Cuando accedemos a un EJB muchas aplicaciones utilizan la JNDI API, por ejemplo podemos autenticar el acceso a un EJB de este modo:

properties.put(Context.SECURITY_PRINCIPAL, "username");
properties.put(Context.SECURITY_CREDENTIALS, "password");
Context ctx = new InitialContext(properties);
Object ref = jndiContext.lookup("SecureBean/remote");
SecureRemoteBusiness remote = (SecureRemoteBusiness)ref;

En el ejemplo, el usuario es autenticado con la conexión a el “JNDI InitialContext”

Autorización.

Como sabemos en las aplicaciones no todos somos iguales, cada usuario tiene un rol ante una aplicación por ejemplo “administrador”, “empleado”, etc. y cada rol puede hacer o no determinadas acciones, es decir tiene o no tiene permiso para.

En EJB existen diferentes tipos de granularidad de permisos, puede ser por usuario o por rol. Esto permite que la autenticación sea un proceso separado de la autorización.

Los roles son definidos de forma logica y pueden representar roles, grupos de usuarios, o cualquier otro sistema de identificación. Los roles del los EJB son mapeados a los usuarios y grupos reales cuando el bean es deployado.

La autorización esta bien definida en la especificación EJB. Se declaran los roles de forma programática y luego se indican los permisos a los beans por medio de anotaciones o declararlos en ejb-jar.xml

Vimos de forma teoría la seguridad en EJB, en un próximo post vamos a hace algo más práctico.

Por que no EJB 3?

Soy un promovedor del uso de Spring pero por X motivo estoy estudiando un poco JEE 5 y la verdad estoy sorprendido por su simpleza, cambio mucho. Lo único que critico es que el tiempo de levantar jboss o glassfish o otro servidor JEE es mayor que usar solo tomcat o jetty (obviamente).

La especificación EJB 3 deja atrás el mal sabor que tenían las anteriores versiones de EJB a la hora de desarrollar. El paso más importante ahora los EJB son pojos, que por medio de anotaciones se infiere el comportamiento. No es necesario heredar de ningún objeto, ni hacer interfaces (gracias a Dios).

Veamos los tipos de beans que existen:

Session EJB: Son los beans que tienen las acciones; son los que tienen la lógica del negocio. Este tipo de bean viene en 2 sabores Stateless (no mantiene el estado en el servidor) o Statefull (mantiene el estado en el servidor). Además se agrego un Sigleton Beans, para cuando necesitamos solo una instancia de nuestro objeto de negocio.

Message-Driven Beans: La mensajería asíncrona es un paradigma en el cual dos o más aplicaciones se se comunican mediante un mensaje que describe un evento de negocio. Estos beans pueden generar mensajes asíncronos y consumirlos.

Entity Beans: Son objetos que modelan nuestros datos (Pojos) y son persistidos por medio del javax.persistence.EntityManager. Usando JPA (descripto en JSR-317) podemos persistir nuestros entity beans como si usáramos un ORM común.

Este es un pequeño resumen de la que nos brinda EJB 3. En próximos post ampliaremos!!