Wednesday Oct 22, 2014

APEX and MAF: seeing is believing

In my previous post, I explained how you could integrate remote APEX web pages in MAF applications and what are your choices if you want to expose web services from PL/SQL logic. I had built a small sample application to support my research for this post. Here is a short recording where you see that sample application in action. 

In this video, I intentionally used different styles for the MAF and APEX UIs. That way, viewers can figure out the respective contributions of each platform more easily. As I wrote in my previous post, consistent styling would have brought a transparent transition between local and remote content.

Friday Oct 10, 2014

Want to bring your APEX Application to iOS and Android? You should consider the Oracle Mobile Application Framework!

For more than 10 years, PL/SQL developers have used Oracle Application Express (APEX) to deliver high quality applications quickly and efficiently. In the last few releases, the product has gained features that make it a good fit for mobile web applications. It now offers mobile and responsive themes, as well as HTML 5 charts and item types, for example. The upcoming APEX 5 will bring a more modern look and feel, as well as reporting features optimized for mobile. Through third party technologies such as Apache Cordova (formerly PhoneGap), it is even possible to wrap a mobile APEX application and distribute it on the Apple App Store and the Google Play Store. Such applications can even send SMS, access the contact book or take pictures; in other words, they can use the native features of mobile devices. 

The main downside of mobile APEX applications is that they cannot be used in offline mode. In other words: those applications are server-based and do not actually run on the phone or tablet. Wrapping the application using Cordova does not change this. No network? No application. Obviously, you could build an entire cross-platform application using Cordova or other comparable toolkits. But this means you will have to work directly with HTML 5, CCS 3 and JavaScript. Those are well-known, flexible and powerful technologies. However, they don't offer the simplicity and productivity you have with APEX. Do not forget that mobile devices are very diverse, especially due to the extreme fragmentation of the Android ecosystem. If you go down the HTML / CSS / JavaScript route, you will have to validate your application in a wide array of scenarios yourself. This is a time-consuming and error-prone process.

We at Oracle think there is a better way. Oracle's Mobile Application Framework (MAF) enables you to build on-device iOS and Android applications without extensive HTML, CSS or JavaScript knowledge. This is possible since MAF developers work with components to design the user interface. Those components are rendered in HTML, CSS and JavaScript at runtime and are validated against a comprehensive set of mobile devices and operating systems. In addition, with MAF, you can target the two dominant mobile operating systems from a single Java code base. Moreover, MAF applications can store local data in an encrypted on-device database, and integrate out of the box with Oracle’s identity management solutions. MAF brings mobile developers the same ease of use and productivity that web developers have with APEX . 

Applications built with MAF rely on web services to fetch data and initiate transactions. Thus, you can still use PL/SQL and APEX on the server side. It is also possible to integrate remote APEX web pages directly in the frame of a MAF application, thus providing a seamless user experience. Let's now have a look at how this is achieved, before exploring the various ways there are to create web services from PL/SQL logic. 

MAF and remote APEX mobile web pages 

If you want to leverage your existing APEX Mobile web pages in a MAF application, you have two options:  to integrate a whole application as a remote URL or to use a local HTML 5 page and display select remote pages inside an iFrame. Which option to choose depends on what you are trying to achieve. Remote URLs are very simple to use, but cannot accept dynamic parameters for the time being. They can be featured on the application’s springboard and navigation bar, however. Using an iFrame in a local HTML 5 page is more flexible, since it is possible to add parameters to the remote URL among other things. This approach works well if you need to integrate a few selected remote pages in features otherwise local to the device. Please note it is possible to leverage Oracle Access Manager to achieve single sign-on between the mobile application and the web application in both cases.

If you choose to integrate remote APEX pages in your MAF application, you must ensure the APEX application uses a mobile template and design its user interface in a way that will make it usable on the target devices. Furthermore, it is possible to give remote APEX mobile applications access to the MAF APIs. That way, remote pages can access the device's native features, such as the camera or GPS. The process is currently a bit cumbersome, since it involves to deploy the MAF JavaScript files on the remote server. We aim to make this much easier in a forthcoming release of MAF. 

The screenshot below shows an APEX page, which uses APEX's standard mobile template, referenced as a remote URL feature in a MAF application. 

You can see the MAF navigation bar displayed at the bottom of the screen. On the other hand, MAF applications now use the new Oracle Alta UI skin by default. This means their appearance is very different from the standard APEX look and feel. Here is a capture of an AMX page from another feature in the same application. 

