Oracle SOA Suite 12.2.1 introduces Integration Workload Statistics. This is a powerful new feature which can be used to do performance measures. Oracle SOA Suite 12.2.1 also introduces untyped JSON support and JavaScript support in composites and Service Bus. What better way to take a good look at both features by doing some performance measures using IWS on composites using untyped JSON and JavaScript!

I created 4 HelloWorld BPEL processes. Two of them are SOAP services and two of them are JSON services (not REST since they do not conform to REST architecture style). Two of these processes contain an assign activity using a JavaScript expression and one of them uses XPATH. I used SOAPUI to fire lots of messages on all services and measured responses. At the same time I had IWS activated to collect data on my processes. The results are quite interesting!

IWS + SOAPUI vs untyped JSON and JavaScript support in SOA Suite 12.2.1

Integration Workload Statistics

Introduction

Integration Workload Statistics provides valuable performance related information on your SOA Suite environment. This ranges from JVM memory usage to duration of BPEL activities. It even provides insight in the functioning of the SOA Suite by providing information on the transfer of messages over composite wires. You can not use it on the integrated WebLogic server provided with the quickstart of JDeveloper though.

Using IWS is simple. First you have to activate it (it’s off by default) by right-clicking the soa-infra application, Monitoring, IWS Reports. Here you can click configure and set the level of detail. After you have applied this setting, you can run reports on the collected data. Report formats supported are CVS, XML and HTML. HTML provides a readable format which also contains some explanation on specific results.

What does IWS report on?

First of all, IWS reports several metrics

• system resource usage
• composite statistics
• statistics for internal system queues
• statistics for synchronous and asynchronous business processes
• endpoint statistics.

on several components

• metrics on BPEL Service Engine
• EDN
• Web Service Binding
• File Adapter
• JMS Adapter
• FTP Adapter
• DB Adapter
• AQ Adapter
• MQ adapter.

As you can see, the REST adapter is not listed. We can still do measures though on processes using the REST adapter and obtain various other relevant pieces of information.

IWS on untyped JSON and JavaScript

My environment was running in VirtualBox. I used XE as database. SOAPUI, the XE database and the SOA AdminServer and Managed Server were running on the same machine. I used 4 different services and put load on them simultaniously.

HelloWorldXML

• A SOAP service receiving XML
• Contains an XPATH assign activity

HelloWorldJS

• An untyped JSON service receiving JSON
• Contains a JavaScript assign activity

HelloWorldXMLJS

• A SOAP service receiving XML
• Contains a JavaScript assign activity

HelloWorldJSXML

• A JSON service (typed)
• REST binding adapter converts the message to XML
• Contains an XPATH assign activity

The SOAPUI results were the following:

As you can see, the JSON services are faster than the SOAP services. The SOAP service containing an XPATH assign was slowest. Apparently a SOAP service using a JavaScript assign is faster than the same service using an XPATH assign.

Now, what were the IWS results? You can download the entire report here.

Interesting to see is that the process durations are around 10 times less than the SOAPUI measured response times. This could be overhead of the infrastructure. Also interesting to see is that the IWS performance results differ from the SOAPUI performance results. IWS reports that the SOAP service with a JavaScript assign activity is slowest while SOAPUI reports that the SOAP service using an XPATH assign activity is slowest. They both report a SOAP service as slowest though. SOAPUI reports that the JSON service with the JavaScript assign is the fastest while IWS reports that the JSON service using an XPATH assign is fastest. Luckily they both report a JSON service as being fastest. They clearly measure different things. There is obviously more to gain by looking further at these results. They are just a small example though of how useful IWS can be.

For a developer, the IWS results are more valuable since they measure the functioning of the SOA infrastructure more directly and from within and provide insight in the functioning of the SOA infrastructure. SOAP UI only fires messages from the outside and measures only total response time. The results from IWS are very useful since they indicate which processes are slowest and which activities take most time. Especially in a complex environment with many processes, this information is very valuable and hard to come by otherwise. I think many customers will like this new functionality.