Enterprise Integration Zone is brought to you in partnership with:

Enterprise Architect in HCL Technologies a $7Billion IT services organization. My role is to work as a Technology Partner for large enterprise customers providing them low cost opensource solutions around Java, Spring and vFabric stack. I am also working on various projects involving, Cloud base solution, Mobile application and Business Analytics around Spring and vFabric space. Over 23 yrs, I have build repository of technologies and tools I liked and used extensively in my day to day work. In this blog, I am putting all these best practices and tools so that it will help the people who visit my website. Krishna is a DZone MVB and is not an employee of DZone and has posted 64 posts at DZone. You can read more from them at their website. View Full User Profile

Claimcheck Pattern with vFabric RabbitMQ and Gemfire

11.06.2012
| 3741 views |
  • submit to reddit

 For people in hurry refer the steps to run this sample.

In continuation to my earlier blog on Claimcheck Pattern in this blog I use AMQP backed message channel to simplify implement Claimcheck Pattern. There is also another good blog on Spring Integration – Payload Storage via Claim-check, which talks about Claimcheck Pattern

The Enterprise Integration Pattern flow is as below,

Claimcheck pattern with vFabric RabbitMQ and Gemfire

Claimcheck pattern with vFabric RabbitMQ and Gemfire

The use case in this blog is, there is a message that gets posted on to a Queue, the message checks into a vFabric Gemfire messageStore, and a GUID is extracted and posted on to a vFabric RabbitMQ Exchange. The subscribers listening to that Exchange and will get the GUID and checks out of the messageStore and calls a Service activator.

As per the Test First development, the JUnit test case looks as below,

@Test
public void testIntegration() {
String request = streamToString(getClass().getResourceAsStream(
"/data/payload.xml"));
Message<String> message = MessageBuilder.withPayload(request)
.build();
channel.send(message);
String outMessage = outChannel.receive(1000).getPayload().toString();
assertEquals(outMessage, request);
}

In the test code, since there is no transformation, we just compare the input data to the data coming out of the target channel.

The test configuration looks as below,

<int:channel id="p2p-pollable-channel" />
<int:publish-subscribe-channel id="pub-sub-channel" />
<int:channel id="checkout-channel3" >
<int:queue />
</int:channel>
<int:claim-check-out message-store="simpleMessageStore"
input-channel="pub-sub-channel" output-channel="checkout-channel3"
remove-message="false" />

In the main configuration the vFabric RabbitMQ configuration looks as below,

<!-- A reference to the org.springframework.amqp.rabbit.connection.ConnectionFactory -->
<rabbit:connection-factory id="connectionFactory" />
<!-- Creates a org.springframework.amqp.rabbit.core.RabbitAdmin to manage
exchanges, queues and bindings -->
<rabbit:admin connection-factory="connectionFactory" />
<int-amqp:channel id="p2p-pollable-channel" connection-factory="connectionFactory" />
<int-amqp:publish-subscribe-channel id="pub-sub-channel" connection-factory="connectionFactory" />

Finally the integration flow demonstrate the claim checkin and claim checkout as below,

<int:claim-check-in message-store="simpleMessageStore"
input-channel="p2p-pollable-channel" output-channel="pub-sub-channel" />

<int:claim-check-out message-store="simpleMessageStore"
input-channel="pub-sub-channel" output-channel="checkout-channel1"
remove-message="false" />

<int:claim-check-out message-store="simpleMessageStore"
input-channel="pub-sub-channel" output-channel="checkout-channel2"
remove-message="false" />

If you notice carefully, “p2p-pollable-channel” and “pub-sub-channel” are physical Queues and Exchanges in vFabric RabbitMQ as per the last blog on Amqp Backed Spring Integration Using vFabric Rabbitmq



Published at DZone with permission of Krishna Prasad, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)