Concepts

Understanding the following concepts will help you work through the tutorials in the FBS series:

• About the FBS
• About EJB

About the FBS

The FBS simulates an online brokerage where users can trade stocks, read financial news, and manage their portfolios. The FBS supports the following user roles: Individual User, Corporate User, and FBS Administrator.

The Individual User represents the end-user of the FBS. After registering, an individual user can login and

• View a personalized home page featuring financial news and stock quotes for a customizable list of ticker symbols.
• Set up preferences and alert settings. For example, a user may request an alert when a stock price goes above or below a specified value.
• Edit profile information.
• View portfolios and transaction history.
• Trade stocks. In this sample application, all trades are simulated. Each FBS instance is in effect a miniature stock exchange. Each FBS maintains a database of stock symbols representing the stocks that can be traded on the particular FBS. When a user buys or sells a stock, the order is sent to the current FBS as a simple message. If the specified stock is not traded in that FBS, the system automatically forwards the order to another FBS.

A Corporate User can set up ESOP (Employee Stock Option Plan) accounts for employees. After a Corporate User sets up ESOP accounts, the FBS notifies the employees via email. Henceforth, employees can use the accounts to manage their assets as Individual Users.

The FBS Administrator maintains two tables: one for stock data and financial news, and one that stores ticker symbols. The FBS Administrator can set up a job to upload stock data and news at specified intervals. The FBS Administrator can manually enter ticker symbols for stocks that can be traded from one particular FBS. The FBS download includes a sample administrator account (account: 1, password: welcome).

About EJB

Developed by Sun Microsystems, Oracle and other vendors, the EJB (Enterprise JavaBean) specification defines an architecture for building applications from server-side components called enterprise beans or EJBs.

Simply put, a software component is a reusable object or group of objects (more precisely, an object graph) not bound to a particular program or application. Any number of applications or processes can use a given component, and multiple instances can be in use at the same time. As such, components offer developers numerous benefits. By building applications with components, you can:

• Improve design by modeling real-world entities.
• Improve developer productivity. Each piece of an application (for example, data model, business logic, and user interface) can be built by a specialist.
• Reuse business logic. Write once, deploy anywhere.
• Simplify deployment.
• Distribute logic and functionality.

• Reduced client-side processing load.
• Fewer network round-trips.
• Clean separation of business logic and presentation logic, interfaces and implementation.
• Easy maintenance: when you deploy an updated component to a server, clients everywhere gain immediate access.

EJBs run in a framework called a container using services provided by a server. A container provides runtime services including life-cycle management and support for persistence, security, and transactions. Each EJB container resides in an EJB server that handles non-application details including process management, logging, security, load balancing, and fail over.

You can distribute EJBs over a network of servers—the physical location of an EJB is transparent to clients—and you can add servers to balance the load as needed. EJBs communicate with each other using the Java Remote Method Invocation (RMI) over the CORBA Internet Inter-ORB Protocol (IIOP), a standard for communication between and among distributed objects running on the Internet, intranets, and in enterprise computing environments.

EJB Types

Version 2 of the EJB specification defines the following EJB types:

• Session Bean
• Entity Bean
• Message-Driven Bean

Session Bean

A session bean is created by a client and exists only for the duration of a single session. A session bean is a private resource that performs operations on behalf of the client such as reading, writing, or updating a database; however, session beans do not represent data to be stored in a database. Session beans can also be transactional, but, because they are not persistent, they cannot be recovered after a system crash.

Session beans can be stateless or can maintain conversational state across methods and transactions. The state describes the conversation between a session bean and its client. The EJB container manages this conversational state of a session bean and destroys the session bean when it is no longer needed.

Entity Bean

An entity bean represents persistent data in a database, as well as methods that act on that data. In a relational database context, one bean exists for each row in a table, and each bean is identified by a unique primary key.

An entity bean can manage its own persistence or have its container manage it. In general, the life cycle of an entity bean is not limited by the life cycle of the virtual machine in which it executes. If the virtual machine crashes, or the database rolls back the current transaction, the entity bean and its references from other clients are not destroyed. Later, a client can reconnect to the same entity bean using its object reference and primary key or when its container reloads its state.

Message-Driven Bean

A message-driven bean (MDB) processes messages sent by clients, other EJBs, or any other J2EE component. An MDB is similar to an event listener, except that it processes Java Messaging Service (JMS) messages instead of events. A typical MDB receives messages from a queue, parses out any requests, then invokes session beans or entity beans as appropriate to respond to the requests.

EJB Elements

EJBs have certain elements in common, including:

• Indirect access mechanism
• Bean implementation
• Deployment descriptor

Indirect Access Mechanism

Clients don't invoke EJB methods directly. In fact, with MDBs, clients don't invoke methods at all. Instead, they place messages in a queue for the MDB to process. Session and entity beans enable access to their operations via interfaces, constructs that list the signatures of available methods.

The home interface (also called a factory interface) defines a set of methods that manage the life cycle of a bean. Corresponding server-side implementation classes are generated at deployment time. 

To provide access to other operations, a bean can expose a local interface or a remote interface (most beans expose one or the other, although it's possible to expose both). Local interfaces expose methods to clients running in the same container or JVM. Remote interfaces make bean methods available to clients no matter where they are deployed. Defined in the first EJB specification, remote interfaces are general and flexible, but incur a certain amount of overhead (for example, in network traffic). Local interfaces were defined in version 2 of the EJB specification to improve performance in the specific scenario where client and bean are colocated. Local interfaces are discussed in more detail in Using EJB Local Interfaces.

The figure below shows how various elements interact when a client creates an EJB instance and calls methods through an interface. When a client invokes create (which returns an interface) on the Home Interface, the EJB Container calls ejbCreate to instantiate the bean. Then the client can access the bean through the remote or local interface returned by create.

Bean Implementation

The bean implementation is a Java class that implements the business logic defined in the remote interface. Transactional semantics are described declaratively and captured in the deployment descriptor. Beans access persistent state via JDBC or SQLJ.  

Deployment Descriptor

The deployment descriptor lists a bean's properties and elements, which may include:

• Home and remote interfaces
• Bean implementation class
• JNDI name for the bean
• Transaction attributes
• Security attributes
• Per-method descriptors

Sun released the EJB 2.0 specification Final Proposed Draft #2 in April of 2001, and a final proposed draft of version 2.1 was released in August of 2002. OTN developers built the FBS sample application to demonstrate key new features defined in these specifications.