Announcement Announcement Module
Collapse
No announcement yet.
Need some direction on publish-subscribe Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Need some direction on publish-subscribe

    I've been dabbling with Spring Integration for a few days now and I'm at a fork in the road on coming up with the right solution. There's so many different rabbit trails I could go down, I'm wondering if someone can point me to the right set of components I need.

    I've got an http inbound gateway that takes a Message<Event> in. Depending on the eventType in the Event header, a router routes the message to a particular handler. The handlers now are just logging messages based on the type to make certain its in the right handler. What I'd now like to do now is morph this into a publish subscribe scenario. I've been through a lot of the Spring Integration examples, but none that I have found is doing something similar to what I'm wanting to do.

    What I'd like to do is send in a subscription Message<Event> on the same http inbound gateway that would check some channel for Message<Events> that have been published (i.e queued up) and respond back with those messages to the subscription request. I'm not sure if that's one Event at a time or if I can stack all events for that subscriber. I believe this is similar to long-polling and I've seen some partial examples, but I'm needing a clearer picture.

    Seems that Spring Integration will do most anything, I just can't put my finger on all the components I need to solve this issue.

  • #2
    If I understand you correctly, you need a service (POJO) with two methods.

    The first method would receive the events and store them (either in memory or persisted). The second method gets the other request type and returns the collection of events.

    If the events are persisted, you wouldn't have to write any code at all; you could use, for example a couple of JDBC outbound adapters to store and retrieve the events.

    Comment


    • #3
      Thanks for the prompt response. So assuming that I don't have a database attached to this Integration Server lets assume that we'll persist in memory. So from my you're thinking that my Handlers would reference this service (POJO) that would invoke the publish events and store them in something like a HashMap. Then on a subsequent request (i.e. subscribe), it would eventually route to some handler that would look up the events that it might be interested in.

      Does it have to be a service or could it be a component? I'm just not seeing that it needs to be a service if it sits behind all the Spring Integration router.

      I'm wondering if there things like Filters that I should be taking advantage of. By using my own service I think it would require me walking through all persisted events to see if they match my subscription criteria?

      Just to confirm, there's no channel or queue that will hold these events for me that I should be using. I should be implementing my own persistence mechanism to hold the events.

      Comment


      • #4
        The reason I said service was just that you'd likely invoke the methods using <service-activator/>s...
        Code:
        <service-activator input-channel="foo ref="myPojo" method="storeEvent"/>
        
        <service-activator input-channel="bar" ref="myPojo" method="getEvents"/>
        We do have a message store (e.g. the SimpleMessageStore implementation) that might be of help, it stores messages in arbitrary groups. But, if one event is of interest to more than one subscriber, it's not clear to me how you can avoid walking the events, unless you use several maps.

        Comment


        • #5
          I can store the events fine, but it doesn't seem to fit my scenario for providing the same event to all subscribes of that event. I've been doing some reading on long-polling and is there a way to combine the DeferredResult with Spring MVC with Spring Integration? Could I get away with using using the DeferredResult with the http inbound gateway? Seems like a stretch, but not sure if that's even possible mixing the two technologies.

          Basically I'd have one gateway that's responsible for publishing the messages (i.e. events) and then another request perhaps on the same gateway or a specific one just for subscriptions that would use a DeferredResult to pick up events as the land on say a publish-subscribe channel.

          A sample configuration of how this may work would be greatly appreciated.
          Last edited by dghighfill; Aug 16th, 2013, 01:46 PM.

          Comment


          • #6
            There's some work going on in Spring 4 to support the kind of scenario you need...

            http://blog.springsource.org/2013/07...architectures/

            Comment


            • #7
              Thanks for the response. So if I was to conclude, Spring Integration today (release 3.x) doesn't give me a way to do this all through configuration and its components. It sounds like the best way may still be to use my http inbound gateway to persists the messages to a store, then have a Spring MVC application that sends in the subscribe request to read the persistent store. This could take advantage of the DeferredResult for sending back events that are in the store. The other option would be to wait until Spring 4.0 release, which I thought I found was September 6th.
              Last edited by dghighfill; Aug 21st, 2013, 10:49 AM.

              Comment


              • #8
                Still trying to confirm the best way to use the DeferredResult. Spring 4.0 isn't an option for us. So my question is, with the http:inbound-gateway is there a way to use a DeferredResult. Most things I see with DeferredResult are a @ResponseBody, but Spring Integration is going to want a Message<T>. Or am I better of developing a separate MVC app that uses the DeferredResult to return the events.

                Comment


                • #9
                  No; you can't use DeferredResult with the http gateway.

                  Comment


                  • #10
                    Thanks for the confirmation. One last question. I'm concerned about sharing the events across the servlet container with a Spring Integration channels that stores the Events and then an MVC app that reads the stored events. Should I just make all http requests (i.e. both publish and subscribe) an MVC app and then take the inbound Event XML after its unmarshalled and then put in on a Message channel for Spring Integration to managing the routing of it to the correct channel? So basically I'd lose the http:inbound-gateways all together and just have Request mappings for the publish and subscriptions of the events, but internally, I'd put the Events on channels that need to be routed elsewhere.

                    See any concerns with this? Again thanks for your quick replies.

                    Comment


                    • #11
                      There's no reason your MVC @Controller can't be in the same servlet context as the http adapter.

                      Comment

                      Working...
                      X