SPECjAppServer2004 Design Document

Version 1.08
Last Modified: January 28, 2005

Table of Contents

Section 1 - Introduction

• 1.1 Goals of SPECjAppServer2004

• 1.2 Business and Application Environment

Section 2 - Application Design

• 2.1 Model for Dealer Domain

• 2.2 Model for Customer Domain

• 2.3 Model for Manufacturing Domain

• 2.4 Model for Supplier Domain

• 2.5 Model for Corporate Domain

• 2.6 Database Model

Section 3 - Workload Description

• 3.1 Definition of Terms

• 3.2 Web Interactions in the Dealer Domain

• 3.3 ECtransactions in the Customer Domain

• 3.4 ECtransactions in the Manufacturing Domain

• 3.5 ECtransactions in the Corporate Domain

• 3.6 ECtransactions in the Supplier Domain

• 3.7 Supplier Emulator

• 3.8 DealerEntry Application

• 3.9 Manufacturing Application

• 3.10 Sample Configurations

Appendix A - UML Diagrams

• A.1 Dealer Domain Class Diagram

• A.2 Corporate Domain Class Diagram

• A.3 Customer Domain Class Diagram

• A.4 Manufacturing Domain Class Diagram

• A.5 Supplier Domain Class Diagram

• A.6 Util Class Diagram

Section 1 - Introduction

1.1 Goals of SPECjAppServer2004

SPECjAppServer2004 is a Java 2 Enterprise Edition (J2EE) benchmark meant to measure the scalability and performance of J2EE servers and containers.

Fundamentally, J2EE is an infrastructure for building scalable, distributed applications which are implemented using Web components and component-oriented Object Transaction Middleware (OTM). As demand increases, J2EE applications need to scale automatically. The SPECjAppServer2004 workload, if it is to truly help improve the performance seen by real customers, should therefore possess the characteristics shown in Table1.

Aspects of everyday DBMS scalability (e.g., database I/O, concurrency, memory management, etc.) are not the focus of this workload. These are adequately stressed by other standard workloads such as TPC-C, TPC-D, TPC-W, etc. SPECjAppServer2004 stresses the ability of J2EE application servers to handle the complexities of dynamic Web page generation, memory management, connection pooling, passivation/activation, object persistence, caching, message queuing, etc.

Comment: While separated from the main text for readability, comments are a part of the design specification, and are meant to provide further clarification on the specific section.

NOTE: A notation such as this describes features in the specification that are not part of the current design. By leaving the wording in the document, it is easier to expand the workload in future versions.

1.2 Business and Application Environment

For reasons of interest, scope, and familiarity, we make use of manufacturing, supply chain management, and order/inventory as the "storyline" of the business problem. This is a meaty, industrial-strength distributed problem. It is heavyweight, mission-critical, worldwide, 7x24, and necessitates use of a powerful and scalable infrastructure. It is one that many Fortune 500 companies are interested in. Most importantly, it requires use of interesting J2EE services, including:

• Dynamic Web page generation
• Transactional components
• Distributed Transactions
• Messaging and asynchronous task management
• Multiple company service providers with multi-site servers
• Interfaces to, and use of, legacy applications
• Secure transmissions
• Role-based authentication
• Object persistence

FIGURE 1: SPECjAppServer2004 World Wide Distributed Business

Businesses aggressively use the Web to permit customers direct specification of product configuration, ordering, and status checking. The businesses strive to fully automate manufacturing, inventory, supply chain management, and customer billing. Figure 1 depicts the essence of what such a business looks like.

Using "Just in Time" manufacturing concepts, they seek maximum efficiency and minimum inventories. Their customer and business processes run concurrently, are transactional, secure, worldwide, 24x7, and fully distributed. Companies like these want their application developers to focus on the business logic, not the complexities and subtleties of scalable transactions, messaging, directory/naming, security, authentication, or the mapping of services onto specific H/W. These businesses prefer to develop using a RAD/IDE infrastructure based on extensible, scalable, distributed components.

Figure 2 depicts the same business as Figure 1, but shows logical domains. The term Domain refers to a logical entity that describes a distinct business sphere of operations.

The five SPECjAppServer2004 domains modeled are : Dealer, Manufacturing, Supplier, Customer, and Corporate. The Dealer domain encompasses the user interface components of a Web-based application used to access the services provided by the other domains (i.e., Manufacturing, Supplier, Customer and Corporate), which can be considered "business domains."  In a company of the size being modeled, it is assumed that each business domain, has separate databases and applications. Most likely, they are implemented on separate computing hardware also. There are producer-consumer relationships between domains in the company and to outside suppliers and customers as well. For historical reasons, each business domain may have distinct entity IDs (i.e., the customer ID used in the customer domain may be different from the ID used for that same customer in the Supplier domain). It is for this reason that global customer or supplier databases are likely to exist in the Corporate domain, with accompanying applications.

FIGURE 2: SPECjAppServer2004 Multi-Domain Worldwide Business

Distributed databases and applications provide the foundation for the SPECjAppServer2004 workload. Customers (such as Automobile Dealers) contact the business through any number of methods, including directly through the Web. Person-to-person contacts, such as over the telephone or through a salesperson, map into this Web access scheme also, as the customer service representative or salesperson themselves use the Web interface. All of the worldwide offices and plants make frequent access to data held in the other offices or plants, and must, at times, compare/collate/verify their data against that held worldwide. The company also interacts with completely separate supplier companies. Each supplier has its own independent set of computing resources.

The SPECjAppServer2004 enterprise business is a successful one. It grows via any number of different means. These include simple growth as well as diversification and corporate mergers. The first method, growth, means simply that the company gains more customers and sells more products. Its factories grow bigger, and it has more of them. The business needs a variety of suppliers; they grow also.

The SPECjAppServer2004 business can also grow via diversification or through mergers. In both these cases, the company, now a conglomerate, may take on entirely new lines of business. It sets up new divisions, each with its possibly distinct set of customers and suppliers. The union of a new division's customers, manufacturing plants, and suppliers is called a Production Group (PG). Figure 3 shows the state of the company after it has gone through a number of stages of growth. As the number of PGs increases, the sizes of the existing PGs grow larger and the newest one is the smallest. A single Corporate Domain acts as a coordination point between the various PGs. This represents a non-linear scaling model as found in the real world.

