((re-sending a yesterday mail that not spot on the list... may you get
finally twice))
Hi Antonio !
Thanks for this first description.
As first big overview of a work plan, I will say :
=== 1) find a name for this feature ===
As a first step I think we have to find a clear and stable name for this
new feature (as we used many until now) :
1) enhancements route
2) Enhancement Workflows
3) flow graphs :
4) ...others...
To my opinion :
1) that use terms of both project Stanbol and Camel, and that's good
2) Is there enough clear difference with chains that already exists ?
And this name don't show the ability to put and publish from other
source IMO
3) show well the configuration opportunities but not the input/output
possibilities
4)
* Entreprise Semantic Integration (referring to Entreprise Integration
Patern)
* Semantic Bus ("Bus" frequently used in camel)
=== 2) defining a set of concrete use-cases ===
2 ou 3 concrete uses cases that use the input/output possibilities and
enhancement flow configurations.
A raw template for this use case definitions :
Fetch from : local folder / rss / mail / ...
Enhance with engine 1
Depending on the result of this engine go to :
* Chain 1
* or to Chain 2 and 3 and merge results
Output the result to : email / ftp / ...
=== 3) Defining and Implementing protocols ===
One of the big strength of Camel is the ability to define in house protocol.
When working on the first version of the code, I really like the idea of
getting a :
engine://
chain://
store://
protocols.
With that we can use the Stanbol's capabilities throw camel without
touch Stanbol api.
=== 4) Defining and implementing some DataFormat ===
With the pluggable DataFormat (http://camel.apache.org/data-format.html)
principle, Camel allow automatic, transparent for the user,
transformation of major data type to java structure or another data type
depending on the input requested by the transformator.
For example a file in input can be used as a input stream in a
transformator 1, and processed as a List<String> in T2...
Set up some basic DataFormat transformator can be a great gain.
We can think of for example :
text <-> content Item
rdf <-> content item metadata
content item <-> html
...
It's seems me to remember set-up a really basic one dataFormat during my
first integration experience..
=== 5) defining and implementing easy routing definition ===
In my first version of code, adding a new route require to build a
bundle and add it to Stanbol.
The structure, and the code of this bundle is pretty simple and allow to
code you route with java DSL (with one I pretty like), but maybe lack a
little bit of flexibility and user friendliness.
Have to keep this opportunity to use java DSL imo, but adding a more
"dynamic" way could be really cool throw a REST endpoint at a first step.
=== 6) Easy testing framework ===
Camel and Stanbol are bigs and even if both have integration testing
opportunities, using both at the same time can be hard to learn.
Could be good to have a set of helper classes and / or good
documentation to set this up easily.
=== 7) Thinking of improvements ===
Camel offer great opportunities in terms of asynchronous processing,
message splitting and merging, parallel processing and dynamic (on
conditionals) processing.
How can this features can be implemented in ? Needs stanbol's api
modifications ?
For another example of idea, why not have a route:// (or graph://)
protocols that allow to use already previously defined routes into a new
route ?
This task is more a "daemon" task where you will add ideas and solutions
during the implementations of others.
what do you think of this 10.000 feet plan ?
++
On 05/05/2014 10:24, Antonio David Perez Morales wrote:
Hi Rupert, Florent and all
My accepted project is "Enhancement Workflows. Enterprise Integration
Patterns in Apache Stanbol", based on the Jira issue [1]. Stanbol provides
a set of components for Semantic Content Management. One of the components
is the Enhancer, which can be used to extract features from content. The
Enhancer is organized using Enhancements Chains, which defines how the
content will be processed but they don't allow to integrate the current
process with the business layer. The goal of the project is to bring EIP to
Stanbol for easing the integration of the Enhancement workflows within the
business layer of enterprise systems. In order to achieve this, Apache
Camel framework is intended to be used as EIP pprovider.
About my person, I hold a graduate degree in Computer Science Engineering
from the University of Seville and I am currently finishing a Master in
Software Engineering and Technology at that institution. I consider myself
hardworking, problem-solving, quick-learning an open source lover mainly
interested in all related with new technologies either web, mobile or
desktop. I love learning new things and facing new challenges every day. I
have coded for a long time with Java, PHP and Javascript. I use them on my
daily work. I can write clean and structured code following code rules and
applying well-known design patterns to improve the quality and maintenance
of the code. Last year, I have been working as Senior Software Engineer at
the R&D division of Zaizi, an open source consultant specialized in Content
and Enterprise Content Management Systems. Apache Stanbol is one of the
main components in our current technical stack; therefore, I have been
widely working with it in the last months, both making integrations with
different enterprise systems like ECMs and directly contributing to the
project. As a result of this effort, I have been confirmed as committer of
the project since January 2014.
Regarding the project, I have been taking a look at Florent code about the
first approach to integrate Camel into Stanbol. Moreover I have already
started to read more and play with Camel (and Camel Spring) to refresh and
familiarize with it (because I worked with Camel several years ago). As a
first example (which is one of the tasks I want to do in the integration) I
have been able to deploy in a local folder some files with example Camel
routes defined in XML (camel-spring) and these routes are automatically
loaded by the example application I have deployed. This way, we can achieve
something similar to the indexing tool, where the indexing result files are
put in a directory inside Stanbol and automatically the new Entityhub is
generated from those files.
I have also read the mail Florent pointed out in a previous mail about the
potential Camel protocols (components) which can be developed to map
Chains, Engines and Stores but I would prefer to talk with Florent first to
decide the tasks to be done and the order of them, because I know the
proposal is very ambitious but achievable.
So, as first steps (and while waiting to talk with Florent through IRC
channel or whatever) I will continue playing with Camel and I will review
again the current Florent code to have a clearer idea on how to improve
this code in order to be integrated as a first version of the Enhancement
Workflows.
Please, comments are more than welcome.
Regards
-------------------------
[1] https://issues.apache.org/jira/browse/STANBOL-1008
On Mon, May 5, 2014 at 10:01 AM, Rupert Westenthaler <
rupert.westentha...@gmail.com> wrote:
Hi all,
Thx florent for the reminder. I would like to ask all 4 Students to
1. write a mail on this list with a short summary of the GSoC project
(project summary + link to the stanbol issue, some info about the
student, first steps). IMO this is important as the Proposals itself
are not fully public available.
2. to join the #stanbol IRC list on freenode.org (also mentors are
welcome to join ^^). Having the people around on IRC really helps to
answer simple questions fast.
and welcome to GSoC 2014!
best
Rupert
On Thu, May 1, 2014 at 1:05 PM, florent andré
<florent.andre-...@4sengines.com> wrote:
Hi there !
As you may notice Gsoc community bonding period has begin for some time
now.
Speaking for Camel/Stanbol integration [1], the good proposal from
Antonio
was accepted ! Congrats !
So Antonio, now bonding have to start! :)
From my point of view, a good way to bond the community to this
integration
could be to create sub-issues to the "can be considered as the main one"
STANBOL-1008. So we can see more specific actions you will take and
discuss
specific parts in the related issue, and get a global overview when
looking
at the parent issue.
Antonio what do you think ? Can you do that ?
As a side point, I remembered this morning this mail [2] exchange that
can
give you pointer or idea for an "easy to set up throw REST" Camel's
routes /
flowchart.
Happy bonding !
++
[1] be warned, don't know if any-one can access it :
https://www.google-melange.com/gsoc/proposal/review/org/google/gsoc2014/adperezmorales3/5629499534213120
[2]
http://mail-archives.apache.org/mod_mbox/incubator-stanbol-dev/201206.mbox/%3c4fdfc494.3090...@4sengines.com%3E
--
| Rupert Westenthaler rupert.westentha...@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
|
REDLINK.CO..........................................................................
| http://redlink.co/