The logical conclusion is that the transition between local and remote content will be transparent to the end user if you use consistent styling. This will be easier to achieve once APEX 5 will be available.

Exposing PL/SQL logic as web services

MAF applications usually fetch data and initiate business transactions through web service calls, although they can interact with the local SQLite database when in offline mode. Your current APEX applications probably contain queries and PL/SQL logic you could reuse in that context. MAF supports the two dominant web service styles: SOAP and RESTFul. Each style has its own pros and cons. SOAP, being the oldest of the two, provides broad standardization and interoperability. It also supports several protocols, such as HTTP, SMTP and JMS. In addition, SOAP offers many enterprise-grade features, such as reliable messaging.  On the other hand, SOAP based implementation are usually slower and consume more resources since the messages exchanged are in XML. RESTFul style services do not suffer from that problem, since they rather rely on lightweight data encodings such as JSON (JavaScript Object Notation). This probably explains the growing popularity of the RESTFul style, even if it only supports the HTTP protocol.  

RESTFul services will be at the core of the upcoming Oracle Mobile Cloud service, by the way. 

There are at least four different ways to expose SQL queries and PL/SQL logic as web services. Those are:

  • RESTFul enabled report regions in APEX
  • APEX REST Service Modules
  • XMLDB native web services
  • TopLink DB Web Service Provider

APEX itself offers two different ways to expose REST web services; both require the use of the Oracle REST Data Services component, formerly known as the Oracle APEX Listener. REST Data Services is a Java Enterprise Edition (JEE) application deployed on WebLogic, GlassFish, or any JEE-compliant server. The two other web servers supported by APEX, namely the Embedded PL/SQL Gateway and the Oracle HTTP server (with mod_plsql), do not support REST web services. 

RESTFul enabled report regions are simple to deploy and reuse existing assets directly. However, they are read-only and developers do not have control over the URL used. Furthermore, parameters are limited to scalar values since they are passed as a CSV string. 

As you can see, RESTFul enabled report regions have many downsides. Fortunately, APEX’s REST Service Modules bring much more to the table, albeit at the cost of added complexity. A service module is essentially a set of URI resource templates. Each module defines a top level URI (like /store for example) and each template is a path branching out from the module’s URI (ex: /store/order). Templates contain at least one handler – but at most one for each HTTP method. A handler is simply the SQL query or anonymous PL/SQL block to execute; it can define parameters and specify the expected input type as well as the response format (JSON or CSV). APEX service modules are very flexible. They support all HTTP methods, give developers full control over the URL, can work with complex parameters and offer a comprehensive array of security features, such as single sign-on and security token support. Curiously, they miss the XML output option found in RESTFul enabled report regions. Also, you will have to look elsewhere if you need to expose SOAP service interfaces. APEX service modules are REST only for the time being.

The user interface provided by APEX to manage service modules, shown in the following screenshot, is both powerful and easy to use. It enables developers to test their services right in their browser and is fully integrated with the rest of the APEX user interface.

If you wish to build SOAP style web services directly on the top of the Oracle Database, you will have to leverage the XML DB Native Web Services feature. To achieve this, the Oracle XML DB HTTP server must be up and running. Your server already fulfills this requirement if you installed APEX on it. Then, you must as the SYS user and configure a specific servlet, whose name is usually « orawsv ».  XML DB Native web services can execute arbitrary SQL queries received as XML and give access to PL/SQL stored procedures as well. In both cases, the database will generate the required WSDL files. As you can see, XML DB native web services are a simple and effective way to expose existing PL/SQL code, although they cannot provide RESTFul service interfaces. Do not forget, however, that a proper service layer must encapsulate the complexity of the underlying application. Consequently, you shouldn’t let service consumers access the packages containing the logic of your APEX application. My recommendation is to create a package to act as the web service interface; the body of this package will simply wrap the procedures and functions meant to be available through the web service. This will obviously require some work. In addition, you need to be careful about the rights granted to the database account assigned to the web services. The fact that XML DB can run arbitrary queries sent as XML messages is a security risk that must be mitigated.

