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.
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.
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
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...