Creating proxy service with a WSDL based interface

In the previous recipe, we have created an OSB service with a pass-through proxy service, which offered the same SOAP-based interface as the external service.

In this recipe, we will create a proxy service Customer Management which uses its own WSDL (CustomerManagement) to define a SOAP-based web service interface to its consumers:

Creating proxy service with a WSDL based interface

Getting ready

Make sure that you have the basic-osb-service project from the previous recipes available in Eclipse OEPE. We will start the recipe from there. If needed, it can be imported from here: chapter-1getting-readypass-through-proxy-service-created. Delete the pass-through proxy service by right-clicking on CustomerService.proxy, selecting Delete, and then confirm the deletion by clicking on the OK button.

How to do it...

In order to create the proxy service, we need to define the service interface (WSDL) for that new service. We won't create the WSDL in this recipe. The WSDL file and the corresponding XML schema files are available in the chapter-1getting-readydefinitionxsd folder.

We start this recipe by first copying the WSDL and the corresponding XML schema files into the OSB project, and then create the new proxy service.

In Eclipse OEPE, perform the following steps:

  1. Copy the Customer.xsd and CreditCard.xsd files from the chapter-1getting-readydefinitionxsd folder into the xsd folder of the project.
  2. Copy the CustomerManagement.wsdl from the chapter-1getting-starteddefinitionwsdl folder into the wsdl folder in the OSB project.
  3. Make sure that the project looks like the following screenshot (you might need to hit F5 to refresh the project in Eclipse OEPE):
    How to do it...

    With the WSDL file in place, we can create the proxy service. Still in Eclipse OEPE, perform the following steps:

  4. Right-click on the proxy folder and select New | Proxy Service.
  5. Enter CustomerManagement for the name of the proxy service into the File name field and click on the Finish button.
  6. The new proxy service artifact is created and the proxy service window is shown, with the General tab with the focus on.
  7. We want to create a proxy service with a WSDL interface, so let's select the option WSDL web service and click on the Browse button.
  8. In the pop-up window, expand the project tree and navigate to the CustomerManagement.wsdl file in the wsdl folder.
  9. Click on the node to expand it and select the CustomerManagementSOAP port.
  10. Click on the OK button:
    How to do it...
  11. Click on Yes, on the confirmation dialog to overwrite the transport settings with the values from the WSDL.
  12. Navigate to the Transport tab and check the Endpoint URI field. This value will be needed when invoking the service or when consuming the WSDL of the proxy service when deployed on the OSB server.
  13. Click on the Message Flow tab to view the actual message flow:
    How to do it...

How it works...

So far the message flow only consists of the interface, which is based on the WSDL. The flow logic itself is empty. If no further actions are added to the message flow, the proxy service works in an 'echo mode'. All the request messages sent to the proxy service are returned unchanged.

Try it by deploying the project to the OSB server and test it through the console or soapUI. To use soapUI for that, create a new soapUI project and import the WSDL. It should be available from here: http://[OSBServer]:[Port]/basic-osb-service/proxy/CustomerManagement?wsdl.

The following screenshot shows the behavior of the 'echo proxy service', when invoked from soapUI:

How it works...

This is not the behavior that we want from our proxy service. In the next recipe, we will add a Routing action to the message flow, so that the business service the external service is called.

Use the echo behaviour to implement a simple mock service

The echo behaviour seems to be strange at the beginning and it's hard to find a use case in the way just shown. But it's good to see and know that the message flow just returns if there are no (more) actions to execute. Whatever the $body variable holds at that time is returned as the response message.

This behaviour can be used to implement a very simple mock service.

A mock service is a service which simulates the behaviour of the real service or part of it. If we have the WSDL but not yet an implementation, we can create a proxy service and due to the echo behaviour, all we need is an assignment to the $body variable (to set up the response), just before the request message is passed back. This can be achieved by a Replace or Assign Action inside a Pipeline Pair Node/Stage pair.

We can also use soapUI to implement mock services. SoapUI provides a lot of functionality to implement very flexible mock services.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset