Hi Bertrand,
You will find some updates in the branches/cameltrial.
It's now compliant with 0.0.9 and Camel/flow stuff has it's own endpoint
/flow.
All code is not so clean for now as I do this in train and pass more
time to fight with svn than anything...
Anyway, this first shot give some entries points to implement this in
Stanbol.
Some not fat documentation here [1].
Some comments on your script
* That's occur some nice things ! :)
* With the creation of generic Stanbol-Camel converters, predicate and
integration in stanbol simple groovy script will resume to only a
MyRoutebuilder class in most cases.
* About the camel context :
** That's were is defined all Camel endpoints and this endpoints can be
call inside this context. It's for example possible to create in context
A a route/flowGraph Mygraph that will be different a Mygraph route in
context B.
** So at a first version I think we have to propose only one context
started when /flow start and where all groovy route are added.
** After, we may can implement a /flow/context that will create, start,
stop others contexts if we need to.
* Integrated with stanbol sending the message sending can then be done
by /flow/{{flowGraphName}} endpoint.
Going a step further, as you can see in the actual /flow component, we
can call any registred engine in Stanbol via the engine:// protocol (for
example :
from("direct://input").to("o.a.s.engines.NER").to("o.a.s.engines.Tika")...).
We can easily also set up this protocols :
- chain:// : in order to process content item via Stanbol's defined chain
- store:// : in order retrieve and store enhancement from/to the store.
[1] :
https://svn.apache.org/repos/asf/incubator/stanbol/branches/cameltrial/README.md
++
On 06/14/2012 07:24 PM, Bertrand Delacretaz wrote:
Hi,
Following very interesting discussions in Salzburg, first with Henri about
flow-based programming, and then with Florent to find out that he had
already done something like that with Camel/Stanbol prototype [1], I have
created a proof of concept for dynamically assembling content enhancement
engines based on a Groovy script.
The resulting engine can also react dynamically to the intermediate results
provided by its various components, and adapt itself accordingly.
The commented code at https://gist.github.com/2931050 is really just a
proof of concept, it doesn't use any Stanbol components but simulates them
in a way that should help explain the idea.
Comments welcome!
-Bertrand
[1] http://svn.apache.org/repos/asf/incubator/stanbol/branches/cameltrial
