llamar un ejb desde un jsp

bueno llamar un ejb desde un servlet es sumamente facil y es una
de las facilidades que nos proporciona la version ejb 3 , pero desde
un jsp no es lo mismo puesto que hay que llamarlo mediante JNDI
(igual no es complicado)

primero vamos a crear nuestro ejb.


package ejb;

import javax.ejb.Remote;

@Remote
public interface saludoRemote {

public String saludo();
}

------------------------------------

package ejb;

import javax.ejb.Stateless;

@Stateless(name="saludoRemote")
public class saludoBean implements saludoRemote {

public String saludo() {

return "hola desde ejb";
}
}

asi nos queda el proyecto

ahora vamos a nuestro proyecto web



bueno desde un servlet solamente tenemos que llamarlo mediante
la opcion del boton derecho insert code->call enterprise bean
y seleccionamos nuestro ejb y nos genera el siguiente codigo

@EJB
private saludoRemote saludoBean;

el @EJB nos ahorra utilizar jndi, ademas este llamado tiene
que ser afuera de cualquier metodo de la clase servlet.

otra observacion que encontre en la red es la implementacion
distinta en el servidor glassfish y JBoss en el momento de ocupar
lookup en distintos servidores.

ejemplo: para jboss

Context context = new InitialContext();
HelloWorld helloWorld = (HelloWorld) context.lookup("HelloWorldBean/remote");

ejemplo: para glassfish

Context context = new InitialContext();
HelloWorld helloWorld = (HelloWorld) context.lookup(HelloWorld.class.getName());

Struts 1.x y Struts 2.x

los cambios que podemos encontrar entre estas dos
versiones son muy importantes, como primera impresion
puede decir que no es la misma. Las principales diferencias
son :


Dependencia del Servlet :

Las acciones en Struts1 tienen dependencias con el servlet
( HttpServletRequest y HttpServletResponse) estos objetos
se pasan al método de ejecución, en Struts 2, "Acciones no son
dependientes de contenedores porque están hechos POJOs simple.
En Struts 2, los contextos de servlets son representados como
mapas sencillos, tambien las acciones se puede acceder a la
solicitud original.

Acction class

Se soluciono el problema de las clases abstractas en Struts 2, en
Struts1 la clase de accion necesita ampliar el marco puesto que
depende de la clase base abstracta. Pero en el caso de Struts 2,
la clase de acción puede implementar interfaces
En el caso de Struts 2, "Acciones no son dependientes de contenedores
porque están hechos POJOs simple. Struts 2 proporciona una
clase ActionSupport base para implementar interfaces de uso común.
Si bien, la interfaz de acción no es necesario. Cualquier objeto POJO
con una ejecución de la firma puede ser utilizado como un
objeto de 2 Struts Acción.

Validación

En las dos versiones podemos hacer validaciones manuales, en
Struts1 se utiliza el método de la ActionForm, o valida a través
de una ampliación de la Validator Commons. Sin embargo, Struts 2,
Se utuliza el marco de validación XWork. El marco de validación Xwork
apoya el encadenamiento de validación.

Modelo de subprocesos

En Struts1, los recursos de acción deben ser flujos seguros o sincronizada.
Lo que las acciones son únicos y multi-hilo, El patron de diseño Singleton se
impone, en caso de Struts 2, los objetos se crean instancias de acción para
cada solicitud, así que no hay hilo( esto genera menos impacto)

Comprobabilidad

Prueba de aplicaciones Struts1 son un poco complejo, pero Struts 2
Las acciones pueden ser probados.

recolección de entrada

Struts1 utiliza un objeto ActionForm para captar de entrada.
Y todos ActionForms necesita extender un marco de base
dependientes de clase. JavaBeans no puede ser utilizado como
ActionForms, por lo que los desarrolladores tienen que crear
clases redundantes para captar de entrada.
Sin embargo Struts 2 utiliza las propiedades de acción (como las
propiedades de entrada independiente de la estructura subyacente)
que elimina la necesidad de un objeto, por lo tanto reduce la
redundancia.

Además, en struts2, las propiedades de acción se puede acceder desde
la página web a través de la taglibs. Struts 2 también soporta el patrón
ActionForm, así como objetos de formulario POJO y Acciones POJO.


bueno existen mas diferencias pero considero que estas son las mas
importantes , despues cuando me maneje mas y encuentre que falta otro
modificare estos puntos.

Proyecto Strust en Netbeans

Para empezar a desarrollar en Struts, primero tenemos que
empezar con los conceptos basicos.

1.- primero vamos a crear nuestro proyecto en netbeans

En esta ultima ventana encontramos lo siguiente:

Action Servlet name : Aqui encontramos el descriptor de
despliegue web.xml, contiene una entrada para el servlet de
acción y especifica el Struts y sus parámetros específicos,
como la ruta de acceso a la clase servlet dentro de la biblioteca
Struts y el struts-config.xml de configuración.

Action Url Pattern : Especifica los patrones de las solicitudes
de entrada que se asignan a la controladora de acciones de Struts

Aplication Resource: Especifica los paquetes que seran utilizados
por struts-config.xml

Add struts TLDs: Le permite generar descriptores de
biblioteca de etiquetas, Un descriptor de biblioteca de etiquetas es
un documento XML que contiene información adicional.

bueno ahora generado el proyecto encontramos lo siguiente:


aqui podemos ver que tenemos el archivo config-struts.xml , este
archivo es donde vamos a guardar nuestras configuraciones, con un
un formato xml, aqui podemos confgurar el action-mappings, form-beans
y muchas cosas mas.

Este archivo de configuracion es el cordinador de nuestro proyecto.

tambien podemos ver el archivo : ApplicationResource.propierties,
este archivo vamos a guardar propiedades que seran llamadas
mediente la implementacion de nuestro proyecto, ej:

errors.usuario= La variable usuario ingresada no corresponde.

bueno existen mas archivos y los podemos apreciar, pero solamente
estamos empezando.

Otro proceso muy importante en el desarrollo de nuestro proyecto
es crear los ActionFormbeans y los Action estos lo podemos encontrar
aqui:


Para finalizar y entender mejor este framework, podemos apreciar
en la siguiente figura como es el comportamiento de nuestro
futuro proyecto.