Publishing WSDLs with a service. Part 1 - single WSDLs.

Publishing WSDLs with a service. Part 1 - single WSDLs.

It is common practise for app servers (both Java / Tomcat and .NET
based) and components offering web services to advertise their WSDLs via
an HTTP GET request. This makes for a quick and easy way to test that
something is there during setup. Also, it is convenient for developers
and sys admins during testing and deployment phases since they can
source the interface description directly from the web service they want
to interact with.

The convention is to respond with the WSDL when the query parameter
of an HTTP GET request to the service's URI is sent with the text
"wsdl". e.g.

In your browser address bar type

http://://?wsdl

which might look like this real WSDL which Intel SOA Products publishes:

http://64.109.190.66:5888/axis2/services/Calculator?wsdl

This then returns the contents of the WSDL used to setup the web service:

http://www.example.com/sample">

http://www.example.com/sample" schemaLocation="SampleProcess.xsd"/>

blah blah.....

SOA Expressway can be configured to do this for services it hosts itself and for ones which it proxies.

With this exercise we're going to setup a simple workflow and then
add a second workflow which will reply with the original workflow's
WSDL.

* In Services Designer, create a Simple Application project. You will then have a basic SOAP request/response workflow.

* Create a second workflow in this project called WSDLReturnProcess.bpel. This should be an empty workflow.

* Drag a Receive action onto WSDLReturnProcess and leave it's
endpoint binding as plain with a binary request and response type. Set
the service URL to be the same as the first workflow and the HTTP Method
to be GET.

* Drag a Reply action onto the WSDLReturnProcess and set it's "message data from" to use the document extension function:

soae-xf:document('SampleProcess.wsdl')

**Note that SampleProcess.wsdl could be any wsdl that is in the Application project that should be 'returned' by SOAE

* Now we just need to set the classification rule for
WSDLReturnProcess so that it looks for GET requests coming in with the
query parameter of "wsdl". Your classification rule should be set to
custom and look like this:

soae3:get-message-metadata()/md3:message/md3:httpMessage/md3:transport/md3:httpRequest/md3:uri/text()='/'

and soae3:get-message-metadata()/md3:message/md3:httpMessage/md3:transport/md3:httpRequest/md3:method/text()='GET'

and soae3:get-message-metadata()/md3:message/md3:httpMessage/md3:transport/md3:httpRequest/md3:query/md3:param[@name='wsdl']

* Finally we can test this in App Runner by sending a blank request
through to the WSDLReturnProcess workflow. Make sure you edit the
request's metadata tab to remove any SOAPaction and set the HTTP Method
to GET and query parameter to "wsdl", otherwise you'll get a
classification failure.

* An improvement that could be made is the replacement of the WSDL classification rule to cope with a case change:

or
soae3:get-message-metadata()/md3:message/md3:httpMessage/md3:transport/md3:httpRequest/md3:query/md3:param[@name='WSDL'
or @name='wsdl']

I've attached an example workflow to this solution.
Pull_Back_WSDL.tgz
SOA Expressway version 2.5.x

- Pete
1 post / 0 new
For more complete information about compiler optimizations, see our Optimization Notice.