c-integration-scenarios.xml - activemq-web - Git at Google

 <div class="wiki-content maincontent">
 <h2>One way and RPC with C services</h2>
 <p>Its common for the C services to be the back end services. The 2 common use cases are</p>

 <ul><li>we send a message one-way to a C service</li><li>we send a message to a C-service and wait for the result, then reply back to the originator the result</li></ul>


 <h3>Making one-ways reliable</h3>

 <p>If we assume that the C-service is fairly atomic, it works or it doesn't and does not partially work, then for one-way handling we just need some code to...</p>

 <ol><li>consume a message from some destination</li><li>invoke the C service and wait until the service completes</li><li>acknowledge the message</li></ol>


 <p>If invoking the C service fails (such that we know it wasn't invoked), we could automatically retry a certain number of times before we acknowledge the message.</p>

 <p>The problem is if the above code were to be killed before the message is acknowledged, we'd invoke the service again.</p>

 <p>To get around this we could persist that we have invoked the service, so that if we are killed we would not invoke the service again but put the message on some dead letter queue for manual reconciliation.</p>

 <ol><li>consume a message from some destination</li><li>have we seen this message before - if so put on a dead letter queue for manual reconciliation</li><li>persist that we have processed this message</li><li>invoke the C service and wait until the service completes</li><li>acknowledge the message</li></ol>


 <p>Another approach could be for the C service to say whether or not it has successfully processed the message before. This just pushes the problem inside the C code requiring that it persists when things are invoked and when things complete so that it can know when duplicate messages are delivered.</p>

 <h3>making RPC reliable</h3>

 <p>This scenario is as above but rather than just acknowledge the inbound message we wish to send a reply and acknowledge the inbound message. So this could be regarded as a small JMS transaction.</p>

 <ol><li>consume a message from some destination</li><li>have we seen this message before - if so put on a dead letter queue for manual reconciliation</li><li>persist that we have processed this message</li><li>invoke the C service and wait until the service completes</li><li>send the reply with results from the C service</li><li>commit the JMS transaction</li></ol>


 <p>Again if the C service is capable of knowing if it has seen the message before then we can avoiid step 3.</p>

 <h3>connectivity to C</h3>

 <p>We can link C into a Java process and invoke it directly via JNI. Another option is to wrap the C code as an Apache module and perform a HTTP POST to invoke a C service and extract the results of the service.</p></div>
	<div class="wiki-content maincontent">
	<h2>One way and RPC with C services</h2>
	<p>Its common for the C services to be the back end services. The 2 common use cases are</p>

	<ul><li>we send a message one-way to a C service</li><li>we send a message to a C-service and wait for the result, then reply back to the originator the result</li></ul>


	<h3>Making one-ways reliable</h3>

	<p>If we assume that the C-service is fairly atomic, it works or it doesn't and does not partially work, then for one-way handling we just need some code to...</p>

	<ol><li>consume a message from some destination</li><li>invoke the C service and wait until the service completes</li><li>acknowledge the message</li></ol>


	<p>If invoking the C service fails (such that we know it wasn't invoked), we could automatically retry a certain number of times before we acknowledge the message.</p>

	<p>The problem is if the above code were to be killed before the message is acknowledged, we'd invoke the service again.</p>

	<p>To get around this we could persist that we have invoked the service, so that if we are killed we would not invoke the service again but put the message on some dead letter queue for manual reconciliation.</p>

	<ol><li>consume a message from some destination</li><li>have we seen this message before - if so put on a dead letter queue for manual reconciliation</li><li>persist that we have processed this message</li><li>invoke the C service and wait until the service completes</li><li>acknowledge the message</li></ol>


	<p>Another approach could be for the C service to say whether or not it has successfully processed the message before. This just pushes the problem inside the C code requiring that it persists when things are invoked and when things complete so that it can know when duplicate messages are delivered.</p>

	<h3>making RPC reliable</h3>

	<p>This scenario is as above but rather than just acknowledge the inbound message we wish to send a reply and acknowledge the inbound message. So this could be regarded as a small JMS transaction.</p>

	<ol><li>consume a message from some destination</li><li>have we seen this message before - if so put on a dead letter queue for manual reconciliation</li><li>persist that we have processed this message</li><li>invoke the C service and wait until the service completes</li><li>send the reply with results from the C service</li><li>commit the JMS transaction</li></ol>


	<p>Again if the C service is capable of knowing if it has seen the message before then we can avoiid step 3.</p>

	<h3>connectivity to C</h3>

	<p>We can link C into a Java process and invoke it directly via JNI. Another option is to wrap the C code as an Apache module and perform a HTTP POST to invoke a C service and extract the results of the service.</p></div>