You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Vassil Dichev <vd...@apache.org> on 2010/11/08 15:40:34 UTC
ESME and Akka
Folks,
For a while I've been thinking about integrating Akka
(http://akkasource.org/) into ESME. Akka is a library for concurrency,
fault-tolerance and remoting and actors are one of its most important
components. The advantages of using Akka are:
1. Easy remoting- it's trivial to make an actor remote
(http://doc.akkasource.org/remote-actors-java). This might help with
federation/clustering in the future.
2. Akka has nice Camel integration (http://doc.akkasource.org/camel).
Camel has a lot of endpoint components, which are conspicuously
similar in intent to our actions:
(http://camel.apache.org/components.html). If we replace our actions
with Camel components, we will have a ready DSL for dozens of actions
at little extra effort. For instance, XMPP support is supposed to
become trivial (at least at first glance).
The upside is that it should be fairly ealy to replace Lift actors
with Akka actors where (and if) needed. The downside is having another
library dependency- but we also won't need to implement and maintain
all the different action types.
What do you think? I will let you know how this idea matures and how
my research goes.
Vassil
Re: ESME and Akka
Posted by Vassil Dichev <vd...@apache.org>.
I have some of those questions as well. We will still use our old
actions though, because they are related with matching a message or
ESME events, which camel isn't aware of.
Vassil
On Mon, Jun 20, 2011 at 11:33 AM, Richard Hirsch <hi...@gmail.com> wrote:
> Our few ideas:
>
> * whether we just use the camel language for our actions
> (http://camel.apache.org/components.html)
> * Whether we restrict the camel components that are necessary
> * What about the old actions - what if they are duplicates to camel components
> * Do we just use akka camel integration in actions or at a deeper
> level as well.
> * There are camel components that read as well as write (camel-mail) -
> what do we with those?
>
> D.
>
> On Sun, Jun 19, 2011 at 7:20 PM, Vassil Dichev <vd...@apache.org> wrote:
>> For those who might not remember, I've had some ideas about using the
>> akka-camel module some time ago:
>>
>> http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/201011.mbox/%3CAANLkTi=viyR_WyazJVaF3WrnZ-G5VsPSof0VMB4wDbak@mail.gmail.com%3E
>>
>> It makes sense, since Camel provides solutions to various integration
>> scenarios, which is one of the use cases for ESME.
>>
>> I've also not been in a hurry XMPP using the Lift library, because if
>> we use the Akka route, we will get this for free.
>>
>> Let me take some time to think about how this can fit into ESME. If
>> there are no other major features planned for 1.4- why not?
>>
>> Cheers,
>> Vassil
>>
>>
>> On Sat, Jun 18, 2011 at 5:34 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>> @vassil - I just saw your tweet about camel, akka and esme. What
>>> about planning that feature for the 1.4 release? I've already pinged
>>> Vladimir about it as well. What about splitting the task between you
>>> two?
>>>
>>> We will be hopefully be finished with the 1.3 release soon and then we
>>> can start on the 1.4
>>>
>>> D.
>>>
>>> On Mon, Nov 8, 2010 at 4:59 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>> The question is actually very valid, since sending messages is only
>>>> part of the problem- the message handler needs to be implemented as
>>>> well as support for linking, etc.
>>>>
>>>> But yes, they're very compatible, since David Pollak and Jonas Boner
>>>> worked together on a common actor interface, so it should be purely
>>>> mechanical replacement (haven't tried to dig into details however)
>>>>
>>>>
>>>> On Mon, Nov 8, 2010 at 5:42 PM, Ethan Jewett <es...@gmail.com> wrote:
>>>>> +1
>>>>>
>>>>> Question: Are Lift actors and Akka actors compatible? So, for example, could
>>>>> we do this incrementally, replacing the Distributor with Akka actors first
>>>>> and then working out to the other actors?
>>>>>
>>>>> Ethan
>>>>>
>>>>> On Mon, Nov 8, 2010 at 3:40 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> For a while I've been thinking about integrating Akka
>>>>>> (http://akkasource.org/) into ESME. Akka is a library for concurrency,
>>>>>> fault-tolerance and remoting and actors are one of its most important
>>>>>> components. The advantages of using Akka are:
>>>>>>
>>>>>> 1. Easy remoting- it's trivial to make an actor remote
>>>>>> (http://doc.akkasource.org/remote-actors-java). This might help with
>>>>>> federation/clustering in the future.
>>>>>> 2. Akka has nice Camel integration (http://doc.akkasource.org/camel).
>>>>>> Camel has a lot of endpoint components, which are conspicuously
>>>>>> similar in intent to our actions:
>>>>>> (http://camel.apache.org/components.html). If we replace our actions
>>>>>> with Camel components, we will have a ready DSL for dozens of actions
>>>>>> at little extra effort. For instance, XMPP support is supposed to
>>>>>> become trivial (at least at first glance).
>>>>>>
>>>>>> The upside is that it should be fairly ealy to replace Lift actors
>>>>>> with Akka actors where (and if) needed. The downside is having another
>>>>>> library dependency- but we also won't need to implement and maintain
>>>>>> all the different action types.
>>>>>>
>>>>>> What do you think? I will let you know how this idea matures and how
>>>>>> my research goes.
>>>>>> Vassil
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Twitter: http://twitter.com/vdichev
>>>> Blog: http://speaking-my-language.blogspot.com
>>>>
>>>
>>
>
Re: ESME and Akka
Posted by Richard Hirsch <hi...@gmail.com>.
Our few ideas:
* whether we just use the camel language for our actions
(http://camel.apache.org/components.html)
* Whether we restrict the camel components that are necessary
* What about the old actions - what if they are duplicates to camel components
* Do we just use akka camel integration in actions or at a deeper
level as well.
* There are camel components that read as well as write (camel-mail) -
what do we with those?
D.
On Sun, Jun 19, 2011 at 7:20 PM, Vassil Dichev <vd...@apache.org> wrote:
> For those who might not remember, I've had some ideas about using the
> akka-camel module some time ago:
>
> http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/201011.mbox/%3CAANLkTi=viyR_WyazJVaF3WrnZ-G5VsPSof0VMB4wDbak@mail.gmail.com%3E
>
> It makes sense, since Camel provides solutions to various integration
> scenarios, which is one of the use cases for ESME.
>
> I've also not been in a hurry XMPP using the Lift library, because if
> we use the Akka route, we will get this for free.
>
> Let me take some time to think about how this can fit into ESME. If
> there are no other major features planned for 1.4- why not?
>
> Cheers,
> Vassil
>
>
> On Sat, Jun 18, 2011 at 5:34 PM, Richard Hirsch <hi...@gmail.com> wrote:
>> @vassil - I just saw your tweet about camel, akka and esme. What
>> about planning that feature for the 1.4 release? I've already pinged
>> Vladimir about it as well. What about splitting the task between you
>> two?
>>
>> We will be hopefully be finished with the 1.3 release soon and then we
>> can start on the 1.4
>>
>> D.
>>
>> On Mon, Nov 8, 2010 at 4:59 PM, Vassil Dichev <vd...@apache.org> wrote:
>>> The question is actually very valid, since sending messages is only
>>> part of the problem- the message handler needs to be implemented as
>>> well as support for linking, etc.
>>>
>>> But yes, they're very compatible, since David Pollak and Jonas Boner
>>> worked together on a common actor interface, so it should be purely
>>> mechanical replacement (haven't tried to dig into details however)
>>>
>>>
>>> On Mon, Nov 8, 2010 at 5:42 PM, Ethan Jewett <es...@gmail.com> wrote:
>>>> +1
>>>>
>>>> Question: Are Lift actors and Akka actors compatible? So, for example, could
>>>> we do this incrementally, replacing the Distributor with Akka actors first
>>>> and then working out to the other actors?
>>>>
>>>> Ethan
>>>>
>>>> On Mon, Nov 8, 2010 at 3:40 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>
>>>>> Folks,
>>>>>
>>>>> For a while I've been thinking about integrating Akka
>>>>> (http://akkasource.org/) into ESME. Akka is a library for concurrency,
>>>>> fault-tolerance and remoting and actors are one of its most important
>>>>> components. The advantages of using Akka are:
>>>>>
>>>>> 1. Easy remoting- it's trivial to make an actor remote
>>>>> (http://doc.akkasource.org/remote-actors-java). This might help with
>>>>> federation/clustering in the future.
>>>>> 2. Akka has nice Camel integration (http://doc.akkasource.org/camel).
>>>>> Camel has a lot of endpoint components, which are conspicuously
>>>>> similar in intent to our actions:
>>>>> (http://camel.apache.org/components.html). If we replace our actions
>>>>> with Camel components, we will have a ready DSL for dozens of actions
>>>>> at little extra effort. For instance, XMPP support is supposed to
>>>>> become trivial (at least at first glance).
>>>>>
>>>>> The upside is that it should be fairly ealy to replace Lift actors
>>>>> with Akka actors where (and if) needed. The downside is having another
>>>>> library dependency- but we also won't need to implement and maintain
>>>>> all the different action types.
>>>>>
>>>>> What do you think? I will let you know how this idea matures and how
>>>>> my research goes.
>>>>> Vassil
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Twitter: http://twitter.com/vdichev
>>> Blog: http://speaking-my-language.blogspot.com
>>>
>>
>
Re: ESME and Akka
Posted by Vassil Dichev <vd...@apache.org>.
For those who might not remember, I've had some ideas about using the
akka-camel module some time ago:
http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/201011.mbox/%3CAANLkTi=viyR_WyazJVaF3WrnZ-G5VsPSof0VMB4wDbak@mail.gmail.com%3E
It makes sense, since Camel provides solutions to various integration
scenarios, which is one of the use cases for ESME.
I've also not been in a hurry XMPP using the Lift library, because if
we use the Akka route, we will get this for free.
Let me take some time to think about how this can fit into ESME. If
there are no other major features planned for 1.4- why not?
Cheers,
Vassil
On Sat, Jun 18, 2011 at 5:34 PM, Richard Hirsch <hi...@gmail.com> wrote:
> @vassil - I just saw your tweet about camel, akka and esme. What
> about planning that feature for the 1.4 release? I've already pinged
> Vladimir about it as well. What about splitting the task between you
> two?
>
> We will be hopefully be finished with the 1.3 release soon and then we
> can start on the 1.4
>
> D.
>
> On Mon, Nov 8, 2010 at 4:59 PM, Vassil Dichev <vd...@apache.org> wrote:
>> The question is actually very valid, since sending messages is only
>> part of the problem- the message handler needs to be implemented as
>> well as support for linking, etc.
>>
>> But yes, they're very compatible, since David Pollak and Jonas Boner
>> worked together on a common actor interface, so it should be purely
>> mechanical replacement (haven't tried to dig into details however)
>>
>>
>> On Mon, Nov 8, 2010 at 5:42 PM, Ethan Jewett <es...@gmail.com> wrote:
>>> +1
>>>
>>> Question: Are Lift actors and Akka actors compatible? So, for example, could
>>> we do this incrementally, replacing the Distributor with Akka actors first
>>> and then working out to the other actors?
>>>
>>> Ethan
>>>
>>> On Mon, Nov 8, 2010 at 3:40 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>
>>>> Folks,
>>>>
>>>> For a while I've been thinking about integrating Akka
>>>> (http://akkasource.org/) into ESME. Akka is a library for concurrency,
>>>> fault-tolerance and remoting and actors are one of its most important
>>>> components. The advantages of using Akka are:
>>>>
>>>> 1. Easy remoting- it's trivial to make an actor remote
>>>> (http://doc.akkasource.org/remote-actors-java). This might help with
>>>> federation/clustering in the future.
>>>> 2. Akka has nice Camel integration (http://doc.akkasource.org/camel).
>>>> Camel has a lot of endpoint components, which are conspicuously
>>>> similar in intent to our actions:
>>>> (http://camel.apache.org/components.html). If we replace our actions
>>>> with Camel components, we will have a ready DSL for dozens of actions
>>>> at little extra effort. For instance, XMPP support is supposed to
>>>> become trivial (at least at first glance).
>>>>
>>>> The upside is that it should be fairly ealy to replace Lift actors
>>>> with Akka actors where (and if) needed. The downside is having another
>>>> library dependency- but we also won't need to implement and maintain
>>>> all the different action types.
>>>>
>>>> What do you think? I will let you know how this idea matures and how
>>>> my research goes.
>>>> Vassil
>>>>
>>>
>>
>>
>>
>> --
>> Twitter: http://twitter.com/vdichev
>> Blog: http://speaking-my-language.blogspot.com
>>
>
Re: ESME and Akka
Posted by Richard Hirsch <hi...@gmail.com>.
@vassil - I just saw your tweet about camel, akka and esme. What
about planning that feature for the 1.4 release? I've already pinged
Vladimir about it as well. What about splitting the task between you
two?
We will be hopefully be finished with the 1.3 release soon and then we
can start on the 1.4
D.
On Mon, Nov 8, 2010 at 4:59 PM, Vassil Dichev <vd...@apache.org> wrote:
> The question is actually very valid, since sending messages is only
> part of the problem- the message handler needs to be implemented as
> well as support for linking, etc.
>
> But yes, they're very compatible, since David Pollak and Jonas Boner
> worked together on a common actor interface, so it should be purely
> mechanical replacement (haven't tried to dig into details however)
>
>
> On Mon, Nov 8, 2010 at 5:42 PM, Ethan Jewett <es...@gmail.com> wrote:
>> +1
>>
>> Question: Are Lift actors and Akka actors compatible? So, for example, could
>> we do this incrementally, replacing the Distributor with Akka actors first
>> and then working out to the other actors?
>>
>> Ethan
>>
>> On Mon, Nov 8, 2010 at 3:40 PM, Vassil Dichev <vd...@apache.org> wrote:
>>
>>> Folks,
>>>
>>> For a while I've been thinking about integrating Akka
>>> (http://akkasource.org/) into ESME. Akka is a library for concurrency,
>>> fault-tolerance and remoting and actors are one of its most important
>>> components. The advantages of using Akka are:
>>>
>>> 1. Easy remoting- it's trivial to make an actor remote
>>> (http://doc.akkasource.org/remote-actors-java). This might help with
>>> federation/clustering in the future.
>>> 2. Akka has nice Camel integration (http://doc.akkasource.org/camel).
>>> Camel has a lot of endpoint components, which are conspicuously
>>> similar in intent to our actions:
>>> (http://camel.apache.org/components.html). If we replace our actions
>>> with Camel components, we will have a ready DSL for dozens of actions
>>> at little extra effort. For instance, XMPP support is supposed to
>>> become trivial (at least at first glance).
>>>
>>> The upside is that it should be fairly ealy to replace Lift actors
>>> with Akka actors where (and if) needed. The downside is having another
>>> library dependency- but we also won't need to implement and maintain
>>> all the different action types.
>>>
>>> What do you think? I will let you know how this idea matures and how
>>> my research goes.
>>> Vassil
>>>
>>
>
>
>
> --
> Twitter: http://twitter.com/vdichev
> Blog: http://speaking-my-language.blogspot.com
>
Re: ESME and Akka
Posted by Vassil Dichev <vd...@apache.org>.
The question is actually very valid, since sending messages is only
part of the problem- the message handler needs to be implemented as
well as support for linking, etc.
But yes, they're very compatible, since David Pollak and Jonas Boner
worked together on a common actor interface, so it should be purely
mechanical replacement (haven't tried to dig into details however)
On Mon, Nov 8, 2010 at 5:42 PM, Ethan Jewett <es...@gmail.com> wrote:
> +1
>
> Question: Are Lift actors and Akka actors compatible? So, for example, could
> we do this incrementally, replacing the Distributor with Akka actors first
> and then working out to the other actors?
>
> Ethan
>
> On Mon, Nov 8, 2010 at 3:40 PM, Vassil Dichev <vd...@apache.org> wrote:
>
>> Folks,
>>
>> For a while I've been thinking about integrating Akka
>> (http://akkasource.org/) into ESME. Akka is a library for concurrency,
>> fault-tolerance and remoting and actors are one of its most important
>> components. The advantages of using Akka are:
>>
>> 1. Easy remoting- it's trivial to make an actor remote
>> (http://doc.akkasource.org/remote-actors-java). This might help with
>> federation/clustering in the future.
>> 2. Akka has nice Camel integration (http://doc.akkasource.org/camel).
>> Camel has a lot of endpoint components, which are conspicuously
>> similar in intent to our actions:
>> (http://camel.apache.org/components.html). If we replace our actions
>> with Camel components, we will have a ready DSL for dozens of actions
>> at little extra effort. For instance, XMPP support is supposed to
>> become trivial (at least at first glance).
>>
>> The upside is that it should be fairly ealy to replace Lift actors
>> with Akka actors where (and if) needed. The downside is having another
>> library dependency- but we also won't need to implement and maintain
>> all the different action types.
>>
>> What do you think? I will let you know how this idea matures and how
>> my research goes.
>> Vassil
>>
>
--
Twitter: http://twitter.com/vdichev
Blog: http://speaking-my-language.blogspot.com
Re: ESME and Akka
Posted by Ethan Jewett <es...@gmail.com>.
Thanks. And I just realized that my question was kinda dumb. Of course they
are compatible, since you would send a message to an Akka actor using that
actor's sending methods, and vice versa for Lift Actors. Sorry ...
Ethan
On Mon, Nov 8, 2010 at 4:45 PM, Richard Hirsch <hi...@gmail.com>wrote:
> @Ethan - look here http://doc.akkasource.org/lift-integration
>
> On Mon, Nov 8, 2010 at 4:42 PM, Ethan Jewett <es...@gmail.com> wrote:
> > +1
> >
> > Question: Are Lift actors and Akka actors compatible? So, for example,
> could
> > we do this incrementally, replacing the Distributor with Akka actors
> first
> > and then working out to the other actors?
> >
> > Ethan
> >
> > On Mon, Nov 8, 2010 at 3:40 PM, Vassil Dichev <vd...@apache.org>
> wrote:
> >
> >> Folks,
> >>
> >> For a while I've been thinking about integrating Akka
> >> (http://akkasource.org/) into ESME. Akka is a library for concurrency,
> >> fault-tolerance and remoting and actors are one of its most important
> >> components. The advantages of using Akka are:
> >>
> >> 1. Easy remoting- it's trivial to make an actor remote
> >> (http://doc.akkasource.org/remote-actors-java). This might help with
> >> federation/clustering in the future.
> >> 2. Akka has nice Camel integration (http://doc.akkasource.org/camel).
> >> Camel has a lot of endpoint components, which are conspicuously
> >> similar in intent to our actions:
> >> (http://camel.apache.org/components.html). If we replace our actions
> >> with Camel components, we will have a ready DSL for dozens of actions
> >> at little extra effort. For instance, XMPP support is supposed to
> >> become trivial (at least at first glance).
> >>
> >> The upside is that it should be fairly ealy to replace Lift actors
> >> with Akka actors where (and if) needed. The downside is having another
> >> library dependency- but we also won't need to implement and maintain
> >> all the different action types.
> >>
> >> What do you think? I will let you know how this idea matures and how
> >> my research goes.
> >> Vassil
> >>
> >
>
Re: ESME and Akka
Posted by Richard Hirsch <hi...@gmail.com>.
@Ethan - look here http://doc.akkasource.org/lift-integration
On Mon, Nov 8, 2010 at 4:42 PM, Ethan Jewett <es...@gmail.com> wrote:
> +1
>
> Question: Are Lift actors and Akka actors compatible? So, for example, could
> we do this incrementally, replacing the Distributor with Akka actors first
> and then working out to the other actors?
>
> Ethan
>
> On Mon, Nov 8, 2010 at 3:40 PM, Vassil Dichev <vd...@apache.org> wrote:
>
>> Folks,
>>
>> For a while I've been thinking about integrating Akka
>> (http://akkasource.org/) into ESME. Akka is a library for concurrency,
>> fault-tolerance and remoting and actors are one of its most important
>> components. The advantages of using Akka are:
>>
>> 1. Easy remoting- it's trivial to make an actor remote
>> (http://doc.akkasource.org/remote-actors-java). This might help with
>> federation/clustering in the future.
>> 2. Akka has nice Camel integration (http://doc.akkasource.org/camel).
>> Camel has a lot of endpoint components, which are conspicuously
>> similar in intent to our actions:
>> (http://camel.apache.org/components.html). If we replace our actions
>> with Camel components, we will have a ready DSL for dozens of actions
>> at little extra effort. For instance, XMPP support is supposed to
>> become trivial (at least at first glance).
>>
>> The upside is that it should be fairly ealy to replace Lift actors
>> with Akka actors where (and if) needed. The downside is having another
>> library dependency- but we also won't need to implement and maintain
>> all the different action types.
>>
>> What do you think? I will let you know how this idea matures and how
>> my research goes.
>> Vassil
>>
>
Re: ESME and Akka
Posted by Ethan Jewett <es...@gmail.com>.
+1
Question: Are Lift actors and Akka actors compatible? So, for example, could
we do this incrementally, replacing the Distributor with Akka actors first
and then working out to the other actors?
Ethan
On Mon, Nov 8, 2010 at 3:40 PM, Vassil Dichev <vd...@apache.org> wrote:
> Folks,
>
> For a while I've been thinking about integrating Akka
> (http://akkasource.org/) into ESME. Akka is a library for concurrency,
> fault-tolerance and remoting and actors are one of its most important
> components. The advantages of using Akka are:
>
> 1. Easy remoting- it's trivial to make an actor remote
> (http://doc.akkasource.org/remote-actors-java). This might help with
> federation/clustering in the future.
> 2. Akka has nice Camel integration (http://doc.akkasource.org/camel).
> Camel has a lot of endpoint components, which are conspicuously
> similar in intent to our actions:
> (http://camel.apache.org/components.html). If we replace our actions
> with Camel components, we will have a ready DSL for dozens of actions
> at little extra effort. For instance, XMPP support is supposed to
> become trivial (at least at first glance).
>
> The upside is that it should be fairly ealy to replace Lift actors
> with Akka actors where (and if) needed. The downside is having another
> library dependency- but we also won't need to implement and maintain
> all the different action types.
>
> What do you think? I will let you know how this idea matures and how
> my research goes.
> Vassil
>
Re: ESME and Akka
Posted by Richard Hirsch <hi...@gmail.com>.
On Mon, Nov 8, 2010 at 3:40 PM, Vassil Dichev <vd...@apache.org> wrote:
> Folks,
>
> For a while I've been thinking about integrating Akka
> (http://akkasource.org/) into ESME. Akka is a library for concurrency,
> fault-tolerance and remoting and actors are one of its most important
> components. The advantages of using Akka are:
>
> 1. Easy remoting- it's trivial to make an actor remote
> (http://doc.akkasource.org/remote-actors-java). This might help with
> federation/clustering in the future.
Cool - as you well know the lift community is also looking into Akka.
> 2. Akka has nice Camel integration (http://doc.akkasource.org/camel).
> Camel has a lot of endpoint components, which are conspicuously
> similar in intent to our actions:
> (http://camel.apache.org/components.html). If we replace our actions
> with Camel components, we will have a ready DSL for dozens of actions
> at little extra effort. For instance, XMPP support is supposed to
> become trivial (at least at first glance).
Even cooler - would solve lots of problems and give us an amazing
amount of interaction possibilities. Like the heavy enterprise focus
as well with spring, AMQP, jdbc, etc. How fatal would the
refactoring be? Could we still have our own actions that are
esme-specific?
>
> The upside is that it should be fairly ealy to replace Lift actors
> with Akka actors where (and if) needed. The downside is having another
> library dependency- but we also won't need to implement and maintain
> all the different action types.
Another dependency with an apache project really isn't problem.
>
> What do you think? I will let you know how this idea matures and how
> my research goes.
> Vassil
>