Gavin King's four-part (so far) "Web Beans Sneak Peek"


News: Gavin King's four-part (so far) "Web Beans Sneak Peek"

  1. 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.

    Threaded Messages (4)

  2. WebBeans? Dumb Name![ Go to top ]

    Maybe all the good names have been taken, but it seems easily confused with the open source NetBeans project which has been around for a decade. I think it reduce confusion if you chose another name.
  3. I hope Spring Webflow will support this nascent standard too.
  4. Web Beans in Java SE[ Go to top ]

    So far, I've had many comments on the blog articles requesting that this spec encompass Java SE use-cases such as Swing applications. This is definitely something we're looking for feedback on, please let us know if this is something you believe Web Beans should consider.
  5. Support for Non-Web Applications[ Go to top ]

    During the last years everbody seemed to associate J2EE (or Java EE) with web applications. I suppose, there are a lot of us creating inhouse applications based on a Java GUI and an application server as middleware. So I always thought that component specs for JavaEE should include non web apps. There should support for configurable binding of Java UI elements with serversided transactional components. Therefore, in my humble opinion, "Web Beans" should only be part of a wider solution.