polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jiri Jetmar <juergen.jet...@gmail.com>
Subject Re: Messaging abstraction (for 3.0)
Date Thu, 18 Jun 2015 08:19:08 GMT
Hi Niclas,

yes, the idea (or the hope :-) ) to use Apache Camel as a integration
framework is the fact
that the guys behind camel had some time to practise how to define a
generic API
and how to integrate the underlying messaging framework and therefore we
can use it to accelerate
our efforts and not to start from scratch..

This might be naiv, but I would give it a try - at least from the
conceptual point of view.

Great that we have some Camel gurus here.. :-)

Cheers,
Jiri

2015-06-17 16:02 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:

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

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