Guranteed Delivery using SI?

[smjain]

Hi All,
We have a requirement to use SI to have guranteed delivery. By Guranteed
deliver I mean the best effort like a retry policy in case of exceptions.

We thought of using a JMS adaptor in front of the channel and in case of exceptions in service activator the message gets back to the queue and gets retried.

Issue arises if we are running something async in the service activator .So not sure what could be the possibilities in that case. Do we execute a poller or depend on a callback. In either case the message context has to be persisted for that period..

Thoughts ??

Regards
Shashank

[Mark Fisher]

When you say running something async in the Service Activator, do you mean an @Async annotation or equivalent (i.e. delegating to a new thread) on a service-level object behind that service-activator? Or, are you just talking about having an asynchronous MessageChannel instance as the service-activator's input-channel?

[smjain]

Thanks Mark,
I meant a code behind the service Activator which we execute asynchronously
Thanks
Shashank

[smjain]

Any updates on the same...

[oleg.zhurakousky]

So, are you doing something along the lines of new Thread().start() inside of Service Activator.
I guess the real question and that is what I believe Mark was trying to understand is if you are implementing your own custom asynchronous processes which are outside of SI and Spring then how do you know that a process resulted in the exception?

[smjain]

Thats precisely the question ..Either we poll to know that the async process ended in exception or there is a callback from the code which is running in async mode.

In either case do we maintain the message as long as we get some feedback..Of success or failure

And yes its a process outside of SI

Thanks
Shashank

[oleg.zhurakousky]

Ok, you essentially talking about custom orchestration of asynchronous processes and of course if those processes run in Spring you can always fire of an Event to Spring Application Context and have SI Event adapter to listen for certain events (e.g., error events) and do whatever it is you want to do.

Having said that, why not orchestrate such processed with Spring Integration and Spring with built in support for asynchronous processing, then everything could and would be handled/orchestrated by Spring Integration components resulting in much less code for you to maintain?

[smjain]

There is a difference here..I am looking for reliability aspect for those async communications.

So in case of failed executions(we get notified through callback or through polling) we need to retry based on some policy or try an alternative execution.

We cant do that unless we have the message persisted for that period till the time we get back the status of the original execution

Thanks
Shashank

[oleg.zhurakousky]

..I am looking for reliability aspect for those async communications.

If I understand correctly those async communications are not accomplished through the framework, but rather through custom code which Spring Integration is not aware which means its reliability aspect falls into yet more custom code on your end and all I am offering is to see if that can be handled by the framework.
For example; There is a huge difference between having a DirectChannel dispatching message to Service Activator synchronously and have such Service Activator to do Thread.start() in its custom code vs. having an ExecutorChannel dispatching message to the Service Activator asynchronously where such service activator dos not have to worry about any custom thread logic since its already been invoked asynchronously.
The fact that you have the threading code inside of the Service Activator worries me already since it does not belong there in the first place simply because by design Service Activator is to handle the business logic which is *WHAT* needs to happen and in your case it seem like you also trying to address *HOW* it needs to happen which is clearly an Integration concern and has to be handled by the framework especially when framework provides such capability which also includes the error handling and other features. . .

We can't do that unless we have the message persisted for that period till the time we get back the status of the original execution

Again, you are talking about the integration concerns that are currently handled by you probably due to the fact that you may not be aware that there are patterns and components within Spring Integration that are designed to handle that exact use case.
For example; There is a pattern called Claim Check http://www.eaipatterns.com/StoreInLibrary.html
Spring Integration provides ClaimCheckInTransformer as well as ClaimCheckOutTransformer which could be configured with various implementations of MessageStore interface (for simple JDBC we also provide implementation of JdbcMessageStore)
As you will see from the reading the pattern description, the responsibility of the Claim Check pattern is to persist the message and only pass the Claim Check around and at any point of time you can use the *Out* transformer to get the actual message.
Also, don't forget that QueueChannel also has a configurable message-store option giving you the capability to persist every message that arrives on such channel.

The bottom line is you need to separate Integration from Business and that is what I am trying to understand.