11.4 Architecture of the Sample Application

With an understanding of these basic architectural considerations, you are ready to examine the architecture of the sample application in detail. Recall that the application is divided into two units: a Web site that serves as a front end to the user and an order fulfillment center on the back end. The Web site follows the Model-View-Controller architecture. Its architecture also combines a number of the J2EE design patterns. The fulfillment center follows a process workflow architecture.

Figure 11.4 provides a high-level view of the major modules of the sample application and the application's relationship to its key participants.

Figure 11.4 Sample Application Architecture and Participants

This discussion does not cover every detail of these architectures; instead, it illustrates several salient points of the design. You should also refer to the Java BluePrints Web site for more detailed information on the sample application architecture and design documents, along with the latest source code.

11.4.1 Application Web Site Architecture

Developing an overall application architecture involves subdividing the application into objects or components and assigning these components to tiers, a process called object decomposition. While most components are consigned to one tier or another, some serve to connect the tiers and need to span tiers, and they must be designed accordingly.

Object design becomes important as applications grow more complex. Large scale development of object-oriented software requires frameworks that define how objects interact. The framework must enable software designs and code to be easily reused. It must also identify the responsibility of each component; that is, the division into components must ensure the unambiguous identity of what the component represents and what it must accomplish.

Additionally, for multitier enterprise applications, it is important to:

• Separate stable code from code that changes more frequently. Usually the presentation and user interface change more often than business rules and database schemas. The overall architecture should separate stable portions of the application from the more volatile parts.
• Divide development effort along skill lines. The people that comprise an enterprise development team typically represent a very diverse set of skills. There are Web page designers who do HTML layout and graphics, programmers, application domain experts, and enterprise information system resource access specialists, among others. The decomposition should result in a set of objects that can be assigned to various subteams based on their particular skills. This division of labor allows work on each object to proceed in parallel.

The MVC architecture works well for the sample application. At the highest level, the application divides into three logical categories of layers--layers that deal with presentation aspects of the application, those that deal with the business rules and data, and those that accept and interpret user requests and control the business objects to fulfill these requests.

Generally, the look and feel of the application interface changes often, its behavior changes less frequently, and business data and rules are relatively stable. Thus, objects responsible for control are often more stable than presentation objects, while business rules and data are generally the most stable of all.

Web page designers, HTML and JSP technology experts, and application administrators handle implementing presentation objects after the application has been deployed. Application developers implement control-related objects. Developers, domain experts, and database experts implement business rules and data objects.

As discussed previously, the sample application's Web site handles customer interactions. (See Section 11.2 on page 352.) The Web site presents the application's data--the product catalog--to the user in response to the user's requests. The Web site's primary responsibilities include handling user requests, retrieving and displaying product catalog data to a user's browser, and allowing users to select and purchase products.

The next phase of the design process is to partition the application into modules and objects that address the different functional requirements. The partitioning process includes deciding how to apportion the application across the different tiers of the J2EE platform, which portions of the application need to be distributed, and which should be implemented for local interaction.

The discussion begins with the functional specification for the user interface to the pet store Web site. See Figure 11.5.

Figure 11.5 Use Cases between Customer and Web Site

A customer accessing the Web site expects to see:

• Links or navigation bars to common navigational tasks
• A catalog providing an organized view of the site's contents
• A search mechanism
• A master view of catalog items
• A detail view that describes the details of a particular item
• A shopping cart view that lets customers review and modify the contents of their shopping cart
• A checkout view that displays the total order cost and allows the customer to enter billing and shipping information
• A receipt view to provide confirmation of the purchase

In addition to these user interface requirements, the application must also support some security requirements, such as allowing only properly signed-on users to access certain features while allowing all users free access to other areas of the site.

Once the functional requirements are identified, the application can be divided into modules based on functionality. Such separation reduces the dependency between modules and allows them to be developed independently. In addition, identifying interfaces between modules enables modules to be developed by third-party component providers.

In this view, the application is divided into these modules:

• A control module to create and maintain user account information, which includes a user identifier, billing, and contact information. This information is maintained in a database. The control module also creates and manages the user's shopping cart and controls the interactions with the user.
• A sign-on module to handle the user log-in process and security, such as verifying a user identifier and password
• A product catalog module that returns product information from the catalog based on a user's search criteria
• A customer module that manages a user's purchasing process and maintains account records for a customer
• A messaging module that enables the application to send and receive asynchronous messages containing purchase orders

Figure 11.6 shows how the modules in the sample application Web site relate to each other.

Figure 11.6 Functional Modules for the Sample Application Web Site

