Hi,

Thanks for you comments Rupert.

@Antonio, can you put yours / transform this in issues ?

Mine under :

On 14/05/2014 10:23, Rupert Westenthaler wrote:
Hi Florent, Antonio, all

Here are my throughs

On Wed, May 7, 2014 at 2:07 PM, florent andré
<florent.andre-...@4sengines.com> wrote:
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)


I like "(1) Enhancements Route" as name for the feature.

I would like to have the ability to use Enhancements Routes similar to
Enhancement Chains.

comments on your restrictions :

Such routes would have some restrictions: (a)
start with a request,

dou you mean a "user" (= curl like) request ?
I don't think it as to be a "restriction" as some Camel inputs components are sort of "pool".
For example "mail endpoint", "file endpoint", "ftp endpoint", etc...

They not directly answer to a "direct request" but when something is send to the email address (or put in a directory), the full Enhancement Route is launched.

(b) end with a response,

Depending on you camel output, "end with a response" is not exactly true in an "classical resquest/reponse http thought"...

I mean that the response of a "route" can be a mail sended or an rdf serialization write to an ftp...


(c) run synchronously.

Camel provide some tool for asynch.. but surely restrict to a synchronous processing is better on a first step (as maybe the previous restrictions)...


If we want we could call such routes "Enhancement Workflows". But
before deciding this I would like to see some working demos.


+1 for working demo !
It's interesting to wonder the difference you do between "route" and "workflow" ! :)


[..]


[...]


[..]
=== 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.


Creating/Installing bundles is not a big hurdle. If we provide a good
Maven Archetype so that users just need to code the route it should
also quite user friendly.


+1 for maven archetype.

Having a Maven project also has the advantage that its more simple to
manage additional dependencies (not knowing how likely such would be).


Sure we can provide a "bundle list" with all camel osgi components... but can be heavy...

On the other hand I remember camel components stack as an easy to add bundles...

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.


If it is possible to dynamically load/compile and install routes (e.g.
from a file or even a configuration or request parameter) we should
definitely provide such a possibility.


Yes doable.
In form of xml dsl file or groovy script (at least)

I would suggest to provide such a RESTful service as part of the the
Felix Webconsole. This would also allow to provide a simple UI as tab
of the Felix WebConsole (similar to the tab of the DataFileProvider).


+1
as the rest of this thread.

++



[..]
=== 7) Thinking of improvements ===

Camel offer great opportunities in terms of asynchronous processing, message
splitting and merging, parallel processing and dynamic (on conditionals)
processing.


The commons.job module already provide means for asynchronous RESTful
services. The Enhancement Task API extension as suggested by David [1]
is also related to this

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.


For API modification you should have a look at the suggested API
changes for the Enhancer 2.0 API (STANBOL-1326 [2]). This is only a
first proposal and the ideal place to collect ideas/suggestions/...


best
Rupert

[1] http://markmail.org/message/u5meqclsdrq6nx6e
[2] https://issues.apache.org/jira/browse/


++


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/






Reply via email to