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:11:11 GMT
The issue is here; https://issues.apache.org/jira/browse/ZEST-32

I would be happy if everyone add their thoughts, ideas....

For Sandro and other new people, in this community, no ideas are crazy
enough to be discarded out of hand. Too often, we have seen, are such ideas
either directly useful, or has an ounce of "food for thought" to grow into
something useful.
Example; "Why is 'null' allowed in method arguments??" was a bizarre idea
at the time, but led to our rule that "No it is not allowed, unless marked
by the implementation"

On Wed, Jun 17, 2015 at 10:02 PM, Niclas Hedhman <niclas@hedhman.org> wrote:

> 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 <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

Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

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