Spring Integration Generic Request Routing

On a project I was on recently, I needed to create a test harness where a lot of requests would come in through a single URL and need to be handled appropriately. Spring Integration provides a very easy way to make this happen. First you need to make use of the generic marshaller I discussed in a previous blog. Next you need to define the payloadRootAnnotationMethodEndpointMapping Spring bean, this will enable Spring to route incoming requests based on their payload root method, based on annotations placed in the endpoint classes, which I will discuss more in a minute.

    <bean class="org.springframework.ws.server.endpoint.mapping.PayloadRootAnnotationMethodEndpointMapping" />

    <bean class="org.springframework.ws.server.endpoint.adapter.GenericMarshallingMethodEndpointAdapter">
        <property name="marshaller" ref="marshaller"/>
        <property name="unmarshaller" ref="marshaller"/>
    </bean>

It is amazingly simple with spring integration to use the endpoint annotations.

@Endpoint
public class MyExposedEndpoint {
    @PayloadRoot(localPart="MyEndpointMethod", namespace="http://www.company.com/mynamespace")
    public void processMyMethod(MyRequest myRequest) {
         // Insert code to process the request here.
    }
}

That's really all there is to it. The web.xml is set up the same as the first blog in this series.

Spring Integration Marshalling with JAXB

The project I was working on used SOAP based Web Services. The .wsdl and .xsd files that described the services we needed to integrate with were provided by the vendor. Often times I needed to access information in the SOAP responses, or I needed to easily build a SOAP request object. While you can work directly with the XML, it is much easier to use marshalling/unmarshalling techniques. Being a proof of concept I chose JAXB to do the marshalling/unmarshalling. There may be better choices depending on your needs and most likely spring integration supports it.

While it is possible to create by hand JAXB Java classes, it seems to make more sense to use the xjc tool and generate the classes automatically. I will not go into great detail on using this tool as there are other resources that do that. xjc was on my class path, so I was able to navigate to the directory containing the .xsd and .wsdl files. I created a directory there called temp and ran the following command on each of the files that I needed classes generated for, which would create all the classes I needed in the appropriate directory structure under temp.

xjc -d temp myVendorFile.xsd

Now that the files had been generated it was a matter of configuring spring to use them. There are several ways to go about this. You can create a generic marshaller that handles all classes, or you can create more targeted marshallers. If you are creating a generic one you might just set the id to marshaller, if you want more targeted the id name will reflect something more specific.

    <bean id="marshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
        <property name="classesToBeBound">
            <list>
                <value>com.vendor.JAXBClass1</value>>
                <value>com.vendor.JAXBClass2</value>
                <value>com.vendor.JAXBClass3</value>
            </list>
        </property>
    </bean>

    <bean id="myServiceClient" class="com.company.project.ws.MyServiceClient">
        <property name="marshaller" ref="marshaller"/>
        <property name="unmarshaller" ref="marshaller"/>
    </bean>

the class MyServiceClient extends the spring WebServiceGatewaySupport class. This is an easy way to send requests and receive responses. Inside your class you can create the request object that you want sent using the JAXB ObjectFactory methods.

MyRequest myRequest = new ObjectFactory().createMyRequest(); 

Then you can set individual elements on that object, whatever they are. The request is sent by using a method from the Spring class. The SoapAction is not set automatically, so it needs to be set manually.

MyResponse myResponse = getWebServiceTemplate().marshallSendAndReceive(serviceUri, myRequest, new WebServiceMessageCallback() { public void doWithMessage(WebServiceMessage message) {
((SoapMessage)message).setSoapAction("MySoapAction");}});

That's really all there is to it. As you can see the above method automatically marshalls the request to XML and unmarshalls the response to the JAXB Java object. Also it is good to surround that method call with a try catch so that if there is a problem on the other end, your software can react appropriately.

Using Variable Substitution from Configuration Files in Spring

It doesn't take long in the development world to learn that hard coding property values is a bad idea.  Hard coded values will require the software to be rebuilt and redeployed if a change is required.   Moving values to configuration files so they can be modified in a central location is a first step.  A second step is moving the configuration file outside of the .war or .ear, so they can be modified at run time to avoid recompiling.  To read about how to externalize property files from your application see my earlier blog.

There are several places in the Spring configuration that can make use of variable substitution from a property file.  First things first. If you create a property file how do you access it from your spring configuration file?  Near the top of the configuration file add the following bean definition:

    <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
         <property name="locations">
            <value>file:my-project.properties</value>
         </property>
    </bean>

If you need to have comments in the property file, start the line with a #.  Properties should be entered into the property file in the following format: property.name=property value, i.e.

my.favorite.search.engine=http://www.google.com

Properties can be referenced from value fields, as well as bean variables.

	<bean id="jmsQueue" class="org.springframework.jndi.JndiObjectFactoryBean">
		<property name="jndiName" value="${my.project.testQueue}"/>
		<property name="jndiTemplate" ref="jndiTemplate" />
	</bean>
	<si-ws:outbound-gateway id="WebServiceGateway"
			 request-channel="jmsChannel"
			 reply-channel="replyChannel"
			 uri="${my.project.uri}"  />

It is also possible to access properties from spring annotations which can be very useful. The scheduled annotation is a good example.

@Scheduled(cron="${my.project.schedule.cron}")

Spring makes it very easy to leverage properties files for making systems easier to configure on the fly. There is no need to continue hard coding values that you or your client may want to change.