NOTE: SPECjAppServer2004 is restricted to a single Production Group. See Section 2 of the SPECjAppServer2004 Run and Reporting Rules for detailed scaling information within this PG.

FIGURE 3: Scaling the Distributed Worldwide SPECjAppServer2004 Business

The SPECjAppServer2004 business is a worldwide operation. Its manufacturing, assembly, or distribution plants are scattered among many cities. Each location has multiple computers, each of which might be an application server, database server, multiplexer of client connections, or whatever. End users may have desktops, webtops, etc. It is not surprising that there are many different computers doing many different types of things for this business. Some computers provide just a single service (contain a single, vital database, for example), whereas others consolidate many services. Some computers may be configured in a Highly Available (H/A) configuration, so that services can continue if a node fails. Cost factors might dictate, on the other hand, that not all of the business' computers can have failover. Instead, the business may configure redundant services mapped to independent computers, leaving it to the runtime environment to find a provider for that business service.

The SPECjAppServer2004 business consists of customers, plants (manufacturing, assembly, or distribution), and suppliers. The business is complex, distributed, and makes use of many independent computers arranged in a variety of topologies. It suggests a large number of interesting ways to stress application servers and middleware.

The SPECjAppServer2004 workload has been specifically modeled after an automobile manufacturer whose main customers are automobile dealers.  Customers use a Web based user interface to browse the products catalog, purchase and sell automobiles, and track dealership inventory.

Section 2 - Application Design

2.1 Model for Dealer Domain

The application implements a Web based user interface that allows customers, in our case automobile dealers, to keep track of their accounts, keep track of dealership inventory, sell automobiles, manage a shopping cart and purchase automobiles.

The Web components in the Dealer Domain communicate with the business domains via the appropriate session beans that provide the services required.  Dealer domain components do not communicate directly with the database nor entity beans.  Interactions with the session beans in the business domains are encapsulated in the SpecAction class.

A UML Diagram for the Dealer Domain is shown in Appendix A.1.

2.1.1 Web Component Definitions

The Web application in the dealer Domain consists of a single controller Servlet, SpecAppServlet, which handles the initial point of contact for handling web requests. A number of JSPs provide the specific user interfaces for the Web interactions.

2.1.1.1 SpecAppServlet

This is the controller Servlet which handles all incoming requests and dispatches them to the appropriate JSPs.  Web interactions and dispatch actions are encapsulated in the SpecServletAction class.  Business logic and access to EJBs in the other domains is encapsulated in the SpecAction class.

2.1.1.2 Dealer Welcome JSP (welcome.jsp)

This is the dealer welcome page. This component enables dealers to login to the application.  Users enter a Dealer Id and, if valid,  the application proceeds to the dealer home page. 

2.1.1.3 Dealer Home JSP (SpecJhome.jsp)

This JSP displays user statistics and provides an account summary.  It also displays user navigation statistics by including the Login Summary JSP. 

2.1.1.4 Login Summary JSP (loginSummary.jsp)

This JSP displays user navigation statistics such as the login date, the total amount of purchases, the total amount of sales, the number of orders placed and cancelled, the number of inventory sell actions and the number of pages visited.

2.1.1.5 Dealer Inventory JSP (dealerinventory.jsp)

This JSP displays the list of items in the dealer inventory plus a list of open orders.  From the item list, users can sell items.  Orders can be cancelled from the list of open orders.

2.1.1.6 Dealer Shopping Cart JSP (shoppingcart.jsp)

This JSP displays the list of items in the dealer's shopping cart.  From this page, users can purchase the items in the cart (immediate or deferred), remove items from the cart, or completely clear its content. 

2.1.1.7 Dealer Purchase JSP (purchase.jsp)

This JSP displays a list of items available for purchase and allows users to add items to their shopping cart.  This page also provides the ability to page back and forth through the list of items.

2.1.1.8 Dealer Order JSP (order.jsp)

This JSP displays detailed information for orders placed via the shopping cart.

2.1.1.9 Dealer Application Header (dealership_incl_header.jsp)

This JSP, common to all application Web pages, provides hyper links to the various functional areas of the application: Dealership Inventory, Shopping Cart, Purchase Automobiles and Logoff. 

2.1.1.10 Dealer Application Footer (dealership_incl_footer.jsp)

This JSP, common to all application Web pages, provides a mechanism to query the product catalog for a given inventory id.

2.1.1.11 Error JSP (error.jsp)

This JSP provides a common, standardized way of displaying application errors to the user.

2.2 Model for Customer Domain

Work in the Customer Domain is OLTP in nature. Functionality in this domain includes adding new orders,  retrieving status of a particular order or all orders of a particular customer, and canceling a given order.

When orders arrive from customers, a credit check is performed on the customer by sending a request to the Corporate domain.  In addition, the proper discount is calculated.

A customer or salesperson can view the status of a particular order. A customer can also check the status of all his outstanding orders.

2.2.1 Bean Definitions

A UML Diagram for the Customer Domain is shown in Appendix A.3.

2.2.1.1 OrderSes

The OrderSes stateless session bean implements order entry  transactions run in the Customer Domain such as creating new orders, canceling orders, getting order status getting customer status, and getting open orders.   It uses various entity beans (OrderEnt, OrderLineEnt, ItemEnt) to implement its methods. For large orders, this bean sends a message to the LargeOrderQueue in the Manufacturing Domain. The DealerEntry application uses the methods of the OrderSes interface and never accesses the entity beans directly.

2.2.1.2 OrderEnt

This entity bean manages access to the Orders table.  

2.2.1.3 OrderLineEnt

This entity bean manages access to the OrderLine table and is called from within the OrderEnt bean. Client applications do not directly access this bean as it is a dependent object.

Comment: According to the EJB 2.0 specification, dependent objects such as this are best implemented as separate Java classes (not enterprise beans). However, since the purpose of SPECjAppServer2004 is partly to stress EJB performance, the decision was made to implement OrderLine as an entity bean.

