Chapter 164. Spring Web Services
Spring Web Services Component
The spring-ws: component allows you to integrate with Spring Web Services. It offers both clientside support, for accessing web services, and serverside support for creating your own contract-first web services.
Dependencies
As of Camel 2.8 this component ships with Spring-WS 2.0.x which (like the rest of Camel) requires Spring 3.0.x.
Earlier Camel versions shipped Spring-WS 1.5.9 which is compatible with Spring 2.5.x and 3.0.x. In order to run earlier versions of
camel-spring-ws
on Spring 2.5.x you need to add the spring-webmvc
module from Spring 2.5.x. In order to run Spring-WS 1.5.9 on Spring 3.0.x you need to exclude the OXM module from Spring 3.0.x as this module is also included in Spring-WS 1.5.9 (see this post)
URI format
The URI scheme for this component is as follows
spring-ws:[mapping-type:]address[?options]
To expose a web service,
mapping-type
needs to be set to one of the following values:
Mapping type | Description |
---|---|
rootqname
|
Offers the option to map web service requests based on the qualified name of the root element contained in the message. |
soapaction
|
Used to map web service requests based on the SOAP action specified in the header of the message. |
uri
|
In order to map web service requests that target a specific URI. |
xpathresult
|
Used to map web service requests based on the evaluation of an XPath expression against the incoming message. The result of the evaluation should match the XPath result specified in the endpoint URI.
|
beanname
|
Allows you to reference a org.apache.camel.component.spring.ws.bean.CamelEndpointDispatcher in order to integrate with existing (legacy) endpoint mappings like PayloadRootQNameEndpointMapping , SoapActionEndpointMapping , etc
|
As a consumer the
address
should contain a value relevant to the specified mapping-type (e.g. a SOAP action, XPath expression). As a producer the address should be set to the URI of the web service you are calling upon.
You can append query options to the URI in the following format,
?option=value&option=value&...
.
Options
Name | Required? | Description |
---|---|---|
soapAction
|
No | SOAP action to include inside a SOAP request when accessing remote web services |
wsAddressingAction
|
No |
WS-Addressing 1.0 action header to include when accessing web services. The To header is set to the address of the web service as specified in the endpoint URI (default Spring-WS behavior).
|
outputAction
|
No | Signifies the value for the response WS-Addressing Action header that is provided by the method. |
faultAction
|
No |
Signifies the value for the faultAction response WS-Addressing Fault Action header that is provided by the method.
|
faultTo
|
No |
Signifies the value for the faultAction response WS-Addressing FaultTo header that is provided by the method.
|
replyTo
|
No |
Signifies the value for the replyTo response WS-Addressing ReplyTo header that is provided by the method.
|
expression
|
Only when mapping-type is xpathresult
|
XPath expression to use in the process of mapping web service requests, should match the result specified by xpathresult
|
timeout
|
No |
Camel 2.10: Sets the socket read timeout (in milliseconds) while invoking a webservice using the producer, see URLConnection.setReadTimeout() and CommonsHttpMessageSender.setReadTimeout(). his option works when using the built-in message sender implementations: CommonsHttpMessageSender nd HttpUrlConnectionMessageSender. ne of these implementations will be used by default for HTTP based services unless you customize the Spring WS configuration options supplied to the component. f you are using a non-standard sender, it is assumed that you will handle your own timeout configuration. Camel 2.12: he built-in message sender HttpComponentsMessageSender s considered instead of CommonsHttpMessageSender hich has been deprecated, see HttpComponentsMessageSender.setReadTimeout().
|
sslContextParameters
|
No |
Camel 2.10: Reference to an
org.apache.camel.util.jsse.SSLContextParameters object in the Registry. See Using the JSSE Configuration Utility. This option works when using the built-in message sender implementations: CommonsHttpMessageSender and HttpUrlConnectionMessageSender. One of these implementations will be used by default for HTTP based services unless you customize the Spring WS configuration options supplied to the component. If you are using a non-standard sender, it is assumed that you will handle your own TLS configuration. See chapter "Configuring Transport Security for Camel Components" in "Security Guide".
Camel 2.12: The built-in message sender HttpComponentsMessageSender is considered instead of CommonsHttpMessageSender, which has been deprecated.
|
webServiceTemplate
|
No | Option to provide a custom WebServiceTemplate. This allows for full control over client-side web services handling; like adding a custom interceptor or specifying a fault resolver, message sender or message factory. |
messageSender
|
No | Option to provide a custom WebServiceMessageSender. For example to perform authentication or use alternative transports |
messageFactory
|
No | Option to provide a custom WebServiceMessageFactory. For example when you want Apache Axiom to handle web service messages instead of SAAJ |
endpointMappingKey
|
No |
Reference to an instance of org.apache.camel.component.spring.ws.type.EndpointMappingKey .
|
endpointMapping
|
Only when mapping-type is rootqname , soapaction , uri or xpathresult
|
Reference to org.apache.camel.component.spring.ws.bean.CamelEndpointMapping in the Registry/ApplicationContext. Only one bean is required in the registry to serve all Camel/Spring-WS endpoints. This bean is auto-discovered by the MessageDispatcher and used to map requests to Camel endpoints based on characteristics specified on the endpoint (like root QName, SOAP action, etc)
|
endpointDispatcher
|
No |
Spring org.springframework.ws.server.endpoint.MessageEndpoint for dispatching messages received by Spring-WS to a Camel endpoint, to integrate with existing (legacy) endpoint mappings like PayloadRootQNameEndpointMapping , SoapActionEndpointMapping , and so on.
|
messageFilter
|
No | Option to provide a custom MessageFilter since 2.10.3. For example when you want to process your headers or attachments by your own. |
messageIdStrategy
|
No |
A custom MessageIdStrategy to control generation of unique message IDs.
|
webServiceEndpointUri
|
No | The default Web Service endpoint URI to use for the producer. |
Message headers
Name | Type | Description |
---|---|---|
CamelSpringWebserviceEndpointUri
|
String
|
URI of the web service you are accessing as a client; overrides the address part of the endpoint URI. |
CamelSpringWebserviceSoapAction
|
String
|
Header to specify the SOAP action of the message; overrides the soapAction option, if present
|
CamelSpringWebserviceSoapHeader
|
Source | Camel 2.11.1: Use this header to specify/access the SOAP headers of the message. |
CamelSpringWebserviceAddressingAction
|
URI
|
Use this header to specify the WS-Addressing action of the message; overrides the wsAddressingAction option, if present
|
CamelSpringWebserviceAddressingFaultTo
|
URI
|
Use this header to specify the WS-Addressing FaultTo , overrides faultTo option, if present.
|
CamelSpringWebserviceAddressingReplyTo
|
URI
|
Use this header to specify the WS-Addressing ReplyTo , overrides replyTo option, if present.
|
CamelSpringWebserviceAddressingOutputAction
|
URI
|
Use this header to specify the WS-Addressing Action, overrides outputAction option, if present.
|
CamelSpringWebserviceAddressingFaultAction
|
URI
|
Use this header to specify the WS-Addressing Fault Action , overrides faultAction option, if present.
|
Accessing web services
To call a
web service
simply define a route:
from("direct:example").to("spring-ws:http://foo.com/bar")
And sent a message:
template.requestBody("direct:example", "<foobar xmlns=\"http://foo.com\"><msg>test message</msg></foobar>");
Remember, if it's a SOAP service you're calling you don't have to include SOAP tags. Spring-WS will perform the XML-to-SOAP marshaling.
Sending SOAP and WS-Addressing action headers
When a remote web service requires a SOAP action or use of the WS-Addressing standard you define your route as:
from("direct:example") .to("spring-ws:http://foo.com/bar?soapAction=http://foo.com&wsAddressingAction=http://bar.com")
Optionally you can override the endpoint options with header values:
template.requestBodyAndHeader("direct:example", "<foobar xmlns=\"http://foo.com\"><msg>test message</msg></foobar>", SpringWebserviceConstants.SPRING_WS_SOAP_ACTION, "http://baz.com");
Using SOAP headers
Available as of Camel 2.11.1
You can provide the SOAP header(s) as a Camel Message header when sending a message to a spring-ws endpoint, for example given the following SOAP header in a String
String body = ... String soapHeader = "<h:Header xmlns:h=\"http://www.webserviceX.NET/\"><h:MessageID>1234567890</h:MessageID><h:Nested><h:NestedID>1111</h:NestedID></h:Nested></h:Header>";
We can set the body and header on the Camel Message as follows:
exchange.getIn().setBody(body); exchange.getIn().setHeader(SpringWebserviceConstants.SPRING_WS_SOAP_HEADER, soapHeader);
And then send the Exchange to a
spring-ws
endpoint to call the Web Service.
Likewise the spring-ws consumer will also enrich the Camel Message with the SOAP header.
For an example see this unit test.
The header and attachment propagation
Spring WS Camel supports propagation of the headers and attachments into Spring-WS WebServiceMessage response since version 2.10.3. The endpoint will use so called "hook" the MessageFilter (default implementation is provided by
BasicMessageFilter
) to propagate the exchange headers and attachments into WebServiceMessage
response. Now you can use
exchange.getOut().getHeaders().put("myCustom","myHeaderValue") exchange.getIn().addAttachment("myAttachment", new DataHandler(...))
Note: If the exchange header in the pipeline contains text, it generates Qname(key)=value attribute in the soap header. Recommended is to create a QName class directly and put into any key into header.
How to use MTOM attachments
The BasicMessageFilter provides all required information for Apache Axiom in order to produce MTOM message. If you want to use Apache Camel Spring WS within Apache Axiom, here is an example: 1. Simply define the messageFactory as is bellow and Spring-WS will use MTOM strategy to populate your SOAP message with optimized attachments.
<bean id="axiomMessageFactory" class="org.springframework.ws.soap.axiom.AxiomSoapMessageFactory"> <property name="payloadCaching" value="false" /> <property name="attachmentCaching" value="true" /> <property name="attachmentCacheThreshold" value="1024" /> </bean>
2. Add into your pom.xml the following dependencies
<dependency> <groupId>org.apache.ws.commons.axiom</groupId> <artifactId>axiom-api</artifactId> <version>1.2.13</version> </dependency> <dependency> <groupId>org.apache.ws.commons.axiom</groupId> <artifactId>axiom-impl</artifactId> <version>1.2.13</version> <scope>runtime</scope> </dependency>
3. Add your attachment into the pipeline, for example using a Processor implementation.
private class Attachement implements Processor { public void process(Exchange exchange) throws Exception { exchange.getOut().copyFrom(exchange.getIn()); File file = new File("testAttachment.txt"); exchange.getOut().addAttachment("test", new DataHandler(new FileDataSource(file))); } }
4. Define endpoint (producer) as ussual, for example like this:
from("direct:send") .process(new Attachement()) .to("spring-ws:http://localhost:8089/mySoapService?soapAction=mySoap&messageFactory=axiomMessageFactory");
5. Now, your producer will generate MTOM message with otpmized attachments.
The custom header and attachment filtering
If you need to provide your custom processing of either headers or attachments, extend existing BasicMessageFilter and override the appropriate methods or write a brand new implementation of the MessageFilter interface. To use your custom filter, add this into your spring context: You can specify either a global a or a local message filter as follows: a) the global custom filter that provides the global configuration for all Spring-WS endpoints
<bean id="messageFilter" class="your.domain.myMessageFiler" scope="singleton" />
or b) the local messageFilter directly on the endpoint as follows:
to("spring-ws:http://yourdomain.com?messageFilter=#myEndpointSpecificMessageFilter");
For more information see CAMEL-5724
If you want to create your own MessageFilter, consider overriding the following methods in the default implementation of MessageFilter in class BasicMessageFilter:
protected void doProcessSoapHeader(Message inOrOut, SoapMessage soapMessage) {your code /*no need to call super*/ } protected void doProcessSoapAttachements(Message inOrOut, SoapMessage response) { your code /*no need to call super*/ }
Using a custom MessageSender and MessageFactory
A custom message sender or factory in the registry can be referenced like this:
from("direct:example") .to("spring-ws:http://foo.com/bar?messageFactory=#messageFactory&messageSender=#messageSender")
Spring configuration:
<!-- authenticate using HTTP Basic Authentication --> <bean id="messageSender" class="org.springframework.ws.transport.http.HttpComponentsMessageSender"> <property name="credentials"> <bean class="org.apache.commons.httpclient.UsernamePasswordCredentials"> <constructor-arg index="0" value="admin"/> <constructor-arg index="1" value="secret"/> </bean> </property> </bean> <!-- force use of Sun SAAJ implementation, http://static.springsource.org/spring-ws/sites/1.5/faq.html#saaj-jboss --> <bean id="messageFactory" class="org.springframework.ws.soap.saaj.SaajSoapMessageFactory"> <property name="messageFactory"> <bean class="com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl"></bean> </property> </bean>
Exposing web services
In order to expose a web service using this component you first need to set-up a MessageDispatcher to look for endpoint mappings in a Spring XML file. If you plan on running inside a servlet container you probably want to use a
MessageDispatcherServlet
configured in web.xml
.
By default the
MessageDispatcherServlet
will look for a Spring XML named /WEB-INF/spring-ws-servlet.xml
. To use Camel with Spring-WS the only mandatory bean in that XML file is CamelEndpointMapping
. This bean allows the MessageDispatcher
to dispatch web service requests to your routes.
web.xml
<web-app> <servlet> <servlet-name>spring-ws</servlet-name> <servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>spring-ws</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> </web-app>
spring-ws-servlet.xml
<bean id="endpointMapping" class="org.apache.camel.component.spring.ws.bean.CamelEndpointMapping" /> <bean id="wsdl" class="org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition"> <property name="schema"> <bean class="org.springframework.xml.xsd.SimpleXsdSchema"> <property name="xsd" value="/WEB-INF/foobar.xsd"/> </bean> </property> <property name="portTypeName" value="FooBar"/> <property name="locationUri" value="/"/> <property name="targetNamespace" value="http://example.com/"/> </bean>
More information on setting up Spring-WS can be found in Writing Contract-First Web Services.
Endpoint mapping in routes
With the XML configuration in-place you can now use Camel's DSL to define what web service requests are handled by your endpoint. The following route will receive all web service requests that have a root element named
GetFoo
within the http://example.com/
namespace:
from("spring-ws:rootqname:{http://example.com/}GetFoo?endpointMapping=#endpointMapping") .convertBodyTo(String.class).to(mock:example)
The following route will receive web service requests containing the
http://example.com/GetFoo
SOAP action:
from("spring-ws:soapaction:http://example.com/GetFoo?endpointMapping=#endpointMapping") .convertBodyTo(String.class).to(mock:example)
The following route will receive all requests sent to
http://example.com/foobar
:
from("spring-ws:uri:http://example.com/foobar?endpointMapping=#endpointMapping") .convertBodyTo(String.class).to(mock:example)
The route below receives requests that contain the element
<foobar>abc</foobar>
anywhere inside the message (and the default namespace).
from("spring-ws:xpathresult:abc?expression=//foobar&endpointMapping=#endpointMapping") .convertBodyTo(String.class).to(mock:example)
Alternative configuration, using existing endpoint mappings
For every endpoint with mapping-type
beanname
one bean of type CamelEndpointDispatcher
with a corresponding name is required in the Registry/ApplicationContext. This bean acts as a bridge between the Camel endpoint and an existing endpoint mapping like PayloadRootQNameEndpointMapping
.
Note
The use of the
beanname
mapping-type is primarily meant for (legacy) situations where you're already using Spring-WS and have endpoint mappings defined in a Spring XML file. The beanname
mapping-type allows you to wire your Camel route into an existing endpoint mapping. When you're starting from scratch it's recommended to define your endpoint mappings as Camel URI's (as illustrated above with endpointMapping
) since it requires less configuration and is more expressive. Alternatively you could use vanilla Spring-WS with the help of annotations.
An example of a route using
beanname
:
<camelContext xmlns="http://camel.apache.org/schema/spring"> <route> <from uri="spring-ws:beanname:QuoteEndpointDispatcher" /> <to uri="mock:example" /> </route> </camelContext> <bean id="legacyEndpointMapping" class="org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping"> <property name="mappings"> <props> <prop key="{http://example.com/}GetFuture">FutureEndpointDispatcher</prop> <prop key="{http://example.com/}GetQuote">QuoteEndpointDispatcher</prop> </props> </property> </bean> <bean id="QuoteEndpointDispatcher" class="org.apache.camel.component.spring.ws.bean.CamelEndpointDispatcher" /> <bean id="FutureEndpointDispatcher" class="org.apache.camel.component.spring.ws.bean.CamelEndpointDispatcher" />
POJO (un)marshalling
Camel's pluggable data formats offer support for POJO/XML marshalling using libraries such as JAXB, XStream, JibX, Castor and XMLBeans. You can use these data formats in your route to sent and receive POJOs (Plain Old Java Objects), to and from web services.
When accessing web services you can marshal the request and unmarshal the response message:
JaxbDataFormat jaxb = new JaxbDataFormat(false); jaxb.setContextPath("com.example.model"); from("direct:example").marshal(jaxb).to("spring-ws:http://foo.com/bar").unmarshal(jaxb);
Similarly when providing web services, you can unmarshal XML requests to POJOs and marshal the response message back to XML:
from("spring-ws:rootqname:{http://example.com/}GetFoo?endpointMapping=#endpointMapping").unmarshal(jaxb) .to("mock:example").marshal(jaxb);