8 Replies Latest reply on Jul 21, 2011 12:40 AM by bleathem

    Ajax push of CDI events directly, with no JMS requirement

    bleathem

      Jira issue: RF-11110 - Ajax push of CDI events directly, with no JMS requirement

       

      Currently CDI push integration is in the works, delegating to JMS in the back end.  Hopwever I would like to see CDI events pushed directly to the browser, without any requirement for JMS.  I think this would be a great feature for RichFaces, greatly lowering the barrier to using push technology in a JSF application.

       

      Ideally we would leverage what we can from the Errai project. Discussion with Mike Brock is required to determine the feasibility of leveraging errai.

       

      I'm curious to hear feedback if anyone else would be excited to see this?  What are your thoughts on how this would fit with the current push implementation in RichFaces?

        • 1. Re: Ajax push of CDI events directly, with no JMS requirement
          cbrock

          It has been my understanding that Errai would satify this requirement directly. We have spoken about making Errai's bus la standalone JS library using something like gwt-exporter to allow our technology to be used outside of GWT.

          • 2. Re: Ajax push of CDI events directly, with no JMS requirement
            bleathem

            Thanks for the reply Miie,

             

            Is this something that's been talked about before?  Is there work that has to be done on the Errai side to make this possible?  What is the current state of this eefort?

             

            Cheers,

            Brian

            • 3. Re: Ajax push of CDI events directly, with no JMS requirement
              cbrock

              Yes, it has been discussed before. Jay and I specifically have talked about it, and a stand-alone JS library is something we're looking at after we get Errai 1.3 out.

              • 4. Re: Ajax push of CDI events directly, with no JMS requirement
                lfryc

                Integration with CDI is one thing, second thing is managing asynchronous nature of message delivery.

                When you fire a message by CDI, you can't know if your client is actually channeled to server, so you need to store it.

                You also can't be sure that your client is connected to same server, so you need to cluster it.

                And there is where JMS plays its part.

                 

                We need surely discuss alternatives to JMS in terms of message delivery.

                Errai could be one of choices (I haven't dive deeper into that yet).

                 

                But employing Errai, we are leaving the simple push mechanism and working on bidirectional message delivery.

                And there is where we should be aware, since we are actually leaving the space of standard JSF communication with all the consequences (like concurrency control, standard validation).

                • 5. Re: Ajax push of CDI events directly, with no JMS requirement
                  bleathem

                  In terms of the frgaility w.r.t. browser connectivity:

                  JMS gurantees delivery of the message as far as the MDB.  But once it's there, the MDB communicates with the browser.  I would have thought this segment of the communication would then be fragile,  dependening on whether or not the browser is connected.  Anything else would require bi-directional communication between the MDB and the browser as you described.  Is this a correct understanding of of the JMS-based JAJAX push currently works?

                   

                  In terms of clustering:

                  Indeed JMS provides a good solution here.  Perhaps Errai has a solution here, but if not, we can always recommend people use the JMS push in clusetered environments, and only use CDI push in standalone environments.  We just have to make the API such that switching between the two is seamless.

                  • 6. Re: Ajax push of CDI events directly, with no JMS requirement
                    lfryc

                    Brian Leathem wrote:

                     

                    In terms of the frgaility w.r.t. browser connectivity:

                    JMS gurantees delivery of the message as far as the MDB.  But once it's there, the MDB communicates with the browser.  I would have thought this segment of the communication would then be fragile,  dependening on whether or not the browser is connected.  Anything else would require bi-directional communication between the MDB and the browser as you described.  Is this a correct understanding of of the JMS-based JAJAX push currently works?

                    I was wrong here - Push currently doesn't guarantee delivery, since it is using Topics, and neither it guarantees delivery to the specific client.

                    But I think this is one of use-cases we should surely cover.

                     

                    After refactoring in 4.1 by Nick, Push is working with own internal message queue, listening on JMS for messages.

                     

                    So for the support of CDI it would be necessary to:

                     

                    1) make consuming JMS messages optional

                    2) create CDI event observer internally using Topic$publish(TopicKey, Object messageData) as it is currently in Showcase

                    • 7. Re: Ajax push of CDI events directly, with no JMS requirement
                      lfryc

                      With my latest modifications, first point to make JMS messages optional is in place, see https://issues.jboss.org/browse/RF-11135

                      • 8. Re: Ajax push of CDI events directly, with no JMS requirement
                        bleathem

                        Exciting stuff! Great job Lukas!