I just pushed a new commit eb870cc944b8c6364edb41156b9148e95b7ea4ad to
the ode trunk, upgrading jacob from the old local implementation
ode-jacob to jacob-2.0-SNAPHOT which lives in a separate git repo after
the migration to git.
A few months ago Tammo and I explored some ideas of refactoring jacob to
make it simpler, possibly faster but most importantly easier to
understand. After some refactoring around Channels that removed the need
for generated Channel(s) and simplifying the ChannelListener
implementation, Tammo did some really cool stuff around serialization,
moving from java serialization to json, which is not only faster but
allows for a better understanding of the ingredients in the vpu soup.
Now it's time for more refactoring after the promising results of the
first round. The goal however is to implement all these changes in a way
that is not too disruptive to the rest of the ODE code base, hence the
commit referenced above. As the jacob refactoring moves on, we plan on
deploying timestamped snapshots and keep the ODE trunk in sync with the
last jacob snapshot. Most of the development will go on branches and
stable versions will be merged to trunk. We also discussed and hope to
release a 1.3.6 version soon.
That said, the jacob improvements ideas revolve around simplifying
usability and provide a simpler mapping for the pi calculus concepts
jacob implements.
The Continuation concept reflects the sequential execution of two
processes (P.Q). As they are executable, the JacobRunnable concept is
not really necessary, Runnable would suffice. Using java reflection via
Method.invoke is not necessary either if we make the convention that all
processes MUST be Runnable (which is the case already actually).
On the Channel side, we think that the interface is unnecessarily
flexible, which imposed the need of using dynamic proxies. The rationale
for that is a bit more complex and has its roots in various
interpretations of pi calculus and the desire of the initial authors to
provide a bridge to object oriented programming. That aside, restricting
the Channel interface to something like:
interface Channel {
void onMessage(Message message);
}
... eliminated the need for Proxies, but may be prone to errors due to
the loss of static typing. That could be addressed though via static
typing of Messages (kinda like the the Actor model does it in Akka or
Erlang). This change adds the fringe benefit of also supporting an event
sourcing style [1] of executing the reactions in the soup [1]. This is
something we'll investigate later.
Finally, the JacobObject concept is a bit of an odd design artifact, as
it semantically maps to the operations in pi calculus, not to object per
se. This is also something I will take a look later, but I expect the
JacobObjects to disappear, or be replaces with something simpler.
Another area I plan to investigate a bit later is a small DSL closer
aligned with pi calculus, hopefully easier to use and promoting better
understanding of process execution and reduction cycles.
Thougths highly appreciated,
Hadrian
--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/
