Designing Enterprise Applicationswith the J2EETM Platform, Second Edition phần 10 pps

ARCHITECTURE OF THE SAMPLE APPLICATION 375 up functions. It also uses a Business Delegate to bridge the EJB and Web tiers, particularly if its entity beans are implemented with a remote client view. The Business Delegate is an object that hides the data retrieval details, such as remote exceptions. A Value Object may be used to limit the number of remote access calls. Other components take care of the presentation of the retrieved data. The Screen View is a JSP page that builds the next screen to display to the user. It relies on a Composite View, which is a template containing the page structure (header, footer, and so forth). It also relies on a View Helper, either a JavaBean component or a helper object, that extracts the dynamic content for the page from the retrieved data. The Screen Flow Manager object keeps track of the next page in the sequence of pages. Figure 11.9 reflects a remote view architecture. In actuality, the sample appli- cation Web site uses a local architecture approach. While this approach limits dis- tribution to one VM, it does provide increased performance and the ability to have fine-grained method access. It also enables the application to leverage all the con- tainer-managed persistence capabilities offered by the EJB container. Using a local or a remote architecture affects the design of the application and its deployment strategy. Figure 11.9 would have fewer layers had it reflected this local client view design. With a local client view, the design can include finer granularity between components. Local method calls do not have the overhead of remote method calls. Because there are few layers and tiers are co-located, it is not necessary to use value objects or business delegates. Value objects are not neces- sary for entity beans implemented with a local client view. Deployment is also affected by use of a local or remote architecture. An appli- cation implementing a local architecture must be deployed in one unit. Applica- tions with a remote architecture may be deployed as separate units or as one unit. For example, you can deploy the Web tier separate from the EJB tier, or even deploy EJB components separately. 11.4.2 Fulfillment Center Architecture The order fulfillment center fulfills customer orders and manages the business’s financial transactions. Processing starts in this back end of the system when a cus- tomer’s purchase order is received from the Web site. Processing an order from start to finish may take a few days. Three modules comprise the fulfillment center—the order process coordina- tor, administrator, and supplier modules. There are submodules within each DEA2e.book Page 375 Friday, March 8, 2002 12:31 AM CHAPTER 11 ARCHITECTURE OF THE SAMPLE APPLICATION 376 module, such as the customer relations submodule. Each module of the fulfillment center can be packaged in a separate EAR file. Packaging modules separately makes it easier to add and change modules. For example, the supplier currently is internal to the system environment, but the design allows the application assem- bler to easily add other, external suppliers. Figure 11.10 shows the modules of the order fulfillment center and their rela- tionships to each other. Figure 11.10 Order Fulfillment Center Architecture Customer <<application>> PetStore Web Site Order Fulfillment <<application>> Order Process Coordinator <<application>> Supplier CustomerRelations PurchaseOrder DB Inventory DB <<application>> Administrator order and invoice [XML/JMS] order [XML/JMS] e-mail DEA2e.book Page 376 Friday, March 8, 2002 12:31 AM ARCHITECTURE OF THE SAMPLE APPLICATION 377 • The order processing module receives the purchase order and verifies the cus- tomer’s credit status. The order processing module acts as the processing co- ordinator orworkflow manager,and maintainsa globalview ofthe entireorder processing flow. When it receives an order from the Web site, it assigns it an identifier and stores it in the database. It communicates with the administrator module if an order requires financial verification. • The administrator module handles any special financial verification or pro- cessing, such as for large orders, and obtains credit card approvals. • A customer relation submodule within the order processing module notifies the customer that the order has been accepted. • The order processing module passes the order to the supplier. • The supplier fills as much of the order as it can from inventory. The supplier maintains theinventory datain a database. It also invoices the order processing module for the portion of the order it is filling and ships this amount. • The order processing module updates its purchase order records based on in- formation from the supplier and the customer relations submodule notifies the customer of order shipments. This process continues until the order is com- pletely filled. DEA2e.book Page 377 Friday, March 8, 2002 12:31 AM CHAPTER 11 ARCHITECTURE OF THE SAMPLE APPLICATION 378 Figure 11.11 shows the flow of work in the order fulfillment center. Figure 11.11 Fulfillment Center Workflow DEA2e.book Page 378 Friday, March 8, 2002 12:31 AM ARCHITECTURE OF THE SAMPLE APPLICATION 379 How is this implemented in the application software? The order fulfillment center is process-oriented, its process driven by the receipt of an order from the Web site. It typically performs the same sequence of activities for each order, and this process usually lasts for longer than a single session. Single session refers to a client’s session, usually an interactive session on the Web site. A single session lasts a few minutes or it can last up to several hours at most. The order fulfillment center’s activities, from start to completion, may last several days. The software implementing the fulfillment center does not use the Model- View-Controller architecture, although it does make use of some of the J2EE design patterns. The fulfillment center uses a number of the J2EE platform tech- nologies, including JMS API, message-driven enterprise beans, JavaMail API, and XML. The MVC architecture, with its focus on view presentation, is better for GUI- based applications such as the Web site. It is not as well-suited for handling complex process control with potentially extended latency between activities, nor for loosely-coupled communication between participants. The transactional model for the fulfillment center is also quite different than that for the Web site. Web site actions can be rolled back, but recovery is more complex in the fulfill- ment workflow. The fulfillment center GUIs are designed following the MVC architecture. In addition, design strategies such as the session facade pattern used in the Web site may apply in the fulfillment center. When a session facade is used in the fulfill- ment center, it is used selectively and only for coordinating components within a model. A session facade is not designed to coordinate an entire ongoing process such as that of the fulfillment center. A session facade, because it is a session bean, is better for storing state for the duration of a single session. The entire ful- fillment process lasts longer than a single session and its state cannot be held in a session bean. Instead, the fulfillment center maintains its state in persistent stor- age, using entity beans to store and retrieve this state. This discussion focuses on the architecture of the order processing module, because this module coordinates all the pieces of the fulfillment center application and ensures that customer orders are processed and filled. It uses the JMS API and message-driven beans to accomplish its tasks. Conceptually, the order processing module divides into three pieces: DEA2e.book Page 379 Friday, March 8, 2002 12:31 AM CHAPTER 11 ARCHITECTURE OF THE SAMPLE APPLICATION 380 • A workflow manager coordinates the activities in the fulfillment center. It knows the overall process and the sequence of activity steps. • Each activity handles its portion of the business logic. For example, one activ- ity notifies the customer of the order status while a different activity prepares invoices for shipped products. • Transition delegates handle the details of transitioning to the next activity. They prepare messages and send them to JMS destinations. The order processing module implements a persistent message model that ensures that message state is saved. The order processing module sends messages to JMS destinations, some of which are queues and others are topics. A queue saves message state until the message is received. A topic is used to distribute a message to multiple recipients who have subscribed to the topic. The fulfillment center uses durable topic subscriptions so that message state is saved until all recipients receive the message. The fulfillment center separates the implementation of process control from business logic. A process manager is responsible for the entire workflow process. It knows the sequence of steps and the rules for following these steps. It ensures that the appropriate module or activity is invoked at the right point to carry out an operation. If necessary, it saves process state in persistent storage so that an order can be filled over multiple days. The process manager uses a persistent message model that saves message state. The activity module contains the business logic, which determines how the operation should be carried out. The business logic within a given activity may be implemented with a session facade pattern. Messages are sent asynchronously using the JMS API between work flow activities. For example, the manage order flow activity sends an asynchronous message (through a JMS queue) to the verify credit activity so that the customer’s credit is verified before completing the order. The verify credit activity sends an asynchronous message to the process manager indicating the results of the credit check. These messages are encoded in XML, making it easy for different applica- tions to communicate. The customer relations submodule uses the JavaMail API to send e-mail notifying customers of order acceptance and shipments. Each activity in the fulfillment center corresponds to a named JMS destina- tion, either a queue or topic. This named destination is the endpoint that maps to a step in the workflow. Components of the system can send messages to and receive messages from these named destinations. A message-driven bean implements the boundary of the application or module responsible for each piece of the work DEA2e.book Page 380 Friday, March 8, 2002 12:31 AM ARCHITECTURE OF THE SAMPLE APPLICATION 381 flow. A message-driven bean enables asynchronous process control messaging, thereby removing any tight-coupling restrictions between activities. The message- driven bean receives and handles the incoming message request to the particular destination. It passes the message contents to its related work activity module, which might be the module to formulate an order addressed to the supplier or a notification message for the customer, and that module carries out the operation. The message-driven bean then invokes a transition delegate, whose responsibility is to notify the next step in the work flow. The order of steps in the work flow is determined and coded appropriately in each transition delegate. The transition delegate asynchronously sends the appropriate message to a named JMS destina- tion, which is subscribed to by the next activity in the sequence. The delegate may also notify the order processing module so that it can maintain its global view of the work flow. Depending on the particular point in the work flow, a transition delegate may be notifying a single activity or it may be notifying several activities. When it needs to notify a single activity, a transition delegate sends its message to a JMS queue. The message-driven bean for the activity that has subscribed to this queue receives any messages sent to the queue. The queue holds the message until it is received by the message-driven bean. When a transition delegate notifies more than one activity, it sends a message to a JMS topic that is subscribed to by the interested activities. This is a durable subscription to ensure that the topic holds the message until received by all subscribers. For example, the transition delegate for the ship order activity notifies the invoice order activity and the notify cus- tomer activity. The invoice order activity and the notify customer activity both subscribe to the same named topic to which the ship order transition delegate sends its message. They both receive the message and can act upon it. Figure 11.12 shows how the activity workflow manager software models a portion of the process control workflow. The diagram shows the message-driven bean placed at the boundary of each activity to receive messages for that activity and the transition delegate that knows the JMS destination subscribed to by the next activity in the sequence. Messages are encoded in XML and are sent via the JMS API to a JMS destination, either a queue or topic. DEA2e.book Page 381 Friday, March 8, 2002 12:31 AM CHAPTER 11 ARCHITECTURE OF THE SAMPLE APPLICATION 382 Figure 11.12 Process Work Flow of Fulfillment Center As noted previously, the process work flow often takes longer than a single session to complete. The state of the various activities must be saved. While the process work flow diagram does not show where and when state is saved, entity beans save state when needed to the purchase order or inventory database. 11.5 Summary This chapter examined the recommended architectures for J2EE applications and covered designing an application for the J2EE platform. It described the Model- View-Controller architecture and showed how this architecture applies to enterprise applications. It also described the more commonly used J2EE design patterns, which are useful for designing components within an application. DEA2e.book Page 382 Friday, March 8, 2002 12:31 AM REFERENCES AND RESOURCES 383 The architecture of the sample application partitions its functionality into mod- ules, assigns functionality to tiers, and decomposes the modules into specific objects to represent the behavior and data of the application. The principles guiding the architecture include reuse of software designs and code, separation of stable code from volatile code, object decomposition along skill lines, and ease of migration from a Web-centric to EJB-centric model. The sample application adapts the MVC architecture to the domain of enter- prise applications and shows how to apply J2EE design patterns to application components. It takes you through the design of the sample application, starting with formulating functional specifications and high-level considerations such as choosing application tiers and deciding between a local or distributed model. It shows you how to decompose an application into objects and design and imple- ment these objects so that they are efficient, modular, and reusable. The J2EE platform provides system services that simplify the work that appli- cation objects need to perform. The sample application uses the J2EE support for distributed transactions across multiple JDBC databases. In addition, it uses deployment and security capabilities of the J2EE platform to support customers with different profiles. 11.6 References and Resources The following resources are recommended for further information on design pat- terns in general and on particular J2EE design patterns. • Core J2EE Patterns. D. Alur, J. Crupi, D. Malks. Copyright 2001, Prentice Hall PTR. • Design Patterns. E. Gamma, R. Helm, R. Johnson, J. Vlissides. Copyright 1995, Addison-Wesley. • Refactoring: Improving the Design of Existing Code. M. Fowler, et al. Copy- right 1999, Addison-Wesley. • Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. F. Buschmann, et al. Copyright 1996, John Wiley & Sons. • Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. D. Schmidt, et al. Copyright 2000, John Wiley & Sons. DEA2e.book Page 383 Friday, March 8, 2002 12:31 AM DEA2e.book Page 384 Friday, March 8, 2002 12:31 AM [...]... application design and development with the Java 2 Platform, Enterprise Edition Its goal has been to introduce enterprise developers to the concepts and technology used in designing applications for the J2EE platform, and to give practical examples of a typical enterprise application While this book has explored many of the decisions that must be made in the process of designing and developing applications,... context is the default context rooted at the base of the Web server’s URL namespace, the path prefix will be an empty string Otherwise, the path prefix starts with a / character but does not end with a / character Servlet Path is the path section that directly corresponds to the mapping that activated this request This path starts with a / character PathInfo is the part of the request path that follows the. .. method EJB home object An object that provides the life cycle operations (create, remove, find) for an enterprise bean The class for the EJB home object is generated by the container’s deployment tools The EJB home object implements the enterprise bean’s home interface The client references an EJB home object to perform life cycle operations on an EJB object The client uses JNDI to locate an EJB home object... plugs into a container The application components deployed on the container then use the client API (exposed by adapter) or tool generated high-level abstractions to access the underlying enterprise information system The resource adapter and EJB container collaborate to provide the underlying mechanisms—transactions, security, and connection pooling—for connectivity to the enterprise information system... enterprise bean business logic The code that implements the functionality of an application In the Enterprise JavaBeans model, this logic is implemented by the methods of an enterprise bean business method A method of an enterprise bean that implements the business logic or rules of an application callback methods Methods in a component called by the container to notify the component of important events... the scripting language used in the JSP page The JSP specification describes the syntax and semantics for the case where the language page attribute is “java.” JSP scriptlet A JSP scripting element containing any code fragment that is valid in the scripting language used in the JSP page The JSP specification describes what is a valid scriptlet for the case where the language page attribute is “java.” JSP... digest authentication An authentication mechanism in which a Web client authenticates to a Web server by sending the server a message digest along its HTTP request message The digest is computed by employing a one-way hash algorithm to a concatenation of the HTTP request message and the client’s password The digest is typically much smaller than the HTTP request and doesn’t contain the password distributed... is defined by the Application Assembler When an application is deployed, the roles are mapped to security identities, such as principals or groups, in the operational environment role mapping The process of associating the groups and/or principals recognized by the container to security roles specified in the deployment descriptor Security roles have to be mapped by the Deployer before the component... specifies a protocol for fetching the object (such as HTTP or FTP), “host“ specifies the Internet name of the targeted host, and “localinfo” is a string (often a file name) passed to the protocol handler on the remote host URL path The URL passed by a HTTP request to invoke a servlet The URL consists of the Context Path + Servlet Path + PathInfo, where Context Path is the path prefix associated with a... object that identifies an enterprise bean A client may serialize the handle and then later deserialize it to obtain a reference to the enterprise bean DEA2e.book Page 393 Friday, March 8, 2002 12:31 AM GLOSSARY home interface One of two interfaces for an enterprise bean The home interface defines zero or more methods for creating and removing an enterprise bean For session beans, the home interface defines . but the design allows the application assem- bler to easily add other, external suppliers. Figure 11 .10 shows the modules of the order fulfillment center and their rela- tionships to each other. Figure. notifies the customer that the order has been accepted. • The order processing module passes the order to the supplier. • The supplier fills as much of the order as it can from inventory. The supplier maintains. development with the Java 2 Platform, Enterprise Edition. Its goal has been to introduce enter- prise developers to the concepts and technology used in designing applications for the J2EE platform,