| CONTENTS | PREV | NEXT | INDEX | Designing Enterprise Applications with the J2EE Platform, Second Edition |
Designing an application starts with assessing functional requirements and then determining an optimal software implementation to meet those requirements. There are numerous analysis tools for gathering and assessing application requirements. Use case analysis is one such tool. Use case analysis identifies the actors in a system and the operations they may perform.
The pet store application is a typical e-commerce site. The customer selects items from a catalog, places them in a shopping cart, and, when ready, purchases the shopping cart contents. Prior to a purchase, the sample application displays the order: the selected items, quantity and price for each item, and the total cost. The customer can revise or update the order. To complete the purchase, the customer provides a shipping address and a credit card number.
Figure 11.3 shows a high-level use case diagram for the sample application. It shows the potential system actors and their actions:
Once you have determined the system's requirements, you can begin designing the application. We have designed the sample application using two different architecture models. The Model-View-Controller architecture works well for the interactive Web site unit, such as the pet store Web site. Because the fulfillment center is not an interactive application, its design is based on a process-oriented architecture.
One important design step is to decide the tiers that the application uses. The J2EE platform is designed for multitier applications, and it offers flexibility in distributing application functionality across the tiers. Certain tiers are always present in a Web-enabled application such as the sample application, including:
It is important to choose whether a Web tier component accesses the enterprise information system resources directly or through an EJB tier. The decision depends on the application's functionality, complexity, and scalability requirements. Good design takes into account the possibility for change and builds in the facility to easily migrate to an EJB-centric approach. The EJB tier offers advantages to its components, such as automatically handling security, transactions, distributed processing, and so forth. By using EJB components, developers can reduce the level of systems programming required for the application and instead can concentrate on the application's business logic.
Next, decide how to distribute application functionality across these tiers. Such distribution follows the application's division into objects and should be undertaken carefully.
In a Web-centric design, Web tier components using container services such as the JDBC API can communicate directly with the enterprise information system resources that hold application data. In this approach, Web tier components are responsible for almost all of the application functionality. They handle dynamic content generation, content presentation, and user requests. They must implement core application functionality, such as order processing and enforcing the application's business rules. Finally, the Web tier components must also manage transactions, such as by using JTA, and connection pooling for data access. Because it must handle so many functions, Web-centric application software can easily become monolithic. As a result, unless special efforts are taken, it does not scale well with increasing software complexity.
In an EJB-centric design, enterprise beans running on EJB servers encapsulate the enterprise information system resources and the core application logic. Web tier components communicate with EJB tier components instead of directly accessing the enterprise information system resources. This approach moves most of the core application functionality to EJB tier components, using the Web tier components only as a front end for receiving client Web requests and for presenting HTML responses to the client.
The principal advantage of an EJB-centric approach is that enterprise beans have access to a broad set of enterprise-level services. These services make it easier to manage transaction and security aspects of the application. The EJB container handles system-level details and provides a managed environment for its components, allowing a developer to focus entirely on the application domain issues. These standardized container-provided services translate into better software reliability. They also make it easier for an application to support multiple client types. The EJB architecture supports a programming paradigm that promotes encapsulation and use of components, resulting in software that stays manageable as applications grow more complex.
There is a trade-off between the two approaches. The Web-centric approach can enable a quick start for small applications with few transactional needs, while the EJB-centric approach is better for building a large-scale enterprise application where code and performance scalability are prime factors. The Web-centric approach, while more prevalent, has limitations for building large-scale, complex applications. Applications built with a Web-centric approach can rapidly become too complex and difficult to maintain.
There are strengths to both approaches, and good design requires selecting the right balance for each application. The sample application demonstrates an approach designed for growth. This design can be considered an EJB-centric architecture. While all of the application's modules use an EJB-centric design, in theory a Web-centric model could have been used in at least one case for the module that reads the catalog.
Most enterprise applications are distributed across a network, because client and data store resources are usually located on different machines from the application itself. An EJB-centric approach, with the business logic residing on the middle tier, gives architects the flexibility to design the application as a distributed or a local application. (Distributed applications are those that interact through remote communication mechanisms.)
The J2EE platform provides facilities to help create distributed applications, but it also lets application developers apply a local model to their application. A developer needs to weigh the advantages and disadvantages of local and remote architecture models, and balance these against the requirements of the application.
11.3.2.1 Comparison of Local and Distributed ArchitecturesA key consideration for developers is whether to use enterprise beans with a local client view or a remote client view. With careful thought, developers can use enterprise beans with both local and remote client views.
Applications implemented with a local architecture model have their components reside in the same Java Virtual Machine (JVM). Because their co-location in the same address space is guaranteed, these components can communicate with each other without the overhead of remote network calls, thus permitting more efficient fine-grained access among them. As a result, these applications usually exhibit better performance.
A distributed architecture is one in which the application is potentially implemented across multiple JVMs, though a distributed application may be deployed on a single JVM. A distributed architecture is more complex because of additional system-level issues, such as remote communication, security, and so forth. At the same time, it may be more modular, maintainable, and reusable because there is less dependency among individual components. While this approach offers greater flexibility to the application, it usually results in decreased performance because access to a remote component involves significant network overhead. Such overhead includes the cost of serialization and deserialization, along with parameter marshalling and demarshalling. (Although much of this overhead may be optimized away if the application is deployed on a single JVM, some overhead still remains.) Applications in a distributed architecture must pass parameters by value, which often necessitates excessive data copying.
A distributed architecture is also typically more scalable than a local application design. Despite the higher performance of a local application architecture, its components must reside in the same address space, so it cannot scale beyond a single machine. While it is possible to partition the clients of a local application to separate instances running the same application, this becomes harder to achieve since they often need to access and update shared data. A distributed system is generally more scalable than a local application since the components are designed from the ground up to run in a different address space.
Distributed applications are generally more highly available than local applications. Since a distributed component does not know or depend on a particular JVM, it is easier to migrate the distributed enterprise bean component to a different JVM in the event of a hardware failure.
11.3.2.2 J2EE Platform Distributed and Local OptionsOften, a distributed application is designed to consist of multiple local applications or components. The local components are used for the portions of the application that require a high level of data passing and fine-grained access, while the remote components allow for greater scalability and network access.
Enterprise beans, which offer local and remote client views, give applications the ability to use a local or a distributed architecture. Enterprise beans within the same JVM can access one another using a local client view and thus take advantage of the local architectural model. Web components residing in the same VM may optionally have access to an enterprise bean's local client view and take advantage of the same benefits from EJB container services. Using an enterprise bean's remote client view gives the application the advantages of a distributed architecture model.
Applications that require a distributed architecture can be designed to reduce the complexity and performance implications of accessing remote objects. The details of locating remote business objects can be encapsulated in a service locator object, thus hiding these details from the rest of an application, whereas accessing business objects can be encapsulated in a business delegate. Fine-grained data access to distributed objects can be reduced by using a single value object to retrieve a set of related data in one remote call. After the value object retrieves its data, it is available locally for an application, which can then access its individual items.