Java Reference
In-Depth Information
public @interface Stateless {
public String name() default "";
public String mappedName() default "";
public String description() default "";
}
As you can see, the stateful annotation matches the stateless annotation verbatim. The
name parameter specifies the name of the bean. In listing 3.2 , the bean name is specified to
be BidderAccountCreator . As the annotation definition shows, the name parameter
is optional and defaults to an empty string. You could easily omit it as follows:
@Stateful
public class DefaultBidderAccountCreator implements BidderAccountCreator {
If the name parameter is omitted, the container assigns the name of the class to the bean. In
this case, the container assumes the bean name is DefaultBidderAccountCreator .
The mappedName field is a vendor-specific name that you can assign to your EJBs; some
containers, such as GlassFish, use this name to assign the global JNDI name for the EJB.
For the most part, this is how a legacy field with EJB names is standardized in Java EE
6 (we'll discuss EJB names in chapter 5 ) . As we noted, the DefaultBidderAccoun-
tCreator implements a business interface name of BidderAccountCreator . Let's
look at the business interfaces for stateful session beans and the limitations as compared to
stateless session beans.
3.3.6. Bean business interfaces
Specifying stateful session bean business interfaces works in almost exactly the same way
as it does for stateless beans, with a couple of exceptions. Stateful session beans support
local and remote invocations through the @Local and @Remote annotations. But a state-
ful session bean can't have a web service endpoint interface. This means that a stateful
session bean can't be exposed using JAX-RS or JAX-WS. This is because web service in-
terfaces are inherently stateless in nature.
A business interface should always include a @Remove annotated method. Multiple meth-
ods can have this annotation. This annotation signals that the client has finished with the
bean. In the next sections we'll dive into the lifecycle, and the reason for always providing
a @Remove method will become clear.
Search WWH ::




Custom Search