Best Practices from Oracle Development's A‑Team

Managing Multiple Applications in Oracle Mobile Cloud Service


When the landscape in IT is changing from an on premise architecture to a cloud based architecture and from a desktop based workstation to mobile and tablet workstations,  some questions may arise from an enterprise architecture perspective. On of those questions will probably be: "How do we manage multiple applications" .
When you have to design multi-channel application you have a set of back-end services, security providers, policies and so on. How do you manage these assets and how do you make them available to different application?

This article will guide you through some concepts used in Oracle Mobile Cloud Service (MCS) so will have a better understanding on how to manage multiple application programming interfaces (API's) and expose them to different applications based upon their needs.

Main Article

Bottom-Up Approach

First of all we need to rethink the way we design mobile API's.

Currently, many enterprises are using a Service oriented architecture which advocates a top-down approach. All the services are created independent from who or what consumes these services. This top-down approach will provide services that can be used in the entire enterprise and if a new application requires any of these services, the application needs to consume these service as-is.

The difference with the bottom-up approach is that we tailor the services, or API's on the need of the mobile application. At first this might contradict with everything a proper enterprise architecture stands for, however when we start to think about it, it makes more sense.

Current SOA enabled services are consumed by applications deployed on heavy hardware. They have plenty of processing power and super fast network connection to the back-end services.
If we look at the mobile landscape, all the processing power comes from a single device. Your mobile phone or tablet needs to parse huge amount of data coming from the server. Because of this we need to rethink the design of the services that are consumes by these devices.

In general an application deployed on a server will call multiple back-end services to build the data model for a single screen. While the server can call these services in parallel and build the screen in an asynchronous way, a mobile device lacks that capability. That is why it is better to tailor these service for mobile consumption. These services also need to be optimized for mobile usage so only the data that is used on the mobile device will be included in the response. This will result in the best performance for your mobile application.

More information about designing mobile optimized API's can be found in the article Creating a Mobile-Optimized REST API.  .

Mobile Backends - Gateway to your Application

If you want a mobile application to connect to your resources in MCS you have to create a mobile backend (MBE). An MBE is like a gateway for your application into your mobile assets. They are a server-side grouping of resources that can be used to group mobile applications.


Even though an MBE is a grouping of resources, this does not mean these resources can only be consumed by a single MBE. Below is a table of the listed resources in the above picture with a short description and an indication if you can reuse them in multiple applications and MBE's.

Resource Type Description Can be shared between applications
API Collection of REST endpoints Yes
Storage Storage to store basic files like images, JSON files and so on Yes
Connectors Connections to REST or SOAP based services which can be your own on-premise services or other cloud based services Yes
Users/Roles Authentication and Authorization configuration Yes
Analytics/Events Analytical information about the usage or custom events happening in your application No
Notifications Notification service to provide push notification to Google and Apple notification service No

As you can see from the above table, most resources can be shared between different mobile backends.

Only the analytics events and the notification service is uniquely bound to an MBE. This can lead to some design considerations.
For example if you want to create advanced analytical events you have to make sure all your mobile applications share the same MBE, otherwise you won't be able to link them together.

Let's say you have a banking application for customers so they can access their accounts. The banking representatives have a different application that provides them with a 360 view of their customers. Both applications are different and will require different roles and users however they need to be exposed through the same MBE otherwise you won't be able to share analytical data between the customer application and the representative application.

The above example shows that there is no one-to-one mapping between an MBE and mobile application. It shows that the MBE is a grouping of related applications that share resources like API's, storage, analytics and so on.

Managing Users and Roles for Multiple Applications

If you are building multiple applications on your MCS instance you also want to make sure you organize and manage users in a proper way.

Following image shows a diagram on how the different security elements in MCS work together:



Users are organized in User Realms. Each realm is a container for users and a schema to define the user attributes.

An MBE can only be linked to a single user realm so only the users in the configured realm will be able to access the application. This feature can be used to create a barrier between your applications and acts as a security boundary so you have full control over who can access your application.

Roles on the other hand are independent of user realms. If you have a "Customer" or "Admin" role, you only have to define it once and it will be reusable over all MBE's and user realms.
The purpose of a role is to restrict access to API's and storage.

Each API can have a global role but you can also assign specific roles for each resource and method combination within your API.
This also means security on your API is independent from an MBE. You cannot restrict a specific user access to an API from one MBE while he has access to that same API through another MBE. In that use case, you have to implement additional security checks on the mobile application itself or through custom code.


When creating multiple applications in MCS it is important to think ahead and consider how to manage the different assets in MCS.
it is important to understand what the relation is between a mobile backend, API, storage, user realms and roles and how these assets can be shared and separated.

A mobile backend is the key gateway for your mobile application. It defines what users can access through the user realm assigned to it. It also specifies the set of API's and storage collections that can be accessed through that MBE. In addition, events and analytical information is grouped within a mobile backend and cannot be shared between multiple MBE's.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha