SPECjAppServer2002 Design Document Version 1.00 Last modified: October 01, 2002

Table of Contents

Section 1 - Introduction

• 1.1 Introduction

• 1.2 Business and Application Environment

Section 2 - Application Design

• 2.1 Model for Customer Domain

• 2.2 Model for Manufacturing Domain

• 2.3 Model for Supplier Domain

• 2.4 Model for Corporate Domain

• 2.5 Database Model

Section 3 - Workload Description

• 3.1 Definition of Terms

• 3.2 ECtransactions in the Customer Domain

• 3.3 ECtransactions in the Manufacturing Domain

• 3.4 ECtransactions in the Corporate Domain

• 3.5 ECtransactions in the Supplier Domain

• 3.6 Supplier Emulator

• 3.7 OrderEntry Application

• 3.8 Manufacturing Application

• 3.9 Sample Configurations

Appendix A - UML Diagrams

• A.1 Corporate Domain Class Diagram

• A.2 Customer Domain Class Diagram

• A.3 Manufacturing Domain Class Diagram

• A.4 Manufacturing State Classes

• A.5 Supplier Domain Class Diagram

• A.6 Key Generation Util Class Diagram

Appendix B - Key Differences Between SPECjAppServer2002 and SPECjAppServer2001

• B.1 EJB 2.0 Container Managed Persistence (CMP)
• B.2 Local Interfaces
• B.3 Container Managed Relationships (CMR)
• B.4 EJB Query Language (QL)

Section 1 - Introduction

1.1 Introduction

SPECjAppServer2002 is a Enterprise JavaBeans (EJB)^TM benchmark meant to measure the scalability and performance of J2EE servers and containers.

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

GUI and presentation are not the focus of this workload, nor are aspects of everyday DBMS scalability (e.g., database I/O, concurrency, memory management, etc.). These are adequately stressed by other standard workloads such as TPC-C, TPC-D, TPC-W, etc. SPECjAppServer2002 stresses the ability of EJB containers to handle the complexities of memory management, connection pooling, passivation/activation, caching, etc.

Comment: While separated from the main text for readability, comments are a part of the standard and are enforced.

NOTE: A notation such as this describes features in the specification that are not part of the current standard. 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, scalable infrastructure. It is one that many Fortune 500 companies are interested in. Most importantly, it requires use of interesting Enterprise JavaBeans services, including:

• 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: EJB 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, supplier 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 four SPECjAppServer2002 domains modeled are : Manufacturing, Supplier & Service Provider, Customer, and Corporate. In a company of the size being modeled, it is assumed that each 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 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: Multi-Domain Worldwide Business

Distributed databases and applications provide the foundation for the SPECjAppServer2002 workload. Customers (including distributors, the government, and OEMs) 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 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 company 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: SPECjAppServer2002 is restricted to a single Production Group. See Section 2 of the SPECjAppServer2002 Run and Reporting Rules for detailed scaling information within this PG.

FIGURE 3: Scaling the Distributed Worldwide Business

The Enterprise 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 SPECjAppServer2002 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.

Section 2 - Application Design

2.1 Model for Customer Domain

Work in the Customer Domain is OLTP in nature. An OrderEntry application runs in this domain whose functionality includes adding new orders, changing an existing order and retrieving status of a particular order or all orders of a particular customer.

Orders are placed by individual customers as well as by distributors. The difference between the two is in the quantity of items ordered. Approximately 57% of work on the system is related to orders from distributors (i.e., contain large number of items), 43% is from individual customers. Orders from distributors are also called Large Orders. Orders arrive from existing customers as well as new customers. In either case, a credit check is performed on the customer by sending a request to the Corporate domain. Various discounts are applied to the order depending on whether the customer is a distributor, repeat or first-time customer, etc.

Existing orders may be changed. The quantities of ordered items may be changed or the order may be cancelled in its entirety. Orders that have already shipped or have entered the shipping process cannot be cancelled.

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

2.1.1 Bean Definitions

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

2.1.1.1 OrderSes

