SOA Suite 12c: Obtaining composite resources such as WSDLs, XSDs and WADLs

In SOA Suite 12c and 11g there are several options to obtain composite resources such as WSDL's and WADL's. In this blog post I will demonstrate some of them and provide some background information. First I'll describe how URL's can be used to access composite resources. Next I'll describe how and when the EM test console and the Webservice test client can be used to gain information about composite WSDL's and XSD's.

Understanding URL's

In order to request WSDL's and WADL's (which contain information on how a service can be called), understanding how URL's are build up in Oracle SOA Suite helps.

REST services

A nice new feature in Oracle SOA Suite 12c is the support for WADL's. In order to obtain information about which (composite) resources are available at which URL, the SOA Infra application provides a WADL. On the integrated Weblogic server domain, this WADL can be accessed at: http://localhost:7101/soa-infra/resources/application.wadl

This WADL provides information on the different ways resources can be requested. For example, I have deployed an HelloWorldREST composite with a HelloWorldRestService service.

I am able to determine the service endpoint:

http://localhost:7101/soa-infra/resources/default/HelloWorldREST/HelloWorldRestService

And since it is a RESTful service, I can request the WADL which provides information on possible service endpoints and how to call them at

http://localhost:7101/soa-infra/resources/default/HelloWorldREST/HelloWorldRestService/application.wadl

What is considered a service however, is a RESTful service, so this will not help you with SOAP webservices like the one below.

The following URL is not accessible:

SOAP services

SOAP services follow a similar scheme to allow accessing services. The URL slightly differs though.

http://[host]:[port]/soa-infra/services/[domainname]/[composite name]/[servicename]

This allows accessing the default revision of an endpoint of a service. If you want to call a specific revision, the below URL allows specifying the revision.

http://[host]:[port]/soa-infra/services/[domainname]/[composite name]![revision]/[servicename]

It is also possible to target a specific deployment of a composite. This can be dangerous because this changes upon redeployment.

http://[host]:[port]/soa-infra/services/[domainname]/[composite name]![revision]*[label]/[servicename]

The last URL has an identifier called 'label'. Labels are used in the MDS (http://docs.oracle.com/cd/E25178_01/core.1111/e10105/repos.htm#CIHCAJHA). Composites are deployed to the MDS and get an automatically generated label upon deployment. This changes after every deployment of a composite with the same name/partition/revision. I have not tried manipulating labels of deployed composites and the effects that might have.

WSDL's

WSDL's can be obtained by using the servicename and append ?WSDL to it. For example to access my HelloWorld service WSDL, the following URL can be used:

http://localhost:7101/soa-infra/services/default/HelloWorld/helloworldbpel_client_ep?WSDL

If you open the endpoint(/service URL) in a browser, you get forwarded to the Webservice Test Client (on development servers):

http://localhost:7101/soa-infra/services/default/HelloWorld/helloworldbpel_client_ep

Test console and test client

Not only by means of constructing the URL manually, can resource URL's be determined. There are also several supporting tools available such as the test console in the Enterprise Manager and the Webservice Test Client. The Webservice Test Client is only installed on development servers. The Enterprise Manager Test console can be used if you have access to the Enterprise Manager. The Monitor role is enough to be able to use the EM test console.

Obtain the concrete default WSDL from the test console

The WSDL can be obtained from the test console in the Enterprise Manager. This is a concrete WSDL generated upon deployment of a SOA Suite composite. It contains references to the default revision of the composite and also a reference in the documentation tag to the abstract WSDL;

If the WSDL URL in the EM test console contains an MDS label and you don't expect it, something is probably wrong and you should try an undeploy and redeploy under different revision and/or a server restart.

Obtain the abstract default WSDL from the composite

As suggested in the previous screenshot of the WSDL, the abstract WSDL can be obtained directly from the composite:

This trick can also be used to obtain XSD's from inside a composite, by for example going to an URL like (on my development environment); http://localhost:7101/soa-infra/services/default/HelloWorld!1.0/Schemas/HelloWorldBPEL.xsd

If the abstract WSDL is placed in the MDS, the reference to the WSDL's and XSD's also refer to an MDS path. This allows by means of relative URL's to access the entire MDS (this was possible in SOA Suite 11g. I have not checked this in SOA Suite 12c yet). In such a case, composite resources cannot be accessed.

Webservice test client

I am mentioning the testclient because you get forwarded to it when opening a service endpoint and it allows you to obtain information about the WSDL and XSD of a service. Also you do not need specific privileges to access the webservice test client.

The Webservice Test client can be used to test SOAP services. It cannot be used for services solely described by a WADL. The Webservice Test client provides a webinterface for calling a SOAP service. In my example I can open the URL obtained from my concrete WSDL of my service in the browser: http://localhost:7101/soa-infra/services/default/HelloWorld/helloworldbpel_client_ep

The URL is translated into the folowing: http://localhost:7101/ws_utc/?wsdlUrl=http://localhost:7101/soa-infra/services/default/HelloWorld!1.0*soa_2c171323-5b85-4d1f-876e-eecda27e5bc6/helloworldbpel_client_ep?WSDL. This is a call to the ws_utc; the Webservices Test Client.

Webservice test client not available?

At first I tried to use the Webservice test client on my production mode server. The client however is only installed when the server is in development mode. Then I read the following: https://community.oracle.com/thread/978505?tstart=0. The post does describe a manual way to install the client on an 11g SOA Suite production mode installation. I could however not find the wlstestclient.ear in SOA Suite 12c. The following looked like it might be the test client in 12.1.3: [ORACLE_HOME]/oracle_common/modules/com.oracle.webservices.wls.ws-testclient-app-wls_12.1.3.ear. After deployment, this ear allowed ws_utc to be called. However, it gave me a HTTP 503 response. I also found the following which might have helped: http://www.thesoaman.com/2011/12/change-weblogic-server-mode-from.html. At this time I decided to try this with the integrated development Weblogic server in JDeveloper instead of patching my production server.