5.5 Design Guidelines
5.5.4 Master-Detail Modeling Using Enterprise Beans
In a master-detail relationship, one object serves as a pointer to another. Typically such a relationship is represented to the user as a list of items from which to select. This list is called a master record and its contents are provided by the master object. Selecting an item from this list leads to an expanded view of that item. The expanded view is provided by a detail object.
A master-detail relationship is a one-to-many type relationship among data sets. For example, if we have a set of customers and a set of orders placed by each customer, a master-detail relationship is created by having customer number as a common field between the two. An application can use this master-detail relation- ship to enable users to navigate through the customer data set and see the detail data for orders placed by the selected customer.
When modeling a master-detail relationship as enterprise beans, the guide- lines for using entity or session beans still hold. The choice is not affected by the master-detail relationship. However, the relationship is relevant when designing the behavior of the master. For example, suppose the master object should be
SUMMARY 137
modeled as a session bean and the details object should be an entity bean. In this case, the issue to be decided is how to implement the behavior of the master:
• Expose the underlying entity beans to its clients when the client wants the de- tail object.
• Implement the logic of collecting the details in the master.
In analyzing various possible combinations of session beans, entity beans, or value objects, to represent master and detail objects, these questions are relevant only when the details are entity beans. For this case there are two possible sce- narios:
• If the client modifies the detail entity object, then the master object needs to expose the underlying entity object to the clients.
• If the client does not modify the detail entity object, then the master object can have the necessary business logic to know which detail bean to access to con- struct the logical master/detail object. The client should not be exposed to the logic associated with accessing and aggregating the entity beans representing the details.
5.6
Summary
There are a number of common services that distributed enterprise applications require. These include maintaining state, operating on shared data, participating in transactions, servicing a large number of clients, providing remote access to data, and controlling access to data. The middle tier of enterprise computing has evolved as the ideal place to provide these services. The J2EE platform promotes the Enter- prise JavaBeans architecture as a way to provide the system services that most enter- prise applications need. The EJB architecture frees enterprise application developers from concerns about these services enabling them to concentrate on providing busi- ness logic.
The Enterprise JavaBeans architecture provides various types of enterprise beans to model business objects: entity beans, stateful session beans, and stateless session beans. When choosing a particular enterprise bean type to model a busi- ness concept, the choice depends on a number of factors such as the need to
provide robust data handling, the need to provide efficient behavior, and the need to maintain client state during a user session.
An entity bean provides an object-oriented view of relational data stored in a database; a stateless session bean gives a procedural view of the data. An Applica- tion Component Provider should use entity beans to model logical entities such as individual records in a database. When implementing behavior to visit multiple rows in a database and present a read-only view of data, stateless session beans are the best choice. They are designed to provide generic services to multiple cli- ents.
Some business concepts actually require more than one view of data. An example would be a catalog that provides browsing and searching services as well as mechanisms to update the product information. In such cases, you can use a stateless session bean to operate on a product information as a whole and an entity bean to provide access to a particular product.
Because enterprise beans are remote objects that consume significant amount of system resources and network bandwidth, they are not appropriate for model- ing all business objects. An Application Component Provider can use data access objects to encapsulate database access and value objects to model objects that are dependent on enterprise beans.
Also, it may not be appropriate to give clients direct access to all enterprise beans used by an application. Some enterprise beans may act as mediators for communication between clients and the EJB tier. Such beans can encapsulate work flow specific to an application or can serve as an entry point to a hierarchy of information.
R
AHUL SHARMAis a Staff Engineer with Sun Microsystems, where he is the lead architect for the J2EE Connector architecture 1.0. Before this, Rahul has worked in the areas of Java computing, Web technologies, distributed computing, CORBA, databases, and object-oriented programming. Rahul received a degree in Computer Science from Delhi University in India. He is presently pursuing his M.B.A. from Haas School of Business, University of California at Berkeley.141
C H A P T E R
6
The Enterprise Information
System Tier
by Rahul Sharma
E
NTERPRISE applications require access to applications running on enterprise information systems. These systems provide the information infrastructure for an enterprise. Examples of enterprise information systems include enterprise resource planning systems, mainframe transaction processing systems, relational database management systems, and other legacy information systems. Enterprises run their businesses using the information stored in these systems; the success of an enter- prise critically depends on this information. An enterprise cannot afford to have an application cause inconsistent data or compromise the integrity of data stored in these systems. This leads to a requirement for ensuring transactional access to enter- prise information systems from various applications.The emergence of the e-business model has added another dimension to infor- mation system access: enterprises want their information to be accessible over the Web to their partners, suppliers, customers, and employees. Typically enterprises develop Web-enabled applications that access and manage information stored in their information systems. These enterprises can use J2EE applications to extend the reach of their existing information systems and make them accessible over the Web. Enterprises also develop new e-business applications. The sample applica- tion described in this book is one example of this class of application.
This added dimension requires an enterprise to ensure secure access to its enterprise information systems because any break in security can compromise critical information. An increase in the number of relationships that an enterprise has to establish with its suppliers, buyers, and partners leads to a requirement that
J2EE applications accessing enterprise information systems be scalable and support a large number of clients.
This chapter describes the application programming model for accessing enterprise information system resources from enterprise applications in a secure, transactional, and scalable manner.