12.3 Overview of the Architecture

As discussed in Chapter 11, both the J2EE and the B2B architectures have strengths and weaknesses but are not mutually exclusive. The B2B architecture supports widely distributed business objects. The J2EE architecture supports transaction systems. Common sense dictates using the B2B architecture for interaction between business objects and decomposing each business object using the J2EE architecture. Bass, Clements, and Kazman [Bass 98] refer to this as hierarchical heterogeneous architecture styles: A component of one style, when decomposed, is structured according to the rules of a different style.

The question now becomes, "How can RSS be described within this architecture?" RSS, as we have already stated, is a very large system encompassing a wide range of functionality that will be distributed across multiple business objects in the B2B architecture. However, RSS, which has historically been a transactional system, is being modernized by a single development team and will be deployed on a single platform or collection of platforms connected by a high-speed LAN. Therefore, does it really make sense to implement this system as a collection of business objects communicating asynchronously without the support of a transaction manager?

On the one hand, building the system as a collection of business components would allow business objects to be easily shared/integrated with other systems within the enterprise. The overall system configuration would be highly configurable. Business objects could be easily relocated to a remote site running on a low-bandwidth WAN connection or replaced with a COTS product. On the other hand, system performance might suffer.

This interesting question is not easily solved without modeling the multiple-business object approach to determine whether performance will be adequate. In the end, we decided to decompose the system into multiple J2EE-based business objects and to provide a common BSR interface to each business object for ease of integration with external systems. Business objects on the same platform or LAN communicate directly using the transactional-based method invocations, whereas business objects on remote systems or systems accessible only through low-bandwidth WANs are integrated using OAGIS BSRs. The identified business objects include ^[1]

^[1] As might be expected, the exact list and the makeup of business objects evolved continuously during the planning effort.

• Order Management: Processes purchase orders and back orders, services customer inputs and outputs, provides a help capability to the customer, and interfaces with the accounting and procurement systems

• Inventory: Maintains the status, location, stock level, and rules for issue of inventory items

• Catalog: Provides information for item identification, selection, pricing, and source identification

• History/Audit: Tracks information required for historical or audit requirements

• PickList: Provides the functionality to prioritize the pulling of items from inventory and provides work-flow capabilities

• Work-in-Process ( WIP ) Confirmation: Provides status, update, tracking, and suspense capabilities for requisitions, shipped items, and others

• Requisition : Provides capabilities for generating requisitions and funds confirmation

• Demand Planning: Processes usage and inventory data to determine inventory needs

• Match Document: Processes invoices, provides acknowledgment of the received invoice, and establishes supply-point segments for received items

Figure 12-2 shows the relationship of these business objects in RSS.

Figure 12-2. RSS high-level architecture

Business objects on a single platform or LAN communicate using EJB- based transactional method invocation (RMI/IIOP). These J2EE-based business objects exchange BSRs with external systems over MQSeries. Business objects communicate with the RSS operational database to perform operations on behalf of applications. The data warehouse synchronizes as required with the operational database to update data values.

Data for each business object is stored in a single operational database because we have already selected performance over modifiability as the critical attribute driver for the architecture. It is our decision to allow a high degree of coupling between business objects running on the same platform.

In essence, the RSS architecture is a three-tier layered architecture. The application components represent the presentation tier, the business objects represent the business logic tier, and the database represents the data tier .

A simplified view of an application is shown in Figure 12-3. RMI is used to communicate between application components and business objects. SQL is used as an interface between business objects and the database. A more detailed view of the architecture is shown in Figure 12-4 and is discussed in the following sections.

Figure 12-3. Simplified view of an RSS application

Figure 12-4. Detailed view of the RSS architecture

Application Components

Application components are responsible for providing information from the user to the computer system and for presenting information from the computer system to the user. Application components include user interfaces, reports , query building, and application-specific work flows.

The structure of an application component is shown in Figure 12-5. The application component contains the following elements:

• Graphical user interface ( GUI ). The GUI is implemented as HTML pages, with dynamic content provided by JSPs or Java servlets.

• Reports. Preset reports are implemented in Java and use the services of the reporting layer. The reporting layer provides a level of abstraction, using the JDBC layer to access the database. This makes the reports independent of the database implementation.

• Generic query builder. The generic query builder allows the user to construct ad hoc queries to the database. It can be an applet, a JSP, a servlet, an SQL prompt, or any commercial query-building tool.

• Session manager. The session manager is a Java servlet or JSP that implements work flow and session management. The session manager accepts the user's input, invokes the service components located in the business objects, and then issues a response to the client.

Figure 12-5. Application component structure

Application components can communicate with business objects by using BSRs, nonstandard component APIs, or a combination of both. Using BSRs maintains a greater degree of independence between applications and business objects. In particular, using nonstandard interfaces to business objects can create a dependency on a particular implementation of a business object for the application component. However, the granularity and performance of BSR-based communication may be inadequate to support user interactions. As a result, it is acceptable to use non-BSR communication with business objects in this situation. The architecture uses RMI to communicate between application components and business objects.

