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
- SPECjEnterprise2010 Design Document
- Section 1 - Introduction
- Section 2 - Application Design
- 2.1 Model for Orders Domain
- 2.1.1 Web Component Definitions
- 2.1.1.1 SpecAppServlet
- 2.1.1.2 Dealer Welcome JSP (welcome.jsp)
- 2.1.1.3 Dealer Home JSP (SpecJhome.jsp)
- 2.1.1.4 Login Summary JSP (loginSummary.jsp)
- 2.1.1.5 Dealer Inventory JSP (dealerinventory.jsp)
- 2.1.1.6 Dealer Shopping Cart JSP (shoppingcart.jsp)
- 2.1.1.7 Dealer Purchase JSP (purchase.jsp)
- 2.1.1.8 Dealer Order JSP (order.jsp)
- 2.1.1.9 Dealer Application Header (dealership_incl_header.jsp)
- 2.1.1.10 Dealer Application Footer (dealership_incl_footer.jsp)
- 2.1.1.11 Error JSP (error.jsp)
- 2.1.2 EJB & JPA component Definitions
- 2.1.2.1 OrderSession
- 2.1.2.2 Order
- 2.1.2.3 OrderLine
- 2.1.2.4 Item
- 2.1.2.5 ItemBrowserSession
- 2.1.2.6 FulfillOrderMDB
- 2.1.2.7 CustomerSession
- 2.1.2.8 Customer
- 2.1.2.9 CustomerInventory
- 2.1.2.10 LargeOrderSenderSession
- 2.2 Model for Manufacturing Domain
- 2.3 Model for Supplier Domain
- 2.4 Database Model
- 2.4.1 Order Database
- 2.4.1.1 Customer Table
- 2.4.1.2 Customer Inventory Table
- 2.4.1.3 Orders Table
- 2.4.1.4 OrderLine Table
- 2.4.1.5 Item Table
- 2.4.2 Manufacturing Database
- 2.4.2.1 Parts Table
- 2.4.2.2 BOM Table
- 2.4.2.3 WorkOrder Table
- 2.4.2.4 Inventory Table
- 2.4.3 Supplier Database
- 2.4.3.1 Supplier Table
- 2.4.3.2 SComponent Table
- 2.4.3.3 PurchaseOrder Table
- 2.4.3.4 PurchaseOrderLine Table
- 2.4.3.5 SupplierComponents Table
- 2.4.3.6 RunConfig Table
- 2.4.4 Utility Database
- 2.4.4.1 Sequence Table
- 2.4.4.2 Loader Table
- 2.4.4.3 Loader Message Table
- 2.4.4.4 Loader Section Table
- 2.1 Model for Orders Domain
- Section 3 - Workload Description
- Appendix A - UML Diagrams
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.
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.
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
A.2 Orders Domain Class Diagram (Entities)
A.3 Manufacturing Domain Class Diagram
A.4 Manufacturing Domain Class Diagram (Entities)
A.5 Supplier Domain Class Diagram
A.6 Supplier Domain Class Diagram (Entities)
A.7 Loader Class Diagram
Product and service names mentioned herein may be the trademarks of their respective owners.
Copyright © 2001-2012 Standard Performance Evaluation Corporation
All Rights Reserved