2.2.1.4 ItemEnt

This entity bean manages access to the Item table and is called from within the OrderEnt bean. Client applications do not directly access this bean.

2.2.1.5 ItemBrowserSes

This stateful session bean is used to browse the items table via the ItemEnt entity bean. This bean caches all items for quick retrieval.

2.2.1.6 FullfilOrderMDB

This message driven bean is responsible for processing messages arriving in the FulfillOrderQueue.  The bean updates customer inventory and marks the corresponding order as completed.

2.3 Model for Manufacturing Domain

This domain models the activity of production lines in a manufacturing plant. There are two types of production lines: Planned lines and LargeOrder lines. The Planned lines run on schedule and produce a pre-defined number of widgets. On the other hand, the LargeOrder lines run only when a large order is received from a customer such as a dealer.

Manufacturing begins when a WorkOrder enters the system. Each WorkOrder is for a specific quantity of a particular type of widget. The planned line WorkOrders are typically created as a result of a forecasting application. The LargeOrder line WorkOrders are generated as a result of customer orders. When a WorkOrder is created, the Bill of Materials (BOM) for the corresponding type of widget is retrieved and the required parts are taken out of inventory. As the widgets move through the assembly line, the WorkOrder status is updated to reflect progress. Once a WorkOrder is complete, it is marked as complete and inventory updated.

As inventory of parts gets depleted, suppliers need to be located and purchase orders need to be sent out. This is done by contacting the Supplier Domain.

2.3.1 Bean Definitions

A UML Diagram for the Manufacturing Domain is shown in Appendix A.4.

2.3.1.1 WorkOrderSes

This stateless session is used to perform operations on work orders and it relies on the WorkOrderEnt entity bean to accomplish its tasks.

2.3.1.2 WorkOrderEnt

This entity bean manages access to the WorkOrder table in the manufacturing database.

2.3.1.3 LargeOrderSes

This stateless session bean handles the searching of Large Orders. The bean uses the LargeOrderEnt entity bean to accomplish this task.

2.3.1.4 LargeOrderMDB

This message driven bean is responsible for processing messages arriving in the LargeOrderQueue and creating the corresponding large orders. The bean uses the LargeOrderEnt entity bean to accomplish this task.

2.3.1.5 LargeOrderEnt

This entity bean manages the large orders that are queued from the Customer Domain onto the LargeOrderQueue and handled by the LargeOrderMDB bean.

2.3.1.6 ReceiveMDB

This message driven bean is responsible for processing messages arriving in the ReceiveQueue and adding components to the inventory. The bean uses the ComponentEnt entity bean to accomplish its tasks.

2.3.1.7 PartEnt

This entity bean is the super class for all entity beans that require access to the component table in the manufacturing database. It is responsible for performing all operations on the Parts table.

2.3.1.8 AssemblyEnt

This entity bean is responsible for managing assemblies. An assembly is represented by a row in the Parts table and is made up of several components.

2.3.1.9 ComponentEnt

This entity bean manages access to the components and assemblies in the Parts table.

2.3.1.10 InventoryEnt

This entity bean manages access to the Inventory table in the manufacturing database. It provides methods to add and remove inventory.

2.3.1.11 BOMEnt

This entity bean manages access to the BOM table in the manufacturing database. It provides methods to retrieve information about the parts that are required to create a manufactured component.

2.4 Model for Supplier Domain

This domain is responsible for interactions with suppliers. The Supplier Domain decides which supplier to choose based on the parts that need to be ordered, the time in which they are required and the price quoted by suppliers. The company sends a purchase order to the selected supplier. The purchase order will include the quantity of various parts being purchased, the site it must be delivered to and the date by which delivery must happen. When parts are received from the supplier, the Supplier Domain sends a message to the Manufacturing Domain to update inventory.

2.4.1 Beans in Supplier Domain

An UML Diagram for the Supplier Domain is shown in Appendix A.5.

2.4.1.1 BuyerMDB

This message driven bean issues Purchase Orders based on requests it receives from the Manufacturing domain via the BuyerQueue.  The bean uses the ComponentEnt, SupplierEnt, and POEnt entity beans to complete its tasks.

2.4.1.2 ReceiverSes

Each instance of this stateless session bean manages the delivery of components related to one Purchase Order. The bean uses the following entity beans to complete its tasks: POEnt, and SComponentEnt.

2.4.1.3 SupplierEnt

This entity bean manages access to the Suppliers table in the supplier database.

2.4.1.4 SupplierComponentEnt

This entity bean manages access to the SupplierComponent table in the supplier database. The bean is called from within SupplierEnt.

2.4.1.5 POEnt

This entity bean manages access to the PurchaseOrder table in the supplier database. It is also responsible for creation of the PO Lines that are in the purchase order.

2.4.1.6 POLineEnt

This entity bean manages access to the PurchaseOrderLine table in the supplier database. The bean is called from within POEnt.

2.4.1.7 SComponentEnt

This entity bean manages access to the Component table in the supplier database.

2.5 Model for Corporate Domain

This domain manages the global list of customers and their inventories. Credit information, including credit limits, about all customers is kept solely in a database in the Corporate Domain. This is to provide security and privacy.

2.5.1 Beans in Corporate Domain

The UML Diagram for the Corporate Domain beans is shown in Appendix A.2.

2.5.1.1 CustomerSes

This stateless session bean is the entry point for services that require access to customer  and customer inventory information (CustomerEnt and CustomerInventoryEnt beans), including checking that a dealer is a valid customer, getting customer and customer inventory information, adding items to the customer inventory, selling customer inventory items, and performing customer credit checks.

2.5.1.2 CustomerEnt

This entity enterprise bean is responsible for keeping track of customer information in the Corporate database. Client applications never make calls to this bean directly.

2.5.1.3 CustomerInventoryEnt 

This entity bean manages the information on customer inventory items.

2.6 Database Model