Once the application is partitioned into functional modules, the next step is to identify units of business logic, data, and presentation logic and model them as software objects. This starts with identifying the options at the highest level, then working down.

The overall design and organization of the Web site follows the Model-View-Controller architecture, while the internal design of some of its individual components follow the J2EE patterns. The application uses the MVC architecture because it provides a structure for handling complex, presentation-oriented applications.

In classic MVC architecture, views register themselves with the model for change notifications. When the model changes, it notifies a view of what changed. In the application's Web site, the nature of HTTP requires the client view to use a request-response paradigm to interact with the model on the EJB tier. Rather than using notification, model changes are reported as a response to the client view.

The sample application's Web site is a complex application. It has numerous views and pages displayed to the customer in potentially different languages, plus content may be personalized. Customers can make an array of different requests, each of which the application interprets and services, with data coming from multiple sources. The application dynamically determines the sequence of views to display to the customer.

Applying the Model-View-Controller architecture to the sample application reduces its complexity and makes it more manageable. The architecture enhances the degree to which the application can be maintained and extended. By separating business and control logic from data presentation, the architecture provides the flexibility to handle such application complexity.

In the design of the Web site application, it is first partitioned into model-view-controller layers. The application divides roughly as shown in Figure 11.7. Keep in mind that these are not clear boundaries between model, view, and controller. Application functions typically straddle these layers.

The next few sections examine the operations that are performed within and across each Model-View-Controller architecture section and their design issues. They also suggest the appropriate J2EE technologies and design patterns to handle these issues.

Figure 11.7 Model-View-Controller Architecture in Sample Application

The sample application uses the J2EE platform technologies (servlets, JSP pages, and XML) for handling user views. In general, the application uses JSP pages for presentations where the presentation data changes rather than the structure of the presentation. The application could use servlets for graphics and other binary data representations or when it appears that data structure frequently changes. If the data already exists in XML or if it must be viewed in multiple ways, this could be handled using XML combined with XSLT.

When designing the application views, consider these key issues:

• Separate presentation logic from business and control logic.

View components should focus on presentation. It is important when designing the view portion of an application to keep logic for presenting a view separate from logic that implements business rules and logic that controls process flow. In addition, it is best to keep presentation logic modular by using view templates and helper objects to structure and build page content.

JSPs are an excellent technology for creating views for Web applications. However, it is important to use JSP pages effectively. The sample application uses JSPs for the Web site so that the JSP logic focuses on rendering the view. The application's JSP pages do not contain control logic. (A controller handles control logic.) This makes it easier to reuse the presentation logic portion of the JSP page. It is also important to avoid putting logic in embedded scriptlets.

The application uses a view helper pattern. It also encapsulates presentation logic in JSP custom tags and uses JavaBeans to hold data. Presentation logic implemented in custom tags or JavaBeans is separate from data and it is modular and reusable--it is defined in one place and used referentially from different JSPs.

• Manage page layout.

Applications usually strive for a common look and feel, and keeping page layouts similar within an application is important to establishing such a look and feel. The pages for the sample application all have the same structure: a banner across the top, a navigation menu down the left side, and a footer at the bottom. Page content appears to the right of the navigation menu, between the banner and the footer. The content of each segment is independent of the others.

Figure 11.8 shows two pages from the sample application. Notice the layout similarity between these pages: the Java Pet Store banner across the top, menu selections on the left side, and the same footer information across the bottom. Page content appears to the right of the menu. However, the content of the two pages is very different.

Figure 11.8 Two Sample Application Pages

A templating mechanism, such as a composite view design pattern used by the sample application, helps to keep page layout consistent. A template determines how to assemble view components into a single view. It consolidates page layout in one location, making it easy to change page layout in one place and have all pages remain consistent. In addition, a template, such as composite view, separates layout from content.

• Separate developer roles.

The MVC architecture provides the means to separate the work of developers who have different skill sets. For the most part, Web page authors primarily have visual design skills. They usually are graphic artists or content editors, and may not be programmers. On the other hand, programmers who know the business model, work flow, and application requirements develop the model and controller components. Separating developer roles minimizes interference among developers and lets them work independently. The application uses the view helper pattern to separate data presentation from business logic. This separation enables the Web page author to change view presentation without fear of corrupting programming logic. Likewise, programmers can implement application logic without affecting the page layout.

The model portion of the MVC architecture encapsulates the business objects and API for the application's functionality. The sample application uses enterprise beans to implement its business logic. Enterprise beans (and the EJB tier) are the recommended J2EE technology for implementing these business objects. Enterprise beans are preferred because of the services provided by the EJB container, particularly for applications that are transactional, distributed, and potentially scalable, and where security is important. Simpler applications with fewer needs may be able to provide their own services and may consider implementing their model as Java objects.

