A lot of interest, and that is great. Jiri; Using Camel as Glue... I assume that you are hopeful that Camel will provide a lot of interfacing to many different external systems and we hook into a single interface somewhere/somehow. That is a possibility that I didn't think of, and worth-while discussing more. I think we even have two Camel experts on the PMC, James and Jeff, and I think Jeff volunteered to assist if needed, or?
Kent; The idea of seeing emitting Events as a side-effect is a very sharp observation. And, wouldn't that also suggest that we have not nailed the @SideEffect concept very well yet, since any side-effects originating from entities (i.e. a UnitOfWork) should be deferred until UoW.complete() ?? Really interesting... The 2 phase commit that you are eluding to, kind of already exist in the current EntityStoreSPI. The ES is called with a applyChanges() (i.e. prepare) on to which the commit() (or cancel()) is called, once all the participants are ready. NOW, I think we scrapped the previous implementation that allowed "per Entity type" segregation of EntityStores, due to complexity in configuring it for the user, but the fundamentals are practically there. The drop was simply pragmatic choice at that time, due to time constraints and other things were considered more important. Sandro; Thanks for reminding me of Actor model, which also led me to realize that the Java 8 Stream API is highly relevant as well Paul, and I didn't know that this is being extended into Java 9 (for sure?) with Flow. Since I have been doing reactive programming in Java since 1997, I am quite happy that it is being formalized at JDK level ;-) May I suggest that we keep pondering over the many possible directions, requirements, wishful thinking, and other crazy ideas on the topic, and we find a spot in Budapest and do a half day hackathon session on ideas of what could and could not work from a use-case point of view? Meanwhile, let's open a Jira ticket and just throw ideas, requirements, wishes, thoughts, concerns and so on at it. Mind you, I don't want us to create a new messaging system or even a new messaging paradigm, I simply want a way to plug such into our Composite system as naturally (for us) as possible. We have; a. ValueComposite with Property methods == superb data transfer objects, easily converted from Entities or to update Entities with. b. Full control of the invocation stack, in a relatively simple way. c. We have a Usecase and UnitOfWork concept, which should be leveraged. The UseCase allows any additional data to be "attached" to the UnitOfWork and picked up by whoever is interested, without passing the data in method calls. We should be able to create something great. Cheers On Wed, Jun 17, 2015 at 9:26 PM, Paul Merlin <[email protected]> wrote: > Hey, > > Sandro Martini a écrit : > > Hi all, > > sorry I still didn't have enough time to look at Zest internals ... > > > > But I think that current state of the art in messaging is Akka (both > > for Scala and Java): http://akka.io/ > > there is even an (unofficial dot Net porting). > > > > Or more generally, something in the Reactive Manifesto ( > > http://www.reactivemanifesto.org/ ) way of thinking, like ReactiveX ( > > http://reactivex.io/ ) and related n implementation language-specific, > > like RxJava ( https://github.com/ReactiveX/RxJava ) could be useful to > > integrate in Zest or use as a base ... > > > > > > I have some (basic) knowledge of Akka, so if useful, tell me ... > > > > Bye, > > Sandro > In the same vein, maybe we should turn our eyeballs towards > http://www.reactive-streams.org/ and the Doug Lea effort to add Flow to > Java 9 > http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/Flow.html > . > > Cheers > > /Paul > > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