The OrderSes stateless session bean implements the OrderEntry transactions run in the Customer Domain. It uses various entity beans (OrderEnt, OrderLineEnt, ItemEnt) to implement its methods. The OrderEntry application uses the methods of the OrderSes interface and never accesses the entity beans directly.

2.1.1.2 OrderEnt

This entity bean manages access to the Orders table.

2.1.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 dependant object.

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

2.1.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.1.1.5 OrderCustomerSes

This stateless session bean is responsible for adding and validating customers within the Customer Domain. It uses the entity bean OrderCustomerEnt to accomplish its tasks.

2.1.1.6 OrderCustomerEnt

This entity bean manages access to the Customer table in the Orders database. It provides methods to add and validate customers and to compute a customer's discount.

2.1.1.7 CartSes

This stateful session bean simulates a shopping cart that a customer would use before placing an order. After a client adds items to the cart, the contents of the cart are bought using the OrderEnt bean.

2.2 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 distributor.

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.2.1 Bean Definitions

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

2.2.1.1 WorkOrderSes

Each instance of this stateless session bean manages one work order and uses the entity bean WorkOrderEnt, and the session bean BuyerSes in the Supplier Domain (see section 2.5) to accomplish its tasks.

2.2.1.2 LargeOrderSes

This stateless session bean handles the creation and searching of Large Orders. This bean uses the entity bean LargeOrderEnt to accomplish its tasks.

2.2.1.3 ReceiveSes

This stateless session bean is created by the ReceiverSes bean in the Supplier Domain (see section 2.3.1.2) and is responsible for adding components to the inventory. This bean uses the entity bean ComponentEnt to accomplish its tasks.

2.2.1.4 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.2.1.5 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.2.1.6 WorkOrderEnt

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

2.2.1.7 LargeOrderEnt

This entity bean manages the large orders that arise from the Customer Domain.

2.2.1.8 ComponentEnt

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

2.2.1.9 InventoryEnt

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

2.2.1.10 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.3 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.3.1 Beans in Supplier Domain

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

2.3.1.1 BuyerSes

This stateful session bean issues Purchase Orders based on requests it receives from the Manufacturing domain and uses the entity beans ComponentEnt, SupplierEnt, and POEnt to complete its tasks.

2.3.1.2 ReceiverSes

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

2.3.1.3 SupplierEnt

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

2.3.1.4 SupplierComponentEnt

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

2.3.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.3.1.6 POLineEnt

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

2.3.1.7 SComponentEnt

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

2.4 Model for Corporate Domain

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

For each new order, the Customer Domain requests a credit worthiness check to the Corporate Domain. Customer discounts are also computed in the Corporate Domain for each new order or whenever an order is changed. The discount computation is based on rules to determine which category the customer belongs to.

2.4.1 Beans in Corporate Domain

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

2.4.1.1 CustomerEnt

This entity enterprise bean is responsible for keeping track of customer information in the Corporate database. See Appendix A for a program listing of the Customer interface. Client applications never make calls to this bean directly.

2.4.1.2 DiscountEnt

This entity bean manages the information on customer discounts.

2.4.1.3 RuleEnt

This entity bean manages the information about rules for customer discounts. The rules for the various categories of discounts are expressed as Java expressions and saved in the database.

2.5 Database Model

