Architecture considerations for integrating mobile applications with cloud and on-premise applications

Introduction

A mobile application requires an easy to use, flexible, secure and fast integration to various backends to access the data required by the mobile application. Ideally such an infrastructure should also allow for leveraging an existing IDM stack to be re-used by the mobile application.

This article is intended to give architectural considerations how to integrate a nice-looking and modern mobile application with various backends using the new Oracle Cloud mobile/integration offerings.

Tip: Oracle Fusion Apps, Siebel, SAP, Salesforce, Oracle Sales Cloud or any application providing SOAP/REST services can be used as backend. This article will only use Oracle Sales Cloud and Oracle Core Banking to illustrate the principles.

Main Mobile/Integration Cloud Offerings

In the examples we will use a set of new Oracle Cloud offerings including:

• MCS (Oracle Mobile Cloud Service)
• ICS (Oracle Integration Cloud Service)
• SOA Suite on JCS (Oracle Java Cloud Service)

You can get more information about these services at: Oracle Cloud Offerings

Main Article

The examples used here are part of a fictitious mobile banking application.

A Simple example

First let us start by looking at the data requirements of such a mobile application which shows a customer’s address data after he has successfully authenticated via a login page. So the first thing is to check what data should be presented on the screen:

{
 profile: {
    name: "John Doe",
    username: "johnDoe",
    addressLine1: "Abbey Road1",
    addressLine2: "London",
    postcode: "ECA1",
    country: "UK"
 }
}

You can get the relevant data from Oracle Sales Cloud, but the retrieved data is not necessarily in the expected format. Here is the result of a sample call:

{
 profile: {
    name: "John Doe",
    username: "johnDoe",
    address1: "Abbey Road1",
    city: "London",
    code: "ECA1",
    country: "UK"
 }
}

It’s obvious that the attribute name adressLine1 used in the application does not map to the attribute name address1 coming from Oracle Sales Cloud. Same applies to addressLine2 versus city. The line with attribute name postcode needs to be mapped, too, as we get the fieldname code from the backend. These mappings needs to be done to use the result in the mobile application.

Let us compare some options to accomplish the above. We also should keep in mind that we need a solution which is fast, reliable and easy to change.

Option 1

Using MCS only for the solution. Here is a short list of pros and cons:

• no additional component involved
• does not scale very well for integration – it has only limited resources available for backend connects and can not parallelise the backend work
• everything needs to be developed manually using JavaScript (you need very experienced people, higher effort in case of changes compared to integration engines)

Option 2

Using MCS as central component for the connect from the mobile devices. Add ICS cloud option for backend integration purposes. Here is a list of pros and cons for this approach:

• additional component involved (but only a single webservice call needed between MCS and ICS which is easy to create and will never be changed)
• ICS scales very well for integration purposes
• built for integration so simple and easy to use with defined ui’s for backend connectivity and data mapping
• replacement of a backend solution is much easier as mobile/MCS side is not affected ( for example use of Oracle Sales Cloud instead of Salesforce)

Comparing these pros and cons for the available options would lead us to use option 2 as the best approach for this integration.

Here is a graphical representation of option 2 :

Explanation

1) Mobile Devices call MCS via REST call
2) MCS calls ICS via REST call
3) ICS calls SalesCloud via sync SOAP (can be any SaaS/OnPremise-Application which offers WebServices)

Tip: In most cases you have the choice if you want to do the sync calls using SOAP or REST calls – normally that depends on which adapter is supported by your application.

A More Complex Example

But what happens if your mobile application needs to work with more complex data and multiple backends. Let us discuss that again using a more complex example from the same mobile application.

Your customer now wants to see the balance of his banking accounts as you can see now in the payload presented here.

{
   profile: {
      name: "John Doe",
      username: "johnDoe",
      addressLine1: "address1",
      addressLine2: "address2",
      postcode: "code",
      country: "UK"
   },
   accounts: [
      {
         id: "1234-5678-1234-8654",
         name: "Classic Checking",
         balance: "7120.36",
         currency: "USD",
         type: "checking",
         actions: [{action:"deposit"},{action:"transfer"},{action:"billPay"}]
      },
      {
         id: "1234-5678-1234-5432",
         name: "Regular Savings",
         balance: "5874.54",
         currency: "USD",
         type: "savings",
         actions: [{action:"deposit"},{action:"transfer"}]
      }
   ]
}

We now have two parts in our payload. The profile part is coming again from Oracle Sales Cloud as mentioned above. The accounts data is stored in our example in Oracle Core Banking. So we will need to retrieve information from more than one source, do the mapping for every source, and combine the results for consumption in the mobile application. So we need to check what options we have to do that and again compare the pros and cons. We will do that based on the decision made for simple integrations so using MCS only is no viable option anymore. As ICS does not yet offer a method to combine the results of multiple sources we will have to add SOA (based on Oracle Java Cloud) to the architecture.

Option 1

MCS calls SOA directly to get the data back from there. SOA in turn calls the backends, does the mapping, aggregates the data and sends this to MCS.

• Mapping is not that much work as in MCS but need to be done more manually compared to ICS
• Any change in a backend (replaced backend or API changes) will trigger a re-development and re-deployment in SOA

Option 2

MCS calls ICS to get the data. ICS then calls SOA and SOA will directly call the backends. SOA does the mapping, aggregates the data and responds this to ICS. ICS then sends the data to MCS in the same format.

• Will fit in the existing architecture
• Reduces the complexity on MCS side as it only has to call ICS for all cases
• Mapping is not that much work as in MCS but needs to be done more manually compared to ICS
• Any change in backend (replaced backend or API changes) will trigger a re-development and re-deployment in SOA

Option 3

Similar to option 2. But this time SOA will not call the backends directly. It will call ICS to get the needed data and combine them to the correct format.

• Will fit in the existing architecture
• Reduces the complexity on MCS side as it only has to call ICS for all cases
• Offers more backend adapters and more flexibility for the mapping – no redeployment needed for changes
• Even replacing backends will be much easier as this can be done in ICS – no need to change anything in SOA – so more flexible

From our experience endpoint virtualization as provided here by the additional layer in ICS is worth the investment – which will lead to choose option 3.

The graphical representation of the architecture looks like this:

Explanation

1) Mobile Devices call MCS via sync REST
2) MCS calls ICS via REST call
3) ICS calls JavaCloudService(SOA 12c) via REST call – (this will give the results back to ICS after the calls in step 4 and 5 have succeeded and SOA has built the payload for the answer)
4) ICS calls Oracle Sales Cloud via sync SOAP to get customer data
5) ICS calls Oracle Core Banking App via sync SOAP to get banking account data

Tip: In most cases you have the choice if you want to do the sync calls using SOAP or REST calls – normally that depends on which adapter is supported by your application.

Identity Management / Security Aspects

MCS is designed with enterprise-grade security baked in. Security begins at the level of the mobile backend. MCS security takes care of:

• Authentication – the user logs in.
• Authorization – the user only gets access to the information he should see and can only perform the actions he should be able to.

MCS uses the OAuth protocol for the authentication from the mobile devices. An OAuth token will be created during login and will be used for the subsequent interactions to identify the user. This token is also used to authorize the users information and actions on MCS. As we only use supplied functions it will not create additional work to use this security framework.

Summary

This article provides an overview of options you have to integrate a mobile application with your existing or future backend environments leveraging Oracle’s PaaS offerings for mobile and integration cloud services. It should provide some guidelines on how to architect the background integration depending on requirements.

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