Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


This will generate the following objects and links:

Support for Spring-WS


Spring-WS provides a client-side web service API that allows for consistent, XML-driven access to web service. The WebServiceTemplate is the core class for client-side web service access in Spring-WS. It contains methods for sending Source objects, and receiving response messages as either Source or Result. This extension will identify client-side services using WebServiceTemplate Methods that are used to invoke the web service.


Code Block
<wsdl:definitions xmlns:wsdl=""
	xmlns:tns="" xmlns:soap=""
	<wsdl:portType name="CLCIQueryPortType123">
		<wsdl:operation name="getClciUso123">
			<wsdl:input message="tns:ClciUsoReadRequest123" />
			<wsdl:output message="tns:ClciUsoReadResponse123" />
			<wsdl:fault name="WSException" message="tns:WSException" />

Will generate:

@Endpoint and @PayloadRoot annotations

The classes where SOAP web service requests are handled are annotated by @Endpoint. The analyzer inspects these classes in search of further @PayloadRoot-annotated methods. This annotation maps the method to the root element of the request payload. It should be noted that typical setup of Spring Web Service configurations is performed from initial .xsd schema files to generate .java files and stubs as well as contract .wsdl files. These .wsdl files are generated following some customizable naming conventions (using for example jsxb2-maven-plugin). The analyzer directly searches the corresponding SOAP web service operations exposed by directly inspecting the nearby .wsdl files in the analysis unit. Thus the presence of .wsdl files (as it is usually the case) in the source code is necessary for the analyzer to correctly interpret SOAP web service operations based on the @PayloadRoot annotation.

Consider the below example code: 

Code Block
// Source:


public class OrderServicePayloadRootAnnotationEndPoint {

    @PayloadRoot(localPart = "placeOrderRequest", namespace = "")
    public JAXBElement<PlaceOrderResponse> getOrder(...) {

Together with an excerpt of the .wsdl file, note the connection between the localPart and the name of the input message

Code Block
    <wsdl:portType name="OrderService">
        <wsdl:operation name="placeOrder">
            <wsdl:input message="tns:placeOrderRequest" name="placeOrderRequest">
            <wsdl:output message="tns:placeOrderResponse" name="placeOrderResponse">

The analyzer will create a SOAP Java Operation object (with fullname OrderService.placeOrder) together with a link to the handler method getOrder.

Image Added

A warning note: the .wsdl file itself will contain a WSDL Operation object that can lead to confusion:

Image Added

This WSDL Operation, though related, does not belong to com.castsoftware.jaxws, and in contrast to SOAP Java Operation objects, it is not expected to participate in transactions, and thus only inter-techno links are expected to be found for the latter (via the web-service linker at application analysis level).

Support for WS call using QName


  • The extension is shipped with a set of CAST Transaction Configuration Center Entry Points, specifically related to JAX-WS Please see CAST Transaction Configuration Center (TCC) Entry Points for more information about this.
  • Once the analysis/snapshot generation has completed, HTTP API transaction entry points will be available for use when configuring the CAST Transaction Configuration Center. In addition, you can view the results in the normal manner (for example via CAST Enlighten).