polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Messaging abstraction (for 3.0)
Date Wed, 17 Jun 2015 14:02:39 GMT
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

We should be able to create something great.


On Wed, Jun 17, 2015 at 9:26 PM, Paul Merlin <paul@nosphere.org> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message