Simplifying Mobile Integration by using JAX-RS RI to build RESTful web services

SOA in large enterprises have evolved and are now using RESTful web services as it is faster, lightweight, easy to implement. REST stands for Representational State Transfer and involves request to be sent from client to server in the form of URI. REST is a simple stateless architecture generally running over HTTP supporting request/reply pattern. Among big REST drivers today are mobile applications, social networking Web sites, mashup tools and automated business processes.

With the increasing amount of smartphone users all over the world, we needed to have a mobile

app strategy to build RESTful services that can bring our product to this growing market.REST

has distinct advantages for loosely coupled services  on massive scale. REST integration patterns are often highly effective for enterprise architects that are working on integrating applications within a SOA framework. However, the need to implement REST based architecture depends completely on business requirements of the company.

REST is preferred and cost-effective architectural style for implementing services due to its scalability, its ability to allow dynamic connectivity without prior planning, ability to enable independent evolution of clients and services and its built-in support for caching and security.

REST can help having centralized data storage for the data coming from both the web and the mobile. This can avoid repetition by just creating a storage layer once, as an API, and reusing it with multiple application versions. We can even easily have REST service distributed between several load-balanced servers, and even save precious CPU cycles by reusing already generated data in some requests.

REST services have uniform interface which only allow HTTP operations: GET, POST, PUT, DELETE. We needed to build Restful services which takes JSON input/output. JSON is recommended for data transfer in a REST API as it is scalable and hence cost-effective and sending or receiving JSON data in each request is preferred as it is light-weight,simple,clean data with minimal tags, human-readable, faster than XML.It is programming language independent and also doesn’t have the concept of namespaces as in XML.

Comparison between the options we had for building Restful services (PROS/CONS)

We had some options to decide an optimal way to build RESTful services for the mobile application utilizing Oracle SOA(11.1.1.6). The following table lists the different options we considered and what made us choose JAX-RS(Jersey) RI.

Custom Wrapper(Spring/hibernate)	Jersey(JAX-RS RI)	HTTP Adapter	Socket Adapter
Single Router	Single router to appropriate Resource class/method	Simple to implement/code	Simple to implement code
Could build all services that were needed	Could build all services that were needed	Easy to build RESTful services with GET or POST method	Custom Java Code needed to be plugged in in socket adapter for a request/reply handshake  and request/response are parsed using XSLT functions
Deploys easily(Single WAR in spring)	Deploys easily(Single WAR)	Deploys easily	Deployment challenges
JSON IN/OUT	JSON IN/OUT	Payload is XML or URL-Encoded type only-NO JSON support	JSON IN/OUT
GSON deserializability	GSON deserializability
Easy for Mobile to consume JSON	Easy for Mobile to consume JSON		Complex configurations even for simple functionality
All custom java/Spring code	PL/SQL,JAVA,SOA code	SOA,JAVA to code	JAVA,SOA to code
Lot of code and customizations needed	Less code because of JAX-WS to JAX-RS translation	Query String inputs	1 socket for each service unless custom router was used
OSS Dependency	OSS Dependency
Time/Learning curve			Reusability challenge

Future support for Mobile applications (REST Based services)

Oracle SOA Suite 11.1.1.7 simplifies integration experience by leveraging mobile integration where Oracle SOA connects mobile applications using JSON and REST via Oracle Service bus and in Oracle SOA 12c simplifies integration by utilizing REST binding exposing traditional SOAP services, Enterprise Java Beans (EJBs), JCA adapters connecting backend applications or any other underlying implementation through JSON/REST.

Methodology

The above figure presents the diagrammatic technical design of approach taken for building RESTful services. This incorporated the use of Façade object oriented pattern wherein Façade Jersey class abstracts other packages used in creation of the web services and wherein one RESTful webservice call  by Mobile application(client) utilizes Façade pattern  to access data from database  which are the result from N number of calls behind service for that one  web service call.

We utilized Oracle SOA to either select or insert data into the database using BPEL/mediator . While some of the PL/SQL procedures contained the hardcoded JSON formatted queries to access the database and other JSON formatting was done in Jersey class using JSONObject and other JSON classes. The SOAP web service was consumed by JAVA proxy for web service. We selected JAX-WS style for proxy wherein client uses JAXB mapping style for serialization to generate asynchronous methods with JAX-WS bindings.

JAX-RS web services/clients were written by configuring Jersey for project and adding all .JAR files to the classpath of project/application.

Configuring    Jersey    JAX-RS RI

1) Register JAX-RS libraries with one or more weblogic server instances or pass .jar files in classpath of   Jersey Project/application

Shared Java EE libraries are registered with one or more WebLogic Server(11g) instances by deploying them to the target servers and indicating that the deployments are to be shared. Shared Java EE libraries must be targeted to the same WebLogic Server instances we want to deploy applications that reference the libraries. When a referencing application is deployed, WebLogic Server merges the shared library files with the application.

We can also just include jersey-core.jar, jersey-server.jar,jsr311-api.jar,asm.jar and jersey-client.jar in the web project/application classpath(if not registering with weblogic server)

2)Configure Web application/project that contains RESTFul webservice to use Jersey JAX-RS RI shared libraries.

We need to configure the Web application that contains the RESTful Web services to use the Jersey shared libraries. We need to update the following two deployment descriptor files that are associated with our application:

web.xml—Update to delegate Web requests to the Jersey servlet.

weblogic.xml—Update to reference the shared libraries that are required by application/project only when registering shared libraries with weblogic server

Updating web.xml to Delegate Web Requests to the Jersey Servlet

The following provides an example of how to update the web.xml file:

    <web-app>

        <servlet>

        <display-name>My Jersey Application</display-name>

        <servlet-name>MyJerseyApp</servlet-name>

        <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>

        <init-param>

            <param-name>javax.ws.rs.Application</param-name>

            <param-value>myPackage.myJerseyApplication</param-value>

        </init-param>

    </servlet>

    <servlet-mapping>

        <servlet-name>MyJerseyApp</servlet-name>

        <url-pattern>/*</url-pattern>

    </servlet-mapping>

</web-app>

Updating weblogic.xml to Reference the Shared Libraries

Update the weblogic.xml file to reference the shared libraries that are required by  application/project. The weblogic.xml file is located in the WEB-INF directory in the root directory of your application archive.

Weblogic.xml is updated only if have deployed JAR files to weblogic server.

Once Jersey class is coded, then deploy it to WAR file and deploy it to application server and run the URL on REST console or browser to test.