An alternate way to build SOAP web services is to use the Oracle TopLink DB Web Service Provider. Both Oracle JDeveloper and Oracle Enterprise Pack for Eclipse (OEPE) provide tooling for it. The provider can expose web services based on PL/SQL code and SQL queries; it can also generate a CRUD API for any database table. The resulting Java application, which contains little to no code, can be deployed on any JEE compliant application server. This obviously lessens the load on the database server, which can lead to improved performance and scalability. On the other hand, this solution necessitates additional infrastructure; however, you need an application server anyway to host Oracle REST Data Services. The TopLink DB Web Service Provider also works with non-Oracle databases, making it an attractive solution if you want to standardize on a single tool in heterogeneous environments. Moreover, TopLink makes it easy to build RESTFul web services, although doing so will require more code than simply using the provider. This is somewhat mitigated by the fact that TopLink can generate the artifacts it needs from an existing database schema. 


APEX cannot produce on-device applications with offline capabilities. This doesn't mean you should leave it behind, quite the contrary. Oracle MAF applications can easily integrate web pages built with APEX. In addition, there are several ways to expose PL/SQL logic as SOAP or REST web services. Thus, adopting MAF on the client side simply consolidates your investments in APEX and PL/SQL on the server side. In the mobile space, APEX and MAF do not compete with each other and are, truly, better together. And the future is even brighter! If IDE-based development is not your cup of tea, you should be soon be able to develop MAF applications in the Cloud, using only a browser...  

Monday Feb 25, 2013

ADF Mobile on BlackBerry 10: a failed but instructive experiment

With the release of their new handsets and operating system, Blackberry occupied lots of media space recently. This prompted me to have a deeper look at their platform and to experiment a bit in relation to ADF Mobile. You shouldn't read anything in this, by the way; my personal curiosity doesn't foreshadow Oracle's strategy. 

The BlackBerry 10 OS, as you may know, is able to run most Android applications through a runtime which supports about 70% of Android's APIs. Just for the sake of it, I tried to repackage a very simple ADF Mobile application and deploy it on the BlackBerry 10 simulator. Deployment was successful, and I was even able to get past the splash screen. It is only then that the application failed with an error message stating « Network_ERR: XMLHttpRequest Exception 101 ». This application is self-contained and didn't call any web services, by the way. The root cause of the error was obviously something else.

To be truthful, I expected the experiment to fail. The Android toolkit provided by BlackBerry contains an executable that scans APKs (packaged Android applications) for compatibility. When I ran it on my ADF Mobile APK, it flagged various minor problems (since we are using various hardware features) as well as a major issue: the presence of native code. You can see the full output below:

Apk2Bar /Verifier version 1.5.1
Research In Motion Ltd ? 2012 All rights reserved.
[osname.apk]:(res/drawable-xhdpi/adfmf_icon.png) found an alternate icon with better size:impact=1
[osname.apk]:(AndroidManifest.xml) uses-feature: minimal Tablet OS version=2.1:impact=2
[osname.apk]:(AndroidManifest.xml) uses-feature: android.hardware.telephony:required minimal Tablet OS version=10.0.6:impact=2
[osname.apk]:(AndroidManifest.xml) uses-feature: minimal Tablet OS version=10.0.9:impact=2
[osname.apk]:(AndroidManifest.xml) native-code: armeabi:impact=5
[osname.apk]:(com/phonegap/ uses method:$setRouting:impact=1
[osname.apk]:(com/phonegap/ uses method:$setRouting:impact=1
[osname.apk]:(com/phonegap/ uses method:$setAudioStreamType:impact=1
[osname.apk]:Summary: [5]=1; [4]=0; [3]=0; [2]=3; [1]=4;
Summary: [5]=1; [4]=0; [3]=0; [2]=3; [1]=4;
Impact Legend: [5]=Severe; [4]=High /context; [3]=Medium /context; [2]=Medium-low /context; [1]=Minor;

The offending native code is part of the JVM that we package with the application itself. Therefore, there is nothing we can do to circumvent the issue right now. Further releases of ADF Mobile could replace the current JVM, thus creating more favorable conditions for this to work.

I must say I was impressed by the developer tools provided by BlackBerry (formerly Research in Motion), especially the device simulator. Its boot time is an order of magnitude shorter than the Android Emulator's, and it was a joy to use.

Does your organization plans to get BlackBerry 10 devices? Is this new platform a more interesting target than Windows Phone? Let us know!   



Frédéric Desbiens

The musings of a member of the Mobility and Development Tools Product Management team.

I focus here on my favorite development frameworks, namely Oracle ADF and the Oracle Mobile Application Framework (MAF), but also have a strong interest in SOA and web services.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.


« November 2015