Random Access Queue

[Mark Fisher]

Sorry, after some more thought, I realized that you would still have your first endpoint definition. The gateway would be an intermediary (rather than using RequestReplyTemplate or sending directly to a channel and then invoking correlator.getResponse()). For example, something more like this:

<endpoint input-channel="input"
         handler-ref="serviceimpl"
         handler-method="execute"
         default-output-channel="responses"/>

<gateway id="serviceGateway"
         target-channel="input"
         response-channel="responses"/>

Then you would invoke it like this:

Message response = serviceGateway.handle(message);

Since this would be backed by a ProxyFactoryBean, you could also provide an interface for the proxy (other than the default MessageHandler):

<gateway id="serviceGateway"
         interface="com.foo.SomeService"
         target-channel="input"
         response-channel="responses"/>

In that case, the code would be using the regular argument and return value of that interface, while the gateway proxy converts to and from Messages.

What do you think?
-Mark

[amsmota]

Hello:

I'm back on my service architecture, I updated the SI from the trunk and I noticed many changes, can you tell me what is the state of the art relating the RequestReplyTemplate, the Correlator and correlated issues?

Basically, I have to decide to go ahead with my changes outside of SI (which I of course don't want to do) or wait for your solution (but I can't wait also...)

Cheers.

[iwein]

You're feeling the sting of being on the bleeding edge. You will not have backwards compatibility until the GA release comes out. On the other hand your customisations are pretty likely to be replaced with something better in the framework.

The <gateway/> suggestion by Mark is not in the namespace yet.The only thing I can sensibly advise here is: patience. The other option you mentioned (personal branch) is not ideal (to say the least).

[Mark Fisher]

Have a look at the GatewayProxyFactoryBeanTests located in the "org.springframework.integration.gateway" package (from SVN head) and the associated configuration files that are referenced from those test cases. The parser for a <gateway/> element will be available soon. For now, it is a pretty simple bean definition.

Since the "gateway" code may be changing a bit before M4, any feedback is greatly appreciated. I'd be especially interested if this accommodates your use cases.

-Mark

[amsmota]

I am not expecting to have backward compatibility in a work-in-progress, nor do I mind to change my code or otherwise test, write, suggest or contribute in any way time allows me. My problem is the issues that I *do* need and you guys aren't going to implement, or at least didn't until now. As is the case of the Iterators in ResponseCorrelator, MessageStore, RetrievalBlockingMessageStore and SimpleMessageStore.

I'm going to test the gateway thing now.

Cheers.

[amsmota]

I see the M4 is out now (although I can't find it in the mvn repository) which is good for me because I have to use the latest from repo in my tests. Actually I can't do any tests for now as I'm working in another part of our app (Birt). But since I'm now integrating Birt with SI I would try to give it another shot.

Once I can get it from the repo, I mean...

One thing I already noted is that the changes I need for my use cases (that I implemented in extended versions of your classes) are not yet supported:

(...) My problem is the issues that I *do* need and you guys aren't going to implement, or at least didn't until now. As is the case of the Iterators in ResponseCorrelator, MessageStore, RetrievalBlockingMessageStore and SimpleMessageStore.

[Mark Fisher]

Spring Integration is now using the SpringSource Enterprise Bundle Repository. The FAQ demonstrates the ivy and maven configuration: http://www.springsource.com/repository/app/faq#q7

While Spring Integration is in the milestone phase, you can use that same configuration but replacing "release" with "milestone" for the Spring Integration JARs.