SOA Suite 12c: Exploring Dependencies – Visualizing dependencies between SOA artifacts

SOA composites as well as Service Bus projects typically consist of fair number of artifacts that hang together in ways that are sometimes not so easy to track down. Through import statements, hard coded references and other direct or indirect definitions, dependencies are registered between the many files that make up the application. From BPEL component to WSDL to XSD to other XSD is a not too uncommon path. However, for developers it can be quite a challenge to get a good grasp on these dependency paths. Inspired by – and perhaps more than just inspired – the App XRay feature in OEPE (Eclipse), JDeveloper 12c ships with the Dependency Explorer. This is a tool that can be set upon almost any artifact in SOA composites or Service Bus projects. It will leverage all its built in knowledge about potential dependencies and it will visualize these dependencies.

For example, let’s look at this simple Service Bus project. Right click on the pipeline definition in the navigator window and select the option Explore Dependencies:


The dependencies for this simple case are shown like this:


In the Dependency Explorer itself, we can right click all components listed and drill further down, list the reference details, select the component in the navigator or bring up the editor for the component.

Here is the drilled down overview of dependencies, starting from the WSDL document ProxyService.wsdl and backtracking what are the references to the WSDL document.


In a previous article, we introduced the SOA Suite 12c support for XQuery library modules.

We can open the dependency explorer for an XQuery library


and learn where it is used:


This overview tells us that we will indirectly impact the ProxyService if we do something wrong with the TimeAndDateLibrary.xqy.

An even more impressive overview is produced by exploring the dependencies for a BPEL component, as is shown here:


This results – in this particular example – in:


One final example shows how a Database Adapter was analyzed – both the usage from the SB Business Service and the reference to the WSDL and indirectly the XSD:


Implement an Asynchronous Web Service using JAX-WS in JDeveloper

This article discusses how to implement an asynchronous web service in Java EE. The Java application will expose a one way operation that will process the request and send a response message to a callback Web Service interface that is indicated in the request header through WS Addressing properties (messageID, replyToAddress). The Asynchronous Web Service is subsequently deployed and invoked from SoapUI.

The article starts with nothing but a simple WSDL file that defines the two portTypes: one way call and the [one way] call back:


The main steps are:

  1. Generate the JAX-WS Client & Proxy for the ThoughtfulGreeterCallback portType (to invoke the callback service in order to send the response)
  2. Generate the JAX-WS Web Service for the ThoughtfulGreeter portType (to implement the one way web service)
  3. Edit the generated code for the ThoughtfulGreeter portType in order to create the response and invoke the callback interface – used on WS-Addressing details in the request

When the implementation is thus complete, we create a new project in SoapUI. In this project, we will create a test request to invoke the ThoughtfulGreeter service. We will also create a MockService in SoapUI to act as the callback interface ThoughfulGreeterCallback. In the request from SoapUI to the ThoughtfulGreeter service, we will specify WS-Addressing properties that refer to the MockService.

Finally, when we have SoapUI make the call to the ThoughtfulGreeter service, we will receive a call (back) to the MockService, containing the response.

Lees verder