SPECjEnterprise2010 Design Document

Version 1.03

Last Modified: 11/19/2009, Version updated on May 20 2010, for 1.01 Kit release

Table of Contents

Section 1 - Introduction

1.1 Goals of SPECjEnterprise2010

SPECjEnterprise2010 is a Java Enterprise Edition (Java EE) benchmark meant to measure the scalability and performance of a Java EE based enterprise system. A Java EE based enterprise system typically constitutes hardware systems, enterprise software stack based on the Java EE 5 specification, database systems, Java Virtual Machine, operating system and the network.

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

TABLE 1.Golden Rules for SPECjEnterprise2010 Workload

Golden Rules Characteristic Description
Showcase Enterprise Components Fully distributed The business problem should necessitate use of worldwide services and data whose exact location is not known a priori.
Redundant & Available Services Services should be redundant and fully available with the runtime mapping unknown to the application developer.
Enterprise Focus Strive to stress all components in an enterprise system (whether this is logical or physical), rather than only he middleware tier.
Scalable business domain As the size of the modeled business grows, the services, data, users, and number of geographically distributed sites should also grow.
Universality An enterprise bean should be capable of being deployed on any vendor's H/W and O/S, as long as a compliant application server is present.
Command Credibility Real-world The performance workload should have the characteristics of real-world systems.
Complexity The workload should capture intra-, extra-, and inter-company business processes.
Openness The workload should be implementable atop all popular full- function Java EE 5 application servers.
Neutrality No workload features are selected with the goal of making any particular product look good (or bad). Fidelity to real-world business requirements is paramount.
Conform To Programmer Craft RAD/IDE application development The workload should be developed as if by a customer using reusable components intended for standardized deployment.
Scoped development skills The implementation should assume Fortune 500 developers who understand business logic, not systems programming.
Pattern Spec to Best Industry Practice Simplicity The workload should be easy to understand, straightforward to implement, and run in reasonable time with excellent repeatability.
Industry-standard Benchmark The workload should take into account the price of the system it is run on.

SPECjEnterprise2010 stresses the ability of the entire enterprise system to efficiently handle the complexities of typical enterprise applications, including but not limited to, dynamic Web page generation, memory management, connection pooling, passivation/activation, object persistence, transaction management, caching, message queuing, e.t.c.

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

The SPECjEnterprise2010 application is based on a scenario that incorporates CRM, manufacturing and supply chain management as its business case. These are concepts that are familiar to all users of Java EE 5, and makes the application approachable and relevant to those users. Because it describes an end-to-end business process it provides realistic opportunities to incorporate all of the key Java EE 5 technologies. These technologies include:

  • Dynamic Web page generation
  • Web Service based interactions
  • Transactional components
  • Distributed Transactions
  • Messaging and asynchronous task management
  • Multiple company service providers with multi-site servers
  • Object persistence

The diagram in Figure 1 provides an overview of the business case and how it is modeled in the SPECjEnterprise2010 application.

Application Overview Overview of the Application

The SPECjEnterprise2010 workload has been specifically modeled after an automobile manufacturer whose main customers are automobile dealers. Those dealers use a web based application to browse a catalog of automobiles, to place orders, and to indicate when they have sold inventory. Orders above a certain size result in special large orders which are requested directly from manufacturing. These interactions are encapsulated in the Orders Domain. It captures the elements that represent a standard E-Commerce catalog and shopping cart.

The 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 Orders 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 component in the Orders Domain communicate with the business domains via the appropriate session beans that provide the services required. Orders domain components uses session beans to acquire information and initiate business transactions. Interactions with the session beans in the business domains are encapsulated in the SpecAction class.

A UML Diagram for the Web component of the Order 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.

Work in the EJB component of the Order Domain is OLTP in nature. Functionality in this part of the domain includes adding new orders, retrieving status of a particular order or all orders of a particular customer, and canceling a given order. This domain also manages the global list of customers and their inventories. Credit information, including credit limits, about all customers is kept solely in a database. This is to provide security and privacy.

When orders arrive from customers, a credit check is performed on the customer. 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.1.2 EJB & JPA component Definitions

A UML Diagram for the EJB component of the Order Domain is shown in Appendix A.3.

2.1.2.1 OrderSession

org.spec.jent.ejb.orders.session.OrderSession

The OrderSession stateless session bean implements order entry transactions run in the Order Domain such as creating new orders, canceling orders, getting number of orders placed by a customer and getting open orders for a customer. It uses various JPA entities (Order, OrderLine, Item) to implement its methods. For processing large orders, this bean uses the LargeOrderSenderSession session bean to send a message to the LargeOrderQueue, from where the order is further processed in the Manufacturing Domain. The web component of the Order domain uses the methods of the OrderSession session bean and never accesses the JPA entities directly.

2.1.2.2 Order

org.spec.jent.ejb.orders.entity.Order

This JPA entity is the java representation of Order data in Orders table.

2.1.2.3 OrderLine

org.spec.jent.ejb.orders.entity.OrderLine

This JPA entity is the java representation of the data in the OrderLine table. The Order entity has a one-to-many bidirectional relationship to the OrderLine entity.

2.1.2.4 Item

org.spec.jent.ejb.orders.entity.Item

This JPA entity is the java representation of the data in the Item table. An Item is an entry in the catalog that is for sale to dealers and items are divided into multiple categories.

2.1.2.5 ItemBrowserSession

org.spec.jent.ejb.orders.session.ItemBrowserSession

This stateful session bean is used to browse the items table via the Item entity. The implementation executes a JPA QL query for retrieving items, but the underlying JPA implementation may cache items for quick retrieval.

2.1.2.6 FulfillOrderMDB

org.spec.jent.ejb.orders.mdb.FulfillOrderMDB

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.1.2.7 CustomerSession

org.spec.jent.ejb.orders.session.CustomerSession

This stateless session bean is the entry point for services that require access to customer and customer inventory information (Customer and CustomerInventory entities), 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.1.2.8 Customer

org.spec.jent.ejb.orders.entity.Customer

This JPA entity is the java representation of the data in the Customer table which stores customer information.

2.1.2.9 CustomerInventory

org.spec.jent.ejb.orders.entity.CustomerInventory

This JPA entity is the java representation of the data in the Customer Inventory table which stores the customer inventory items. The Customer entity has a one-to-many bidirectional relationship with the CustomerInventory entity.

2.1.2.10 LargeOrderSenderSession

org.spec.jent.ejb.orders.session.LargeOrderSenderSession

The stateless session bean is used by the OrderSession bean to send messages to the manufacturing domain. It sends a JMS message containing details of a large order to the LargeOrderQueue.

2.2 Model for Manufacturing Domain

This domain models the activity of production across multiple manufacturing plants in different locations. 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 and is manufactured at one of possibly many locations. 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 at a location, the Bill of Materials (BOM) for the corresponding type of widget is retrieved and the required parts are taken out of the inventory of the location. 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

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

2.2.1.1 WorkOrderSession

org.spec.jent.ejb.mfg.session.WorkOrderSession

This stateless session bean is used to perform operations such

2.2.1.2 WorkOrder

org.spec.jent.ejb.mfg.entity.WorkOrder

This JPA entity is the java representation of the data in the WorkOrder table in the manufacturing database.

2.2.1.4 LargerOrderMDB

org.spec.jent.ejb.mfg.mdb.LargerOrderMDB

This message driven bean is responsible for processing messages arriving from the Order domain in the LargeOrderQueue, creating the corresponding WorkOrders and taking them through the various stages to completion. The bean uses the WorkOrder entity to accomplish this task.

2.2.1.6 ReceiveMDB

org.spec.jent.ejb.mfg.mdb.ReceiveMDB

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

2.2.1.7 MessageSenderSession

org.spec.jent.ejb.mfg.session.MessageSenderSession

This stateless session bean is used to by other stateless session beans in the manufacturing domain to create and send messages to other domains. It sends a JMS message to the Supplier domain for a new requisition and to the Order domain to notify it of a fulfilled order.

2.2.1.8 Assembly

org.spec.jent.ejb.mfg.entity.Assembly

This JPA entity the java representation of the Assembly data and derives from the Component entity. An assembly is represented by a row in the Parts table and is made up of several BOMs.

2.2.1.9 Component

org.spec.jent.ejb.mfg.entity.Component

