Gavin King is writing a sneak peek of Web Beans, a JSR based on JBoss Seam. Topics covered so far:
quick introductions,
binding annotations and component types, declaring components via XML, and scopes, contexts, and resolver messages (as Web Beans adds a conversational scope to the application, session, and request scopes provided through JSF.)
Some relevant extracts from "
Introducing Web Beans:"
A Web Bean is an application component containing business logic. A Web Bean may be called directly from Java code, or it may be invoked via Unified EL. A Web Bean may access transactional resources. Dependencies between Web Beans are managed automatically by the Web Beans container. Most Web Beans are stateful and contextual. The lifecycle of a Web Bean is always managed by the container.
What does it mean to be contextual? Since Web Beans may be stateful, it matters which bean instance I have. Unlike a stateless component model (for example, stateless session beans) or a singleton component model (such as servlets), different clients of a component see the component in different states. The client-visible state depends upon which instance of the component the client has a reference to.
One great advantage of the contextual model is that it allows stateful components to be treated like services! The client need not concern itself with managing the lifecycle of the component it is using, nor does it even need to know what that lifecyle is. Components interact by passing messages, and the component implementations define the lifecycle of their own state.
...a Web Beans developer may define some kind of stereotype as an annotation, for example @Mock, @Staging or @AustralianTaxLaw that allows whole sets of components to be conditionally installed in particular deployments of the system.
From
Injection, binding annotations and component types:
f we have more than one component that implements a particular API type, the injection point can specify exactly which component should be injected using a binding annotation. For example, there might be two implementations of PaymentProcessor:@Component @PayByCheque
public class ChequePaymentProcessor implements PaymentProcessor {
public void process(Payment payment) { ... }
}
@Component @PayByCreditCard
public class CreditCardPaymentProcessor implements PaymentProcessor {
public void process(Payment payment) { ... }
}A client component developer uses the binding annotation to specify exactly which component should be injected:@In @PayByCheque PaymentProcessor chequePaymentProcessor;
@In @PayByCreditCard PaymentProcessor creditCardPaymentProcessor;Equivalently, using constructor injection:public Checkout(@PayByCheque PaymentProcessor chequePaymentProcessor,
@PayByCreditCard PaymentProcessor creditCardPaymentProcessor) {
this.chequePaymentProcessor = chequePaymentProcessor;
this.creditCardPaymentProcessor = creditCardPaymentProcessor;
}
The third part, called "
Declaring components using XML," discusses how to wire components through XML, which would be required if components are provided from an external library that presumably wouldn't know about the Web Beans annotations (or the specific business requirements for a given application.)
The most recent post, "
Scopes, contexts and resolver methods," describes the four contextual scopes (application, session, request, and conversation), as well as a dependent "psuedo-scope" where the scope of a component is inherited from other components into which it's injected (i.e., component "A" is conversationally-scoped, and component "B" is declared as being in the dependent scope and injected into "A;" it will be conversationally scoped because it's dependent on "A.")
A resolver method allows a developer to hook into the injection mechanism to offer run-time polymorphism.
It's an interesting series. Web Beans is a JSR (
JSR-299) and this is an excellent overview of some of its capabilities.
