My name is Rickard.Lundin from sweden, and just came across your page.
Sorry for writing this lengthy msg :-) I understand if you don't have time to read it.
I have an idea of extending JFBP to spread out to 1 -100000 machines across the internet , using suns JXTA api (that does tunneling and other infrastructure needed for an internet-application)
The "C++ THREAD" seems to be able to handle multiple machines/ip, but I have not been able to find any thing alike for the JFBP (in the java code or docs).
I have an little project http://aortas.sourceforge.net , that can execute Tasklets (small mobile programs, or simply tail-recursion over the LAN)
I'm currently internet-extending Aorta both with suns JXTA (xml centric) http://www.jxta.org/ and also an non xml api , called xeq-tunnel http://www.xeq.se/xeqtunnel
Jxta and xeq are two different ways of internet-extending a LAN application. xeq-tunneling gives seamless JVM-2-JVM function calls.
I came across your JFBP project while searching for "Dataflow & pararell DNA alignment algoritms" , and my first idea was to allow Aorta handle the dataflow paradigm , but , why should I reinvent the wheel , if JBFP already exists. One alternative would be to use Aorta-Jxta to spread out "components" across the internet.
What do I need Dataflow for ?
1) DNA alignement algoritms can be pararellized more easily using dataflow paradigm according to http://portal.acm.org/citation.cfm?doid=76263.76296#FullText
2) I have an old mips2000 simulator , written in c and in dataflow similar way. Would be extremly fun to have it spread out over multiple machines dataflow-wize.
Hi, Rickard. Fascinating concept! JXTA certainly looks like a good match with JFBP, and I believe your idea of having thousands of machines collaborating on this kind of processing job would give us more processing power than the biggest number-crunchers yet built :-) And DNA analysis is fascinating in its own right!
If we could "hide" JXTA API in JFBP components, then we have the potential to easily move components anywhere in the entire network. Amanda has speculated about self-modifying networks - that would be a natural extension of this idea, but demonstrating JFBP talking to JXTA would be a good first step. In an earlier main-frame implementation of FBP I successfully demonstrated multiple virtual machines talking to each other - worked fine! And you separate the I/O-type logic into separate components, so it doesn't clutter up the real application code.
Last comment - how can I help?
Thanks for your positive reply :-) Most helpful.
I will take a look at the JFBP sourcecode and give a detailed reply. The main idea is to use jxta/xeq/Aorta as an infrastructure and not clutter up existing application code at all. In the end JFBP could be extended with a "few" classes and/or JFBP dataflow applications could run over internet using Aorta. Well , it works both ways :-)
My current "time plan" are.
0) look at JFBP code.
1) Refactor Aorta to be able to spread "Components" in LAN.
2) Add/Extend JFBP to handle jvm-2-jvm connections.
3) When 1) and 2) works we have a LAN version of JFBP.
Later on scaling from LAN to internet I first intend to use xeq-tunneling (which is straightforward) and later on JXTA. JXTA from Sun will become Grand-duke of internet-collaboration api, I hope.
Jxta is still a vision , since Sun hasn't implemented it 100% yet. Xeq-tunnel works very well but are only for "function tunneling" ,which will do for a start.
Sounds like an excellent plan! Pease let me know if you have any questions.
I have a web page describing the syntax of a JFBP network definition which you may find helpful: http://jpaulmorrison.com/fbp/syntax.htm
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.