The design of the model portion of the application considers these issues:

• Keep the functional interface manageable.

The model for most applications consists of many cooperating business objects. As the number of business objects increases, developers have more difficulty understanding how they interact. Developers can be overwhelmed by the number of APIs exposed by these object interfaces.

A complex API can be simplified using two mechanisms--a facade class and a command pattern. A facade coordinates operations between cooperating classes. It presents a single interface to the business objects representing the application model or functionality. A facade encapsulates and hides the complexity of these business objects from clients. In addition, because their implementation details are kept hidden by a facade, the objects can change without affecting the clients. The sample application uses a session facade session bean as a single interface to other enterprise bean business objects.

A facade's effectiveness is limited, since complex applications can cause the facade's API to grow too large. This is the case with the sample application. Rather than continuing to add methods to the session facade class, the sample application implements a command pattern on top of the facade. A command pattern encapsulates each application function in a separate class. Each command instance represents a single request for an application service along with data necessary to perform the service.

• Develop code as components to promote reuse.

Application development is enhanced when developers design code to be modular, reusable components, or promote using off-the-shelf frameworks and components. Modular components are designed to be independent from other components; they are only loosely-coupled to other components. With loose coupling, changes to components have little or no impact on other components. Also, modular components are designed to do only a single function. Single- function components can be easily reused and they have no extra overhead. Off-the-shelf frameworks can serve as a backbone to which other components plug in. Both off-the-shelf frameworks and components let developers leverage the expertise of others.

• Manage data access for portability.

The sample application uses business data stored in several databases. Data could also be stored in legacy systems. Each type of data repository may have its own API. It is best if the application's business objects are not tightly coupled to a specific data persistence mechanism, because changing the underlying data store or database requires changing the data access logic in the business objects. The application uses enterprise beans with container-managed persistence because, with container-managed persistence, the EJB container handles the data access details. This decouples access to persistent data from the data's particular storage mechanism. When the application uses enterprise beans with bean-managed persistence, which it must do in certain situations, it then implements a data access object to achieve the same decoupling. A data access object encapsulates data access mechanism details so that these details are kept separate from business logic.

• Locate objects.

Enterprise beans and other components in a distributed system routinely use the Java Naming and Directory Interface (JNDI) to locate other resources and components. Lookup procedures can be complex. The application uses a service locator object to handle all the lookup details for finding distributed objects. A business object can make one call to the service locator rather than including this lookup logic itself, thus letting it focus on business logic.

• Separate developer roles.

As with view development, business component development is most effective when developer roles are separated. For example, by using container-managed persistence or having database developers implement data access objects, the application shields business logic developers from the implementation details of database access calls.

The controller section of the MVC architecture controls the flow of the application and serves as the glue between the model and view--it executes business logic in the model in response to user requests and helps select the next view for display. The controller decouples data presentation from business data and logic.

It is possible to implement a controller in the client, Web, or EJB tier, or in a combination of these tiers. A client presenting only views is considered a thin client. A rich client implements views and a controller. Generally, a Web-tier controller handles HTTP requests, passing requests to an EJB-tier controller, which in turn invokes the business logic processing. A Web-tier controller also selects view components for presentation by a thin Web client.

The sample application divides controller functionality between its Web and EJB tiers, and control crosses tier boundaries. The controller receives and handles requests between the Web and EJB tiers. The application also combines a controller with a command pattern. A Web-tier front controller, implemented as a servlet, receives HTTP requests and performs functions specific to the Web tier, such as changing output encoding. All user requests flow through the front controller. The front controller, using the data in the request, extracts the type of request and converts it to the appropriate type of event object. It then passes the event to the EJB-tier controller, implemented as a session bean, which matches the event to the proper command. Ultimately, the command invokes the appropriate action on a session facade, which executes the business logic.

The application selects the next view to display entirely in the Web tier, using the screen flow manager for this task. While selection of the next view can be done in either tier, it usually is done in the Web tier.

A front controller is a good design approach because it provides a single point of contact for all application requests. It interprets requests, executes business logic, and handles security, error handling, and view selection. Centralizing application control provides a natural point for implementing application-wide services and reduces code redundancy.

Implementing a controller with a command pattern not only simplifies a session facade interface (see Section 11.4.1.2 on page 369), it also keeps the controller implementation cleaner by encapsulating event- and request-handling tasks into smaller objects. It also enables Java platform events to be used as the bridge between Web- and EJB-tier controllers.