This JPA entity is the java representation of the Parts table. It is the superclass of the Assembly entity.

2.2.1.10 Inventory

org.spec.jent.ejb.mfg.entity.Inventory

This JPA entity is the java representation of the Inventory table in the manufacturing database and represents the inventory at a particular manufacturing location.

2.2.1.11 BOM

org.spec.jent.ejb.mfg.entity.BOM

This JPA entity is the java representation of the BOM table in the manufacturing database. It contains information about the parts that are required to manufacture a widget.

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 lead time specified by suppliers and the price quoted by suppliers. The company sends a purchase order to a supplier who can supply the parts within a specified time frame at the lowest cost. The purchase order will include the quantity of various parts being purchased, the location 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 BuyerMDB

org.spec.jent.ejb.supplier.mdb.BuyerMDB

This message driven bean processes the JMS messages received on the BuyerQueue from the manufacturing domain, uses the SupplierSession to create the PurchaseOrder objects from a message and queues them on the PurchaseOrderQueue.

2.3.1.2 PurchaseOrderMDB

org.spec.jent.ejb.supplier.mdb.PurchaseOrderMDB

This message driven bean processes the JMS messages received on the PurchaseOrdeQueue from the BuyerMDB and sends a Web Services message to the Supplier for the fulfillment of the PurchaseOrder(s).

2.3.1.3 SupplierSession

org.spec.jent.ejb.supplier.session.SupplierSession

The stateless session bean is responsible for creating PurchaseOrders based on delivery date and cost constraints and processing delivery of components. The bean uses the following entity beans to complete its tasks: PurchaseOrder, PurchaseOrderLine, Supplier, SupplierComponent and SComponent.

2.3.1.4 Supplier

org.spec.jent.ejb.supplier.entity.Supplier

This JPA entity is the java representation of the supplier information in Suppliers table in the supplier database.

2.3.1.5 SComponent

org.spec.jent.ejb.supplier.entity.SComponent

This JPA entity is the java representation of the Component table in the supplier database. The Component table in the supplier database contains information about the requisitioned parts including quantity demanded and quantity on order.

2.3.1.6 SupplierComponent

org.spec.jent.ejb.supplier.entity.SupplierComponent

This JPA entity is the java representation of the Supp_Component table in the supplier database. The Supp_Component table in the supplier database contains information about the various components a supplier supplies, including price, quantity, discount and lead time.

2.3.1.7 PurchaseOrder

org.spec.jent.ejb.supplier.entity.PurchaseOrder

This JPA entity is the java representation of the PurchaseOrder table in the supplier database.

2.3.1.8 PurchaseOrderLine

org.spec.jent.ejb.supplier.entity.PurchaseOrderLine

This JPA entity is the java representation of the PurchaseOrderLine table in the supplier database. A PurchaseOrder has a one-to-many bidirectional relationship with PurchaseOrderLine

2.3.2 Other Packages

Besides the three domains, several other packages are included:

  • common
    • Source code for helper classes used by all the beans (i.e. it is common across different domains as well as beans).

  • util
    • Beans used to generate primary keys for the various domains.

  • supplier.emulator
    • Supplier Emulator Servlet.

  • driver
    • SPECjEnterprise2010 driver

  • load
    • Database data generation and load programs required to load the SPECjEnterprise2010 database(s) according to the benchmark scaling rules.

2.4 Database Model