The components of the SPECjAppServer2004 database are defined to consist of 4 separate and individual databases (See section 2.3.3 of the SPECjAppServer2004 Run and Reporting Rules for how these databases can be combined). A database exists in each of the domains and consists of multiple tables. The benchmark implementation assumes a relational database accessible via JDBC. This is because it is more likely that enterprises will move their applications to the component model first, leaving their data in legacy databases.

2.6.1 Corporate Database

The Corporate database exists in the Corporate domain and has the master copy of customers, suppliers and parts. Some of this information will be duplicated in other databases. Assume that a nightly (or weekly) batch program will extract data from the Corporate database, massage it as necessary, and refresh the corresponding tables in the other databases.

2.6.1.1 Customer Table

The customer table contains information on all customers of the company. A part of this table is replicated in other domains. Confidential information such as credit rating/limit, account balance etc. is kept only in the Corporate database. Other domains must query this table to obtain the information.

C_ID

integer

C_FIRST

char(16)

C_LAST

char(16)

C_STREET1

char(20)

C_STREET2

char(20)

C_CITY

char(20)

C_STATE

char(2)

C_COUNTRY

char(10)

C_ZIP

char(9)

C_PHONE

char(16)

C_CONTACT

char(25)

C_SINCE

date

C_BALANCE

numeric(12,2)

C_CREDIT

char(2)

C_CREDIT_LIMIT

numeric(12,2)

C_YTD_PAYMENT

numeric(12,2)

2.6.1.2 Parts Table

There is a single global parts table that identifies all widgets of the company. These include widgets that are manufactured (i.e., assemblies) and components that are purchased.

P_ID

char(20)

P_NAME

char(35)

P_DESC

varchar(100)

P_REV

char(6)

P_UNIT

char(10)

P_COST

numeric(12,2)

P_PRICE

numeric(12,2)

P_PLANNER

integer

P_TYPE

integer

P_IND

integer

P_LOMARK

integer

P_HIMARK

integer

The attribute, P_TYPE indicates what type of product this is. If P_IND specifies Manufactured, it should have a corresponding entry in the BOM table. Only Manufactured parts are part of the ITEM table in the Orders database.

2.6.1.3 Supplier Table

The supplier table contains a list of all suppliers for the company.

SUPP_ID

integer

SUPP_NAME

char(16)

SUPP_STREET1

char(20)

SUPP_STREET2

char(20)

SUPP_CITY

char(20)

SUPP_STATE

char(2)

SUPP_COUNTRY

char(10)

SUPP_ZIP

char(9)

SUPP_PHONE

char(16)

SUPP_CONTACT

char(25)

2.6.1.4 Site Table

The site table contains addresses of various sites of the company. These include manufacturing sites (locations where suppliers ship widgets to) and warehouses (locations where the company ships widgets from).

Table Name: C_site

SITE_ID

integer

SITE_NAME

char(16)

SITE_STREET1

char(20)

SITE_STREET2

char(20)

SITE_CITY

char(20)

SITE_STATE

char(2)

SITE_COUNTRY

char(10)

SITE_ZIP

char(9)

2.6.1.5 Customer Inventory Table

This table keeps track of items in customer inventories.

Table Name: C_customerinventory

CI_ID

integer

CI_ITEMID

char(20)

CI_QUANTITY

integer

CI_CUSTOMERID

integer

CI_VALUE

numeric(12,2)

2.6.2 Orders Database

The Orders database exists in the Customer Domain.  New orders can be created, existing orders changed, and status of orders retrieved.

2.6.2.1 Orders Table

Table Name: O_orders

O_ID

integer

O_C_ID

integer

O_OL_CNT

integer

O_DISCOUNT

numeric(4,2)

O_TOTAL

numeric(12,2)

O_STATUS

integer

O_ENTRY_DATE

timestamp

O_SHIP_DATE

date

2.6.2.2 OrderLine Table

Table Name: O_orderline

OL_ID

integer

OL_O_ID

integer

OL_I_ID

char(20)

OL_QTY

integer

OL_TOTAL_VALUE

numeric(12,2)

OL_MSRP

numeric(12,2)

OL_STATUS

integer

OL_SHIP_DATE

date

2.6.2.3 Item Table

Table Name: O_item

I_ID

char(20)

I_NAME

char(35)

I_DESC

varchar(100)

I_PRICE

numeric(12,2)

I_DISCOUNT

numeric(6,4)

I_CATEGORY

integer

2.6.3 Manufacturing Database

The Manufacturing database exists in the Manufacturing domain and handles the manufacturing of assemblies, BOMs, inventory and management of the shop floor. A customer is any person or organization that orders items. Customers order widgets - these are the products manufactured by the company (for simplicity, it is assumed that the company is not a reseller). All manufactured widgets are assemblies and must have an entry in the BOM table. Assemblies are comprised of components. The list of all assemblies and components make up the global parts table. A single P_ID uniquely identifies every component that the company handles.

2.6.3.1 Parts Table

This table is derived from the Parts table in the Corporate Domain.

Table Name: M_parts

P_ID

char(20)

P_NAME

char(35)

P_DESC

varchar(100)

P_REV

char(6)

P_PLANNER

integer

P_TYPE

integer

P_IND

integer

P_LOMARK

integer

P_HIMARK

integer

2.6.3.2 BOM Table

The BOM table holds the bill of materials for the various widgets produced by the company. Each widget (assembly) is comprised of multiple components. For simplicity, sub-assemblies are not dealt with (i.e., the components in an assembly cannot in turn be assemblies).

Table Name: M_bom

B_COMP_ID

char(20)

B_ASSEMBLY_ID

char(20)

B_LINE_NO

integer

B_QTY

integer

B_OPS

integer

B_ENG_CHANGE

char(10)

B_OPS_DESC

varchar(100)

There will be multiple rows for each assembly in this table that lists all its components.

2.6.3.3 WorkOrder Table

The manufacturing operations are managed by the use of WorkOrders. WorkOrders indicate what needs to be manufactured and are used to track progress through the assembly line.

Table Name: M_workorder

WO_NUMBER

integer

WO_O_ID

integer

WO_OL_ID

integer

WO_STATUS

integer

WO_ASSEMBLY_ID

char(20)

WO_ORIG_QTY

