We are soon going to embark on a major project to introduce enterprise notification handling at the University. Part of that will be the ability to handle a large number of messages in an efficient and robust manner. We already use Oracle SOA Suite here at the University, but wanted to test its throughput versus a lighter approach, that of Java and the Spring framework.
The scenarios
We chose four scenarios to test:
- Basic assign, parameter passed in is passed out as response
- DB Write , parameter passed in is written to Oracle Database
- DB Read, parameter passed in is used to read value from Oracle Database
- DB Read/Write, parameter passed in is written to Oracle Database, then read back out again
Testing constraints
We then applied the same constraints to both Oracle SOA and Java:
- A connection pool must be used with the same settings (min 1, max 10 connections)
- The same table structure/setup must be used with both technologies
- We use the same back-end Oracle database
- Testing would be done using a SOAP UI load test
For Oracle SOA, we set up a simple composite which tested the various features.
For Java Spring, we used Spring Boot, Spring Web Services, and Spring JPA.
The results
The results were as follows (total timings are rounded up to the nearest second):
Oracle SOA
| 500 calls | 2000 calls | 5000 calls | |
| Assign | 2 sec | 293 ms avg | 6 sec | 504 ms avg | 16 sec | 593 ms avg |
| Write | 3 sec | 1284 ms avg | 10 sec | 861 ms avg | 29 sec | 1094 ms avg |
| Read | 2 sec | 389 ms avg | 9 sec | 838 ms avg | 21 sec | 803 ms avg |
| Write Read | 3 sec | 1038 ms avg | 18 sec | 1644 ms avg | 36 sec | 1403 ms avg |
Java (Spring framework)
| 500 calls | 2000 calls | 5000 calls | |
| Assign | 1 sec | 101 ms avg | 1 sec | 82 ms avg | 2 sec | 72 ms avg |
| Write | 1 sec | 112 ms avg | 2 sec | 232 ms avg | 5 sec | 203 ms avg |
| Read | 1 sec | 73 ms avg | 1 sec | 116 ms avg | 3 sec | 116 ms avg |
| Write Read | 1 sec | 271 ms avg | 3 sec | 256 ms avg | 6 sec | 234 ms avg |
Conclusions
It is clear that the Java Spring solution is giving better throughput times,, and that is especially evident when we increase the load. However it would be unfair to use throughput times alone in looking at what Oracle SOA provides. It gives for example an “out of the box” message resilience and support for automated message retry that would have to be coded in when using Java even with the benefit of Spring frameworks. However, Spring can provide a very useful high throughput entry point into Oracle SOA.
We want to benefit from the strengths of each of the technologies, so we are going to use the following:
- Java Spring Web Services will be used as the initial entry point for creating/editing/deleting notification messages
- The Java Spring WS will put a message in a queue for Oracle SOA
- Oracle SOA will poll the queue for messages, then will apply the necessary business processing and rule logic for pushing notifications out
- Oracle SOA will handle message retry in the event of processing failures
- Java Spring Web Services will be used for pulling user notifications out for subscriber systems
As with most of the modern web, building a solution is about choosing the right set of technologies and not choosing a single technology approach. We’re confident now that we can introduce the necessary scale to handle a modern enterprise notifications system.