The components of the SPECjEnterprise2010 database are defined to consist of three separate and individual databases (See section 2.3.3 of the SPECjEnterprise2010 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.4.1 Order Database

The Order database exists in the Order domain and stores the order, customer and catalog item data.

2.4.1.1 Customer Table

The customer table contains information on all customers of the company.

Table Name: O_CUSTOMER

Field Name Field Type Comments
C_ID integer Customer ID (Primary Key)
C_FIRST char(16) First name (unused if c_last is company)
C_LAST char(16) Last name
C_STREET1 char(20) Street address, line 1
C_STREET2 char(20) Street address, line 2
C_CITY char(20) City
C_STATE char(2) State
C_COUNTRY char(10) Country
C_ZIP char(9) Zipcode
C_PHONE char(16) Phone
C_CONTACT char(25) Contact person
C_SINCE date Customer since
C_BALANCE numeric(12,2) Account balance
C_CREDIT char(2) Credit rating `BC' or `GC'
C_CREDIT_LIMIT numeric(12,2) Credit limit
C_YTD_PAYMENT numeric(12,2) Year to date payment made
C_VERSION integer default 0 Version column used by JPA for optimistic locking

2.4.1.2 Customer Inventory Table

This table keeps track of items in customer inventories.

Table Name: O_CUSTOMERINVENTORY

Field Name Field Type Comments
CI_ID integer not null Customer Inventory ID (Primary key)
CI_ITEMID char(20) Item ID
CI_QUANTITY integer Quantity
CI_CUSTOMERID integer Customer ID (Foreign Key to C_CUSTOMER)
CI_VALUE numeric(12,2) Monetary value associated with the inventory entry
CI_VERSION integer default Version column used by JPA for optimistic locking

2.4.1.3 Orders Table

Table Name: O_ORDERS

Field Name Field Type Comments
O_ID integer not null Order ID (Primary Key)
O_C_ID integer Customer who placed this order
O_OL_CNT integer Number of order lines
O_DISCOUNT numeric(4,2) Customer's discount for this order
O_TOTAL numeric(12,2) Order total
O_STATUS integer Status of complete order
O_ENTRY_DATE timestamp Order entry date and time
O_SHIP_DATE date Order ship date
O_VERSION integer default 0 Version column used by JPA for optimistic locking

2.4.1.4 OrderLine Table

Table Name: O_ORDERLINE

Field Name Field Type Comments
OL_ID integer not null Order line ID (Primary Key)
OL_O_ID integer not null Order ID (Primary Key and Foreign Key to O_ORDERS)
OL_I_ID char(20) Item ID
OL_QTY integer Item Quantity
OL_TOTAL_VALUE numeric(12,2) Value of this line item
OL_MSRP numeric(12,2) Manufacturer suggested retail price
OL_STATUS integer Status: OUTSTANDING, SHIPPED
OL_SHIP_DATE date Order line ship date
OL_VERSION integer default 0 Version column used by JPA for optimistic locking

2.4.1.5 Item Table

Table Name: O_ITEM

Field Name Field Type Comments
I_ID char(20) not null Item ID (Primary key)
I_NAME char(35) Name
I_DESC varchar(100) Description
I_PRICE numeric(12,2) Item price
I_DISCOUNT numeric(6,4) Discount for this item
I_CATEGORY integer not null Item category
I_VERSION integer default 0 Version column used by JPA for optimistic locking

2.4.2 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.4.2.1 Parts Table

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

Table Name: M_PARTS

Field Name Field Type Comments
P_ID char(20) not null Encoded part number (Primary key)
P_NAME char(35) Part name
P_DESC varchar(100) Description
P_REV char(6) Revision number
P_PLANNER integer Planner code - person who plans the part
P_TYPE integer Product code
P_IND integer Manufactured or Purchased part
P_LOMARK integer Low water mark for inventory
P_HIMARK integer High water mark for inventory
P_VERSION integer default 0 Version column used by JPA for optimistic locking

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

Field Name Field Type Comments
B_COMP_ID char(20) not null Component (Primary Key and Foreign Key to M_PARTS)
B_ASSEMBLY_ID char(20) not null Assembly to which this belongs (Primary Key and Foreign Key to M_PARTS)
B_LINE_NO integer Line number in BOM (Primary Key)
B_QTY integer Quantity/assembly
B_OPS integer Op # - which step in the process this is used
B_ENG_CHANGE char(10) Engineering change reference
B_OPS_DESC varchar(100) Operation description
B_VERSION integer default 0 Version column used by JPA for optimistic locking

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

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

Field Name Field Type Comments
WO_NUMBER integer not null Work Order number (Primary key)
WO_LOCATION integer not null Location the workorder should be provisioned
WO_O_ID integer Sales Order ID if this is for a custom order
WO_OL_ID integer Orderline ID in sales order
WO_STATUS integer Current status
WO_ASSEMBLY_ID char(20) Assembly being manufactured (Foreign Key to M_PARTS)
WO_ORIG_QTY integer Original qty
WO_COMP_QTY integer Completed qty
WO_DUE_DATE timestamp Date when the order is due
WO_START_DATE timestamp Date & time at which work began
WO_VERSION integer default 0 Version column used by JPA for optimistic locking

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.4.2.4 Inventory Table

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

Table Name: M_INVENTORY

Field Name Field Type Comments
IN_P_ID char(20) not null Part number (Primary Key and Foreign Key to M_PARTS)
IN_QTY integer Amount in inventory
IN_ORDERED integer Qty ordered
IN_LOCATION integer not null Location inventory should be provisioned
IN_ACC_CODE integer Finance code - is part usable?
IN_ACT_DATE timestamp Date of last activity
IN_VERSION integer default 0 Version column used by JPA for optimistic locking

2.4.3 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.4.3.1 Supplier Table

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

Table Name: S_SUPPLIER

Field Name Field Type Comments
SUPP_ID integer not null Supplier ID (Primary key)
SUPP_NAME char(16) Supplier name
SUPP_STREET1 char(20) Street address, line 1
SUPP_STREET2 char(20) Street address, line 2
SUPP_CITY char(20) City
SUPP_STATE char(2) State
SUPP_COUNTRY char(10) Country
SUPP_ZIP char(9) Zip code
SUPP_PHONE char(16) Phone
SUPP_CONTACT char(25) Contact person
SUPP_WS_URL varchar(128) Suppliers web services URL
SUPP_REPLY_URL varchar(128) Return URL for web services
SUPP_VERSION integer default 0 Version column used by JPA for optimistic locking

2.4.3.2 SComponent Table

Table Name: S_COMPONENT

Field Name Field Type Comments
COMP_ID char(20) not null Encoded part number (Primary key)
COMP_SITE_ID integer not null
COMP_NAME char(10) Part name
COMP_DESC varchar(100) Description
COMP_UNIT char(10) Unit of measure for this part
COMP_COST numeric(12,2) Current best cost for this part
QTY_ON_ORDER integer Keeps track of outstanding POs
QTY_DEMANDED integer Qty requested by Mfg
LEAD_TIME integer Lead time for delivery
CONTAINER_SIZE integer Min amount supplier will supply
COMP_VERSION integer default 0 Version column used by JPA for optimistic locking

2.4.3.3 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

Field Name Field Type Comments
PO_NUMBER integer not null Primary key
PO_SITE_ID integer not null Site to ship this PO to
PO_SUPP_ID integer Supplier for this PO
PO_START_DATE timestamp Time when PO was initiated
PO_SENT_DATE date Date on which the purchase order was sent
PO_VERSION integer default 0 Version column used by JPA for optimistic locking

2.4.3.4 PurchaseOrderLine Table

Table Name: S_PURCHASE_ORDERLINE

Field Name Field Type Comments
POL_NUMBER integer not null Purchase OrderLine number (Primary Key)
POL_PO_ID integer not null Purchase order to which this belongs (Primary Key and Foreign Key to S_PURCHASE_ORDER)
POL_LOCATION integer not null Location the part should be delivered
POL_P_ID char(20) Part number
POL_QTY integer Quantity ordered
POL_BALANCE numeric(12,2) Balance outstanding
POL_DELDATE date Delivery date requested
POL_MESSAGE varchar(100) Optional comment field
POL_LEADTIME integer default 0 The lead time for this purchase order line
POL_VERSION integer default 0 Version column used by JPA for optimistic locking

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

Table Name: S_SUPP_COMPONENT

Field Name Field Type Comments
SC_P_ID char(20) not null Component
SC_SUPP_ID integer not null Supplier for this component
SC_PRICE numeric(12,2) Supplier's price for this component
SC_QTY integer Quantity for discount
SC_DISCOUNT numeric(6,4) Percentage discount
SC_DEL_DATE integer Delivery in days (from date of ordering)
SC_VERSION integer default 0 Version column used by JPA for optimistic locking

2.4.3.6 RunConfig Table

This table maintains the properties for the run. It includes txRate, itemsPerTxRate, and maxItemsPerLoc property values required for the correct workload at an injection rate.

Table Name: S_RUN_CONFIG

Field Name Field Type Comments
NAME varchar2(20)
VALUE integer

2.4.4 Utility Database

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

2.4.4.1 Sequence Table

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

Table Name: U_SEQUENCES

Field Name Field Type Comments
S_ID varchar(50) not null Sequence block ID
S_NEXTNUM integer Next available sequence number

2.4.4.2 Loader Table

Table Name: U_LOADER

Field Name Field Type Comments
L_TXRATE integer
L_ITEMCOUNT integer
L_ITEMS_PER_TXRATE integer
L_DBIR integer
L_PARALLELISM integer
L_IS_FF integer
L_FF_DIR varchar(1000)
L_FF_DEL varchar(10)
L_IS_STANDALONE integer
L_DB_DRIVER_CLASS varchar(512)
L_DB_URL varchar(512)
L_DB_USER varchar(512)
L_DB_PASSWORD varchar(512)
L_ROOT_SEED numeric(19,0)
L_STATUS integer
L_STARTED_AT timestamp
L_ENDED_AT timestamp
L_VERSION integer default 0

2.4.4.3 Loader Message Table

Table Name: U_LOAD_MESSAGE

Field Name Field Type Comments
LM_ID integer
LM_TEXT clob

2.4.4.4 Loader Section Table

Table Name: U_LOAD_SECTION

Field Name Field Type Comments
LS_ID integer
LS_DOMAIN varchar(50)
LS_TABLENAMES varchar(200)
LS_SECTION_ID integer
LS_START_STEP integer
LS_NUM_STEPS integer
LS_STATE integer
LS_VERSION integer default 0


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 SPECjEnterprise2010 Run and Reporting Rules, keeps track of various statistics and reports the final metric. See section 2.8 of the SPECjEnterprise2010 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 SPECjEnterprise2010 workload. Refer to the Java EE 5 and EJB 3.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 Java EE 5 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 SPECjEnterprise2010 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 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 SPECjEnterprise2010 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 SPECjEnterprise2010 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, establishes 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 ItemBrowserSession 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 adds an item to the ShoppingCart object associated with the user session. The shopping cart is maintained as a map between and Item's unique id and the Item object itself. If an item already exists in the shopping cart, adding additional quantities of the item only updates the quantity and price.

3.2.8 doRemoveFromShoppingCart

This Web Interaction removes an 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 OrderSession 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 OrderSession bean. The shopping cart is cleared.

3.2.12 doCancelOrder

This Web Interaction cancels an open order by invoking the cancelOrder method of the OrderSession 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 CustomerSession 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 CustomerSession bean and the getOpenOrders and getItemInfo methods of the OrderSession bean.

3.3 ECTransactions in the Order Domain

The Order 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 OrderSession 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 GetOpenOrders

This ECtransaction gets the open orders for a particular customer id. This ECtransaction is implemented by the getOpenOrders method of the OrderSession bean.

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 OrderSession bean.

3.3.5 GetOrderCount

This ECtransaction retrieves the count of all orders for a particular customer id. This ECtransaction is implemented by the getOrderCount method of the OrderSession bean.

3.3.5 GetItem

This ECtransaction retrieves a Item based on the Item's id. This ECtransaction is implemented by the getItem method of the OrderSession 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 ItemBrowserSession 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 ItemBrowserSession 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 browseReverse method of the ItemBrowserSession bean.

3.3.10 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 CustomerSession bean.

3.3.11 GetCustomer

This ECtransaction retrieves customer information for a given customer id. This ECtransaction is implemented by the getCustomer method of the CustomerSession bean.

3.3.12 GetInventories

This ECtransaction returns a List of CustomerInventory objects representing all the records in the Customer Inventory table for a given customer id. This ECtransaction is implemented by the getInventories method of the CustomerSession bean.

3.3.13 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 CustomerSession bean.

3.3.14 AddInventory

This ECtransaction adds 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 CustomerSession bean.

3.3.15 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 CustomerSession bean.

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 may cause requests to be queued into BuyerQueue to be processed in the Supplier Domain, if any parts' inventory level falls below the low water mark. This ECtransaction is implemented by the scheduleWorkOrder method of the WorkOrderSession 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 WorkOrderSession 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 WorkOrderSession 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 WorkOrderSession 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 Deliver

This ECtransaction is called from the Supplier Domain BuyerService servlet endpoint when it receives a message from the Supplier Emulator indicating delivery of parts pertaining to some purchase order has been delivered. It invokes the processDelivery method of the SupplierSession bean, which sends a message to the ReceiveQueue for inventory updates. The message is consumed by the ReceiveMDB message driven bean in the Manufacturing domain which invokes the MfgSession bean's deliver method to update the inventory. In addition this ECtransaction updates the corresponding Purchase Order Line entries with the delivery date. This ECtransaction is implemented by the processDelivery method of the SupplierSession bean.

3.6 Supplier Emulator

The Supplier Emulator is a Web Services Servlet endpoint that can run inside any java enabled Web server with Web Services support. It is not part of the SUT and can run on a machine that is external to it. It communicates with the SUT by sending and receiving Web Services messages. 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 PurchaseOrderMDB bean in the Supplier Domain, processes the purchase order and after sleeping for an amount of time based on the lead time of the component, sends a delivery message pertaining to the order lines in the purchase order to the BuyerService. 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.6) as Web Services messages. The web service message contains the details of the purchase order:

poNumber ID of the purchase order
siteId ID of the site that the purchase order should be delivered to

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

lineNumber Line number in purchase order
Id ID of part
qty qty to order
leadTime maximum lead time that the part must be delivered within
location location to deliver the parts

3.6.2 Parts Delivery

On receipt of a purchase order, the Emulator extract each purchase order line from the Web Services message.

The purchase order lines are then grouped by their lead times and a corresponding DeliveryHandler object is created. The DeliveryHandler object is scheduled to be executed after a certain delay, which is the lead time multiplied by a constant factor, by one of the pool of threads in the ThreadSchedulerFactory. When a thread in the pool executes the DeliveryHandler's run method, a web services message representing the delivery information is created based on the purchase order lines.

The web services message representing the delivery information is then transmitted to the Supplier Domain. The Web Services servlet endpoint, BuyerService, in the supplier domain receives the delivery message and in turn calls the SupplierSession Bean further process the delivery.

The SupplierSession bean extracts the delivery information, updates the SComponent table in supplier database with quantity delivered and sends the delivery information on to the ReceiveQueue. The ReceiveMDB in the Manufacturing Domain receives the delivery message from the ReceiveQueue and updates the inventory with the delivery information.

3.7 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 SPECjEnterprise2010 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 SPECjEnterprise2010 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.7.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.7.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.7.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.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 Planned lines are scheduled from the manufacturing driver. The LargeOrder lines are scheduled when a new LargeOrder is created in the Order domain through the Dealer driver.