integer

WO_COMP_QTY

integer

WO_DUE_DATE

date

WO_START_DATE

timestamp

The system creates a work order and assigns it a number. The work order may be for a batch assembly or for a single sales order item. If the latter, the fields WO_O_ID and WO_OL_ID will identify the particular order line this work order is for. WO_STATUS monitors progress of this work order and will contain values such as OPEN, STARTED, CANCELLED, COMPLETED, ARCHIVED.

2.6.3.4 LargeOrder Table

This table is a temporary repository for large custom orders that are received in the Customer Domain. The Driver will create work orders for each entry in this table and then delete it.

Table Name: M_largeorder

LO_ID

integer

LO_O_ID

integer

LO_OL_ID

integer

LO_ASSEMBLY_ID

char(20)

LO_QTY

integer

LO_DUE_DATE

date

LO_CATEGORY

integer

2.6.3.5 Inventory Table

The inventory table contains data about all parts - finished assemblies and components.

Table Name: M_inventory

IN_P_ID

char(20)

IN_QTY

integer

IN_ORDERED

integer

IN_LOCATION

char(20)

IN_ACC_CODE

integer

IN_ACT_DATE

date

2.6.4 Supplier Database

The Supplier database exists in the Supplier Domain and handles interaction with suppliers. Purchase orders for parts are issued to suppliers from this domain and received inventory transferred to the Manufacturing Domain.

2.6.4.1 Supplier Table

Table Name: S_supplier

Except for the name, this table is identical to the Supplier table in the Corporate database. See section 2.6.1.3

2.6.4.2 Site Table

Table Name: S_site

Except for the name, this table is identical to the Site table in the Corporate database. See section 2.6.1.4.

2.6.4.3 Component Table

This table contains information on all the components that are purchased from outside suppliers. Its schema is derived from the Parts table in the Corporate database.

Table Name: S_component

COMP_ID

char(20)

COMP_NAME

char(10)

COMP_DESC

varchar(100)

COMP_UNIT

char(10)

COMP_COST

numeric(12,2)

QTY_ON_ORDER

integer

QTY_DEMANDED

integer

LEAD_TIME

integer

CONTAINER_SIZE

integer

2.6.4.4 PurchaseOrder Table

The company issues purchase orders to its suppliers. Each PO will contain multiple lines (one for each part).

Table Name: S_purchase_order

PO_NUMBER

integer

PO_SUPP_ID

integer

PO_SITE_ID

integer

2.6.4.5 PurchaseOrderLine Table

Table Name: S_purchase_orderline

POL_NUMBER

integer

POL_PO_ID

integer

POL_P_ID

char(20)

POL_QTY

integer

POL_BALANCE

numeric(12,2)

POL_DELDATE

date

POL_MESSAGE

varchar(100)

Comment: POL_P_ID is the part number. In reality, it should be the supplier's part number. To do this, a mapping between the part numbers and the suppliers is required (a complicated scenario, since it is desirable to have multiple suppliers for each part). The supplier part number is usually part of the BOM but to keep things simple, a single part number is used throughout.

2.6.4.6 SupplierComponents Table

This table maintains a list of suppliers for each component that is purchased. Whenever a supplier responds to a bid request, information in this table is updated with the latest pricing and availability information.

SC_P_ID

char(20)

SC_SUPP_ID

integer

SC_PRICE

numeric(12,2)

SC_QTY

integer

SC_DISCOUNT

numeric(6,4)

SC_DEL_DATE

integer

2.6.5 Utility Database

The Utility database exists in the Util Domain and handles blocks of sequence numbers for Orders, WorkOrders, and Customers.

2.6.5.1 Sequence Table

This table contains blocks of sequence numbers used for the various domains.

Table Name: U_sequences

S_ID

varchar(50)

S_NEXTNUM

integer

S_BLOCKSIZE

integer

Section 3 - Workload Description

3.1 Definition of Terms

The term Test Submitter refers to the organization that is submitting a benchmark result and is responsible for the accuracy of the submission.

The term Driver refers to code that drives the benchmark. The Driver implements the run rules described in section 2 of the SPECjAppServer2004 Run and Reporting Rules, keeps track of various statistics and reports the final metric. See section 2.8 of the SPECjAppServer2004 Run and Reporting Rules for more details on the Driver.

The term EJB Container refers to the runtime environment that controls the lifecycle of the enterprise beans of the SPECjAppServer2004 workload. Refer to the J2EE 1.3 and EJB 2.0 specifications for more details.

The term Web Container refers to the runtime environment that controls the execution of Servlets and JSPs.  Refer to the J2EE 1.3 specifications for more details.

The term ECtransaction refers to a remote method call on an Enterprise Java Bean.

The term Web Interaction refers to an HTTP request to the Web-based portion of the application.

The term Business Transaction refers to a unit of work initiated by the Driver and may involve one or more ECtransactions and/or Web Interactions.

The term Database Transaction as used is this specification refers to a unit of work on the database with full ACID properties as described in section 2.10 of the SPECjAppServer2004 Run and Reporting Rules. A database transaction is initiated by the EJB Container or an enterprise bean as part of a transaction.

The term [x .. y] represents a closed range of values starting with x and ending with y.

The term randomly selected within [x .. y] means independently selected at random and uniformly distributed between x and y, inclusively, with a mean of (x+y)/2, and with the same number of digits of precision as shown. For example, [0.01 .. 100.00] has 10,000 unique values, whereas [1 ..100] has only 100 unique values.

The term non-uniform random function (NURand) is used in this specification to refer to the method used for generating customer IDs, and part numbers. This method generates an independently selected and non-uniformly distributed random number over the specified range of values [x .. y], and is specified as follows:

NURand(A, x, y) = ((random(0, A) | random(x, y)) % (y - x + 1)) + x

where:

expr1 | expr2 stands for the bitwise logical OR operation between expr1 and expr2
expr1 % expr2 stands for expr1 modulo expr2
random(x, y) stands for randomly selected within [x .. y]
A is a constant chosen according to the size of the range [x .. y]
NURand is defined in the TPC-W benchmark specification which is copyrighted by the TPC.

The term Measurement Interval is used in this specification to refer to a steady state period during the execution of the benchmark for which the test submitter is reporting a performance metric (See section 2.9 of the SPECjAppServer2004 Run and Reporting Rules for detailed requirements).

The term Response Time is used in this specification to refer to the time elapsed from the first byte sent by the Driver to request a business transaction until the last byte received by the Driver to complete that business transaction (See section 2.6.2 and 2.7.1 of the SPECjAppServer2004 Run and Reporting Rules for detailed requirements).

The term Injection Rate is used in this specification to refer to the rate at which business transaction requests from the Dealer application in the Dealer Domain are injected into the SUT.

The term Delay Time is used in this specification to refer to the time elapsed from the last byte received by the Driver to complete a business transaction until the first byte sent by the Driver to request the next business transaction. The Delay Time is a function of the response time and the injection rate. For a required injection rate, the delay time will be smaller for larger response times.

The term Cycle Time is used in this specification to refer to the time elapsed from the first byte sent by the Driver to request a business transaction until the first byte sent by the Driver to request the next business transaction. The Cycle Time is the sum of the Response Time and Delay Time.

3.2 Web Interactions in the Dealer Domain

The primary application in the Dealer domain is DealerEntry.  The DealerEntry Driver implements the business transactions in this domain by making HTTP requests to the Web application in the Dealer domain. See section 3.8 for a description of the DealerEntry application.  The Web Interactions in the Dealer domain are described below.

3.2.1 doWelcome

This Web Interaction displays the welcome page of the application, which is used to login to the application.

3.2.2 doLogin

This Web interaction logs the user into the application using the supplied Dealer ID, established the appropriate session attributes and invokes the doHome Web Interaction.   User login is accomplished by invoking the validateCustomer method in the CustomerSes bean.

3.2.3 doHome

This Web Interaction displays the home page with personalized user information.

3.2.4 doLogout

This Web Interaction log the user out of the application by invalidating the session and transferring control to the doWelcome Web Interaction.

3.2.5 doVehicleQuotes

This Web Interaction displays catalog items.  If coma-separated list of  Item IDs is supplied, those specific items are displayed.  Otherwise, the first ten items of the product catalog are displayed, and the entire list can be navigated by paging forward and backwards through the catalog.  This Web Interaction invokes the getItems, browseReverse, browseForward, getCurrentMin, getCurrentMax, and getTotalItems methods of the ItemBrowserSes bean.

3.2.6 doShoppingCart

The Web Interaction displays the content of the shopping cart, which is maintained as a session attribute in an ShoppingCart object.

3.2.7 doAddToShoppingCart

This Web Interaction add an item to the shopping cart by populating a ShoppingCartDataBean object and adding it to the ShoppingCart object associated with the user session.

3.2.8 doRemoveFromShoppingCart

This Web Interaction removes a single item from the shopping cart.

3.2.9 doClearCart

This Web Interaction removes (clears) all items from the shopping cart.

3.2.10 doPurchase

This Web Interaction purchases all items in the shopping cart by invoking the newOrder method of the OrderSes bean.  The shopping cart is cleared.

3.2.11 doDeferedPurchase

This Web Interaction submits a deferred purchase of all items in the shopping cart by invoking the newOrder method of the OrderSes bean.  The shopping cart is cleared.

3.2.12 doCancelOrder

This Web Interaction cancels an open order by invoking the cancelOrder method of the OrderSes bean.

3.2.13 doSell

This Web Interaction sells a number of items for a given entry in the dealer inventory.  This is accomplished by invoking the sellInventory method of the CustomerSes bean.

3.2.14 doInventory

This Web Interaction displays the list of items in the dealer inventory as well as the list of open order for the dealer. This is accomplished by invoking the getInventory method of the CustomerSes bean and the getOpenOrders and getItemInfo methods of the OrderSes bean.

3.3 ECTransactions in the Customer Domain

The Customer domain is responsible for managing (e.g., creating, canceling, changing) orders, checking customer credit and providing access to the items catalog.

3.3.1 NewOrder

This ECtransaction will enter a new order for a customer having a certain number of order-lines. This ECtransaction is implemented by the newOrder method of the OrderSes bean. It gets the price of all items ordered, taking into account the item discount and calculate the order total. It then computes the customer's discount for this order and checks whether the customer has sufficient credit to cover his or her purchase. If the customer does not have enough credit, it returns an error. Otherwise, it enters a row in the orders table, and as many rows in the OrderLine table, as the number of items. Large orders will trigger a message to be submitted to the LargeOrderQueue for processing by the Manufacturing domain.

3.3.2 GetOrderStatus

This ECtransaction gets the status of a particular order and all its OrderLines. This ECtransaction is implemented by the getOrderStatus method of the OrderSes bean. It finds the customer ID and order ship date for the order that corresponds to orderId. For all order lines that belong to this order, it retrieves the item ID, quantity of items ordered and OrderLine ship date.

3.3.3 GetCustomerStatus

This ECtransaction gets the status of all outstanding orders for a particular customer. This ECtransaction is implemented by the getCustomerStatus method of the OrderSes bean. For each order that has not yet been delivered for this customer, it retrieves the order ID, count of OrderLines and order ship date. For all order lines in this order, it retrieves the item ID and quantity.

3.3.4 CancelOrder

This ECtransaction cancels an order by deleting the order row as well as its associated OrderLine rows. This ECtransaction is implemented by the cancelOrder method of the OrderSes bean.

3.3.5 GetOpenOrders

This ECtransaction retrieves all open orders for a user as a Collection of OrderDataBean objects. This ECtransaction is implemented by the getOpenOrders method of the OrderSes bean.

3.3.6 GetItemInfo

This ECptransaction retrieves a list of catalog items, given a list of item ids. This ECtransaction is implemented by the getItemInfo method of the OrderSes bean.

3.3.7 GetItems

This ECTransaction retrieves a collection of up to ten catalog items based on a comma-separated query list of item ids. This ECtransaction is implemented by the getItems method of the ItemBrowserSes bean.

3.3.8 BrowseForward

This ECTransaction retrieves a collection of up to ten catalog items from the last item retrieved previously. This ECtransaction is implemented by the browseForward method of the ItemBrowserSes bean.

3.3.9 BrowseReverse

This ECTransaction retrieves a collection of up to ten catalog items up to the first item retrieved previously. This ECtransaction is implemented by the browseForward method of the ItemBrowserSes bean.

3.4 ECtransactions in the Manufacturing Domain

The Manufacturing domain is responsible for creating and executing WorkOrders and managing the assembly lines.

3.4.1 ScheduleWorkOrder

This ECtransaction is called from the Manufacturing application (see section 3.9) that simulates the normal manufacturing activity of planned lines or the transaction is called for a single sales order. It creates a row in the WorkOrder table, identifies the components that make up this assembly in the BOM and assigns the required parts from inventory. This transaction can cause requests to be queued into BuyerQueue to be processed in the Supplier Domain if it needs any parts with low inventory. This ECtransaction is implemented by the scheduleWorkOrder method of the WorkOrderSes bean.

3.4.2 UpdateWorkOrder

As each station completes its operation, it will update the work order status. This ECtransaction is implemented by the updateWorkOrder method of the WorkOrderSes bean.

3.4.3 CompleteWorkOrder

This ECtransaction marks the work order as complete and transfers widgets to inventory. It gets the assembly ID of this work order and updates the inventory for this assembly. It updates completed quantity and WorkOrder status to COMPLETED. Note that WorkOrders persist indefinitely. This ECtransaction is implemented by the completeWorkOrder method of the WorkOrderSes bean.

3.4.4 CancelWorkOrder

This ECtransaction cancels work orders if possible and adds the inventory back. This ECtransaction is implemented by the cancelWorkOrder  method of the WorkOrderSes bean.

3.4.5 FindLargeOrders

This ECtransaction retrieves all large orders that currently exist in the LargeOrder table. This ECtransaction is implemented by the findLargeOrders method of the LargeOrderSes bean.

3.5 ECtransactions in the Corporate Domain

3.5.1 ValidateCustomer

This ECtransaction checks whether a customer for a given customer id is present in the database. This ECtransaction is implemented by the validateCustomer method of the CustomerSes bean.

3.5.2 GetCustomerInfo

This ECtransaction retrieves customer information for a give customer id.  This ECtransaction is implemented by the getCustomerInfo method of the CustomerSes bean.

3.5.3 GetInventory

This ECtransaction returns a Collection of CustomerInventoryDataBean objects representing all the records in the Customer Inventory table for a given customer id.   This ECtransaction is implemented by the getInventory method of the CustomerSes bean.

3.5.4 SellInventory

This ECtransaction is used to perform the sell of a given quantity for a item id present in a customer's inventory.  If the quantity matches what is held in the inventory, it removes the item from the customer inventory and adjusts the customer's balance.  This ECtransaction is implemented by the sellInventory method of the CustomerSes bean.

3.5.5 AddInventory

This ECtransaction add items to the customer inventory as a result of purchasing the content of the customer's shopping cart or as a result of a large order being fulfilled.  This ECtransaction is implemented by the addInventory  methods of the CustomerSes bean.

3.5.6 CheckCustomerCredit

This ECtransaction checks whether a customer has a credit balance to cover the purchase. This is called from NewOrder ECtransaction in the Customer Domain when a customer enters an order. This ECtransaction is implemented by the CheckCustomerCredit method of the CustomerSes bean.

3.6 ECtransactions in the Supplier Domain

The Supplier Domain is responsible for the supply of components required to complete work orders. Orders for components are received from the Manufacturing Domain and sent to external suppliers. When orders are delivered inventory in Manufacturing is updated.

3.6.1 DeliverPO

This ECtransaction is called from the Supplier Domain servlet when it receives a message from the Supplier Emulator indicating that a purchase order has been delivered. It sends a message to the ReceiverQueue for inventory updating by the ReceiveMDB message driven bean in the Manufacturing domain. In addition this ECtransaction updates the corresponding Purchase Order Line entries with the delivery date.  This ECtransaction is implemented by the deliverPO method of the ReceiverSes bean.

3.7 Supplier Emulator

The Supplier Emulator is a Java Servlet that can run inside any java enabled Web server. It is not part of the SUT, hence must run on a machine that is external to it. It communicates with the SUT by sending and receiving XML documents via a HTTP connection that conforms to the HTTP 1.1 protocol. The emulator provides the Supplier Domain with a way to emulate the process of sending and receiving orders to/from suppliers.

The supplier emulator accepts a purchase order from the BuyerMDB bean in the Supplier Domain, processes the purchase order, and then delivers the order lines contained in the purchase order to the ReceiverSes Bean after sleeping for an amount of time based on the lead time of the component. This interaction between the Supplier Domain and the Emulator is shown in Figure 4.

FIGURE 4: Supplier Emulator Interactions

3.7.1 Purchase Orders

Purchase orders are received from the Supplier Domain (see section 3.6) in XML format over a HTTP connection. Contained in the XML document are the details of the purchase order:

For each line in the purchase order, the following must be provided:

3.7.2 Parts Delivery

On receipt of a purchase order, the Emulator will parse the XML and each purchase order line is extracted. If the XML is in the correct format a positive response is returned over the HTTP connection, otherwise a negative response will be returned. The HTTP connection is then closed.

The purchase order lines are then processed one at a time in ascending order based on lead-time. For each line, an XML document is generated that contains:

The XML for the purchase order line is then transmitted via HTTP to a servlet in the Supplier Domain, which in turn calls the ReceiverSes Bean. Note that a servlet in the Supplier Domain is required as the communication between the Supplier Domain and the Emulator is over http.

3.8 DealerEntry Application

The DealerEntry application is responsible for simulating users utilizing the Web interface in the Dealer domain and generating business transactions to purchase items, manage dealership inventory and browse the items catalog.

The business transaction mix is determined based on the weight associated with each transaction type according to section 2.6.1 of the SPECjAppServer2004 Run and Reporting Rules.

