Overview
Session beans are a key technology within the J2EE platform because they allow business functionality to be developed and then deployed independently of the presentational layer.
For example, you might create an application with a user interface built using Java's Swing API. This application might then provide access to some business functionality for the employees working on the company's internal network.
If the underlying business functionality is implemented as Session beans, a different user interface could take its place without having to redevelop the entire application. A Web-based interface would make the application available from the Internet at a single stroke.
There are two types of Session beans, and a couple of analogies help explain the differences between them. You almost certainly will have used the so-called wizards—helpers to guide you through some task—in any modern word-processing program or IDE. A wizard encapsulates a conversation between you the user and the application running on the computer. The steps in that conversation are dictated by the Next and the Back buttons. The wizard remembers the answers from one page, and these sometimes dictate the choices for the next. When you are done, you select the Finish button and the wizard goes away and does its stuff.
The wizard is analogous to a stateful Session bean. The wizard remembers the answers from each page, or put another way, it remembers the state of the conversation. It also provides some service, as characterized by the Finish button. This is precisely what a stateful session bean does.
Here is another analogy, this time with databases. You may well have had cause to write stored procedures. These are named routines (methods and functions) that are written in a database vendor's version of the SQL language (for example, PL/SQL for Oracle and Transact-SQL for Microsoft SQL Server) and stored in the database. They provide a way to implement business rules on the database.
To invoke a stored procedure, a client-side application needs to know just the name of the stored procedure and the parameters it requires. No knowledge of the underlying database schema is needed, so to call a stored procedure called find_jobs_by_ advertiser written in Transact-SQL, the client would use the following:
exec find_jobs_by_advertiser "winston"
Behind the scenes, this would probably run a query against the Job table, but the important thing is that the client does not need to know this detail.
A stored procedure is analogous to a stateless Session bean. The stored procedure just provides a service and can be invoked by any client. You may be wondering why have Session beans at all if stored procedures—which are a tried-and-trusted technology—already solve the problem. But Session beans do have a number of advantages. Implementing stateful conversations is cumbersome using stored procedures, but trivial with Session beans. Also, stored procedures are written in some database vendor's proprietary dialect of SQL, so they are not portable across RDBMS. Session beans are, of course, written in Java, so they will be portable across any compliant EJB container.
Session beans provide a service to a client application. In other words, Session beans are an extension of a client's business functionality into the middle tier.
Note
The Unified Modeling Language offers a number of useful diagrams to help specify an application, one of which is the use case diagram (see Appendix A, “An Introduction to UML,” found on the CD-ROM accompanying this book, for further details).
Each use case represents an item of business functionality that is required to fulfill an end-user's goal. However, while use case diagrams indicate the system boundary of the application being developed, the use cases themselves typically say nothing about the actual look-and-feel of the system. In other words, the presentational layer or user interface is not directly specified.
It is quite possible to directly relate UML use cases to Session beans. A given use case specifies an item of business functionality, while the Session bean implements that functionality. Neither are concerned with the detail of how that functionality is presented to the user.
This direct correspondence of the logical design (as characterized here in UML use cases) to the physical implementation (in this case, Session beans) is one of the reasons that the J2EE platform is so appealing, quickly allowing designs to be realized into working code.