Introduction

To build functional and performant mobile apps, the back-end data services need to be optimized for mobile consumption. RESTful web services using JSON as payload format are widely considered as the best architectural choice for integration between mobile apps and back-end systems. Nevertheless, we have seen many customers of Oracle’s Mobile Application Framework (MAF) consuming SOAP web services in their mobile apps. One reason this is happening might be the nice declarative support in MAF/JDeveloper where you can easily create a SOAP-based data control through a wizard and build your pages using drag and drop. However, this wizard is only intended for really simple SOAP services. It cannot handle all XSD types, nor can it handle more complex, nested payloads. One way to work around these limitations is to process the SOAP payload programmatically in Java, but this is not a trivial task to do. While most of the issues around consuming more complex web services can ultimately be solved, this article explains why you should really abandon SOAP and go for REST-JSON services for one simple reason: performance. The differences in performance are staggering and get worse as the mobile device gets older.

Main Article

This articles discusses the results of a test conducted by Oracle’s A-Team to compare the performance of REST-JSON, REST-XML and SOAP service calls in MAF. We will first discuss the test set-up, then discuss the test results and we will end with a discussion of the options you have if you are currently consuming SOAP web services in your MAF application.

Test Set-Up

We have created an ADF Business Components (ADF BC) application that uses the HR schema to return a list of departments, including a nested list of employees for each department. So, the payload returned consists of 27 departments with 107 nested employee records.Each department row has 4 attributes, each employee row has 11 attributes.
In JSON format this payload is 26.2 KB, in XML format the payload is 77.3 KB in size (whitespace and carriage returns have been removed).

The more verbose structure of XML causes a payload that triples the size of the JSON payload.

Since the payload is relatively small, and the test was conducted on a fast WIFI network, this difference in payload size did not have a measurable impact on the test results, however if your own apps handle bigger payloads in environments with slow networks this difference can become a significant factor impacting overall performance.

The ADF BC application exposes its department-employees data in three different ways:

• Through an SDO SOAP web service using the standard “Publish as SOAP” functionality in ADF BC
• Through a Jersey servlet using the ADF BC “writeToXML” facility and some custom code in the ADF BC application to publish the data as REST-XML.
• Through a Jersey servlet using Google Gson library and some custom code in the ADF BC application to publish the data through REST-JSON.

The MAF 2.1 application consists of one page where we can invoke the three services through 3 buttons. After clicking a button the department list is shown and a popup showing the time it took to call the REST or SOAP service.

We separately timed the conversion to department and employee Java objects, and UI rendering time is not included either. All service calls where made programmatically in Java:

• The REST-JSON call was made using the RestServiceAdapter API.
• The SOAP and REST-XML calls were made using the AdfmfJavaUtilities.invokeDataControlMethod API.

As the name suggests, this call requires the presence of a data control, so we first ran the JDeveloper Web Service Data Control Wizard (SOAP/REST).
If you are implicitly invoking the web service in your own apps because you are using drag and drop from your SOAP or REST-XML data control, than the test results are still valid for you: under the covers MAF uses the same AdfmfJavaUtilities.invokeDataControlMethod API. The only difference is that when you directly build your UI on top of the SOAP or REST-XML data control, MAF does not convert the GenericType response objects to a list of concrete java objects, like we do in our test. We will study the performance of deserialization of Java objects in more detail in a separate article, but our measurements revealed that this Java object conversion is playing a minimal role in the overall performance comparison of SOAP versus REST.

Test Results

We have tested the web service calls on 4 different devices: an iPad 2 (iOS 8.0) an iPhone 4S (iOS 8.1), a Samsung Galaxy S4 phone (Android 4.4.2) and in the iOS Simulator. On each device, we called each service 10 times. The first invocation of each service was omitted from the test results because that call generally took 1-2 seconds longer because the relevant Java classes needed to be loaded. Here is a visual representation of the test results:

As you can see, the differences in performance are very significant. When we ignore the iOS Simulator which is not really relevant here, the REST-JSON calls are between 9 (Samsung Galaxy S4) and 30 (iPhone 4S) times faster.

REST-JSON is 9 to 30 times faster than SOAP in mobile applications!

If you want to know the exact average response times in milliseconds, here are the same data in table format:

We can conclude that calling SOAP web services on an older device like the iPhone 4S is just unusable. With waiting times up to 10 seconds, your end users are likely to discard your app as quickly as they installed it. On newer devices the difference is not that dramatic but still significant. And don’t forget that market share of older devices is still relatively large. According to this site, the market share of iPhone 4S (11%) is still larger than iPhone 6 (10%).You might wonder where these enormous performance differences come from. There is just one, simple reason: XML parsing is slow and CPU intensive. Also note it is not just the XML payload that needs to be parsed, all the XSD’s and the WSDL are parsed as well. For this simple ADF BC SOAP service that’s already 10 XML files.

I am using SOAP Web Services today, what should I do now?

Depending on your situation, there are various options to investigate:

• Make the SOAP calls faster
• Execute SOAP calls in a background thread
• Rewrite your SOAP services to REST-JSON
• Transform your SOAP Services to REST-JSON before consuming them in MAF

Let’s go over all these options.

The first one sounds probably most attractive to you as it minimizes the impact on your existing apps. As explained above, the slow and numerous XML parsing is the main cause of the bad performance. You might wonder: can’t we use a third party library to see if we can increase the speed of XML parsing? The answer is no, there is no way to plug-in your own XML parser code when calling AdfmfJavaUtilities.invokeDataControlMethod or when directly using the SOAP data control. The only way to use third party libraries is to not use the MAF API’s at all to call a SOAP service. But remember that MAF 2.1 uses the JDK 1.8 Compact 2 Profile, which does NOT include the JAX-WS API’s. So, this route would require a lot of investigation and custom code with no guarantee of a faster solution.

A bit more viable option, assuming you have to stick with SOAP for whatever reason, is to execute your web service calls in a background thread, allowing the user to continue to work with the app while the data loads in the background. This should be done in combination with on-device data caching using the SQLIte database so you can quickly show the end user the data previously stored in the SQLite database, while in the background you fetch the latest data from the server. Notice that with this approach you put all your SQLIte and SOAP-calling logic in a service class that you turn into a bean data control, which means you have to rewire your UI bindings from the SOAP data control to the bean data control.

The only real solution is to embrace industry best practices and move to REST-JSON services. If you have control over the development of your backend SOAP services and you don’t (yet) have other systems relying on the same SOAP API , you might be able to change them into RESTful services using JSON. The amount of effort involved depends on the way these services have been built. For example, if JAX-WS is being used, it is no rocket science to replace this with an implementation based on JAX-RS.

However, in the majority of cases you will be faced with existing backend SOAP services that cannot be changed. In this situation, you should add a layer to your server-side architecture that transforms the enterprise SOAP services to mobile-optimized REST-JSON services. Oracle offers two options to do this:

• You can implement this layer on-premise using Oracle Service Bus (OSB) 12c or Oracle API Gateway. A-Team provides an article series for OSB newbies to create such a mobile-optimized API.
• You can implement this layer in the cloud using Oracle Mobile Cloud Services (MCS). MCS is a new product that was announced during Oracle Open World 2014, and will be released later this year, for more information see the article Intro to Mobile Cloud Service.

While building this transformation layer takes additional time and possibly requires learning new skills, it is our experience that building this layer is an investment that quickly pays back. A mobile-optimized REST-API is much easier to consume in MAF resulting in shorter development cycles, and above all in much more responsive mobile apps as we have shown in this article.As mentioned in the introduction, you might have started using SOAP services with MAF because of the nice declarative support through a wizard and data control. A-Team offers a free extension to Oracle MAF called the A-Team Mobile Persistence Accelerator (AMPA) which provides the same level of declarative support for REST-JSON services. In addition, AMPA provides you with an on-device data caching layer and data synchronization functionality which allows you to use the mobile app in offline mode without any Java coding required from your side.

I am using the REST-XML Data Control today, what should I do now?

While not as bad as SOAP performance, the above test results clearly show that calling RESTful services with XML payload through a data control are considerably slower than REST-JSON calls through the RestServiceAdapter. The options discussed in the previous section to move to REST-JSON also apply here. There is another way you can improve performance by using the RestServiceAdapter to programmatically call your REST-XML service instead of the REST-XML data control. We will study the performance impact of this approach in a separate article.

All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission