Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Entity Bean Handle Dilemma
Let's start by talking about what I refer to as "The Entity Bean Handle Dilemma." You might have heard or seen other publications mention that you can encounter certain issues when providing an excessive number of handles to remote interfaces for entity beans. For example, suppose that you have an entity bean that encapsulates a product in some e-commerce application. Now suppose that this product EJB's home interface provides some finder method that can look up products based on stock status. As you can imagine, for a large-scale commerce site with many products, an enormous number of products might be located using such finder operations. Now multiply such finder lookup operations by a thousand or more concurrent client requests under a heavily trafficked site.
Believe me, despite any hype about scalability from a vendor, this can cripple an EJB application server. I've attended talks and read articles from vendors, EJB/J2EE expert authors, and even a few EJB/J2EE expert consultants; after the talks or in private communication with these folks, I start asking questions about example scalability scenarios in which they've run such applications. About 75% of the time, their responses reveal the minimalist scenarios in which they've deployed their EJB applications. I even sat in on a talk in which one guy harped on about how scalable and well-performing such EJB application servers are—afterward, however, I discovered that he was running the "Pet Store Demo" that is associated with the J2EE reference implementation, and he was running it on an intranet with two other colleagues.
One way around such a dilemma is to create a mechanism by which entity bean data is serialized and sent back to the client that requests such data. Various patterns discuss this approach. The approach basically revolves around providing a session bean that receives the client request, formulates the entity bean home interface finder call, receives the response, and manages how data from the entity bean remote interfaces is serialized into a response to the client. In fact, this leads to a very common pattern in which session beans act as the primary interface for clients to the application server, and the session beans handle all access to the data tier via entity beans. This pattern leads to an architecture in which session beans represent the business objects and managers for collections of entities.
Such a pattern is great for data retrieval, but when data must be updated, created, or deleted, a different set of problems must be considered. The session bean front-line interface for clients can still be maintained as the pattern, of course. However, for creates or deletes, the session bean simply might provide an extra amount of overhead because it will largely delegate the creation or removal call to the entity-bean tier. The new EJB v2.0 "local interface" can partially alleviate this problem because local interfaces help avoid the remote method invocation overhead from the session bean interaction with the entity bean. As for updates, if a session bean has serialized the entity bean data, it will have to perform another lookup on the EJB home interface for the entity bean to perform the update.