A session bean works for a client and may either be invoked by local clients collocated in the same JVM or by a remote client outside the JVM. In this section we first discuss how a client accesses a session bean and then see how the @EJB annotation is used to inject session bean references.
Almost any Java component can be a session bean client. POJOs, servlets, JSPs, or other EJBs can access session beans. In fact, stateless session beans exposed through web services endpoints can even be accessed by non-Java clients such as .NET applications. However, in this section we concentrate on clients that access session beans either locally or remotely through RMI. In topic 15 you’ll see how EJB web service clients look.
Fortunately, in EJB 3 accessing a remote or local session bean looks exactly the same. As a matter of fact, other than method invocation patterns, stateless and stateful session beans pretty much look alike from a client’s perspective too. In all of these cases, a session bean client follows these general steps to use a session bean:
1 The client obtains a reference to the beans directly or indirectly from JNDI.
2 All session bean invocations are made through an interface appropriate for the access type.
3 The client makes as many method calls as are necessary to complete the business task at hand.
4 In case of a stateful session bean, the last client invocation should be a remove method.
To keep things as simple as possible, let’s explore a client that uses the BidManagerBean stateless session bean to add a bid to the ActionBazaar site. We’ll leave it as an exercise for you to extend the client code to use the BidderAccountCreator-Bean stateful session bean. For starters, let’s see how the code to use the BidManagerBean from another EJB might look:
This code uses dependency injection through the @javax.ejb.EJB annotation to obtain a reference to the BidManagerBean. This is by far the easiest method of procuring a reference to a session bean. Depending on your client environment, you might have to use one of the two other options available for obtaining EJB references: using EJB context lookup or using JNDI lookup. Since neither of these options is used often in real life, we’ll focus on DI for right now.
Using the @EJB annotation
Recall from our discussion on DI in topic 2 that the @EJB annotation is specifically intended for injecting session beans into client code. Also recall that since injection is only possible within managed environments, this annotation only works inside another EJB, in code running inside an application-client container (ACC), or in components registered with the web container (such as a servlet or JSF backing bean). However, some application servers will support injection of EJB references into POJOs as a vendor-specific extension. Here is the specification for the @EJB annotation:
All three of the parameters for the @EJB annotation are optional. The name element suggests the JNDI name that is used to bind the injected EJB in the environment-naming context. The beanInterface specifies the business interface to be used to access the EJB. The beanName element allows us to distinguish among EJBs if multiple EJBs implement the same business interface. In our GoldBidManagerBean code, we chose to use the remote interface of the BidManagerBean. If we want to use the local interface of the BidManagerBean EJB instead, we can use the following:
We have not specified the name parameter for the @EJB annotation in this code and the JNDI name is derived from the interface name (BidManagerLocal in our case). If we want to inject an EJB bound to a different JNDI name, we can use the @EJB annotation as follows:
Injection and stateful session beans
For the most part, using DI is a no-brainer. There are a few nuances to keep an eye on while using DI with stateful beans, though. You can inject a stateful session into another stateful session bean instance if you need to. For example, you can inject the BidderAccountCreator stateful EJB from UserAccountRegistration EJB that is another stateful session bean as follows:
This code will create an instance of BidderAccountCreatorBean which will be specifically meant for the client accessing the instance of the UserAccount-RegistrationBean. If the client removes the instance of UserAccountRegistra-tionBean, the associated instance of BidderAccountCreatorBean will also be automatically removed.
Keep in mind that you must not inject a stateful session bean into a stateless object, such as a stateless session bean or servlet that may be shared by multiple concurrent clients (you should use JNDI in such cases instead). However, injecting an instance of a stateless session bean into a stateful session bean is perfectly legal. Topic 12 discusses in much greater detail how you can use EJB from other tiers.
This concludes our brief discussion on accessing session beans. Next, we’ll briefly explore potential performance issues of stateful session beans.
