Con determinadas excepciones, muy especiales, toda clase de Java con un constructor que no acepte parámetros es un Web Bean. Esto incluye cada JavaBean. Además, cada sesión estilo EJB 3 es un Web Bean. Por supuesto, los JavaBeans y EJB que usted ha escrito a diario no han podido aprovechar los nuevos servicios definidos por la especificación de Web Beans, pero podrá utilizar cada uno de ellos como Web Beans — inyectándolos en otros Web Beans, configurándolos a través de los servicios de configuración, incluso agregándoles interceptores y decoradores — sin tocar su código existente.

Suponga que tenemos dos clases existentes de Java, las cuales hemos estado utilizando por años en varias aplicaciones. La primera clase analiza una cadena en un lista de oraciones:

public class SentenceParser {

    public List<String

> parse(String text) { ... }

}

La segunda clase existente es un bean de front-end sin estado de sesión capaz de traducir oraciones de un idioma a otro:

@Stateless

public class SentenceTranslator implements Translator {

    public String translate(String sentence) { ... }

}

Donde Translator es la interfaz local:

@Local

public interface Translator {

    public String translate(String sentence);

}

Lamentablemente, no tenemos una clase preexistente que traduzca todos los documentos de texto. Entonces, escribamos un Web Bean que realice esta tarea:

public class TextTranslator {

    

    private SentenceParser sentenceParser;

    private Translator sentenceTranslator;

    

    @Initializer

    TextTranslator(SentenceParser sentenceParser, Translator sentenceTranslator) {

        this.sentenceParser = sentenceParser;

        this.sentenceTranslator = sentenceTranslator;

    }

    

    public String translate(String text) {

        StringBuilder sb = new StringBuilder();

        for (String sentence: sentenceParser.parse(text)) {

            sb.append(sentenceTranslator.translate(sentence));

        }

        return sb.toString();

    }

    

}

Podemos obtener una instancia de TextTranslator inyectándola en una Web Bean, Servlet o EJB:

@Initializer

public setTextTranslator(TextTranslator textTranslator) {

    this.textTranslator = textTranslator;

}

De modo alterno, podemos obtener una instancia llamando directamente un método del administrador de Web Bean:

TextTranslator tt = manager.getInstanceByType(TextTranslator.class);

Pero espere: ¡TextTranslator no tiene un constructor sin parámetros! ¿Es éste aún un Web Bean? Bueno, una clase que no tiene un constructor sin parámetros aún puede ser un Web Bean si tiene un constructor anotado @Initializer.

Como pudo adivinar, la anotación @Initializer tiene algo que ver con la ¡inyección de dependencia! @Initializer puede aplicarse a un constructor o método de un Web Bean, y pide a un administrador de Bean llamar a ese constructor o método cuando inicia el Web Bean. El administrador de Web Bean inyectará otros Web Beans a los parámetros del constructor o método.

En el momento de inicialización, el administrador de Web Bean debe confirmar que exista exactamente un Web Bean que complete cada punto de inyección. En nuestro ejemplo, si no estaba disponible ninguna implementación de Translator — si el EJB de SentenceTranslator no estaba desplegado — el administrador de Web Bean produciría una UnsatisfiedDependencyException. Si más de una implementación de Translator estuviera disponible, el administrador de Web Bean produciría una AmbiguousDependencyException.

Entonces, ¿qué es, exactamente un Web Bean?

Un Web Bean es una clase de aplicación que contiene lógica de negocios. Un Web Bean puede llamarse directamente desde el código de Java, o invocarse a través de Unified EL. Un Web Bean puede acceder recursos transaccionales. Las dependencias entre Web Beans son manejadas automáticamente por el administrador de Web Bean. La mayoría de Web Beans son con estado y contextuales. El ciclo de vida de un Web Bean siempre es manejado por el administrador de Web Bean.

