You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Raul Kripalani <ra...@evosent.com> on 2013/07/12 01:59:00 UTC
Camel toolbox for frequently used pieces of logic
Hi guys,
For a few months I've been wanting to build a set of utility classes with
the goal of providing a "toolbox" for commonly used AggregationStrategies,
OnPrepare processors, debug processors, etc.
Basically to make life easier for everyone. I feel there's too much
repeating that users can avoid if we provide certain basic uses cases out
of the box.
Moreover, newcomers find it hard to fully understand the role of properties
and headers for data pipelining inside routes. This toolbox can help settle
the concepts in common EIP scenarios.
So feel free to contribute your thoughts and ideas on
https://issues.apache.org/jira/browse/CAMEL-6542.
What pieces of logic do you tend to repeat across projects? What do you
carry in your Camel "toolbox" that other users may benefit from?
Thanks,
*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk
Re: Camel toolbox for frequently used pieces of logic
Posted by Willem jiang <wi...@gmail.com>.
+1 for providing some utility DSL or method to enhance the usage of Camel.
Split and Aggregate are the common EIP We may use every day.
I think we can add some utility for the Split at same time.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Friday, July 12, 2013 at 9:04 AM, Raul Kripalani wrote:
> Hey Johan,
>
> Thanks for the quick feedback! I agree with you – the goal is not to
> enforce particular ways of solving problems, but rather to provide
> shortcuts to commonly used tactics, even for short-lived
> interactions/mediations built on Camel.
>
> Just to give a concrete example, I find myself repeating things like these
> over and over again:
> - storing the output of an enrichment in a property
> - multicasting to a number of endpoints and filtering all responses,
> keeping only the ones that satisfy a given condition
> - storing the result body of a split in a List (not a List<Exchange> like
> the GroupedExchangeAggregationStrategy offers)
> - ...
>
> So I'd like to offer these pieces of logic in built-in utility classes,
> such that users can do things like these elegantly:
>
> from(abc)
> .to(def)
> .enrich(xyz, AggregationStrategies.storeInProperty("MyCamelProperty"))
> .log(...);
>
> or:
>
> import static o.a.c.t.AggregationStrategies.*;
>
> from(abc)
> .split(body().tokenize(","),
> storeInList(keepOnly(xpath("/result = 'ok'")))
> .to("http:...")
> .end();
>
> Maybe it's calling this a "toolbox" is an overelaborate term (maybe it's a
> DSL or fluent builder for Aggregation strategies). But I like the idea of
> everyone contributing reusable bits and pieces to build up a communal
> toolbox.
>
> Check out https://issues.apache.org/jira/browse/CAMEL-6542 for a few
> utility methods that sprang to mind.
>
> Regards,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>
> On Fri, Jul 12, 2013 at 1:21 AM, Johan Edstrom <seijoed@gmail.com (mailto:seijoed@gmail.com)> wrote:
>
> > Just my 2 cents...
> > I tend to focus more on Camel as a library and much less
> > on it as an EIP engine or runtime.
> > I think things get "over-EIP'ed" many times.
> >
> > In general I just try and keep routes as short as humanly possible,
> > as asynchronous as possible and as distributable as possible.
> >
> > Whenever I hear toolbox I tend to think constraints, one of the things
> > I really like about Camel is that there isn't a forced / enforced way of
> > solving problems. -- That quickly brings JBI to mind :)
> >
> > Or how competing frameworks talks about channels, deployment models
> > controlling
> > what to do or how to construct xml descriptors....
> >
> >
> >
> > On Jul 11, 2013, at 5:59 PM, Raul Kripalani <raul@evosent.com (mailto:raul@evosent.com)> wrote:
> >
> > > Hi guys,
> > >
> > > For a few months I've been wanting to build a set of utility classes with
> > > the goal of providing a "toolbox" for commonly used
> >
> >
> > AggregationStrategies,
> > > OnPrepare processors, debug processors, etc.
> > >
> > > Basically to make life easier for everyone. I feel there's too much
> > > repeating that users can avoid if we provide certain basic uses cases out
> > > of the box.
> > >
> > > Moreover, newcomers find it hard to fully understand the role of
> > properties
> > > and headers for data pipelining inside routes. This toolbox can help
> >
> >
> > settle
> > > the concepts in common EIP scenarios.
> > >
> > > So feel free to contribute your thoughts and ideas on
> > > https://issues.apache.org/jira/browse/CAMEL-6542.
> > >
> > > What pieces of logic do you tend to repeat across projects? What do you
> > > carry in your Camel "toolbox" that other users may benefit from?
> > >
> > > Thanks,
> > >
> > > *Raúl Kripalani*
> > > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > > Integration specialist
> > > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > > http://blog.raulkr.net | twitter: @raulvk
> >
>
Re: Camel toolbox for frequently used pieces of logic
Posted by Raul Kripalani <ra...@evosent.com>.
Hey Johan,
Thanks for the quick feedback! I agree with you – the goal is not to
enforce particular ways of solving problems, but rather to provide
shortcuts to commonly used tactics, even for short-lived
interactions/mediations built on Camel.
Just to give a concrete example, I find myself repeating things like these
over and over again:
- storing the output of an enrichment in a property
- multicasting to a number of endpoints and filtering all responses,
keeping only the ones that satisfy a given condition
- storing the result body of a split in a List (not a List<Exchange> like
the GroupedExchangeAggregationStrategy offers)
- ...
So I'd like to offer these pieces of logic in built-in utility classes,
such that users can do things like these elegantly:
from(abc)
.to(def)
.enrich(xyz, AggregationStrategies.storeInProperty("MyCamelProperty"))
.log(...);
or:
import static o.a.c.t.AggregationStrategies.*;
from(abc)
.split(body().tokenize(","),
storeInList(keepOnly(xpath("/result = 'ok'")))
.to("http:...")
.end();
Maybe it's calling this a "toolbox" is an overelaborate term (maybe it's a
DSL or fluent builder for Aggregation strategies). But I like the idea of
everyone contributing reusable bits and pieces to build up a communal
toolbox.
Check out https://issues.apache.org/jira/browse/CAMEL-6542 for a few
utility methods that sprang to mind.
Regards,
*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk
On Fri, Jul 12, 2013 at 1:21 AM, Johan Edstrom <se...@gmail.com> wrote:
> Just my 2 cents...
> I tend to focus more on Camel as a library and much less
> on it as an EIP engine or runtime.
> I think things get "over-EIP'ed" many times.
>
> In general I just try and keep routes as short as humanly possible,
> as asynchronous as possible and as distributable as possible.
>
> Whenever I hear toolbox I tend to think constraints, one of the things
> I really like about Camel is that there isn't a forced / enforced way of
> solving problems. -- That quickly brings JBI to mind :)
>
> Or how competing frameworks talks about channels, deployment models
> controlling
> what to do or how to construct xml descriptors....
>
>
>
> On Jul 11, 2013, at 5:59 PM, Raul Kripalani <ra...@evosent.com> wrote:
>
> > Hi guys,
> >
> > For a few months I've been wanting to build a set of utility classes with
> > the goal of providing a "toolbox" for commonly used
> AggregationStrategies,
> > OnPrepare processors, debug processors, etc.
> >
> > Basically to make life easier for everyone. I feel there's too much
> > repeating that users can avoid if we provide certain basic uses cases out
> > of the box.
> >
> > Moreover, newcomers find it hard to fully understand the role of
> properties
> > and headers for data pipelining inside routes. This toolbox can help
> settle
> > the concepts in common EIP scenarios.
> >
> > So feel free to contribute your thoughts and ideas on
> > https://issues.apache.org/jira/browse/CAMEL-6542.
> >
> > What pieces of logic do you tend to repeat across projects? What do you
> > carry in your Camel "toolbox" that other users may benefit from?
> >
> > Thanks,
> >
> > *Raúl Kripalani*
> > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > Integration specialist
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
>
>
Re: Camel toolbox for frequently used pieces of logic
Posted by Johan Edstrom <se...@gmail.com>.
Just my 2 cents...
I tend to focus more on Camel as a library and much less
on it as an EIP engine or runtime.
I think things get "over-EIP'ed" many times.
In general I just try and keep routes as short as humanly possible,
as asynchronous as possible and as distributable as possible.
Whenever I hear toolbox I tend to think constraints, one of the things
I really like about Camel is that there isn't a forced / enforced way of
solving problems. -- That quickly brings JBI to mind :)
Or how competing frameworks talks about channels, deployment models controlling
what to do or how to construct xml descriptors....
On Jul 11, 2013, at 5:59 PM, Raul Kripalani <ra...@evosent.com> wrote:
> Hi guys,
>
> For a few months I've been wanting to build a set of utility classes with
> the goal of providing a "toolbox" for commonly used AggregationStrategies,
> OnPrepare processors, debug processors, etc.
>
> Basically to make life easier for everyone. I feel there's too much
> repeating that users can avoid if we provide certain basic uses cases out
> of the box.
>
> Moreover, newcomers find it hard to fully understand the role of properties
> and headers for data pipelining inside routes. This toolbox can help settle
> the concepts in common EIP scenarios.
>
> So feel free to contribute your thoughts and ideas on
> https://issues.apache.org/jira/browse/CAMEL-6542.
>
> What pieces of logic do you tend to repeat across projects? What do you
> carry in your Camel "toolbox" that other users may benefit from?
>
> Thanks,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
Re: Camel toolbox for frequently used pieces of logic
Posted by Christian Müller <ch...@gmail.com>.
+1
Because we have users which are using the XML DSL and try to avoid writing
Java code - for whatever reason. With this "toolbox" of common
implementations of popular Camel interfaces/concepts, we serve their needs
much better. E.g. some thing like the UseLatestAggregationStrategy [1].
[1]
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=blob;f=camel-core/src/main/java/org/apache/camel/processor/aggregate/UseLatestAggregationStrategy.java;h=aee57720752153c2b50833be4a8e8c8fb52c7233;hb=HEAD
Best,
Christian
-----------------
Software Integration Specialist
Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html
https://www.linkedin.com/pub/christian-mueller/11/551/642
On Fri, Jul 12, 2013 at 1:59 AM, Raul Kripalani <ra...@evosent.com> wrote:
> Hi guys,
>
> For a few months I've been wanting to build a set of utility classes with
> the goal of providing a "toolbox" for commonly used AggregationStrategies,
> OnPrepare processors, debug processors, etc.
>
> Basically to make life easier for everyone. I feel there's too much
> repeating that users can avoid if we provide certain basic uses cases out
> of the box.
>
> Moreover, newcomers find it hard to fully understand the role of properties
> and headers for data pipelining inside routes. This toolbox can help settle
> the concepts in common EIP scenarios.
>
> So feel free to contribute your thoughts and ideas on
> https://issues.apache.org/jira/browse/CAMEL-6542.
>
> What pieces of logic do you tend to repeat across projects? What do you
> carry in your Camel "toolbox" that other users may benefit from?
>
> Thanks,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>