SPECjEnterprise®2018 Web Profile Design

1. Introduction

This document describes the design of the SPECjEnterprise®2018 Web Profile benchmark.

1.1. Goals of the SPECjEnterprise®2018 Web Profile benchmark

The SPECjEnterprise®2018 Web Profile benchmark is a Java Enterprise Edition 7 Web Profile (Java EE 7 Web Profile) benchmark that measures the scalability and performance of a Java EE 7 Web Profile based enterprise system. A Java EE 7 Web Profile based enterprise system typically constitutes hardware systems, enterprise software stack based on the Java EE 7 Web Profile specification, database systems, Java Virtual Machine, operating system and the network.

Fundamentally, Java EE 7 Web Profile 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 7 Web Profile applications need to scale automatically. The benchmark workload possesses the characteristics shown in Table1.

TABLE 1.Golden Rules for SPECjEnterprise®2018 Web Profile 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 being 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 the middleware tier.
	Scalable business domain	As the size of the modeled business grows, the services, data and users should also grow.
	Universality	A web application should be capable of being deployed on any vendor’s H/W and O/S, as long as a compatible 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- and inter-company business processes.
	Openness	The workload should be implementable atop all popular full- function Java EE 7 Web Profile 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	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 Workload to Best Industry Practice	Simplicity	The workload should be easy to understand, straightforward to implement, and run in a reasonable time with excellent repeatability.

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 being 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 the middleware tier.

Scalable business domain

As the size of the modeled business grows, the services, data and users should also grow.

Universality

A web application should be capable of being deployed on any vendor’s H/W and O/S, as long as a compatible 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- and inter-company business processes.

Openness

The workload should be implementable atop all popular full- function Java EE 7 Web Profile 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

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 Workload to Best Industry Practice

Simplicity

The workload should be easy to understand, straightforward to implement, and run in a reasonable time with excellent repeatability.

1.2. SPECjEnterprise®2018 Web Profile background

The application that is tested in this benchmark emulates an automotive insurance brokerage application. It is designed to scale and be deployed in a distributed manner as it consists of three services (Insurance, Insurance Provider and Vehicle) that all can be deployed independently. Technologies covered in this benchmark:

Expression Language (EL) 3.0
Standard Tag Library for JavaServer Pages (JSTL) 1.2
JavaServer Faces (JSF) 2.2
Java API for RESTful Web Services (JAX-RS) 2.0
Java API for WebSocket (WebSocket) 1.0
Java API for JSON Processing (JSON-P) 1.0
Common Annotations for the Java Platform 1.2
Enterprise JavaBeans (EJB) 3.2 Lite
Java Transaction API (JTA) 1.2
Java Persistence API (JPA) 2.1
Bean Validation 1.1
Contexts and Dependency Injection for the Java 1.1
Dependency Injection for Java 1.0

This benchmark reflects that newer enterprise applications are written as smaller independent services suitable for both cloud and bare-metal deployments. The benchmark scales well in a distributed public hosting environment in addition to a private bare metal or virtual environment.

2. Application

The SPECjEnterprise®2018 Web Profile application consists of three services;

Vehicle
Insurance Provider
Insurance

Each service is encapsulated in a WAR file. The three services can be deployed independent of each other or together. All communication between these services uses JAX-RS APIs with JSON as the data type.

2.1. Vehicle Service

The vehicle service emulates a service that provides data about vehicles. The data type used to represent vehicle data is VehicleDescription.

The vehicle service provides a simple HTML page to search the vehicle data and manually populate the database. This is only provided for debugging/testing and is not used during the benchmark.

Insurance and Insurance Provider services communicate with the Vehicle service using JAX-RS APIs.

The vehicle service is a read-only service where the data can be cached at the JPA layer.

2.1.1. Vehicle JAX-RS API

The vehicle service provides a rest interface to search for vehicles based on these criteria:

Make (returns List<String> of model names)
Id (returns VehicleDescription)
Ids (returns List<VehicleDescription>)

2.1.2. Vehicle Service Clients

2.1.3. Vehicle Database model

The vehicle domain consists of only one table

2.2. Insurance Provider Service

The insurance provider service emulates a service gateway for several insurance companies to receive requests to generate insurance quotes for vehicles. The insurance provider service calculates the quote based on several lookups on database tables.

There are five insurance companies, each with different rating profiles depending on the PolicyHolder data (age, gender, violations, etc) and VehicleDescription data (model, make, year, etc).

When the Insurance Provider service receives a request for a quote, it will try to find a matching driver profile, vehicle characteristics and the requested coverages. If some of these are not found in the company’s list it will fall back to the default values.

Each of the listed driver profiles, vehicles and coverages have a rate relativity. A rate relativity is a factor describing how much risk that specific item adds to the total cost. The base value of the rate relativity is 1.0. Anything above the base value will add to the total cost and anything below the base value will reduce the total cost.

Each insurance company has their own rates based on different profiles.

The Insurance Provider service does lookups to the Vehicle service to get VehicleDescription data.

2.2.1. Insurance Provider Request/Response

The Insurance service contacts the Insurance Provider service to request a quote for a specific PolicyHolder with a specific VehicleDescription. The Insurance Provider service returns a list of possible quotes from each of the different insurance companies.

2.2.2. Insurance Provider Database model

The main table describing an insurance company is the 'P_ACTUARIAL_CLASS' table. It consists of several lists that are looked up when the service receives a quote request.

2.3. Insurance Service

The insurance service is the main service that provides both a web frontend and a REST API. It is the only module that directly deals with users. The web frontend is JSF based and the REST API is provided using JAX-RS. To validated that the REST API is providing the same logic as JSF there is also a react.js (https://reactjs.org/) client frontend for testing and validation purposes. It is however not used directly in the benchmark.

The insurance service provides a complete web and rest frontend to create/manage/delete users for the system. These users are called PolicyHolders internally. It also provides functionality to manage an inventory of vehicles and manage their insurance status.

2.3.1. Insurance Web Flow

The diagram below describes the frontend of the insurance service.

The application requires login credentials from the users to have access to any of pages except the Welcome and Registration pages. For the JSF front end, the server creates a user-session that it caches for the duration of that session. For the REST endpoints, the client retains the session state, but the server requires login credentials for access to all services. Login credentials for REST are propagated to the server using a JWT cookie.

All the communication between the driver using JSF or REST are secured with HTTPS.

2.3.2. Insurance Database model

3. Workload

The clients that drive the load simulate web users interacting with the application against the insurance service. The load is distributed with the ratio 15% JSF requests and 85% REST requests. This ratio of JSF to REST requests is meant to simulate traffic to the external web frontend using JSF and business to business traffic using the REST API.

4. Summary

The three services are as mentioned earlier independent. By design they can be deployed on either a single application server instance or multiple. The databases are also independent, but they can also be installed on a single database instance.

Java and Java EE are trademarks of Oracle.

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