Application components access data through the business objects, except for reports and ad hoc queries. Database access for reports is done through a reporting layer, whereas ad hoc queries access the database directly.

Business Objects

Business objects encapsulate the business logic and data of a business entity. Business objects communicate internally using RMI, externally using BSRs, and with the database layer using SQL. Each business object defines one or more service components, one or more data components, and wrapper components as required. A service component provides the functionality of a business object. A data component encapsulates data elements maintained in the RDBMS. A wrapper component is used for communication with legacy systems that do not have a BSR interface.

Service Components

Service components provide the business logic for a business object. Service components communicate with one or more data components to obtain required information, to respond to a call from another service component or application, to respond to a BSR, or to generate a BSR.

Service components must use the BSR interface to communicate with external business objects and systems. Service components also provide interfaces for use by application components, other service components within the business object, and other local business objects.

Service components do not access the database directly; they access it through data components. Service components perform bulk operations on data components on behalf of Java servlets in application components.

The Session Entity Faade pattern [J2EE 01a] provides functionality similar to that provided by a service component. The service component acts as a faadea unified, simple interface to all the service's clients. Those clients use the service component as one-stop shopping for functionality and data access.

Service components are implemented as EJB session beans. Session beans act as agents for clients and are typically instantiated for each client session. Order placement is a good example of functionality that would be implemented as a session bean.

Accessing data components through service components also simplifies transaction management. For example, if the session bean implementing the service component specifies transactions as required, all entity beans invoked by the session bean will run in the same transaction context as the session bean.

EJB defines stateless and stateful session beans. Stateless session beans are components that model business processes performed in a single method call. These beans hold no conversational state on behalf of clients, meaning that they are free of a client-specific state after each method call. For a stateless session bean to be useful, the client must pass all client data that the bean needs as parameters to business logic methods . Because they can support multiple clients, stateless session beans can offer better scalability for applications with a large number of clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients.

Stateful session beans hold conversations with clients that span multiple method invocations. Stateful session beans store a conversational state within the bean. This state must be available for that same client's next method request.

The RSS architecture uses stateless session beans to provide generic services to multiple clients. For example, a service that manipulates multiple rows in a database and represents a shared view of the data can be modeled as a stateless session bean. One example of such service is a catalog listing products and associated prices. Because all users are interested in this information, the stateless session bean can be easily shared. Stateless session beans are the best choice for implementing behavior to visit multiple rows in a database and presenting a read-only view of data.

Session beans encapsulate a business task. As a result, there is typically a strong correlation between service components and system use cases. In RSS, examples include order placement, requisition, and delivery.

Often, use cases contain steps that are common to other use cases, such as obtaining a list of items. These steps are usually extracted from the use case and modeled as use cases themselves . They are associated to the original use case with the include relationship. These steps may be modeled as session beans or simply as reusable Java classes.

Data Components

Data components provide encapsulation. They communicate with the database to obtain or update information. In this architecture, data components are implemented as entity beans. Data components represent data in a database and add behavior to that data. Instead of writing database logic in an application, the application accesses data through the remote interface to the entity bean.

Data components can use either bean-managed or container-managed persistence. With bean-managed persistence (BMP), database calls are implemented within the bean, using, for example, JDBC. With container-managed persistence (CMP), there is no persistence logic inside the bean; rather, the EJB container manages data persistence based on information provided in the deployment descriptor.

Even though container-managed persistence allows beans to be smaller and eliminates the need to develop data-access logic, bean-managed persistence proves to be better in large and complex systems, for three reasons

1. There is usually a need to develop logic, especially for finder methods.

2. Complex data fields may not be directly mappable to underlying storage.

3. There may be relationships between entity beans that must be specified.

Data components should represent coarse-grained objects, such as those that provide complex behavior beyond simply getting and setting field values. These coarse-grained objects typically have dependent objects with real domain meaning only when they are associated with their coarse-grained parents. These finer-grained, dependent-data subcomponents can be implemented as Java classes.

Data components apply the Aggregate Entity pattern. This pattern uses an aggregate entity bean to model, represent, and manage a set of interrelated persistent objects rather than representing them as individual fine-grained entity beans [Larman 00]. An aggregate entity bean consists of a tree of objects.

For example, an invoice can be represented as a coarse-grained entity bean. The lines in the invoice are dependent objects. This representation avoids the problems that emerge when the entity bean schema matches the relational schema. To use the same invoice example, this would mean defining a separate entity bean for each invoice header and for each line in the invoice. Examples of problems that could emerge include

• Excessive communication overhead between the coarse-grained entity bean and the dependent entity beans

• Significant overhead resulting from the presence of a large number of entity beans