Each business transaction is placed on behalf of a customer, whose Id is randomly selected within [1 .. nCust] where nCust is derived according to section 2.3.4 of the SPECjAppServer2004 Run and Reporting Rules.  

For all of the business transactions, the Driver keeps track of the average response times, targeted and actual cycle times, count of transactions, etc. and generates a report with the final metric and other statistics at the end of the benchmark run.

3.8.1 Purchase Business Transactions

For Purchase Business Transactions, the application then determines whether to place a large order or a small order, to decide the number of items to place in the shopping cart and to select the type of order to place.   90% of the time, small orders are placed. For large orders, the type of order is always immediately purchased and for small orders, 50% of the time the orders are deferred, which results in the creation of open orders. Small orders are those with a total quantity of items randomly selected within [10 .. 20], and large orders are those with a total quantity of items randomly selected within [100 .. 200].  The number of items to order is randomly selected within [1 .. 5] and the quantity to order for each item is determined by dividing the total quantity equally amongst the number of items to order. Items are selected using doVehicleQuotes and added to the shopping cart using doAddToShoppingCart Web Interactions.

Finally, the Driver checks out to effect the purchase. 50% of the time, the shopping cart is checked out immediately after the items have been added to the cart using doPurchase Web Interactions. 40% of the time the cart is cancelled using doClearCart Web Interactions, refilled with doAddToShoppingCart Web Interactions and checked out via doPurchase Web Interactions. 10% of the time all items but one are removed from the shopping cart using doRemoveFromShoppingCart Web Interactions prior to checking it out using the doPurchase Web Interaction.

3.8.2 Manage Business Transactions

For Manage Business Transactions, the application navigates to the dealer inventory page using the doInventory Web Interaction and then cancels open orders until only five are left (if there are less than five open orders, only one of them is cancelled).  Orders are cancelled using the doCancelOrder Web Interaction. In addition, the application sells vehicles in the dealer inventory until only ten are left (if there are less than ten vehicles in the inventory, only one of them is sold).  Vehicles are sold one item type at a time using doSell Web Interactions.

3.8.3 Browse Business Transactions

For Browse Business Transactions, the application navigates to the purchase automobiles Web page and pages a total of thirteen times, ten forward and three backwards using doVehicleQuotes Web Interactions.

3.9 Manufacturing Application

The Manufacturing application runs two types of assembly lines for each PG: Planned and LargeOrder. For simplicity, it is assumed that the work necessary to manufacturing distinct widgets is identical. The only real difference between the lines are how they are scheduled.

The manufacturing driver keeps track of the number of WorkOrders initiated, the number of widgets produced and the average time for the completion of each WorkOrder.

3.9.1 Planned Lines

The Planned Lines run continuously and concurrently, producing, on average, 47% of all widgets. The rate at which widgets are manufactured must roughly equal the rate at which widgets are being ordered. The idea is Just In Time Manufacturing. The factory floors are composed of a grand total of p Planned Lines (see section 2.3.5 of the SPECjAppServer2004 Run and Reporting Rules for the values of p), each with 3 Stations. A Station marks a distinct operation in the manufacturing flow, such as multi-step manufacture, test, packaging, etc.

The Manufacturing driver spawns threads for each Planned Line. Each Planned Line generates WorkOrders at an average rate of 0.2 per second (or 1 WorkOrder in 5 seconds). The type is randomly selected within [1, NUM_ITEMS], where NUM_ITEMS is the number of items being manufactured by the company. 75% of the time, the quantity for the WorkOrder is chosen as 5 and 25% of the time, the quantity is chosen as 6. This yields a rate of 5.25 widgets per WorkOrder.

The first station will get the WorkOrder ID once it is generated. It will then wait for its designated sleep time and update the WorkOrder status. The sleep time is a constant amount of .333 seconds. The WorkOrder moves along to the next station and so on until it reaches the final station (each station is aware of where in the chain it stands). Thus the WorkOrder will spend 1 second in all the 3 stations combined. At the final station, the WorkOrder is marked complete, the items are transferred into inventory. The Response Time Tr from WorkOrder start to finish is measured and the Delay Time Td is computed as:

Td = 5 - Tr

Since the Planned Line needs to produce 1 widget in 5 seconds, Tr can be as high as 5 seconds. If Tr is lower than 5 (i.e., Td > 0), the Planned Line will sleep for Td seconds before looping back to create the next WorkOrder.

3.9.2 LargeOrder Lines

The LargeOrder Lines handle production above and beyond the rate at which the Planned Lines can produce a particular widget. Aggregated, activity on these lines originate from 10% of all orders received and represent approximately 53% of all widgets manufactured.

The Customer Domain notifies the Manufacturing Domain via the LargeOrderQueue every time a LargeOrder is received. The LargeOrder line started from the manufacturing driver checks for the existence of Large orders in the queue and immediately schedules a new WorkOrder for each. The large order dequeueing may be driven by one or more LargeOrder driver agents on multiple driver machines. If more than one LargeOrder agent is used, each agent will process large orders of a different
category. The LargeOrder category is set in round-robin fashion in the Customer Domain upon creation and submission to the queue. The number of categories configured for large orders and the number of  LargeOrder driver agents must be the same.

Like a Planned Line, a Large Order Line has 3 Stations and the same average time spent per station. There are as many concurrent Large Order lines as incoming orders require.

3.10 Sample Configurations

Figure 5 shows an example layout of the Driver and SUT components for the Standard Workload. In this example, the SUT consists of 3 Containers to handle the load. Multiplexing/Load balancing between the Containers is accomplished by a commercial product. All the Domains are combined into a single database.

FIGURE 5: Example configuration for the Standard Workload

Figure 6 shows an example layout of the Driver and SUT components for the Distributed Workload. In this layout, there is a single Container for each of the Domains that manages its own database.

FIGURE 6: Example configuration for the Distributed Workload

Appendix A - UML Diagrams

A.1 Dealer Domain Class Diagram

A.2 Corporate Domain Class Diagram

A.3 Customer Domain Class Diagram

A.4 Manufacturing Domain Class Diagram

A.5 Supplier Domain Class Diagram

A.6 Util Class Diagram