The home interface defines the methods that enable a client accessing an application to create, find, and remove entity objects. You must create a remote home interface that meets the following requirements:.
All home interfaces automatically by extending javax. EJBHome define two remove methods for destroying an enterprise bean when it is no longer needed:. Object primaryKey throws java. RemoteException, RemoveException. To build an enterprise bean that allows local access, you must code the local interface and the local home interface.
The home interface defines the methods that enable a client using the application to create and remove entity beans. The local home interface is defined by you and implemented by the container. A local home interface always extends javax. For example:. If an entity bean is the target of a container-managed relationship, it must have local interfaces. The direction of the relationship determines whether or not a bean is a target. Because they require local access, entity beans that participate in a container-managed relationship must reside in the same EJB JAR file.
The primary benefit of this locality is improved performance—local calls are faster than remote calls. Since local interfaces follow pass by reference semantics, you must be aware of the potential sharing of objects passed through the local interface.
In particular, be careful that the state of one enterprise bean is not assigned as the state of another. You must also exercise caution in determining which objects to pass across the local interface, particularly in the case where there is a change in transaction or security content. Besides the business methods you define in the remote interface, the EJBObject interface defines several abstract methods that enable you to:.
For more information about these built-in methods and how they are used, see the Enterprise JavaBeans Specification, v2. The Enterprise JavaBeans Specification, v2. For an entity bean that uses bean-managed persistence, the bean class must be defined as public and cannot be abstract. The bean class must implement the javax. EntityBean interface.
These methods must always be included. In addition to these methods, the entity bean class must also define one or more ejbCreate methods and the ejbFindByPrimaryKey finder method. Optionally, it may define one ejbPostCreate method for each ejbCreate method. It may provide additional, developer-defined finder methods that take the form ejbFind XXX , where XXX represents a unique method name continuation for example, ejbFindApplesAndOranges that does not duplicate any other method names.
Entity beans typically implement one or more business methods. These methods are usually unique to each bean and represent its particular functionality. Business method names can be anything, but must not conflict with the method names used in the EJB architecture. Business methods must be declared as public. Method arguments and return value types must be Java RMI legal. The throws clause may define application-specific exceptions and may include java. The entity bean must implement one or more ejbCreate methods.
There must be one method for each way a client is allowed to invoke the bean. Each ejbCreate method must be declared as public , return the primary key type, and be named ejbCreate. The return type can be any legal Java RMI type that converts to a number for key purposes. All arguments must be legal Java RMI types. The throws clause may define application-specific exceptions, and may include java.
This is the method in which relationships are established. For each ejbCreate method, the entity bean class may define a corresponding ejbPostCreate method to handle entity services immediately following creation.
Each ejbPostCreate method must be declared as public , must return void, and be named ejbPostCreate. The method arguments, if any, must match in number and argument type its corresponding ejbCreate method.
If specific application tasks need to be performed when a bean is first made ready for an application, or when a bean is no longer needed, you should program those operations within the ejbActivate and ejbPassivate methods. For example, you may release references to database and backend resources during ejbPassivate and regain them during ejbActivate.
An entity bean can collaborate with the container to store the bean state information in a database, for synchronization purposes. In the case of bean-managed persistence, you are responsible for coding ejbLoad and ejbStore. The container ensures that the state of the bean is synchronized with the database by calling ejbLoad at the beginning of a transaction and calling ejbStore when the transaction completes successfully.
Use your implementation of ejbStore to store state information in the database, and use your implementation of ejbLoad to retrieve state information from the database. The following example shows ejbLoad and ejbStore method definitions that store and retrieve active data.
For more information about bean isolation levels that access transactions concurrently with other beans, see "Handling Synchronization of Concurrent Access". A container calls setEntityContext after it creates an entity bean instance to provide the bean with an interface to the container. Implement this method to store the entity context passed by the container. You can later use this reference to get the primary key of the instance, and so on.
Similarly, a container calls unsetEntityContext to remove the container reference from the instance. This is the last bean class method a container calls before the bean instance becomes a candidate for removal. After this call, the Java garbage collection mechanism eventually calls finalize on the instance to clean it up and dispose of it. The client can invoke the remove methods on the entity bean's home or component interface to remove the associated record from the database.
The container invokes the ejbRemove method on an entity bean instance in response to a client invocation on the entity bean's home or component interface, or as the result of a cascade-delete operation. Because entity beans are persistent, shared among clients, and may have more than one instance instantiated at the same time, an entity bean must implement at least one ejbFindByPrimaryKey method.
Entity Beans Only. Session Beans Only. Instead, they access the database directly as an Entity bean would. Entity Management. In the above and following diagrams, white shapes indicate components to be written, while gray shapes indicate components already written or to be generated.
This pattern consists of Entity beans for each set, or table, of meaningful data, fronted by Session beans that encapsulate the business rules and logic. The application server manages all persistence within the Entity beans, and Session beans act as a buffer between the client and the Entity beans. This pattern most closely follows the EJB specification, and would be considered by Sun the default recommended EJB method of development. For example, rather than the client remotely instantiating Order, Customer, and Product Entity beans to place an order, a single OrderPlacement Session bean can be instantiated remotely.
On the server, the Session bean will manage the use of the various Entity beans required to complete the task. This can be a significant performance benefit. This allows parts of the application to change without affecting the other parts. It also allows additional companion layers such as a second user interface to be applied.
No hand coding of transactions is required. If Entity beans are used carefully, this pattern performs second only to the Session Only pattern discussed in this document. See Entity Bean Notes at the end of this document for important findings on the appropriate way to use them in an application. This pattern is identical to the first pattern except that the Entity beans are bean-managed instead of container managed.
This change allows alternative persistence mechanisms that may not be supported by the application server to be used. Because of the similarities between pattern 1 and 2, the following Pros and Cons indicate only the differences between this pattern and pattern 1.
While it is possible that significant time and testing could yield a more efficient mechanism than Container Management, this avenue is not generally recommended as a method to increase performance due to added time to market, minimal possible performance benefits, and the real possibility of performance loss.
This pattern allows the client to talk directly to the Entity beans, and uses Session beans only for complex database queries that would involve several Entity beans. This pattern may save some development time, but is generally not recommended for design and performance reasons. This pattern might even be viewed as how not to design an EJB application. Eliminating Session beans as buffers between the client and the Entity beans merges the business logic layer with the presentation layer, creating a less flexible system.
The presentation layer is generally the most frequently changed, and business logic will be exposed to defects and require testing every time the presentation is modified. This system will also prove slower due to the increased network activity generated by the frequent access of Entity beans by the client.
For example, instead of calling a PlaceOrder method on a Session bean, the client may have to instantiate and modify several Entity beans to place an order. Further, since Entity use is not wrapped in a Session bean method, transactions must be managed manually by the client.
Not surprisingly, this pattern performed abysmally in tests, bringing standard throughput on the server from down to users. Even at users, however, it performed 5 times slower than the Container Managed pattern did at users. Virtually any enterprise application you develop must interact with information stored in a database.
Whether a system supports order entry, access to patients ' medical records, or wireless stock trading from a PDA, persistent data is typically critical to what a business application does. Given this, defining a category of EJB for working with persistent data makes sense. A lot of processing can take place related to retrieving and updating the contents of a database, so the EJB architecture provides a foundation to support it.
It's true that the need for persistent data goes along with using entity beans, but that isn't the sole intent. Multitudes of enterprise applications have been built without the use of entity beans, so there must be more to them than just persistence. What you should be thinking when you design entity beans is that the goal is to create reusable business objects that manage persistent data as part of their responsibilities.
Entity beans should represent key business entities that can be reused across an enterprise's applications. Examples of business entities can include objects that represent customers, orders, invoices, medical records, stock trades, and so on.
The responsibilities of the EJB container include the management of concurrent access and transactions so that entity beans can fulfill their role when faced with the demands of multiple clients. When multiple clients access a particular business object that's been implemented using an entity bean, the container enforces serialized access to that object.
This means that two clients can't modify the state of such an object at the same time. For example, if you and your business partner maintain a joint bank account, an application that uses an entity bean to represent an account could correctly handle simultaneous requests from both of you to withdraw funds without any special effort by the application programmer. If your request reached the entity instance first in the form of a method call on the enterprise bean , it would be processed completely before the container would allow any other calls to be made on the bean instance that is representing your account.
The concurrency management provided for entity beans supports this type of scenario even without the use of transactions you'll see much more about the role of transactions in EJB in Chapter 12, "Transactions".
Entity beans aren't always the preferred approach for read-only access to a database, but their support for concurrent access makes them well suited for modifying persistent data. Another advantage of entity beans relates to instance pooling and scalability. As you'll learn more about later in this chapter, the container maintains a pool of entity instances that are used to support the specific business entities accessed by an application.
This pooling provides for efficient sharing of memory while ensuring the integrity of the data associated with your business entities. This built-in scalability is something you wouldn't get if you were to use session beans or regular Java classes to manage entity state.
The rest of this section looks more at the characteristics of an entity bean. One of the first things you need to learn is how to decide whether a particular type of object warrants an entity bean representation.
You then need to learn what you have to do as a bean provider to develop an entity bean and the interfaces, classes, and deployment descriptors that support it. If you've worked with regular JavaBeans, you know that they typically implement GUI widgets or simple data structures.
Those that serve as data structures are usually more concerned with exposing properties to the classes that use them than they are with implementing any significant application logic. JavaBeans are primarily client-side and Web tier components , so you wouldn't want them to do any more than this in most cases.
EJBs have some similarity to JavaBeans in that they share the idea of component-based development. That's about as far as the similarity goes, however. EJBs live on the server and are given far more responsibility than their distant cousin, JavaBeans. EJBs are heavyweight components, so they need to offer more than access to a simple set of properties to make their use worthwhile.
Primarily, an EJB justifies its existence and the overhead incurred when accessing it through the container by providing business logic to an application. An entity bean class is usually expected to contain more than its persistent attributes and a list of get and set methods to go with them. Otherwise, it would be hard to justify its reuse across applications. An entity bean typically is expected to do more by providing the business logic related to the data it represents.
At a minimum, this can include the validation rules that control how an entity's state can be modified. It's also reasonable to expect an entity bean to define the methods that manipulate its data and aid in its interpretation by the applications that use it. As a developer, it's business logic like this that you want to reuse. As with any good object-oriented design, putting business logic into components that are reused means that the logic is written only once and it can be maintained in one place.
As part of this, you must be conscious of the type of business logic that's appropriate for an entity bean. The logic implemented within an entity bean class should, in general, apply only to the data for which the entity is responsible and the relationships it maintains.
As you'll see in later chapters, more elaborate workflow or controller logic usually is more appropriately placed in a session bean. Although most entity beans contain non-trivial business logic, this isn't as strict a guideline as it might seem at first. Because of the persistence mechanisms associated with entity beans and the concurrent access control provided by the container, it sometimes makes sense to implement an entity bean that is significant from a data standpoint but not from a business logic one.
The services offered by the EJB container provide a relatively simple way to support manipulation of shared data by multiple users of a system. Part of an entity bean's deployment descriptor, the abstract schema defines the bean's persistent fields and relationships.
The term abstract distinguishes this schema from the physical schema of the underlying data store. In a relational database, for example, the physical schema is made up of structures such as tables and columns.
You specify the name of an abstract schema in the deployment descriptor. You'll probably find it helpful to sketch the abstract schema before writing any code. Figure represents a simple abstract schema that describes the relationships between three entity beans.
These relationships are discussed further in the sections that follow. The persistent fields of an entity bean are stored in the underlying data store. Collectively, these fields constitute the state of the bean. At runtime, the EJB container automatically synchronizes this state with the database.
During deployment, the container typically maps the entity bean to a database table and maps the persistent fields to the table's columns. A CustomerBean entity bean, for example, might have persistent fields such as firstName , lastName , phone , and emailAddress. In container-managed persistence, these fields are virtual. You declare them in the abstract schema, but you do not code them as instance variables in the entity bean class.
Instead, the persistent fields are identified in the code by access methods getters and setters. A relationship field is like a foreign key in a database table: it identifies a related bean. Like a persistent field, a relationship field is virtual and is defined in the enterprise bean class via access methods. But unlike a persistent field, a relationship field does not represent the bean's state.
Relationship fields are discussed further in Direction in Container-Managed Relationships.
0コメント