Pivot
  1. Pivot
  2. PIVOT-851

Verify if move to a more reactive approach for event propagation and loose coupling between components

    Details

      Description

      Verify if move to a more reactive approach for event propagation and loose coupling between components.

      For example, verify (for what it's possible in Java, without a full rewrite in Scala)
      http://www.scala-lang.org/sites/default/files/sids/imaier/Mon,%202009-11-02,%2008:55/scala-swing-design.pdf
      http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf

      http://stackoverflow.com/questions/3755453/scala-listener-observer
      http://stackoverflow.com/questions/3084546/design-patterns-for-functional-oo-hybrid-languages

      An innovative frameworks like Play have chosen for its new major release (2.0, released in March 2012) to do a full rewrite in Scala BUT with full compatibility even with Java (and Java 8 should have the same features too ...).
      Last, another interesting point to explore (but again mainly for Scala, or using Akka even from Java) could be to use Actors (local and/or remote), even for events ... just as idea.

      Many other interesting ideas for a more "complete" approach to make applications from Eclise E4 (extension points, mapping controllers to URLs, etc), for example some info here:
      http://www.vogella.com/articles/Eclipse4RCP/article.html
      and of course even from Griffon (in from the Groovy side).

      At the moment this issue is only a pleceholder to share in the same place ideas and links on this subject ... so as always comments are welcome.

        Issue Links

          Activity

          Show
          Sandro Martini added a comment - Other very interesting ideas: http://debasishg.blogspot.it/2011/01/cqrs-with-akka-actors-and-functional.html http://debasishg.blogspot.it/2012/01/event-sourcing-akka-fsms-and-functional.html
          Hide
          Sandro Martini added a comment - - edited

          Some related readings (on Event Sourcing), as a starting point (even without the need to rewrite in a different language):

          http://martinfowler.com/eaaDev/EventSourcing.html

          http://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/
          http://blog.zilverline.com/2012/07/04/simple-event-sourcing-introduction-part-1/
          http://lostechies.com/jimmybogard/2011/10/11/event-sourcing-as-a-strategic-advantage/
          http://julienletrouit.com/?cat=4

          Others, more specific to Scala features (for example using Actors):
          http://jonasboner.com/2009/02/12/event-sourcing-using-actors/
          http://debasishg.blogspot.it/2009/02/retroactive-event-processing-with-scala.html

          Generally speaking, using Event Sourcing approach we could have (more) loose coupled components, and probably a simpler approach than Listeners, but of course we have to check at performances, and more important the ability at compile time to discover problems, etc ...

          Note that the Event Store could be pluggable (and by default not persistent), other implementations could use remote storage or even local (maybe with a NoSQL storage) ... and we could process events in a parallel way, etc ...

          In this way for example we could have a simple way to record/playback application events, useful in customer support, and probably even in debug (and in unit tests) for developers.

          Of course this could handle not only GUI Events, but maybe even other kind of events.

          But all this at the moment is only to get some more idea on if / what to do ...

          Show
          Sandro Martini added a comment - - edited Some related readings (on Event Sourcing), as a starting point (even without the need to rewrite in a different language): http://martinfowler.com/eaaDev/EventSourcing.html http://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/ http://blog.zilverline.com/2012/07/04/simple-event-sourcing-introduction-part-1/ http://lostechies.com/jimmybogard/2011/10/11/event-sourcing-as-a-strategic-advantage/ http://julienletrouit.com/?cat=4 Others, more specific to Scala features (for example using Actors): http://jonasboner.com/2009/02/12/event-sourcing-using-actors/ http://debasishg.blogspot.it/2009/02/retroactive-event-processing-with-scala.html Generally speaking, using Event Sourcing approach we could have (more) loose coupled components, and probably a simpler approach than Listeners, but of course we have to check at performances, and more important the ability at compile time to discover problems, etc ... Note that the Event Store could be pluggable (and by default not persistent), other implementations could use remote storage or even local (maybe with a NoSQL storage) ... and we could process events in a parallel way, etc ... In this way for example we could have a simple way to record/playback application events, useful in customer support, and probably even in debug (and in unit tests) for developers. Of course this could handle not only GUI Events, but maybe even other kind of events. But all this at the moment is only to get some more idea on if / what to do ...
          Hide
          Sandro Martini added a comment - - edited

          Other great article on this: http://jim-mcbeath.blogspot.it/2009/10/simple-publishsubscribe-example-in.html

          And a paper, from Scala people: http://infoscience.epfl.ch/record/176887 , with a link inside to the updated pdf paper (in 2012)
          and the original (older) version: http://lampwww.epfl.ch%2F~imaier%2Fpub%2FDeprecatingObserversTR2010.pdf , for a more better approach, using reactive concepts ...

          Show
          Sandro Martini added a comment - - edited Other great article on this: http://jim-mcbeath.blogspot.it/2009/10/simple-publishsubscribe-example-in.html And a paper, from Scala people: http://infoscience.epfl.ch/record/176887 , with a link inside to the updated pdf paper (in 2012) and the original (older) version: http://lampwww.epfl.ch%2F~imaier%2Fpub%2FDeprecatingObserversTR2010.pdf , for a more better approach, using reactive concepts ...
          Hide
          Sandro Martini added a comment -

          An interesting article on pub/sub in JavaScript (inside the browser): "Going Postal with postal.js", from here: http://sett.ociweb.com/sett/settJun2012.html

          It explains some interesting tricks (implemented in postal.js) on Channels and Topics, and on subscriptions, like no duplication of events, filtering, throttle, delay, timeout on publishing events, etc ...
          Verify even the idea to publish events (but already serialized in json strings) ... maybe as an alternative.

          Show
          Sandro Martini added a comment - An interesting article on pub/sub in JavaScript (inside the browser): "Going Postal with postal.js", from here: http://sett.ociweb.com/sett/settJun2012.html It explains some interesting tricks (implemented in postal.js) on Channels and Topics, and on subscriptions, like no duplication of events, filtering, throttle, delay, timeout on publishing events, etc ... Verify even the idea to publish events (but already serialized in json strings) ... maybe as an alternative.
          Hide
          Sandro Martini added a comment - - edited

          This could be the foundation for the reactive infrastructure that we could use: https://github.com/Netflix/RxJava
          It has an Apache License so there should not be problem in using it, and it support many languages (in the JVM) and JavaScript, etc.
          Some info from here: https://github.com/Netflix/RxJava/wiki

          A (really useful and complete) article here: https://gist.github.com/staltz/868e7e9bc2a7b8c1f754

          A real world example: http://blog.couchbase.com/why-couchbase-chose-rxjava-new-java-sdk

          Show
          Sandro Martini added a comment - - edited This could be the foundation for the reactive infrastructure that we could use: https://github.com/Netflix/RxJava It has an Apache License so there should not be problem in using it, and it support many languages (in the JVM) and JavaScript, etc. Some info from here: https://github.com/Netflix/RxJava/wiki A (really useful and complete) article here: https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 A real world example: http://blog.couchbase.com/why-couchbase-chose-rxjava-new-java-sdk
          Hide
          Sandro Martini added a comment - - edited

          Our collections should be improved to better support functional programming (FP) abstractions (prefer, immutability, handle functions as arguments for what is possible before Java 8, etc).

          But try to add changes in a SAM compatible way, for simpler/better interoperability with Java 8.
          For some info, look here:
          http://zeroturnaround.com/rebellabs/java-8-the-first-taste-of-lambdas/
          http://stackoverflow.com/questions/17913409/what-is-a-sam-type-in-java

          Show
          Sandro Martini added a comment - - edited Our collections should be improved to better support functional programming (FP) abstractions (prefer, immutability, handle functions as arguments for what is possible before Java 8, etc). But try to add changes in a SAM compatible way, for simpler/better interoperability with Java 8. For some info, look here: http://zeroturnaround.com/rebellabs/java-8-the-first-taste-of-lambdas/ http://stackoverflow.com/questions/17913409/what-is-a-sam-type-in-java
          Hide
          Sandro Martini added a comment -

          Some reference:
          ReactiveJava: https://github.com/ReactiveX/RxJava
          Akka (for Java or for Scala): http://akka.io/

          RxJava could be a better candidate (more Java oriented, and for local usage) as backend for internal event/messaging, anyway we are free to explore all solutions.

          Show
          Sandro Martini added a comment - Some reference: ReactiveJava: https://github.com/ReactiveX/RxJava Akka (for Java or for Scala): http://akka.io/ RxJava could be a better candidate (more Java oriented, and for local usage) as backend for internal event/messaging, anyway we are free to explore all solutions.

            People

            • Assignee:
              Sandro Martini
              Reporter:
              Sandro Martini
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development