Mit bestimmten, ganz besonderen Ausnahmen ist jede Java-Klasse mit einem Konstruktor, die keine Parameter akzeptiert ein Web Bean. Das beinhaltet jedes JavaBean. Desweiteren ist jedes EJB 3-artige Session Bean ein Web Bean. Sicher, die von Ihnen täglich geschriebenen JavaBeans und EJBs konnten die neuen, in der Web Beans Spezifikation definierten Dienste nicht nutzen, aber Sie werden diese allesamt benutzen können können, das Web Beans — diese in andere Web Beans einspeisen, diese via der Web Beans XML-Konfigurationseinrichtung konfigurieren und diesen sogar Interzeptoren und Dekoratoren hinzufügen, ohne den bestehenden Code anzurühren.

Nehmen wir an, Sie besitzen zwei bestehende Java Klassen, die bis dato in verschiedenen Anwendungen verwendet wurden. Die erste Klasse parst einen String in eine Liste von Sätzen:

public class SentenceParser {

    public List<String

> parse(String text) { ... }

}

Bei der zweiten bestehenden Klasse handelt es sich um das Front-End eines "stateless Session Beans" für ein externes System, das in der Lage ist Sätze von einer Sprache in eine andere zu übersetzen:

@Stateless

public class SentenceTranslator implements Translator {

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

}

Wo Translator das lokale Interface ist:

@Local

public interface Translator {

    public String translate(String sentence);

}

Leider besitzen wir keine bereits bestehende Klasse die ganze Textdokumente übersetzt. Schreiben wir also ein Web Bean, das diesen Job übernimmt:

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();

    }

    

}

Wir erhalten eine Instanz von TextTranslator durch dessen Einspeisung in ein Web Bean, Servlet oder EJB:

@Initializer

public setTextTranslator(TextTranslator textTranslator) {

    this.textTranslator = textTranslator;

}

Alternativ erhalten wir eine Instanz durch direkten Aufruf einer Methode des Web Bean Managers:

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

Aber warten Sie: TextTranslator besitzt keinen Konstruktor ohne Parameter! Handelt es sich noch um ein Web Bean? Nun, eine Klasse, die keinen Konstruktor ohne Parameter besitzt, kann nach wie vor Web Bean sein, falls es einen mit @Initializer annotierten Konstruktor besitzt.

Wie Sie wahrscheinlich bereits erraten haben, hat die @Initializer-Annotation etwas mit Dependency-Einspeisung zu tun! @Initializer kann am Konstruktor oder der Methode eines Web Beans angewendet werden und teilt dem Web Bean Manager mit, diesen Konstruktor oder diese Methode bei Instantiierung des Web Beans aufzurufen. Der Web Bean Manager speist andere Web Beans in die Parameter des Konstruktors oder der Methode ein.

Zum Zeitpunkt der Systeminitialisierung muss der Web Bean Manager validieren, dass genau ein Web Bean existiert, das jedem Einspeisungspunkt gerecht wird. Für unser Beispiel bedeutet das, wenn keine Implementierung von Translator verfügbar ist — wenn der SentenceTranslator EJB nicht deployt wurde — dass der Web Bean Manager eine UnsatisfiedDependencyException melden würde. Wäre mehr als eine Implementierung von Translator verfügbar, so würde der Web Bean Manager eine AmbiguousDependencyException melden.

Was also genau ist ein Web Bean?

Bei einem Web Bean handelt es sich um eine Anwendungsklasse, die Business Logik enthält. Ein Web Bean kann direkt von Java Code oder via Unified EL aufgerufen werden. Ein Web Bean kann auf transaktionale Ressourcen zugreifen. Abhängigkeiten zwischen Web Beans werden automatisch durch den Web Bean Manager verwaltet. Die meisten Web Beans sind stateful und kontextbezogen. Der Lebenszyklus eines Web Beans wird immer durch den Web Bean Manager verwaltet.

Erinnern wir uns. Was genau bedeutet es, "kontextuell" zu sein? Da Web Beans "stateful" sein können, ist es relevant welche Bean-Instanz ich besitze. Anders als ein Komponentenmodell, das "stateless" ist (etwas "stateless" Session Beans) oder ein Singleton Komponentenmodell (wie Servlets oder Singleton Beans), sehen verschiedene Clients eines Web Beans das Web Bean in unterschiedlichen Stati. Der Client-sichtbare Status ist abhängig davon, auf welche Instanz des Web Beans der Client verweist (eine Referenz besitzt).

Wie beim "stateless" oder "singleton" Modell anders jedoch als bei "stateful" Session Beans, steuert der Client den Lebenszyklus der Instanz nicht durch expliziertes Erstellen und Löschen. Stattdessen bestimmt der Geltungsbereich des Web Beans:

Für einen bestimmten Thread in einer Web Beans Anwendung kann ein aktiver Kontext mit dem Geltungsbereich des Web Beans assoziiert sein. Dieser Kontext kann eindeutig für den Thread sein (etwa wenn für die Web Bean Anfrage ein Geltungsbereich gilt) oder aber kann mit anderen Threads (etwa wenn für die Web Bean ein Session-Geltungsbereich gilt) oder gar allen Threads (falls ein Anwendungs-Geltungsbereich gilt) geteilt werden.

Clients (etwa andere Web Beans), die in demselben Kontext ausführen sehen dieselbe Instanz des Web Beans. Clients in einem anderen Kontext aber sehen eine andere Instanz.

Ein großer Vorteil des kontextuellen Modells ist es, dass es uns gestattet, stateful Web Beans wie Dienste zu behandeln! Der Client muss sich keine Gedanken um das Management des Lebenszyklus des verwendeten Web Beans machen und muss nicht einmal wissen was der Lebenszyklus ist. Web Beans interagieren durch Weitergabe von Nachrichten und die Web Bean Implementierungen definieren den Lebenszyklus ihres eigenen Status. Die Web Beans sind lose gepaart, weil:

Wir können ein Web Bean durch ein anderes Web Bean ersetzen, das dasselbe API und einen anderen Lebenszyklus (einen anderen Geltungsbereich) besitzt, ohne dass die übrige Web Bean Implementierung hiervon betroffen ist. Genau genommen definieren Web Beans eine raffinierte Einrichtung zur Außerkraftsetzung von Web Bean Implementierungen zum Zeitpunkt des Deployment wie wir in Abschnitt 4.2, „Deployment Typen“ noch sehen werden.

Beachten Sie, dass es sich nicht bei allen Clients eines Web Beans um Web Beans handelt. Andere Objekte wie Servlets oder Message-Driven Beans — die ihrem Wesen nach nicht einspeisbar sind, kontextuelle Objekte — können durch Einspeisung ebenfalls Verweise auf ein Web Beans erhalten.

Formeller gilt, gemäß der Spezifikation:

Sehen wir uns jetzt genauer an, was diese Begriffe für einen Entwickler von Web Beans bedeuten.

@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 { ... }

Wir haben bereits gesehen, dass JavaBeans, EJBs und einige andere Java-Klassen Web Beans sein können. Aber um was für Objekte genau handelt es sich bei 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();

}