The manufacturing driver directs WorkOrders to different locations and keeps track of the number of WorkOrders initiated, the number of widgets produced and the average time for the completion of each WorkOrder on the Planned line. Similar WorkOrders statistics for the Large Orders are computed from the entries in the WorkOrder table which are marked with quantity higher than 20.

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 SPECjEnterprise2010 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.8.2 LargeOrder Lines

The Order Domain notifies the Manufacturing Domain via the LargeOrderQueue every time a LargeOrder is received. The LargeOrderMDB on receipt of a message on the LargeOrderQueue creates a work order corresponding to the LargeOrder and takes the work order through the different phases to its completion without any delay between the three phases. This is a departure from the earlier design in SPECjAppServer2004, where like a Planned Line, a Large Order Line has 3 Stations and the same average time spent per station.

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

standard configuration example

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.


Appendix A - UML Diagrams

A.1 Orders Domain Class Diagram

UML diagram for the Orders Domain

A.2 Orders Domain Class Diagram (Entities)

UML class diagram for the Orders Domain (Entities)

A.3 Manufacturing Domain Class Diagram

UML diagram for the Manufacturing Domain

A.4 Manufacturing Domain Class Diagram (Entities)

UML class diagram for the Manufacturing Domain (Entities)

A.5 Supplier Domain Class Diagram

UML diagram for the Supplier Domain

A.6 Supplier Domain Class Diagram (Entities)

UML class diagram for the Supplier Domain (Entities)

A.7 Loader Class Diagram

UML diagram for the Loader


Product and service names mentioned herein may be the trademarks of their respective owners.

Copyright © 2001-2012 Standard Performance Evaluation Corporation
All Rights Reserved