This article had the working title ‘blurred lines’ because I felt that people might be confused about what Oracle offers in the mobile space. However, putting it on the internet with that title is not a good idea, because it would attract lots of people that are looking for that song… So anyone who’s looking for music: you’re in the wrong place! This article is more suited for people who need an overview of what Oracle in doing with Mobile. Let’s move on.

Recently, OOW2015 made more clear than ever that Oracle is really dedicated to offer a complete portfolio of Cloud Services, covering virtually anything that an enterprise would require for moving its IT business into the cloud. As a result, Oracle is also (more) active in areas where historically they had less presence, e.g. in Mobile. The many new developments in both the client and server sides are at such a high pace, that one might feel that Oracle has had some kind of wake-up call. Simultaneously, that makes it easy to lose track: the Oracle strategy may seem like blurred lines. Let’s try to put that into some more perspective.

Client side

Oracle currently has a lot of technologies that ‘have mobile capabilities’. Next to the obvious Oracle Mobile Application Framework (MAF), also Oracle JET is positioned as ‘mobile first’ with its new Masonry layout. A good example that supports this claim very well is the Oracle JET WorkBetter example application.

The figure above shows how the application adjusts itself very nicely to the device. Just spend some time to check it out yourself. It’s surprising!

Newest additions in client technologies will be the Application Builder AB and Mobile Application Accelerator MAX. Both are services in the Oracle Cloud that can be used for ‘Business users that will build their application without assistance from the IT department’. The Application Builder generates a web application that can be used on a mobile device. The Mobile Application Accelerator generates an Oracle MAF application – which is obviously focused on mobile devices.

Oracle did make a positioning statement on its client technologies in OOW 2015: it was based on developer skills:

• Java developers: Oracle MAF and ADF
• PL/SQL developers: Oracle Form and APEX
• JavaScript developers: Oracle JET
• Business users: Oracle Application Builder and Mobile Application Accelerator

But that cannot be a good basis for picking your client technology! Picking APEX as a technology because you have PL/SQL developers will not bring you anywhere close to a fancy mobile application!

Looking at the choice for client technology, the following aspects should be taken into account:

• Mobile capabilities: when mobile capabilities are required like user management, push notifications, device capabilities like location and camera, the choice will be towards a mobile app. The Oracle technology of choice is then Oracle MAF and in the near future Oracle MAX for the business user. For Oracle MAX it will depend on what mobile capabilities will become available in the application development environment.
• Mobile apps lifecycle: a mobile app that is offered via an App store will benefit from the App lifecycle model. The App can be installed, can have configuration settings on the mobile device and can be updated when required, etc. When these capabilities are required, Oracle MAF is again the technology of choice. For Oracle MAX, the same consideration as above applies.
• Web applications: there will be a – presumably large – number of web applications that don’t require specific mobile capabilities, but nevertheless need to be accessed from a mobile device. These can be built using Oracle JET or Oracle ADF or the future Oracle Application Builder.

Perhaps your company’s requirements are even different: you only need to make APIs available to external App developers. In that case, your will want to provide a rich API with the required capabilities. Your focus will then be on the server side of things, to provide a secure, standards based API solution that is attractive to app developers for at least the iOS, Android and Windows platforms.

Server side

Mobile applications that are used via non-enterprise mobile networks require a secure API access to data and services inside the enterprise. An infrastructure needs to be put in place where these requirements are implemented.

In that area, Oracle has several offerings, each with their own specific functionality and therefore with their own right to exist:

• Oracle API Catalog is a design time governance tool that can collect API data from services WSDL and WADL. It makes visible to the developer what services are available on the various environments. Oracle API Catalog is built on top of the Oracle Enterprise Repository OER.
• Oracle API Manager runs on top of the Service Bus and supports API life cycle management: discover, consume and monitor APIs running on the OSB.
• Oracle API Gateway is a standalone product for management of services and (security) policy enforcement for services. It is an OEM-ed product that was also known under the name Oracle Enterprise Gateway.
• Oracle Mobile Cloud Service is a NodeJS based platform that offers support for making services (APIs) available to mobile clients. This platform also supports additional functionalities like sending push notifications, user management, storage, off-line capability, analytics and API Catalog functionality. This is – obviously – a Cloud offering, but it important to note that this does not have an on-premises version.
• From the security area, there is a ‘Managed Secure Container‘ that secures enterprise apps and data on a mobile iOS or Android device.  Note that this component was put in ‘Server side’ – whereas it would be more likely to put it on ‘Client side’. It was put here as it is one of the infrastructural components that an application may need.
• And then there is also the Service Bus and SOA Suite that – already for some time – can support APIs, i.e. REST services.