The components of the SPECjAppServer2002 database are defined to consist of 4 separate and individual databases (See section 2.3.2 of the SPECjAppServer2002 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.5.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.5.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(9,2)

C_CREDIT

char(2)

C_CREDIT_LIMIT

numeric(9,2)

C_YTD_PAYMENT

numeric(9,2)

2.5.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(15)

P_NAME

char(10)

P_DESC

varchar(100)

P_REV

char(6)

P_UNIT

char(10)

P_COST

numeric(9,2)

P_PRICE

numeric(9,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 (for ex: desktop/server/component). 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.5.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.5.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).

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.5.1.5 Rule Table

The Rule table contains all the customer discount rules, one row per rule. Multiple types of rules are possible in the schema (identified by R_ID), but only one is used - namely, discount.

R_ID

char(20)

R_TEXT

long varchar

2.5.1.6 Discount Table

This table holds the discounts for the various categories of customers. When a customer falls into a particular category (based on the rules in the Rule table), his discount level is looked up in the Discount table.

D_ID

varchar(64)

D_PERCENT

integer

2.5.2 Orders Database

The Orders database exists in the Customer Domain. It handles sales orders and runs the OrderEntry application. New orders can be created, existing orders changed, and status of orders retrieved.

2.5.2.1 Customer Table

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

2.5.2.2 Orders Table

O_ID

integer

O_C_ID

integer

O_OL_CNT

integer

O_TOTAL

numeric(9,2)

O_DISCOUNT

numeric(4,2)

O_ENTRY_DATE

timestamp

O_SHIP_DATE

date

O_STATUS

integer

2.5.2.3 OrderLine Table

OL_ID

integer

OL_O_ID

integer

OL_I_ID

char(15)

OL_QTY

integer

OL_STATUS

integer

OL_SHIP_DATE

date

2.5.2.4 Item Table

I_ID

char(15)

I_PRICE

numeric(9,2)

I_NAME

char(20)

I_DESC

varchar(100)

I_DISCOUNT

numeric(6,4)

2.5.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.5.3.1 Parts Table

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

P_ID

char(15)

P_NAME

char(10)

P_DESC

varchar(100)

P_REV

char(6)

P_PLANNER

integer

P_TYPE

integer

P_IND

integer

P_LOMARK

integer

P_HIMARK

integer

2.5.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).

B_COMP_ID

char(15)

B_ASSEMBLY_ID

char(15)

B_LINE_NO

integer

B_QTY

integer

B_ENG_CHANGE

char(10)

B_OPS

integer

B_OPS_DESC

varchar(100)

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

2.5.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.

WO_NUMBER

integer

WO_O_ID

integer

WO_OL_ID

integer

WO_STATUS

integer

WO_ASSEMBLY_ID

char(15)

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.5.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.

LO_ID

integer

LO_O_ID

integer

LO_OL_ID

integer

LO_ASSEMBLY_ID

char(15)

LO_QTY

integer

LO_DUE_DATE

date

2.5.3.5 Inventory Table

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

IN_P_ID

char(15)

IN_QTY

integer

IN_ORDERED

integer

IN_LOCATION

char(20)

IN_ACC_CODE

integer

IN_ACT_DATE

date

2.5.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.5.4.1 Supplier Table

This table is identical to the Supplier table in the Corporate database. See section 2.5.1.3

2.5.4.2 Site Table

This table is identical to the Site table in the Corporate database. See section 2.5.1.4.

2.5.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.

COMP_ID

char(15)

COMP_NAME

char(10)

COMP_DESC

varchar(100)

COMP_UNIT

char(10)

COMP_COST

numeric(9,2)

QTY_ON_ORDER

integer

QTY_DEMANDED

integer

LEAD_TIME

integer

CONTAINER_SIZE

integer

2.5.4.4 PurchaseOrder Table

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

PO_NUMBER

integer

PO_SUPP_ID

integer

PO_SITE_ID

integer

2.5.4.5 PurchaseOrderLine Table

POL_NUMBER

integer

POL_PO_ID

integer

POL_P_ID

char(15)

POL_QTY

integer

POL_BALANCE

