The session Bean also has the home and remote interface, plus an implementation class. It can also provide local interfaces, although they are not discussed here.We will create a session Bean that will interact with our CompactDisc entity Bean, allowing users to interact with the data from the CompactDisc entity Bean, but without interacting with the entity Bean directly.The application could easily be extended to include the data from the other tables in the database as well.The session Bean will be implemented as a stateless session Bean, and will be called CompactDiscAccess.
The Session Bean Home Interface
The home interface for the session Bean is relatively straightforward, as you can see from Listing below.Listing CompactDiscAccessHome.java
Only a create method is found in here, and it is used by clients to create instances of the session Bean so that it can be used.There is no concept of a finder method in session Beans because they do not represent any data.
The Session Bean Remote Interface
The remote interface contains the business methods of the EJB.This is shown in Listing below.
The business methods are all there to interact with products. As it stands, they are all compact discs, but it could be extended to include the other data types. If you look carefully, you will notice that the methods return either collections, or a type you have not yet seen, the CompactDiscProduct.This is our regular JavaBean type, which instances will be used to contain the data from the entity Bean, so they can be passed across to the Web application as serialized objects, thus reducing the remote method calling overhead.CompactDiscProduct can be seen in Listing beow . It is very similar to the CompactDisc Bean class used in the shopping-cart demonstration sites from Topics “Session Tracking Using JSP,” and , “Databases and JSP.”
Remember, the class shown in Listing above is a regular JavaBean class, which will be used as a serialized Bean to get our entity Bean data to the Web application.
The Session Bean Implementation
The implementation class for the session Bean is fairly complex. Unlike the entity Bean where the container essentially does it all, with a session Bean, you do have to write your own business logic.That is one thing the container cannot do! The implementation is shown in Listing below Some of the methods have been omitted for brevity, but the version on the book Web site has the whole thing.
There are three methods of special note in Listing above:n locateCDHomeInterface() —First we’ll explain the private method,locateCDHomeInterface().This utility method is used by the session Bean to locate the home interface of the entity Bean. It needs this so it can perform the appropriate finder methods on the entity Beans. Notice that it uses the same mechanism.
It uses JNDI to do the lookup, and then the PortableRemoteObject.narrow() method to do the cast. n searchCatalog() —The searchCatalog() method is our business method; it looks through both the titles and the artist names to see if they correspond. In the example, it is a basic String comparison, but obviously this could be extended to be checking Strings that contain values, and also, if we had other entity Beans, it could check through those as well. Notice that when it adds items to the LinkedList, it uses a further private utility method, convertBean().
n convertBean() —This utility method is crucial to the performance of our application. Here, entity Beans returned by our search are converted into CompactDiscProduct instances.These are then added to the List, which can be serialized and sent back to the client Web application. The final list of methods in the implementation are the lifecycle methods.They are very similar to the lifecycle methods of the entity Bean.
The Session Bean Lifecycle
The lifecycle of a stateless session Bean can be seen in Figure below. The lifecycle of a stateless session Bean is fairly straightforward, simply because these Beans are not tied to any particular client, so the EJB container can pool them.When a container requires additional Beans to be placed within the pool, it invokes the no argument constructor on the Bean, sets the session context which can be used by the business methods if required, and it then calls the ejbCreate() method.The Bean is now ready to accept client method calls. When the container no longer requires the Bean to be in the pool, it will remove it by invoking the ejbRemove() method. Remember, with stateless session Beans, any client can access any Bean from the pool each time they use a stateless session Bean. Stateful session Beans, however, are more complex.The lifecycle for a stateful session Bean is shown in Figure .
The stateless session Bean lifecycle.
The stateful session Bean lifecycle.
The core difference is that the session Bean can now be passivated. Because stateful session Beans are not pooled, and because each client has their own instance of the session bean, there could potentially be a lot of resources taken up by these stateful session Beans whose clients are hardly ever using them.Therefore, the processes of passivation and activation discussed earlier in relation to entity Beans are employed here.
Deploying a Session Bean
To deploy a session Bean, the ejb-jar.xml file has some additional content. For WebLogic, additional content also needs to be added to weblogic-ejb-jar.xml. Because the session Bean will be used by our Web application, a modification will also need to be made here. Listings below show these three deployment descriptors.
Most of this should be self explanatory, and you have seen most of it before as well, except for the entity Bean. Notice that the session Bean deployment information contains a link to the entity Bean via an <ejb-ref> element.You have seen that before, in web.xml, where it was used to provide a JNDI lookup name for the JSP to locate the entity Bean. Here it is used to provide the JNDI lookup name for the entity Bean that the session Bean can use.You can see the lookup name in use in the private method of the session Bean. The additional content in weblogic-ejb-jar.xml can be seen in Listing below.
Finally, web.xml needs to be modified so that the Web application can access the session Bean.This can be seen in Listing below.
Listing web.xml (for session bean)
As you can see, session Beans are very similar to entity Beans as far as the deployment process goes.We will finish this section with a JSP that interacts with the session Bean to complete a search using the searchCatalog() method defined in the session Bean; see Listing below .We have not used tags or beans so you can clearly see what is going on in the Java code.
There should be no surprises within Listing 15.17. It is accessing the session Bean, which then completes the search, and returns references to serialized JavaBeans of type CompactDiscProduct to the client; the client can then iterate through them and display them on the page.
JSP Related Interview Questions
|J2EE Interview Questions||Core Java Interview Questions|
|JDBC Interview Questions||Java Servlets Interview Questions|
|Hibernate Interview Questions||JavaServer Faces (JSF) Interview Questions|
|JSTL(JSP Standard Tag Library) Interview Questions||JBOSS Interview Questions|
|Log4j Interview Questions||NHibernate Interview Questions|
|Apache Struts 2 Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.