Entity Beans Overview
Entity Beans Overview
Java programmers are already familiar with objects. An entity bean is an object with special properties:
It is permanent. Standard Java objects come into existence when they are created in a program. When the program terminates, the object is lost. But an entity bean stays around until it is deleted. A program can create an entity bean, then the program can be stopped and restarted. The entity bean will continue to exist. After being restarted, the program can again find the entity bean it was working with, and continue using the same entity bean.
In practice, entity beans need to be backed up by some kind of permanent storage, typically a database.
It is executed remotely. Methods of an entity bean run on a “server” machine. When you call an entity bean’s method, your program’s thread stops executing and control passes over to the server. When the method returns from the server, the local thread resumes executing.
It is identified by a primary key. Entity Beans must have a primary key. The primary key is unique — each entity bean is uniquely identified by its primary key. For example, an “employee” entity bean may have Social Security numbers as primary keys. You can only use entity beans when your objects have a unique identifier field, or when you can add such a field.
Session beans are different from entity beans in that they are not permanent objects. They are also not shareable in general, though it is possible to share them by using their “handles”.
Session beans can be used to distribute and isloate processing tasks, somewhat analogous to the way each Java class can be used to encapsulate a type of related processing. Each session bean can be used to perform a certain task on behalf of its client. The tasks can be distributed on different machines.
Another way session beans can be thought of, is like how browsers and web-servers operate. A web-server is located in a particular location, but multiple browsers can connect to it and get it to perform services (such as delivering HTML pages) on their behalf. Each server performs a specialized unique task The clients can connect to any of a number of servers, depending upon their needs.
In the same way, each session bean may perform a type of task, at a given remote location. Its clients will be other Java programs (rather than a browser). Its clients will connect to it when they need that type of task done. The tasks will be usually be programmatic and more specific than “give me this HTML page”. An example might be a session bean that performs a specialized calculation that is secret from the clients. The clients do not need to know how to do the calculation, but just need to know the results. The session bean might provide methods for providing the input of the calculation and for getting the result of the calculation. The client just needs to access the session bean and call its methods. Another example may be when the book-keeping needs to be done in a central location. For instance, a bank’s ATM machines may be Java programs that are clients of a session bean running in a central location and that does the book-keeping tasks of maintaining the balance in the account, reducing the amount for each ATM withdrawal and increasing it for each ATM deposit etc.
Session beans do not have a primary key. Unlike entity beans, session beans are not primarily meant to be shared or found later (though they can be.) Therefore two session beans may have the same fields and still be two different objects.
The EJB interfaces
Each EJB provides some interfaces that its clients use to work with the EJB.
The remote interface is the business end of the EJB. This is the set of actual services provides by the EJB.
The home interface is the book-keeping interface. It helps clients create a new instance of an EJB, or to find an existing instance of an EJB. The methods used to find existing EJBs are known as “finder” methods. Since session beans are not designed to be shareable, there are no session bean finder methods.
The home interface doesn’t actually need an implementation! This is because its tasks are straightforward enough that the EJB container can automatically provide the implementation.
The remote interface, however, needs an implementation which is supplied by the EJB program
It is network based. Standard Java objects are used only by one program.