But… what to use when?

Picking your solution

The figure below gives an overview of the previously mentioned technologies. The blue arrows are (some of) the areas where you need to make decisions. For example ‘do I need design time and/or run-time governance?’ Or, ‘do I need to give my Business user the ability to make a mobile App?’. 

All in all, it’s still a complex puzzle. Therefore, below a couple of typical use cases are described for additional clarification.

A simple web application for mobile devices

Imagine you have a simple enterprise web application that you want to offer on mobile devices. Mobile devices should also be able to connect to that application from other networks. Then your solution could be to:

• build the web application using ADF
• implement APIs on your on-premises Service Bus
• expose the web application on the internet

This is illustrated in the figure below:

Note that there is not much new in this situation. The only thing that Mobile adds is that the ADF web application has to ‘work on a Mobile device’.

A new web application for mobile – built with Oracle JET

You want to built a web application for the mobile market, and decided to use a modern, HTML5/JavaScript based framework: Oracle JET. The a solution can consist of:

• build the mobile web application using JET
• implement APIs on your on-premises Service Bus
• implement an API Gateway in your DMZ for safely exposing the API functionality

This is illustrated in the figure below:

3rd parties build web application for mobile devices

Your company has some APIs that it wants to make available for 3rd parties. These 3rd parties can then use these APIs in their web applications and/or mobile apps. Then your solution could be to:

• implement APIs on your on-premises Service Bus
• expose these APIs using the API Gateway installed in your DMZ

Because there are 3rd parties that access your APIs, it’s a good idea to pay some more attention to governance, and therefore API Catalog and API Manager are added in the mix.

This is illustrated in the figure below:

 

Let the LOB user build the web application

The above applications will be most likely built by IT staff. Now, if you would want a web application to be built by a LOB user, the Oracle solution would move you to a Cloud solution using the ‘Application Builder Cloud Service’. In this situation, the on-premises set-up will not change. It still needs an API Gateway that exposes on-premises services. In this set-up, the claim is that the LOB user can quickly build web applications with the Application Builder. In reality, the implementation and exposing of services on the API Gateway may then very well become the limiting factor. Think of this as the ‘house of 2 speeds’: the ‘fast LOB application developer’ versus the ‘slow API/service developer’.

Illustrated in the figure below:

Add mobile capabilities

At some point, the application requirements may include mobile capabilities. E.g. mobile notifications are required. That will clearly cross the boundary where one has to move from a web application to a mobile app. The client technology will change – in the Oracle case the app will be developed using Oracle MAF. The mobile capabilities can then be used in combination with the Oracle Mobile Cloud Service. Simultaneously, there will still be a need for accessing the enterprises on-premises APIs. For this, the Mobile Cloud Service offers connectors that can – uh well – connect to an on-premise api/service. That could mean that the on-site set-up will not change. But, given the fact that on-premise APISs are only accessed from the MCS, a more simple setup may be sufficient. For example, the connector could connect via a proxy in the network’s DMZ to the enterprise APIs. That would result in a simple set-up on-premises combined with the MCS.

Illustrated in the figure below:

Let the LOB user build the mobile app

Also here, Oracle caters for the wish to have an LOB user build a mobile app. The Mobile Application Accelerator (MAX) will be added in the near future as a feature in the Mobile Cloud Service. So, the set-up will remain the same as in the previous situation…pretty much of the rest of your setup will remain the same.

 

Conclusion

From the above, we conclude:

• Oracle has several client technologies that are suited for mobile devices
• Oracle has client technologies in the Cloud (AB and MAX) that support application/app building by a LOB user
• One of the factors that drives the choice for client technology is whether mobile capabilities like notifications are required
• The Mobile Cloud Service offers several (mobile) capabilities that can be used by apps: notifications, user management, storage, off-line data and analytics
• Using the Mobile Cloud Service to realize the infrastructure to make enterprise services available to mobile apps will be a simple and fast way to implement a secure and feature rich infrastructure. Probably quicker and more secure and feature rich when compared to an on-premises solution with the current Oracle on-premises products.

So, Oracle is moving fast in the mobile space, with new products that try to make entry into the mobile space easy. Focus seems to be on powerful, feature rich Cloud Services that all use modern and standards based technologies like NodeJS and JavaScipt. On top of that, Oracle works on creating a complete mobile eco system with partners like Samsung, AuraPlayer, Xamarin, Sencha, Syniverse, AirWatch, etc.

Gartner predictions indicate that enterprises will spend huge efforts in the next 5 years to establish and/or re-new their mobile presence. Oracle is positioning itself as an end-to-end partner in the mobile area. Curious to see where that takes us…