Siva's Blog

In this blog, we will review native REST service support added in 12.2.1. And you can refer to post to find information about same from 12.13 perspective.

Before discussing further, we will first see how 12.2.1 provides the backward compatibility with 12.1.3. In 12.1.3, REST Proxy Service converts native REST payload to SOAP before calling a Pipeline/Split-Join and REST Business Service convert SOAP to REST native payload i.e. the internal communication happen using WSDL interfaces only.

In 12.13, while creating REST binding as Proxy or Business service check the option as shown below and other steps remain same.

We can see WSDL and WADL gets created in your project.

To access REST resource use url like http://localhost:<<OSB Port>/<<proxy endpoint>>/<<resource name>>  so it will be http://localhost:7003/restDemo/REST1213WayPS/employees

To access design-time WADL use url like http://localhost:<<OSB Port>/sbresource?WADL/<>/<>  so it will be http://localhost:7003/sbresource?WADL/RESTIn1213way/WSDL/REST1213WayPS

To access effective WADL use url like http://localhost:<<OSB Port>/sbresource?(PROXY or BIZ)/<<project path>>/<<proxy or biz service name>>  so it will be http://localhost:7003/sbresource?PROXY/RESTIn1213way/ProxyServices/REST1213WayPS

Now in 12.2.1, we have native REST support and no need of creating WSDL for internal communication. This native support is broadly classified into following categories:

• Un-typed Proxy/Business Service –  For which method information is available at design time so no WADL is involved.
• Typed Proxy/Business Service – For which the method information is available at design time so WADL is used/created having this information.

REST binding can be used to create both Proxy and Business services that fall into above categories. In this post, we discuss from Proxy Service perspective and same can be followed for business services.

Creating Typed Proxy Service:

We use REST binding to create native REST service. So drag REST binding from Components to Proxy Services swim lane or right click to choose REST option.

Provide name for REST binding and do not select WSDL interfaces check box as we are creating native REST services. Click Next.

Create a new REST resource as shown below.

Create a REST method using following steps by clicking + icon in Methods.

Now verify that WADL file is generated automatically with method information as defined above. Now create pipeline using the following steps.

Connect Proxy Service, Pipeline and Business Service as shown below. Use the same business service as we used earlier.

Finish the message flow as shown below.

Deploy and test your project in Service Bus console. Observe that you can see all media types supported by REST service are shown in Accept choice list.

Now we will see how to use an existing WADL to create Typed REST services.

Again drag the REST binding from Components to Proxy Services swim lane or right click in swim lane to choose REST option.

Provide name for REST binding and do not select WSDL interfaces check box as we are creating native REST services. Click Next.

Choose REST1213WayPS.wadl. This confirms that WADLs generated by 1213 REST services are supported here. Observe that REST methods are populated automatically from selected WADL.

Click Finish and verify that new WADL is generated again for this Proxy Service.

Now finish pipeline message flow as above using WADL created in above step.

To access REST resource use url http://localhost:7003/restDemo/typedService/typedEmployees

To access design-time WADL use url http://localhost:7003/sbresource?WADL/RESTTypedServices/TypedRestService

To access effective WADL use url http://localhost:7003/sbresource?PROXY/RESTTypedServices/TypedRestService

Observations:

• WADL is always created for Typed native REST services when one is not chosen during creation.
• No where we are able to give the input/output message structure (XML or JSON schema) for REST methods. I think this may be improved in later releases.
• When a native REST Proxy Service supports multiple content types (XML, JSON), automatic payload conversion (XML to JSON and vice-versa) is not happening as we see in WSDL based REST services. I will try to cover more on this in later posts.
• Content-Type HTTP header is used by OSB for content parsing and we can see this set automatically when media type is chosen in test console.
• Value given for soa:name in WADL is populated for $operation context variable in pipeline.
• 1213 WADL is not supported for creating pipelines but can be used to create Proxy, however a new WADL will be generated by OSB as we saw above.

Creating Un-typed Proxy Service:

Create a Proxy Service using following steps. Observe the usage of Transport and no where we define REST resource or methods.

Create pipeline using following steps and observe that we are not selecting any WADL as we did earlier.

Connect all these pieces as shown below and complete Message Flow as we did earlier.

Deploy and test your project in Service Bus console. Observe that you can see all media types supported by REST service are shown in Media Type choice list as we have not specified supported types any where. Service Bus uses the Content-Type HTTP header for parsing the payload and you can see this is set automatically when we choose the media type in Test Console.

To access REST resource use url http://localhost:7003/restDemo/untypedService

Observations:

• No WADL is used during creation of Un-typed native REST services.
• Again, no where we are able to give the input/output message structure (XML or JSON schema) for REST methods.
• Again, no automatic payload conversion will happen when REST Proxy supports multiple Content Types.
• Content-Type HTTP header is used by OSB for content parsing and we can see this set automatically when media type is chosen in test console.

In above 2 sections, we created  both Proxy and Pipeline separately and we can observe that WADL is optional for REST based pipelines. So even Pipelines are classified into Typed and Un-typed  depending on usage of WADL.

So now the Q arises about compatibility between Proxy and Pipelines as both of them can be Typed /Un-Typed. Since Typed is more restrictive having REST methods we will be able to call both Un-Typed and Typed pipelines provided they used same WADL. In the same way, Un-Typed will be able to call both Un-typed and Typed Pipelines.

The source code used in this post can be downloaded from here and please note that you need to create DB connection pool to run this project with JNDI eis/DB/LocalDB.

Reference:

https://docs.oracle.com/middleware/1221/osb/develop/GUID-C346DF7D-041D-4E10-BE1C-451F50719106.htm#OSBDV89235