Volvamos atrás por un segundo. ¿Qué significa "contextual"? Puesto que Web Beans puede tener estados, es importante saber qué instancia de bean se tiene. A diferencia de un modelo de componente sin estado (por ejemplo, beans sin estado de sesión) o un modelo de componente singleton (como servlets, o beans singleton), clientes diferentes de un Web Bean ven el Web Bean en estados diferentes. El estado cliente-visible depende de la instancia de Web Bean a la que se refiere el cliente.

No obstante, como un modelo sin estado o un modelo singleton, pero a diferencia de los beans con estado de sesión, el cliente no controla el ciclo de vida de la instancia explícitamente creando y destruyéndolo. En su lugar, el ámbito del Web Bean determina:

Para un subproceso dado en una aplicación de Web Beans, puede haber un contexto activo asociado con el ámbito del Web Bean. Este contexto puede ser único para el subproceso (por ejemplo, si el Web Bean tiene un ámbito de petición), o puede compartirse con algunos subprocesos (por ejemplo, si el Web Bean tiene un ámbito de sesión) o incluso con todos los otros subprocesos (si es el ámbito de la aplicación).

Los clientes (por ejemplo, otros Web Beans) ejecutando en el mismo contexto verán la misma instancia del Web Bean. Pero los clientes en un contexto diferente verán una instancia diferente.

Una gran ventaja del modelo contextual es que permite a los Web Beans con estado ser tratados como ¡servicios! El cliente no necesita preocuparse por manejar el ciclo de vida del Web Bean que está utilizando, ni necesita saber qué ciclo de vida es. Los Web Beans interactúan pasando mensajes, y las implementaciones del Web Bean definen el ciclo de vida de su propio estado. Los Web Beans están en parejas sueltas porque:

Podemos remplazar un Web Bean por un Web Bean diferente que implemente la misma API y tenga un ciclo de vida diferente (un ámbito diferente) sin afectar la otra implementación de Web Bean. De hecho, Web Beans define una facilidad altamente desarrollada para anular las implementaciones de Web Bean en el momento del despliegue, como también ver en Sección 4.2, “Tipos de despliegue”.

Observe que todos los clientes de una Web Bean son Web Beans. Otros objetos tales como Servlets o Message-Driven Beans — los cuales son por naturaleza no inyectables, objetos contextuales — también pueden obtener referencias a Web Beans por inyección.

Más formalmente, de acuerdo con la especificación:

Veamos lo que significan algunos de estos términos, para el desarrollador de Web Bean.

@CreditCard PaymentProcessor paymentProcessor

@CreditCard

public class CreditCardPaymentProcessor 

    implements PaymentProcessor { ... }

@Mock

public class MockSentenceTranslator implements Translator {

    public String translate(String sentence) {

        return "Lorem ipsum dolor sit amet";

    }

}

@SessionScoped

public class ShoppingCart { ... }

@SessionScoped @Named("cart")

public class ShoppingCart { ... }

<h:dataTable value="#{cart.lineItems}" var="item">
    ....
</h:dataTable
>

@SessionScoped @Named

public class ShoppingCart { ... }

@SessionScoped 

@Interceptors(TransactionInterceptor.class)

public class ShoppingCart { ... }

@SessionScoped @Transactional

public class ShoppingCart { ... }

Ya hemos visto que JavaBeans, EJB y algunas otras clases de Java pueden ser Web Beans. Pero, exactamente, ¿qué clase de objetos son los Web Beans?

@Stateful @SessionScoped

public class ShoppingCart {


    ...

    

    @Remove

    public void destroy() {}


}

@ApplicationScoped

public class Generator {


    private Random random = new Random( System.currentTimeMillis() );

    

    @Produces @Random int next() {

        return random.nextInt(100);

    }


}

@Random int randomNumber

@Produces @RequestScoped Connection connect(User user) {

    return createConnection( user.getId(), user.getPassword() );

}

void close(@Disposes Connection connection) {

    connection.close();

}