The REST Adapter is an important new feature of Oracle SOA Suite 12c. This new adapter allows easy calling/exposing of RESTful services (see https://technology.amis.nl/2014/05/14/what-is-rest/ for an introduction to REST) based on a WADL or configured manually. Not only does Oracle introduce the REST Adapter, but JSON support is also added in SOA Suite 12c. These features will greatly increase the integration options and flexibility of Oracle SOA Suite. In this blog I’ll describe how a RESTful service can be called by using the REST adapter. Exposing a RESTful service will be described in a later blog.
Calling RESTful services in Oracle SOA Suite
SOA Suite 11g
In recent history (SOA Suite 11g) there were no out of the box options to integrate with or expose RESTful services. Also there were no out of the box options to handle JSON payloads. Since Oracle SOA Suite has many options for integration with Java code, there are several workarounds such as using the SocketAdapter (http://javaoraclesoa.blogspot.nl/2012/12/receiving-json-requests-in-oracle-bpel.html) or using the Spring component (https://technology.amis.nl/2009/12/16/soa-suite-11g-using-spring-component-to-mimic-http-binding-and-integrate-restful-services/). These workarounds however all have major drawbacks and it is difficult to set them up in such a way that they are flexible and the code is maintainable.
SOA Suite 12c
SOA Suite 12c introduces the REST adapter to make life a lot easier.
The REST Adapter can be configured in 2 ways. Manually or by means of a WADL (Web Application Definition Language). The manual definition will not be described in detail since the result should be the same as is done by means of a WADL. This also nicely illustrates that using a WADL is preferable.
Using a WADL
A WADL for REST services can be compared to a WSDL for SOAP services. As with SOAP services, using a predefined definition file makes the configuration easier. This is especially true when calling REST services. Some frameworks provide out of the box WADL’s such as JAX-RS (see for a simple implementation example; https://technology.amis.nl/2014/05/14/what-is-rest/). If a WADL is available, use it. It is more likely more complete then what you can create yourself. When there is no WADL available, a third party tool can be used to generate a WADL. Smartbear SOAP UI for example. In SOAP UI you can configure a RESTful service and SOAP UI will generate the corresponding WADL for you for free. ‘naam’ in the below screenshots is dutch for ‘name’.
Now back to the SOA Suite.
The WADL chooser supports URL’s to download a WADL from. Also deployed SOA composites or OSB proxies can be selected which provide a RESTful interface. A deployed JAX-RS service however cannot be selected.
For the operation bindings, Template and Query style REST parameters are supported (see http://www.soapui.org/REST-Testing/understanding-rest-parameters.html for an overview of REST parameter types). When you edit an operation binding, you can specify the response message. The request is defined by the resource definition. The response can be JSON or XML. You can also specify the expected response HTTP code.
When you have configured the REST Adapter, it is easy to do the assignments as usual in BPEL (or Mediator or BPM, whatever you like). Now you can call a REST service returning a JSON message and convert the reply to XML to do the things you usually do with the SOA Suite.
Also the Enterprise Manager supports parsing WADL files to easily test services.
JSON support with the Native Format Builder
In the above sample I’ve used a service which obtained it’s parameters from a GET request and returned a JSON payload. The JSON payload is converted to XML and can be processed as usual. JSON support is new in SOA Suite 12c. Also several other native formats are supported such as MFL. Message Format Language (MFL) was previously used by the OSB 11g as an alternative to the NXSD used in the rest of the SOA Suite (mainly the file adapter).
My first try at importing a WADL failed because I had neglected to use certain annotations in my JAX-RS RESTful service (see https://technology.amis.nl/2014/05/14/what-is-rest/ for correct sample code). The response could not be determined in this case (and the wizard would not let me set it manually). I manually created an NXSD file and referred to it in the WSDL generated for the REST binding. This implementation method of JSON support with NXSD and the usage of NXSD by the REST adapter leaves the door open to more options for interaction with the SOA Suite. More on this in a later blog post.
7 thoughts on “SOA Suite 12c: Introducing the REST Adapter. Calling a RESTful service returning JSON”
i am trying to create one bpel that will accept user input in weblogic by creating synchronous bpel and post data to the rest service. i did exactly what u did but changed the method into post. i am getting error called base uri not absolute. please help me as i am new to soa.
Could you please let me know the configuration plan settings for rest reference, is endpointURI is not supported for binding.rest reference, or it will support? or is it the location attribute the rest base url/uri is referred from? In order to deploy to other environments. Thanks.
The information posted about Rest Adapter was quite useful. But I am trying to achieve how to configure Rest without choosing Response schema but it’s a query method. I guess it’s needed to give the response schema.
Is there any possibility to create any type schema and configure it as response and it would work for all cases.
Hope this helps you,
With kind regards,
Thanks for this. I am new to REST and this is very helpful. Just to be clear. In your post, when you refer to SOA Suite 12c, are you referring to jDeveloper?
Very informative post, I have following questions can you please clarify?
Assume that I have payload as JSON
1) If I create a proxy-rest and business-Rest reference service and connect them directly without any pipeline will it still convert JSON to xml while doing wire transfer to busienss service?
2) If I use in above case pipeline then its always does JSON to XML on wire transformation internally?
is it an performance overhead to the OSB ?
3) if above not ture then, does pipeline understand JSON as native format and can work without converting it to XML?
The questions you are asking are related to the implementation of the REST binding in the Service Bus. In this blog post I’ve looked at the implementation in SOA Suite composites. Since the two might differ, I think it better not to make assumptions without further looking into it. I might do that in a followup post.
With kind regards,
Comments are closed.