Introduction
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 Mobile Cloud Services so will have a better understanding on how to manage multiple API’s and expose them to different application based upon their needs.
Main Article
Bottom-Up approach
First of all we need to rethink the way we design 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 Creating a Mobile-Optimized REST API article. .
Mobile Back-ends, 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 consumes by a single MBE. Below is a table of the listed resources in the above image with a short description and 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 resource can be shared between different Mobile-Backends.
Only the analytics/events and the notification service is uniquely bound to a 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 application 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 application 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 a MBE and mobile application. It shows that the MBE is a grouping of related application that share resources like API’s, storage, analytics and so on.
Managing users and roles for multiple application
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 from 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 rule 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 a 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.
Conclusion
When creating multiple applications on 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 back-end, API, storage, user realms and roles and how these assets can shared and separated.
A Mobile-Backend is the key gateway for your mobile application. It defines what users can access it through the user realm assigned to it. It also specified the collection of API’s and Storages that can be access through that MBE. In addition, events and analytical information is grouped within a mobile back-end and cannot be shared between multiple MBE’s.
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission