Mule Workaround

Mule Workaround


Using Mule Community edition as ESB, sometimes is not so easy, using CXF endpoint in a message oriented way (proxy=true) is a mess, sometimes ago I was fighting with an integration that at some point had to invoke a web service deployed on an Web Methods integration server.

Unfortunately the WM integration server that I used doesn’t support the HTTP 1.1 specs, in particular the Transfer-Encoding: Chunked directive.

For the CXF outbound endpoint, it’s natural use this way to build the HTTP request as the message it’s a stream,
to obtain better performances especially with big payload. 

I tried to set up the CXF connector to doesn’t use this feature without lucky… very bad for an ESB, its main target is integrate.. also/especially for legacy systems.

After some session using tcpmon to sniff the request and a post on the community forum without any reply, I found a workaround… it’s not elegant but it works.

I added an additional bridge between the CXF outbound and the integration server.

Just to understand the problem, in my case the message arrived from a JMS queue, I transformed this message using XSLT then sent it to the WS. see the following Mule configuration fragment (I snipped the transformers) :

<service name="resumeWm">
			<inbound>
				<jms:inbound-endpoint name="job_in" queue="jobs_toResume_dev" synchronous="false">
					<transformers>
					</transformers>
					<response-transformers>
                                        </response-transformers>
				</jms:inbound-endpoint>
			</inbound>
			<echo-component></echo-component>
			<outbound>
				<pass-through-router>
					  <cxf:outbound-endpoint 
						applyTransformersToProtocol="false" 
						address="http://url" 
						proxy="true"   
						synchronous="true"
						>
					</cxf:outbound-endpoint>
				</pass-through-router>
			</outbound>
		</service>

I this way I wasn’t able to configure Mule and CXF to use only the HTTP1.0 specs… I tried to add a custom cxf.xml… but it seems to be ignored.

As ultima ratio I tried a workaround, I added a protocol bridge,hence instead of invoke directly the WS, I sent the messages on a VM queue using CXF, than I grab the message from the queue and using an http outbound endpoint I forwarded the message to the Integration service… using a simple http connector force HTTP1.0 it’s very easy. following the modified version :

<service name="resumeWm">
			<inbound>
				<jms:inbound-endpoint name="job_in" queue="jobs_toResume_dev" synchronous="false">
					<transformers>
					</transformers>
					<response-transformers>
                                        </response-transformers>
				</jms:inbound-endpoint>
			</inbound>
			<echo-component></echo-component>
			<outbound>
				<pass-through-router>
					  <cxf:outbound-endpoint 
						applyTransformersToProtocol="false" 
						address="vm://wmworkaround" 
						proxy="true"   
						synchronous="true"
						protocolConnector="vmConnector"
						>
					</cxf:outbound-endpoint>
				</pass-through-router>
			</outbound>
		</service>
 
		<service name="httpBridge">
		<inbound>
			<vm:inbound-endpoint address="vm://wmworkaround" connector-ref="vmConnector" synchronous="true"/>
		</inbound>
		<echo-component>
			<logging-interceptor/>
		</echo-component>
		<outbound>
			<pass-through-router>
			<http:outbound-endpoint address="http://url" synchronous="false">
				<mule-xml:xml-to-dom-transformer/>
				<property key="http.version" value="HTTP/1.0"/>
			</http:outbound-endpoint>
			</pass-through-router>
		</outbound>
		</service>

I verified this solution with TCPMON, and the request is HTTP1.0 compliant.