diff --git a/src/docbkx/client.xml b/src/docbkx/client.xml
index 48e13a54..079179d5 100644
--- a/src/docbkx/client.xml
+++ b/src/docbkx/client.xml
@@ -75,7 +75,7 @@
]]>
- The folowing example shows how override the default configuration, and to use Commons Http to
+ The following example shows how override the default configuration, and to use Commons Http to
authenticate using HTTP authentication:
@@ -110,7 +110,7 @@
JMS URIs are: jms:SomeQueue,
jms:SomeTopic?priority=3&deliveryMode=NON_PERSISTENT, and
jms:RequestQueue?replyToName=ResponseName.
- For more information on this URI syntax, refer to the class level Javadocs of the
+ For more information on this URI syntax, refer to the class level Javadoc of the
JmsMessageSender.
@@ -119,8 +119,8 @@
this can be overriden to use TextMessages by using the
messageType parameter on the JMS URI. For example:
jms:Queue?messageType=TEXT_MESSAGE.
- Note that BytesMessages are the prefered type, because
- TextMessages do not support attachments and charactering
+ Note that BytesMessages are the preferred type, because
+ TextMessages do not support attachments and character
encodings reliably.
@@ -302,8 +302,8 @@ public class WebServiceClient {
in the Java code.
- Please note that the WebServiceTemplate class is threadsafe once
- configured (assuming that all of it's dependencies are threadsafe too, which is the case for
+ Please note that the WebServiceTemplate class is thread-safe once
+ configured (assuming that all of it's dependencies are thread-safe too, which is the case for
all of the dependencies that ship with Spring-WS), and so multiple objects can use the same
shared WebServiceTemplate instance if so desired.
The WebServiceTemplate exposes a zero argument constructor and
@@ -415,4 +415,290 @@ public void marshalWithSoapActionHeader(final Source s) {
}]]>
+
+ Client-side testing
+
+ When it comes to testing your Web service clients (i.e. classes that uses the
+ WebServiceTemplate to access a Web service), there are two possible
+ approaches:
+
+
+
+
+ Write Unit Tests, which simply mock away the
+ WebServiceTemplate class,
+ WebServiceOperations interface, or the complete client class.
+
+
+ The advantage of this approach is that it's quite easy to accomplish; the disadvantage is that
+ you are not really testing the exact content of the XML messages that are sent over the wire,
+ especially when mocking out the entire client class.
+
+
+
+
+ Write Integrations Tests, which do test the contents of the message.
+
+
+
+
+ The first approach can easily be accomplished with mocking frameworks such as EasyMock, JMock, etc.
+ The next section will focus on writing integration tests, using the test features introduced in Spring
+ Web Services 2.0.
+
+
+ Writing integration tests
+
+ Spring Web Services 2.0 introduced support for creating Web service client tests.
+ In this context, a client is a class that uses the WebServiceTemplate
+ to access a Web service.
+
+
+ The integration test support lives in the org.springframework.ws.test.client package.
+ The core class in that package is the MockWebServiceServer.
+ The underlying idea is that the web service template connects to this mock server, sends it request
+ message, which the mock server then verifies against the registered expectations.
+ If the expectations are met, the mock server then prepares a response message, which is send back to the
+ template.
+
+
+ The typical usage of the MockWebServiceServer is:
+
+
+
+ Create a MockWebServiceServer instance by calling
+ MockWebServiceServer.createServer(WebServiceTemplate),
+ MockWebServiceServer.createServer(WebServiceGatewaySupport), or
+ MockWebServiceServer.createServer(ApplicationContext).
+
+
+
+
+ Set up request expectations by calling expect(RequestMatcher),
+ possibly by using the default RequestMatcher implementations
+ provided in RequestMatchers (which can be statically imported).
+ Multiple expectations can be set up by chaining
+ andExpect(RequestMatcher) calls.
+
+
+
+
+ Create an appropriate response message by calling
+ andRespond(ResponseCreator), possibly by using the default
+ ResponseCreator implementations provided in
+ ResponseCreators (which can be statically imported).
+
+
+
+
+ Use the WebServiceTemplate as normal, either directly of through
+ client code.
+
+
+
+
+ Call MockWebServiceServer.verify() to make sure that all
+ expectations have been met.
+
+
+
+
+
+
+ Note that the MockWebServiceServer (and related classes) offers a
+ 'fluent' API, so you can typically use the Code Completion features (i.e. ctrl-space) in your IDE
+ to guide you through the process of setting up the mock server.
+
+
+
+ Consider, for example, this Web service client class:
+
+
+
+
+
+
+
+
+
+
+
+ The CustomerClient extends
+ WebServiceGatewaySupport, which provides it with a
+ webServiceTemplate property.
+
+
+
+
+ CustomerCountRequest is an object supported by a marshaller.
+ For instance, it could have a @XmlRootElement annotation
+ to be supported by JAXB2.
+
+
+
+
+ The CustomerClient uses the WebServiceTemplate
+ offered by WebServiceGatewaySupport to marshal the request object
+ into a SOAP message, and sends that to the web service.
+ The response object is unmarshalled into a CustomerCountResponse.
+
+
+
+
+
+ A typical test for CustomerClient would look like this:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ " +
+ "John Doe" +
+ "");
+ Source responsePayload = new StringSource(
+ "" +
+ "10" +
+ "");
+
+ mockServer.expect(payload(requestPayload)).andRespond(withPayload(responsePayload));
+
+ int result = client.getCustomerCount();
+ assertEquals(10, result);
+
+ mockServer.verify();
+ }
+
+}]]>
+
+
+
+ The CustomerClientIntegrationTest imports the
+ MockWebServiceServer, and statically imports
+ RequestMatchers and ResponseCreators.
+
+
+
+
+ This tests uses the standard testing facilities provided in the Spring Framework.
+ This is not required, but is generally the easiest way to set up the test.
+
+
+
+
+ The CustomerClient is configured in
+ integration-test.xml, and wired into this test using
+ @Autowired.
+
+
+
+
+ In a @Before method, we create a
+ MockWebServiceServer by using the
+ createServer factory method.
+
+
+
+
+ We define expectations by calling expect() with a
+ payload() RequestMatcher provided
+ by the statically imported RequestMatchers.
+ We also set up a response by calling andRespond() with a
+ withPayload() ResponseCreator
+ provided by the statically imported ResponseCreators.
+
+
+ This part of the test might look a bit confusing, but the Code Completion features of your
+ IDE are of great help.
+ After typing expect(, simply type ctrl-space, and your IDE will
+ provide you with a list of possible request matching strategies, provided you
+ statically imported RequestMatchers.
+ The same applies to andRespond(, provided you statically imported
+ ResponseCreators.
+
+
+
+
+ We call getCustomerCount() on the
+ CustomerClient, thus using the
+ WebServiceTemplate.
+ The template has been set up for 'testing mode' by now, so no real
+ (HTTP) connection is made by this method call.
+ We also make some JUnit assertions based on the result of the method call.
+
+
+
+
+ We call verify() on the
+ MockWebServiceServer, thus verifying that the expected
+ message was actually received.
+
+
+
+
+
+
+
\ No newline at end of file