Announcement Announcement Module
Collapse
No announcement yet.
Random Access Queue Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    You should be able to use the same basic configuration. Then just add a ResponseCorrelator that is subscribed to the "responses" channel. If you provide a reference to that correlator in your client code, then you can call responseCorrelator.getResponse(correlationId).

    Nevertheless, what I think we need to introduce is a way to do this at a higher level so that these configuration details are not so tedious. Also, it should be very consistent with the RequestReplyTemplate usage. There are a couple JIRA issues related to this. Feel free to add comments:
    http://jira.springframework.org/browse/INT-126
    http://jira.springframework.org/browse/INT-143

    Thanks,
    Mark

    Comment


    • #17
      Well, I have added this to the RequestReplyTemplate and it works for me.

      Code:
      	private final ResponseCorrelator correlator;
      
      	public RequestReplyTemplate(MessageChannel requestChannel, ResponseCorrelator correlator, ExecutorService executor) {
      		Assert.notNull(requestChannel, "'requestChannel' must not be null");
      		Assert.notNull(correlator, "'correlator' must not be null");
      		Assert.notNull(executor, "'executor' must not be null");
      		this.requestChannel = requestChannel;
      		this.correlator = correlator;
      		this.executor = executor;
      	}
      
      	public RequestReplyTemplate(MessageChannel requestChannel, ResponseCorrelator correlator) {
      		this(requestChannel, correlator, Executors.newSingleThreadExecutor());
      	}
      	
      	
      	public void requestCorrelator(final Message<?> requestMessage) {		
      		ReplyHandler replyHandler = new ReplyHandler() {
      			public void handle(Message<?> replyMessage, MessageHeader originalMessageHeader) {
      				correlator.handle(replyMessage);
      			}
      		};
      		request(requestMessage, replyHandler);
      		
      	}
      It misses some checks yet.

      However, reading the comments on the Jira it's not this that you want, or at least is only partially what you want?

      Comment


      • #18
        'm afraid (and apologize for) I'm not understanding the big picture here. For example, I don't know what you mean by "subscribe". And I also can't figure out what does the <handler/> tag also.

        But nevertheless, this is the situation of my tests. In my config i had:

        Code:
        	<channel id="input"/>
        	<channel id="responses"/>
        
        	<endpoint input-channel="input" handler-ref="serviceimpl"
        		handler-method="execute" default-output-channel="responses"/>
        	
        	<beans:bean id="serviceimpl"
        		class="com.meridianp2p.stf.service.testservice.TestService"/>
        	
        	<beans:bean id="resource"
        		class="com.meridianp2p.stf.service.testservice.TestResource">
        		<beans:property name="requestChannel" ref="input"/>
        		<beans:property name="responseChannel" ref="responses"/>
        	</beans:bean>
        and now I have

        Code:
        	<channel id="input"/>
        	<channel id="responses"/>
        
        	<endpoint input-channel="input" handler-ref="serviceimpl"
        		handler-method="execute" default-output-channel="responses"/>
        	
        	<endpoint input-channel="responses" handler-ref="correlator"/>
        	
        	<beans:bean id="correlator" class="org.springframework.integration.handler.ResponseCorrelator"/>
        	
        	<beans:bean id="serviceimpl"
        		class="com.meridianp2p.stf.service.testservice.TestService"/>
        	
        	<beans:bean id="resource"
        		class="com.meridianp2p.stf.service.testservice.TestResource">
        		<beans:property name="requestChannel" ref="input"/>
        		<beans:property name="responseChannel" ref="responses"/>
        		<beans:property name="correlator" ref="correlator"/>
        	</beans:bean>
        It's working ok with the changes I've made to the ResponseCorrelator, but I don't see the point in having a response channel and a ResponseCorrelator to do only one thing.

        Other thing that worries me is the impact that all this will have when I change my intra-VM queues to JMS queues...

        Comment


        • #19
          Continuing my changes, I finished the synchronous-that-falls-down-to-asynchronous-with-correlationId-when-timedout message type, which I integrated in the RequestReplyTemplate. Now probably this is getting too complex and should be separated like suggested in Jira INT-143.

          I feel a little uncomfortable with this kind of configuration

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

          <endpoint input-channel="responses" handler-ref="correlator"/>
          but I don't know how to do it better.

          Anyhow I have to move to other implementations so I only be testing this furthermore in my "spare" time. If you want me to publish the code here I can clean it up a little, but probably there are better ways to do what I did.

          If I can be of assistance please let me know.

          Comment


          • #20
            Thanks so much for all of the feedback.

            I am thinking that the RequestReplyTemplate and ResponseCorrelator need to be encapsulated. It seems that all of this can be hidden inside a Messaging Gateway implementation (see http://eaipatterns.com/MessagingGateway.html). Something like the following would be used instead of your endpoint definitions:

            Code:
            <gateway id="serviceGateway"
                     input-channel="input"
                     handler="serviceimpl"
                     method="execute"
                     response-channel="responses"/>
            This might internally use RequestReplyTemplate and ResponseCorrelator, but the result would be a proxy for "serviceimpl" whose bean name is "serviceGateway".

            If an anonymous, temporary channel is sufficient, then the "response-channel" can be left out. Also, if the proxy should just implement MessageHandler, then the "method" should be left out.

            Your idea of falling back to async after a timeout is interesting and could probably be available as one strategy used by the gateway.

            Regards,
            Mark

            Comment


            • #21
              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:
              Code:
              <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:
              Code:
              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):
              Code:
              <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

              Comment


              • #22
                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.

                Comment


                • #23
                  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).

                  Comment


                  • #24
                    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

                    Comment


                    • #25
                      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.

                      Comment


                      • #26
                        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:

                        Originally posted by amsmota View Post
                        (...) 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.
                        Last edited by amsmota; May 26th, 2008, 06:00 AM.

                        Comment


                        • #27
                          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.

                          Comment

                          Working...
                          X