• Overhead resulting from fine-grained management for fine-grained components, especially in bean creation

• Overhead resulting from numerous , dynamically established connections between entity beans

• Added development complexity resulting from distributed debugging

Figure 12-6 shows the Aggregate Entity pattern, in which entity beans represent independent objects with associated sets of dependent objects, or subcomponents, thus providing a coarse-grained, entity bean schema. The Aggregate Entity pattern states:

In general, an entity bean should represent an independent business object that has an independent identity and life cycle, and is referenced by multiple enterprise beans and/or clients. A dependent object should not be implemented as an entity bean. Instead, a dependent object is better implemented as a Java class (or several classes) and included as part of the entity bean on which it depends [Harpner 99, p. 99].

Figure 12-6. Data component internals: Aggregate Entity pattern

This form of aggregation requires access to subcomponents always to be performed through the entity bean. One way to reduce the overhead of having to go through the entity bean is to have group operations. In Figure 12-6, for example, Entity Bean 1 could have a method SetSubentity1() that sets all the attributes in Subentity 1 without having to call an individual set method for every attribute.

Elements identified as data components have common qualities. In particular, they

• Are referenced by more than one component or client

• Have an independent life cycle that is not bound or managed by the life cycle of another element

• Require a unique identity

• Provide complex behavior beyond simply getting and setting field values

• Usually have dependent objectsones that have no real domain meaning when standing alone

Wrapper Components

A wrapper component is an adapter that allows a service component to communicate with an external system that does not have a BSR interface. Figure 12-7 illustrates how to use BSR-to-API and API-to-API wrappers. Use a BSR-to-API wrapper to communicate with an external legacy system that may eventually become a business object of its own. Use an API-to-Native-API wrapper when a component communicates with an external legacy system that is accessed only by components in the same business object or that will eventually become a part of the same business object when modernized.

Figure 12-7. Types of wrapper components

BSR Interface

The BSR interface provides service for communication between business objects. This interface can be constructed using a layered architecture:

• An interface layer, which receives information in an OAGIS XML BOD from the messaging system.

• An interpreter layer, which interprets the message content. This layer includes an XML parser. Business objects interface with the interpreter to send and receive information.

• An application layer, which provides the core application functionality: the business objects.

The BSR interface package must receive BSRs, parse the BODs contained in the BSRs, and translate the BODs into calls to service components. The BSR interface package also must generate BODs and send BSRs when requested from a service component or as a confirmation/reply to a BSR.

Figure 12-8 shows the parts of a BSR interface:

• BSR interpreter. The BSR interpreter receives XML messages, parses them, and generates the appropriate calls to the service components inside the business object.

• BSR constructor. The BSR constructor receives requests from service components to construct BSRs to send to external systems. The BSR constructor is also called from the BSR interpreter if the incoming BSR requires another BSR to be generated as a confirmation or reply.

• XML parser. XML parsers are available from several sources, as discussed in Section 7.5.

• Data type definition ( DTD ) or XML schema repository. The DTD/schema repository contains the DTDs or schemas for all the BODs defined by the OAGIS, as well as user-defined BODs. This repository can reside in the database or on any file system.

Figure 12-8. Elements of a BSR interface package

Figure 12-9 illustrates the operations that take place when the BSR interface receives a BSR.

1. The external BSR interface sends a BSR over MQSeries to the RSS BSR interface.

2. The RSS BSR interface invokes the BSR interpreter that knows how to handle the incoming BSR.

3. The BSR interpreter invokes the XML parser to extract the information from the BOD associated with the incoming BSR.

4. The XML parser obtains the DTD/schema from the DTD/schema repository.

5. The BSR interpreter invokes the service component that knows how to process the incoming BSR and passes it the information that was extracted from the BOD.

Figure 12-9. Processing an incoming BSR

Figure 12-10 shows the operations that take place when a service component invokes the service of a BSR interface.

1. An RSS service component that needs to communicate with an external system sends a request for BSR construction to the BSR constructor.

2. The BSR constructor invokes the XML parser to construct the BOD to be sent in the BSR.

3. The XML parser obtains the DTD/schema from the DTD/schema repository.

4. The BSR constructor requests the RSS BSR interface to send the BSR to the external system.

5. The RSS BSR interface sends the BSR to the external BSR interface.

Figure 12-10. Processing an outgoing BSR

If a BSR is required as a reply to an incoming BSR, the BSR interpreter requests the services of the BSR constructor, and the operations in steps 2 through 5 take place.

The BSR interface receives incoming messages from MQSeries and sends the BSRs to the interpreter. The BSR interface also accepts outgoing BSRs and sends them to the MQSeries queue of the intended recipient system.

Alternatively, the BSR constructor can communicate with the external BSR directly. The problem with this approach is that two components must now interact directly with MQSeries instead of isolating this interface to a single component.