numeric(9,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.5.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(15)

SC_SUPP_ID

integer

SC_PRICE

numeric(9,2)

SC_DISCOUNT

numeric(6,4)

SC_QTY

integer

SC_DEL_DATE

integer

2.5.5 Utility Database

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

2.5.5.1 Sequence Table

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

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 SPECjAppServer2002 Run and Reporting Rules, keeps track of various statistics and reports the final metric. See section 2.8 of the SPECjAppServer2002 Run and Reporting Rules for more details on the Driver.

The term EJB Container (or Container for short) refers to the entity that controls the lifecycle of the enterprise beans of the SPECjAppServer2002 workload. Refer to the EJB 2.0 specifications for more details.

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

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

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 SPECjAppServer2002 Run and Reporting Rules. A database transaction is initiated by the 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 SPECjAppServer2002 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 SPECjAppServer2002 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 OrderEntry application in the Customer 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 ECTransactions in the Customer Domain

The primary application that runs in the customer domain is OrderEntry. This workload does not concern itself with user interactions that are typical in an OrderEntry application. For example, searching for item IDs, getting item descriptions, obtaining and verifying customer information etc. are not dealt with. The OrderEntry Driver implements the business transactions in this domain by making method calls to the CartSes, OrdersSes and OrderCustomerSes beans. See section 3.7 for a description of the OrderEntry application. The ECtransactions are listed below:

3.2.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 calls the Corporate domain to check whether the customer has sufficient credit to cover his 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. If the order is a custom order, it will trigger a LargeOrder to be created in the Manufacturing domain.

3.2.2 ChangeOrder

This ECtransaction will make changes to an existing undelivered order. This ECtransaction is implemented by the changeOrder method of the OrderSes bean. The OrderLine rows are modified appropriately. The quantity fields are updated and the new order total computed. Customer discount and credit are re-evaluated for this new order total. If the quantity is 0, the OrderLine is deleted. If a new itemId is passed, a new order line is added.

3.2.3 OrderStatus

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.2.4 CustomerStatus

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.2.5 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.2.6 AddCustomer

This ECtransaction adds a new customer to the Customer domain. It calls the AddCustomer transaction in the Corp domain to add the customer to the Corporate database as well. This ECtransaction is implemented by the addCustomer method of the OrderCustomerSes bean.

3.2.7 ValidateCustomer

This ECtransaction validates an existing customer by checking if the customer's information has properly formed fields. The primary purpose of this ECtransaction is to simulate some business logic. This ECtransaction is implemented by the validateCustomer method of the OrderCustomerSes bean.

3.2.8 AddToCart

This ECtransaction adds an item to the Cart using the add method of the CartSes bean.

3.2.9 BuyCart

This ECtransaction buys the contents of the Cart by calling the buy method of the CartSes bean. This method in turn calls newOrder on the OrderSes bean.

3.3 ECtransactions in the Manufacturing Domain

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

3.3.1 ScheduleWorkOrder

This ECtransaction is called from the Manufacturing application (see section 3.8) 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. When this ECtransaction is called for a single sales order (large order), the large order is deleted after the WorkOrder is created. This transaction can cause calls into the Supplier Domain if it needs any parts with low inventory. This ECtransaction is implemented by the scheduleWorkOrder method of the WorkOrderSes bean.

3.3.2 UpdateWorkOrder

As each station completes its operation, it will update the work order status. The WorkOrder status is maintained using the State Pattern described by the UML Diagram in Appendix A.4. This ECtransaction is implemented by the updateWorkOrder method of the WorkOrderSes bean.

3.3.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.3.4 CreateLargeOrder

This ECtransaction is initiated from within the Customer Domain whenever a large custom order has been entered. It will cause the creation of a work order based on the sales order. The work order will then go through the normal manufacturing flow until it is complete. This ECtransaction is implemented by the createLargeOrder method of the LargeOrderSes bean.

3.3.5 FindLargeOrders

This ECtransaction is called by the Driver and it retrieves all large orders that currently exist in the LargeOrder table. Note that the large orders are deleted by scheduleWorkOrder after they are scheduled. This ECtransaction is implemented by the findLargeOrders method of the LargeOrderSes bean.

3.4 ECtransactions in the Corporate Domain

3.4.1 AddCustomer

This ECtransaction is invoked from within the Customer domain to dynamically add new customers. This ECtransaction is implemented by the create method of the CustomerEntHome bean.

3.4.2 HasSufficientCredit

This ECtransaction checks whether a customer has a credit balance to cover his purchase. This is called from NewOrder and ChangeOrder ECtransactions in the Customer Domain when a customer enters/updates an order. This ECtransaction is implemented by the hasSufficientCredit method of the CustomerEntHome bean.

3.4.3 GetPercentDiscount

This ECtransaction computes the customer's discount for a particular order, based on discount rules and customer history. This is called from the NewOrder and ChangeOrder ECtransactions in the Customer Domain. The bulk of the work is performed by a rule engine parser which parses the discount rules stored in the C_RULE table and determines which category the customer falls into. It then looks up the C_DISCOUNT table to get the percentage discount for this customer category. This ECtransaction is implemented by the getPercentDiscount method of the CustomerEntHome bean.

3.5 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.5.1 AddComponent

This ECtransaction will check if there are any outstanding Purchase Orders and add the component to a list of components to be ordered. This ECtransaction is implemented by the add method of the BuyerSes bean.

3.5.2 Purchase

Once all components that are low in inventory have been added to a purchase order (AddComponent), ScheduleWorkOrder calls Purchase to buy the components. This ECtransaction will find all suppliers that can deliver all components within the required lead time and select the supplier that provides the best price and create the Purchase Order. It sends the Purchase Order to the Supplier emulator in XML format over a http connection. This ECtransaction is implemented by the purchase method of the BuyerSes bean.

3.5.3 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 finds all the Purchase Order Lines and updates the POL_DELDATE field. This transaction will update inventory in Manufacturing, and, update QTY_ON_ORDER and QTY_DEMANDED in the COMPONENT table. This ECtransaction is implemented by the deliverPO method of the ReceiverSes bean.

3.6 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 BuyerSes 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.6.1 Purchase Orders

Purchase orders are received from the Supplier Domain (see section 3.5.2) 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.6.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.7 OrderEntry Application

The OrderEntry application is responsible for entering new orders, changing existing orders and retrieving order status.

Each new order is placed on behalf of a customer, whose Id is chosen using NURand (A, 1, nCust) where A is 255 and nCust is derived according to section 2.3.4 of the SPECjAppServer2002 Run and Reporting Rules. If the selected customerId is not within the scope of the initial database population, a new customer is added using randomly generated data for the various fields in the O_Customer table. If the selected customerId is within the initial database population, the customerId is verified.

The next step is to determine the OrderLines. The items for the OrderLines are chosen using NURand (A, 1, NUM_ITEMS) where A is 63 and NUM_ITEMS is the number of items being manufactured by the company. The count of OrderLines in the order is randomly selected within [1..5]. 90% of the time, the order is placed by a regular customer for whom the total number of widgets is randomly selected within [10..20]. This number is divided equally amongst all the OrderLines. The average order size is thus 15 widgets, with each OrderLine having an average quantity of 5. 10% of the time, the order is assumed to be placed by a distributor (called Large Order). For these orders, the total number of widgets is randomly selected within [100..200], again dividing them equally amongst all the OrderLines, the count of which is randomly selected within [1..5]. Thus, the overall average order size is 150 widgets for a large order, which are equally distributed amongst all the OrderLines.

The average number of widgets for Large Orders is 10 times that of a regular order. Let's compute what this means for an Injection Rate of 10. On an average there will be 5 new Orders received per second (based on the mix requirement in 4.6.1). 4.5 of these orders have an average size of 15 and 0.5 are from a distributor with an average size of 150. The average widgets ordered per second is thus 67.5 (4.5 * 15) for a regular order and 75 (0.5 * 150) for a Large Order. Thus, 53% of the widgets ordered are from Large Orders. Generalizing this, for an Injection Rate of Ir, there will be 6.75*Ir widgets for regular orders and 7.5*Ir widgets for large orders, giving a total widget ordering rate of 14.25*Ir.

Finally, the Driver places the order. 50% of the time the order is placed by calling the newOrder method of the OrderSes bean. The other 50% of the time, the order is placed by first adding items to a Shopping Cart. The Driver chooses the Cart to use by using an array of 1000 Carts and selecting from this array thus :

cartId = -ln(x) * 100

where x = random number from a uniform distribution such that (0 < x <= 1)
if (cartId > 1000) cartId = 1000;

If cartId is not null (i.e., the Cart already exists), the Driver deletes all the items in the Cart. It then adds all the order lines one by one. After all the items are added, the Cart's contents are bought. The Shopping Cart is then deleted 90% of the time. 10% of the time, the Cart is left intact and could be later re-used.

The Driver saves the orderId returned by all the successful newOrder transactions in a newOrderIds array for use by the changeOrder and getOrderStatus transactions.

For every changeOrder business transaction, the orderId is randomly selected within [1..NUM_ORDERS] plus the newOrderIds array, where NUM_ORDERS is the number of Orders in the initial database. The Driver first performs a getOrderStatus ECtransaction to find the status and OrderLine count n, in the order it would like to change. If it finds that the order has been shipped or no longer exists, or if the order has only 1 OrderLine, it will re-try the transaction on a different order. 90% of the time, the OrderLines will be changed. The remaining 10% of the time, the order is deleted. For OrderLines to be changed, the count of lines to be changed is randomly selected within [1..n]. For each of these order lines, the quantity is alternatively incremented or decremented. For an order that is to be deleted, the Driver takes care to do this only on one of newOrderIds i.e., an order that exists in the initial database population is not deleted. This preserves the cardinality of the tables for successive runs.

For the getOrderStatus business transaction, an orderId is randomly selected within [1..NUM_ORDERS] plus the newOrderIds array where NUM_ORDERS is the number of Orders in the initial database. The getOrderStatus ECtransaction is executed using the selected order ID.

For the getCustStatus business transactions, the customerId of the customer is randomly selected within [1..NUMCUSTOMERS] where NUMCUSTOMERS is the number of customers in the initial database and the corresponding ECtransaction executed.

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 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.8.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 SPECjAppServer2002 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). Each WorkOrder will produce on average 11.25 widgets of a particular type. The type is selected by using NURand (A, 1, NUM_ITEMS), where A is 63 and NUM_ITEMS is the number of items being manufactured by the company. 75% of the time, the quantity for the WorkOrder is chosen as 11 and 25% of the time, the quantity is chosen as 12. This yields a rate of 11.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.8.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 53% of all widgets manufactured.

The Customer Domain notifies the Manufacturing Domain every time a LargeOrder is received. The LargeOrder line started from the manufacturing driver periodically checks for the existence of Large orders and immediately schedules a new WorkOrder for each.

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.9 Sample Configurations

Figure 5 shows an example layout of the Driver and SUT components for the Centralized 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 Centralized 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 Corporate Domain Class Diagram (pdf)

A.2 Customer Domain Class Diagram (pdf)

A.3 Manufacturing Domain Class Diagram (pdf)

A.4 Manufacturing State Classes (pdf)

A.5 Supplier Domain Class Diagram (pdf)

A.6 Key Generation Util Class Diagram (pdf)

Appendix B - Key Differences Between SPECjAppServer2002 and SPECjAppServer2001

B.1 EJB 2.0 Container Managed Persistence (CMP)

SPECjAppServer2002 has been converted to use the EJB 2.0 style for CMP entity beans.  All entity bean CMP implementations are now defined as abstract classes, and the member variables have been replaced with  their corresponding "accessor" (i.e., getXXX) and "mutator" (i.e., setXXX) methods.

B.2 Local Interfaces

SPECjAppServer2002 takes advantage of the local interface features in EJB 2.0.  Since all entity beans within a domain are to be deployed in a single EJB container, they now have local interfaces for efficient access within the container.

B.3 Container Managed Relationships (CMR)

SPECjAppServer2002 utilizes CMR to represent relationships between entity beans.  Since each domain may be deployed in separate containers, the CMR relationships are limited to those entities within each domain.

B.4 EJB Query Language (QL)

SPECjAppServer2002 uses EJB-QL in the deployment descriptors to define the queries which implement the finder methods associated with each entity bean.

---

Home - Contact - Site Map - Privacy - About SPEC

---

webmaster@spec.org
Last updated: Fri Sep 26 11:12:02 EDT 2003
Copyright 1995 - 2024 Standard Performance Evaluation Corporation
URL: http://www.spec.org/jAppServer2002/docs/DesignDocument.html