The application's controller section includes a request intercepting filter. This servlet provides application-wide security services. The request intercepting filter handles all incoming user requests and checks that users are properly logged in. Centralizing application-wide services in one place makes it is easy to add and remove services.

The architecture for the sample application's Web site consists of a set of components divided into model, view, and controller layers. The components in the controller layer handle client requests--they receive client requests and start the process of providing the appropriate response. The controller layer components are Request Intercepting Filter, Event Controller, Event Factory, Event, EJB Tier Controller, and Command Factory.

The model layer contains the components that handle business logic: Session Facade, Business Object, and Data Access Object. They extract and formulate the data required to handle a client request. The Command Handler component straddles the controller and model layer, and serves as a bridge between them. The view layer contains the components whose job is to format and present a response to the client. It consists of the following components: Screen View, Composite View, Screen Flow Manager, and View Helper. Three additional components--Service Locator, Value Object, and Business Delegate--apply the MVC approach in a distributed setting. They handle the issues that arise in a distributed architecture.

Let's examine the architecture of the application in more detail by following a user request received by the Web site. This section shows how the model, view, and controller portions of the Web site handle the request and how different objects or components are designed to handle the application's functionality. Whenever possible, these components follow J2EE design patterns. Figure 11.9 shows how the sample application architecture decomposes into components.

Figure 11.9 Class Diagram Showing Sample Application Architectural Components

A client interacts with different views presented in the browser and eventually submits an HTTP request. The request goes to the controller section where it is handled by a Request Intercepting Filter. This servlet filter receives the request and does the necessary security checks. It then passes the request to the Front Controller servlet. The Front Controller's job is to pull out data from the request form and create an event object with that data. It uses an event factory to create the right type of event and then passes the event to an EJB Tier Controller session bean. This session bean maps the event to a command using the services of a Command Factory and a Command Handler object. A Command Handler object simplifies a session facade by determining the action to perform.

To handle the request, the Command Handler object invokes the correct action on a Session Facade, which is a session bean in the model section. The Session Facade organizes the work that needs to be done. It invokes operations on other session and entity beans, referred to as business objects, that carry out the details of the application's business logic. Entity beans may access the database if it's necessary to retrieve data. If the entity bean uses container-managed persistence, the EJB container handles the data access logic. Otherwise, if the entity bean uses bean-managed persistence, there may be an additional Data Access Object to hold the access logic.

The sample application includes an EJB Tier Controller that relies on a command handler object. The EJB Tier Controller provides a single method, handleEvent, through which requests from the Front Controller pass as events. The handleEvent method includes an event argument that encapsulates the requested operation and any required data. Based on the event type, the EJB Tier Controller uses the Command Factory to get the proper Command Handler. The Command Handler orchestrates updates to model data contained in EJB components. By using the command pattern, the EJB Tier Controller delegates the execution of business functionality to the Command Handler.

For example, the application centralizes business logic in a PlaceOrder command handler. The PlaceOrder command handler orchestrates the details of business operations in one object. The PlaceOrder command handler bean calls four different enterprise beans (both entity and session beans) to carry out its operations, such as requesting database information, preparing orders, formulating response information, building and sending XML messages, and so forth.

To present a page to the user, the application must retrieve data and then format it properly. Not only must the application build the presentation page, it must also know the correct page to display within the sequence of pages. At the data retrieval level, the application uses a Service Locator object to perform look 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 application Web site uses a local architecture approach. While this approach limits distribution 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 container-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 necessary for entity beans implemented with a local client view.

Deployment is also affected by use of a local or remote architecture. An application implementing a local architecture must be deployed in one unit. Applications 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 customer'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 coordinator, administrator, and supplier modules. There are submodules within each 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 assembler to easily add other, external suppliers.

Figure 11.10 shows the modules of the order fulfillment center and their relationships to each other.

Figure 11.10 Order Fulfillment Center Architecture

• The order processing module receives the purchase order and verifies the customer's credit status. The order processing module acts as the processing coordinator or workflow manager, and maintains a global view of the entire order 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 processing, 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 the inventory data in 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 information from the supplier and the customer relations submodule notifies the customer of order shipments. This process continues until the order is completely filled.

Figure 11.11 shows the flow of work in the order fulfillment center.

Figure 11.11 Fulfillment Center Workflow

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 technologies, 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 fulfillment 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 fulfillment 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 fulfillment 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 storage, 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:

• 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 activity 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 applications 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 destination, 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 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 destination, 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 customer 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.

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.