Oracle Mobile Cloud Services (MCS) is a cloud-based service introduced mid-2015 that provides a unified hub for developing, deploying, maintaining, monitoring, and analyzing mobile apps and the resources that they rely on.
It should be noted that MCS is markedly different from other offerings in the MBaaS space, specifically targeting enterprise clients while other products such as Kinvey and Google’s Firebase offer product versions geared for enterprise clients among other service levels.
MCS provides the following product versions:
For this review, we tested the Non-Metered version with iOS.
MCS offers all the essential and common features we have come to expect from an MBaaS provider, and also provides several nice value-add features such as an App Policies API, the Mobile Application Accelerator (MAX) interface, and Location (geolocation) that help it stand apart from competitors in certain respects. This review will focus primarily on the functionality and quality of the essential and common features, though we’ll also look briefly at additional features.
Authentication and User Management
For an app to access any resources through a mobile backend, its user first has to be authenticated with that mobile backend. Oracle provides OAuth, enterprise single sign-on (SSO), Facebook login, and HTTP Basic authentication for this purpose. The authentication features in MCS are first class and provide app users a robust, secure, and easy to use authentication method using industry standard practices, including the requisite social login capabilities.
Users can be added and managed through the console interface. The user management features are simple and straight-forward, consisting of the ability to create a new user, a password for that user, and allowing the new user to be assigned user roles. Having said that, MCS has the most complex set of roles for creating a team user account from the MBaaS offerings we have reviewed so far.
The user roles in MCS provide access granularity to the available business objects. Individual business object access granularity is then left to the developer by breaking down the business object access into one or more custom APIs, each mapped to specific roles.
For example, full business object READ/WRITE access may be provided in a single role. If the object access to READ/WRITE actions must be separated, a “readOnly role” and an “editor role” would need to be defined. This breaks the CRUD (create, read, update, delete) actions into two separate custom APIs, one providing WRITE access and the other provide READ access.
The Storage API allows mobile apps to store, update, retrieve, and delete media such as JSON objects, text files, and images. This is done in collections in an MCS environment. Each object is stored and retrieved from the collection by a user or system-generated GUID (globally unique ID), and roles are used to control who can read and write the objects in the collection.
Storage is handled by a container that provides a group of storage collections (i.e., a document object key-value store). A storage collection can be defined as shared/user-related collection of binary/string objects, and can be marked as cacheable and participate in synchronization.
MCS can provide list of all object metadata within the storage collection but each object must be subsequently queried for the raw object. If a storage object is marked as cached, then the mobile application will pull the objects in the collection on every attempt to access the object if a device is online.
If a storage object is marked as cached, then the mobile application will pull the objects in the collection on every attempt in order to access the object if a device is online.
Though not intended as a content delivery network, storage in MCS is ideally suited for a limited data set where the keys are known.
The file storage feature in MCS is lean but can provide value for simple data structures either associated to a specific user or for shared access. In our opinion, the storage API has limitations with respect to cache/synchronization that a developer must be aware of prior to considering the use of this feature.
Limitations could be overcome if support is provided to allow user-defined synchronization policies and provide mechanisms for bulk retrieval of storage objects within the collection.
MCS provides Database APIs for creating and managing database tables for mobile apps. The Database Management API is used to:
UI/REST-API methods support create/delete table methods and list/get table metadata. Everything else related to the user defined table needs to be handled with custom code in a custom API.
Lightweight query operations are also supported. For this, Oracle recommends that the heavyweight database available via the PaaS connector API be used for full SQL support.
CRUD operations for table objects are conducted via custom API.
The data storage features in MCS provide simple, lightweight access to business objects that do not require a high level of query/filtering requirements. This is common to document storage and simple queries. Sorting methods are also supported.
If an app’s requirements are more in line with a relational database model, such as unions, joins, aggregation, and such, then more sophisticated APIs are available for use with a subscription.
MCS provides offline caching of custom API model data, which is defined by the associated synchronization policy applied. Tailoring of synchronization policies provides fine granularity of control relating to how model synchronization is applied, and if desired, can also prevent local caching.
The MCS storage API also provides offline caching. However, the objects in the defined storage API are always retrieved from the storage services when the application is online.
MCS provides a notifications API to simplify sending notifications to devices running mobile apps. Developers can set up mobile applications for notifications and use the Notifications API to send notifications or implementation code within the custom APIs to trigger notifications.
MCS supports basic one-way messaging from service to mobile device, and any distribution-based notifications (e.g. tags, groups) must be implemented via the custom API.
For SMS messaging, individual devices must be registered via the UI/REST API in order to participate in SMS notifications. APNS, GCM, WNS or SMS registration is done via mobile APIs.
Notifications can be sent immediately or scheduled for a later time to any of the following:
MCS allows notifications to be issued or cancelled, and notifications status checks queried using a notification ID, using UI/REST-AP. Custom payload support is also supported.
MCS is designed with enterprise-grade security baked in. Once a user is authenticated, access to APIs is controlled through its mobile user management features. Realms allow mobile apps to use a shared set of users and data, and roles define permissions that control user access to APIs and resources from the mobile apps.
Security for custom APIs can be configured individually for each API. Users can decide whether or not an API can be accessed anonymously (without a user login). If not, the authorization policy can be defined by specifying which roles can access the API or specific endpoints.
MCS’s connector APIs also have access to security functionality, which is especially important if the connection involves transmitting proprietary or sensitive information.
The security features are well thought out and simple to define. If security is desired for a particular business object, object access is constrained to users who are authenticated and participate in roles associated to the business object.
MCS provides an analytics API to help measure patterns in app performance and usage. The analytics service in MCS provides features such as:
Custom reports on desired analytics can be created and stored in the console, and sessions (which in MCS are more like context sessions than user sessions) can be requested and terminated at any given time.
MCS’s analytics features are lean but powerful and can provide many broad insights into usage patterns, in some cases outweighing the features of many competitors’ entry level offerings. Comparatively, the analytics tool in MCS is more robust than those provided with many other MBaaS offerings, though it is not quite on par with Firebase, which we have found to provide best in class analytics for an MBaaS.
MCS’s Express API Builder, which takes user data input to rapidly scaffold a custom API based on the provided schema, has the added benefit of tooling in the UI that allows a developer to “shape” the data that is presented to the mobile device. This data shaping allows the developer to constrain a result set by limiting the fields presented to the mobile device which can save bandwidth by providing lean payloads tailored to the mobile application. Unfortunately at this time, data shaping capabilities via the UI are only available in the express API. If the developer wishes to shape the result set, they would have to implement this in the custom API code.
Unlike the MCS platform APIs (which provide a core set of known services), custom APIs let users use Node.js to code any service the client’s mobile apps need, published through a REST interface. Data can be relayed using an MCS connector to a backend service. Custom APIs are NodeJS proxies, which allows clients to access data from connector APIs via a common interface, protected via role-based access.
MCS’s Express API Designer can be used to create an API by providing sample data, leaving MCS to define a set of endpoints.
List/object synchronization is regulated by sync policies and is available via a platform synchronization library, which in turn calls the custom API.
MCS provides four types of connector APIs:
MCS also includes the following additional features, which are not generally thought to be integral to an MBaaS and were not tested for this review. Some of these features are nice value adds that enhance an MBaaS product.
The App Policies API can be used to create read-only custom properties in a mobile backend. The properties can be accessed in the client’s application with REST calls.
App policies are custom properties that can be defined and adjusted in a mobile backend and then referenced from apps through a simple REST call. With an app policy defined, their value can be updated at any time, even after the mobile backend has been published. This allows for changes to the appearance and behavior of a deployed app without having to update the app itself.
Here are some of the things app policies could be used for:
Location is one of the most important contextual data points and with it the impact of location-aware mobile apps on users and businesses is increasing.
MCS’s location integration is a light-weight offering that is comprised of a set of location-aware objects that have hierarchal linkages so that an asset can be associated to a device or a place.
MCS uses three location-aware objects, location device, place, and asset, which are explained here.
A developer has to create specific custom APIs accessing the locationManagement REST endpoint to handle requests from a mobile app/service app with a Bluetooth listener that receives beacon broadcasts and then sends handset geolocation coordinates and the device name to the service in order to refresh the GPS position information of assets associated with specified device name.
Other custom APIs would handle user/timed events to process actions that would query the asset/device/place information and perform tasks related to the location information.
One nice feature of MCS is the Mobile Application Accelerator (MAX) interface. In concert with its Express Custom API, it provides a hybrid application interface using the client’s data model schema as the basis for creating the services needed to create, modify and deliver content to the mobile device. This includes boilerplate code to consume and display them on mobile platforms. This feature has the ability to provide rapid-development capabilities to compliment natively developed or stand-alone apps, providing interfaces for data model instance management utilizing the common master-detail pattern.
MCS is a robust service with a high-quality, easy to use console that provides all the necessary interfaces to setup and deploy mobile projects in a very short timeframe.
Overall, the administration portal is well thought out and provides quick access to all the components needed to produce the mobile product offering. Some elements of the interface, however, are a bit difficult to find, though they are generally within the correct context.
The other concern we had was that, in logging in to the service console, the first thing the user sees is basically a help page with tutorials, which is beneficial to new users but can become a nuisance. To make it their own and not see support material every time, users need to customize the home page.
The iOS SDK has code libraries and comes with sample apps. As far as the design of the client SDKs are concerned, they are not very modern, and though the iOS SDK comes with a sample app, it is somewhat clumsily written in Swift. More attention could have been paid to the quality of the code.
The mobile libraries are first generation attempts at bringing mobile devices into the Oracle Cloud offering and though MCS lacks more modern development paradigms such as Reactive programming, it is easy to use and to shield the developer from many of the complex requirements of designing and implementing enterprise grade mobile applications.
MCS provides a lot of flexibility in creating custom APIs, though there is a chunk of work that must be done that could have been part of the system. So even if someone doesn’t need the flexibility, they’re forced to do the work.
Performance – Response Time
Performance was tested by trying to ascertain how many responses per minute the database can process and respond with information to complete a request.
We gauged response times by retrieving 150 data items using 100 concurrent users. In comparing MCS’s performance with some other MBaaS solutions, it averaged 105 responses per minute for data downloads, which clearly outperformed Kinvey, Developer Edition (46 responses/min), Backendless Cloud (56 responses/min) and Firebase Spark (77 responses/min). Though comparing these entry-level products to the enterprise-level performance of Oracle’s solution isn’t a fair comparison, it sheds light on the performance bang you can get for your buck when investing in an enterprise solution.
Performance – Throughput
When multiple users connect to a single server, they share the same bandwidth for downloading content. In measuring throughput to help us understand the rate at which data is transferred, we had 200 concurrent users download a 1 MB image.
In direct comparison to other MBaaS solutions, Oracle again proved that there is a benefit in investing in an enterprise solution, though it may not be vast. While Oracle (73.6 MB/s) did outpace the other solutions, it was not by a huge margin. The throughput for the other MBaaS solutions was as follows: Kinvey, Developer Edition (59.2 MB/s), Backendless Cloud (58.4 MB/s), and Firebase Spark (50 MB/s). With this in mind, it would be interesting to test enterprise-level solutions from the other vendors to see how significantly the performance increases from these lower-tier offerings.
Testability, defined by applying the concepts of verifiability and controllability, allows the Quality Assurance team to identify areas to test, how to test, and what tests can be performed for each feature. If the testability of the SDK is high, then the probability of finding faults in the system by means of testing is greater. This also helps us gauge which tests provide us with the most confidence and correctness.
From the MBaaS offerings we’ve been exposed to, MCS has the most complex roles required to set up a team user account. After the team user is created, an admin has to assign the proper roles. MCS is specifically designed for an organization that has different roles take on different responsibility structures (e.g. service admin vs account admin). Having said this, reading their documentation and understanding all the different roles is very important, and will save time when doing troubleshooting.
From time to time, we faced problems loading the MCS console. The console would either display a blank screen or an error page telling us to try again. Our workaround was to try a different browser, clear the browser cache, and/or restart the machine, which can be troublesome from time to time.
Authentication and User Management
Setting up a team member is more complex than it is for MBaaS offerings such as Backendless or Kinvey. However, since MCS is an enterprise MBaaS, it’s expected that a team member has to be created by an admin and assigned the role properly. Testing is quite simple, though, after the account has been properly set up.
Initial setup is different than most MBaaS offerings because the collection has to be created and a permission/role has to be assigned before the object can be saved. Most competing solutions do not have this requirement so the object can be uploaded as an entity. Other than that, testing is very straightforward, objects can be updated/added/deleted via Rest API or a demo application or using the console itself.
Oracle allows users to use the MCS console to control how long data from the storage API remains cached in a device. The default is set to 24 hours but can be changed from the console in the Administration section by modifying the “policies.properties” file.*
This can be tested by shortening or lengthening the time through the console and verifying the sync time to the application using a proxy to check the received value from the application. Once the value is synced to the application, a verification needs to be made that the object expires (is no longer accessible) according to the set value.
Before creating the location, a team member must have a location management role. With this role, a list of places, assets and devices can be defined using the location management API from custom code, directly in the location section of the console, or by uploading a csv file.
The list of assets, devices, and places can be retrieved using Rest API or the console, but can only be updated using the console.
To test the location services, the app needs to be connected with a map to verify the list of locations in MCS. Otherwise, users can only check the data point via Rest API to see if the API is sending it from MCS.
Custom API For Database
There is an API test interface on the console that allows users to make different calls to the database based on the methods included in the custom API. However, before this can be tested, the documentation, schemas and RAML files have to be defined along with the test scope. After the test scope has been set, the testing itself is quite straightforward but may be time consuming depending on how many custom APIs have been created and what the scope is for each of them.
To test notifications, a notification-enabled application is needed to receive it. The web interface from the documentation page or Postman will let users send the notification using Rest API.
Oracle Connector is a means to connect to external APIs. It can be easily set up through the console, and includes REST, SOAP, ICS, and Fusion application connectors. The console has a setup wizard, which is very easy to follow.
After the initial setup, the API test interface in the Oracle console as well as any Rest API tools can be used to test the configuration. Since Oracle supports several API connectors, it may be time consuming to ensure that all the connectors work as expected. The documentation is very thorough, and going through it will help speed up the configuration time.
To deliver an analytics event, the JSON payload needs to be delivered using REST calls or through the application. To test this, the JSON payload can be constructed and then delivered using REST API tools to ensure the event is tracked correctly. We can also use the demo application with proxy to view the JSON payload.
For custom events, testing could be very time consuming as a company will usually want a multitude of different events on the same screen and for every button tap. A predefined list of custom events is recommended, and it will help speed up the testing process since there will be no guessing and assumptions involved. Once the list of events is defined, testing is quite straightforward.
Footnote for *: This value is labelled as Sync_CollectionTimeToLive in the policies file. To access this value, the request header must include Oracle-Mobile-Sync-Agent and should be set to true. This value is returned in the header of the response and is labelled as Oracle-Mobile-Sync-Expires, and can be accessed in the app source code and used to configure the cache time to live. If the storage collection is configured to disable offline caching, the response header will include the value Oracle-Mobile-Sync-No-Store set to true to direct the app not to cache the returned data.
MCS can only be deployed to the Oracle Cloud. There are client tools available for connecting to the Oracle services that can be installed locally on an OS platform.
MCS Cloud has tooling via the administration console to easily create multiple versions, and publishing of a production version can be performed in a single click.
Support for MCS is top notch, with an extensive amount of reading material around platform concepts and implementation details. A large offering of video tutorials is also available, all arranged into manageable segments each geared toward a specific feature set. There are also tutorials for helping a developer quickly scaffold a working mobile ecosystem showcasing the features of the platform, providing a basis for understanding the implementation requirements of the various pieces necessary to serve enterprise mobile data.
With regards to testing, we especially like the API documentation and the API test interface. The API documentation has all the API endpoints MCS provides, and gives us easy and fast access to all API endpoint information. The API test interface, accessed from the console in the individual sections, displays the sample request and response for the backend. Users can easily troubleshoot using the API test interface to ensure the endpoints are working correctly before trying to access it with the new application.
The iOS client SDK comes with help documentation as well as a sample app, which we discussed in the Design section. The app, however, is not itself documented.
MCS offers a scalable pricing model for enterprises large and small, starting at a $65 per month for a maximum of 10,000 API calls, though with a 35 block minimum, which brings the minimum monthly cost for the entry level solution to at least $2275. This is in line with other enterprise-focused MBaaS offerings such as Kinvey’s Business Edition, which costs approximately $2000 per month.
Unlike many competitors who expand their feature set (and price) with product tiers, Oracle chooses to provide all features at the base price and clients only pay more for additional API call volume and storage.
The one feature that adds significant value to MCS is MAX, which is unique in the realm of MBaaS offerings. If this is not a needed feature, there is definitely less value to be had for the price tag, but it’s debatable at that point it it’s more or less than its competitors.
The Final Word
MCS is a reasonably mature offering that has some growing pains, though this is something to be expected to a certain extent from an enterprise product this young and a company that is new to this space.
On the whole, though, the pros outweigh the cons, and if finishing touches are upcoming in future releases, it will go a long way to making this a very strong contender in the MBaaS space.
The following is our rating scorecard for Oracle:
iOS App Development, mobile strategyRead More
Android App Development, iOS App Development, Mobile TestingRead More