again about BPM, Workflow and Orchestration.
--
View this message in context:
http://camel.465427.n5.nabble.com/Question-on-the-proper-usage-of-Camel-tp5472181p5709293.html
Sent from the Camel - Users mailing list archive at Nabble.com.
oration subsidiary)
http://fusesource.com
Blog: http://opensourceknowledge.blogspot.com
-
--
View this message in context:
http://camel.465427.n5.nabble.com/Question-on-the-proper-usage-of-Camel-tp5472181p5489369.html
Sent from the Camel - Users
Hi
About the stacks
The Camel routing engine is a sort of complicated engine, that
supports both synchronous and asynchronous non-blocking routing, and
mixed as well.
To ensure this works with all the EIPs, components, processors, beans,
etc in use, the routing engine, need to invoke the process
Hi
I haven't had the time and pleasure to read this conversation. But i
got a little time for a few comments.
About debugging Java Camel routes
The Java programming language does not offer lambda expressions (high
order functions) so you cannot build a DSL with function blocks for
predicates, in
Thanks for the comments from all of you, now we have to analyze all of this
and possibly refactor our code, based on your feedback. Thanks for help,
Greg
W dniu 13 lutego 2012 10:13 użytkownik Ioannis Canellos
napisał:
> Grezgorz,
>
> Allow me to clarify that I did not mean that you are "overusi
Grezgorz,
Allow me to clarify that I did not mean that you are "overusing" camel. Or at
least I don't consider building 20 processors Camel overuse. I think that you
are just making your life harder, regardless of camel.
For instance in a plain java application, building & wiring 20 classes to
Am 11.02.2012 14:00, schrieb Grzegorz Borkowski:
Ashwin, Matt,
Thanks for you feedback. Here is some additional explanation of my points:
1. The external systems provide us with the ready-to-use
proxies/stubs/facades. We just call the Java method on such stub and it
does some remote calls inter
I'll jump in and try to clarify a few things. From the subject of this
tread, it looks like your not quite sure if you're using Camel in the
intended way. You already got a few good suggestions. In particular,
Ashwin's 1b is what I would have recommended myself too. Yet, Denis
Krizanovic's sugg
Ioannis, Denis,
Thanks for you input.
What you say is exactly the same what I think now, that we tried to
"overuse" Camel. We actually used it as a workflow engine for the message
processing, instead of integration engine. Instead of using Java
if-then-else logic inside a processor, we used Camel
If all your doing is using an API, and you don't really care what is
happening underneath, then I can see no need for Camel.
It would be the equivalent of trying to use Camel to do a series of String
manipulation calls. For all you know, the String class makes remote calls
over proprietary Oracle
There are some points I miss here. From the initial description I understand
that your use case is fairly simple: consume message from A, enrich / transform
them using B & finally send them to C.
What I don't get is how you ended up having like 20 processors. The number
sounds really big to me.
Grzegorz-
1. I was under the impression that you had a bunch of custom code doing
things like Web Service or database access. My contention was that
using Camel components to replace a lot of that boiler code is a big
win. There are still nice gains to be had from using Camel in your
scenar
Ashwin, Matt,
Thanks for you feedback. Here is some additional explanation of my points:
1. The external systems provide us with the ready-to-use
proxies/stubs/facades. We just call the Java method on such stub and it
does some remote calls internally, but it's beyond our control. What we
see, is
Hi Grzegorz-
What you are experiencing is not uncommon for folks that are used to
100% Java-based coding. Its not really a technical issue, as much as it
is a conceptual one. I think one of the most important concepts to
think about is that the Camel approach encourages "configuring", vs
"c
..
-
---------------------
Ashwin Karpe
Apache Camel Committer & Sr Principal Consultant
FUSESource (a Progress Software Corporation subsidiary)
http://fusesource.com
Blog: http://opensourceknowledge.blogspot.com
-
--
View this message in context:
http://camel.465427.n5.nabble.com/Question-on-the-proper-usage-of-Camel-tp5472181p5472699.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Hi All,
In our project we've been using Camel for a year, but with very mixed
feelings. I'd like to ask you if the way we use it is correct - maybe our
problems come from the wrong usage of the tool. Camel experts, please share
your opinions on this. Below you'll find description of the project.
16 matches
Mail list logo
