You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by realice <re...@gmail.com> on 2012/09/12 23:25:58 UTC
Camel vs BPEL
Hi, can anyone give some really good convincing stuff that why should we use
camel over BPEL? I'm trying to convince somebody here to use camel instead
of oracle SOA 11g that has BPEL engine as so called 'orchestrator'. any
references, materials are good, and especially like to have some input from
the gurus
many thanks
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel vs BPEL
Posted by Raul Kripalani <ra...@evosent.com>.
In a typical enterprise architecture, you've got a) the need to orchestrate
services to compose business processes which, b) rely on neutrally-exposed,
proxied and mediated services that may perform lightweight orchestration and
routing.
Whether you end up using Camel for a) or not (I'm assuming that you are
using Camel for b - as it's the best fit ;)), you should really
differentiate between those two layers at least. Camel is definitely a great
fit for both, but there are tradeoffs.
Camel's support for so many Enterprise Integration Patterns makes it good
for implementing orchestration flows, and its error handling/compensation
features are on par with BPEL.
A good point about BPEL is that the data transformation/assignment rules can
be expressed inside the BPEL process. But they are essentially limited to
XPath, XQuery and XSLT. With Camel, you have more than 20 transformation
technologies at your fingertips, and the payload doesn't need to be XML.
When it comes to connectivity, you must be already aware that BPEL is
WS-centric. Camel has 80+ components to interact with practically any
protocol, technology or resource out there.
I hope this helps a bit.
Regards,
Raúl.
---
Raúl Kripalani (raul@evosent.com)
Enterprise Architect, Program Manager, Open Source Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214p5719439.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel vs BPEL
Posted by Łukasz Budnik <lu...@gmail.com>.
Hi guys,
I'm using WS-BPEL for 5 years and Apache Camel for 3 years. I use them
BOTH. It depends on the use case. If I have to write complex system
integrations then WS-BPEL-based service orchestration is ideal. If I
have to implement service flows then WS-BPEL is simply my number one.
On the other hand when I want simple (more like step-by-step) system
integration I use Apache Camel. What is more you can combine them both
in system!
But that's my point of view.
cheers,
Łukasz
On 13 September 2012 00:23, Bing Lu <re...@gmail.com> wrote:
> i tried that already :)
>
> On Wed, Sep 12, 2012 at 6:05 PM, Donald Whytock <dw...@gmail.com> wrote:
>
>> Camel's a lot cheaper than Oracle...?
>>
>> On Wed, Sep 12, 2012 at 5:58 PM, Bing Lu <re...@gmail.com> wrote:
>> > thanks for the links. I'm trying to convince them why camel is better
>> than
>> > BPEL in the system integration world, any suggestions welcome
>> >
>> > On Wed, Sep 12, 2012 at 5:37 PM, chris snow <ch...@gmail.com> wrote:
>> >
>> >> you may find these links useful:
>> >>
>> >>
>> >>
>> http://fusesource.com/apache-camel-conference-2012/videos/camelone-2012-kai-wahner-video
>> >>
>> >>
>> http://camel.465427.n5.nabble.com/Camel-EAI-patterns-vs-BPEL-processes-td5713573.html
>> >>
>> >>
>> >> On Wed, Sep 12, 2012 at 10:25 PM, realice <re...@gmail.com> wrote:
>> >> > Hi, can anyone give some really good convincing stuff that why should
>> we
>> >> use
>> >> > camel over BPEL? I'm trying to convince somebody here to use camel
>> >> instead
>> >> > of oracle SOA 11g that has BPEL engine as so called 'orchestrator'.
>> any
>> >> > references, materials are good, and especially like to have some input
>> >> from
>> >> > the gurus
>> >> >
>> >> > many thanks
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > View this message in context:
>> >> http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214.html
>> >> > Sent from the Camel - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >>
>> >> --
>> >> Chris Snow -
>> >> http://uk.linkedin.com/pub/chris-snow-mba-tech-mgmt-cissp/6/0/316
>> >>
>>
Re: Camel vs BPEL
Posted by Bing Lu <re...@gmail.com>.
i tried that already :)
On Wed, Sep 12, 2012 at 6:05 PM, Donald Whytock <dw...@gmail.com> wrote:
> Camel's a lot cheaper than Oracle...?
>
> On Wed, Sep 12, 2012 at 5:58 PM, Bing Lu <re...@gmail.com> wrote:
> > thanks for the links. I'm trying to convince them why camel is better
> than
> > BPEL in the system integration world, any suggestions welcome
> >
> > On Wed, Sep 12, 2012 at 5:37 PM, chris snow <ch...@gmail.com> wrote:
> >
> >> you may find these links useful:
> >>
> >>
> >>
> http://fusesource.com/apache-camel-conference-2012/videos/camelone-2012-kai-wahner-video
> >>
> >>
> http://camel.465427.n5.nabble.com/Camel-EAI-patterns-vs-BPEL-processes-td5713573.html
> >>
> >>
> >> On Wed, Sep 12, 2012 at 10:25 PM, realice <re...@gmail.com> wrote:
> >> > Hi, can anyone give some really good convincing stuff that why should
> we
> >> use
> >> > camel over BPEL? I'm trying to convince somebody here to use camel
> >> instead
> >> > of oracle SOA 11g that has BPEL engine as so called 'orchestrator'.
> any
> >> > references, materials are good, and especially like to have some input
> >> from
> >> > the gurus
> >> >
> >> > many thanks
> >> >
> >> >
> >> >
> >> > --
> >> > View this message in context:
> >> http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214.html
> >> > Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
> >>
> >>
> >> --
> >> Chris Snow -
> >> http://uk.linkedin.com/pub/chris-snow-mba-tech-mgmt-cissp/6/0/316
> >>
>
Re: Camel vs BPEL
Posted by Donald Whytock <dw...@gmail.com>.
Camel's a lot cheaper than Oracle...?
On Wed, Sep 12, 2012 at 5:58 PM, Bing Lu <re...@gmail.com> wrote:
> thanks for the links. I'm trying to convince them why camel is better than
> BPEL in the system integration world, any suggestions welcome
>
> On Wed, Sep 12, 2012 at 5:37 PM, chris snow <ch...@gmail.com> wrote:
>
>> you may find these links useful:
>>
>>
>> http://fusesource.com/apache-camel-conference-2012/videos/camelone-2012-kai-wahner-video
>>
>> http://camel.465427.n5.nabble.com/Camel-EAI-patterns-vs-BPEL-processes-td5713573.html
>>
>>
>> On Wed, Sep 12, 2012 at 10:25 PM, realice <re...@gmail.com> wrote:
>> > Hi, can anyone give some really good convincing stuff that why should we
>> use
>> > camel over BPEL? I'm trying to convince somebody here to use camel
>> instead
>> > of oracle SOA 11g that has BPEL engine as so called 'orchestrator'. any
>> > references, materials are good, and especially like to have some input
>> from
>> > the gurus
>> >
>> > many thanks
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214.html
>> > Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> Chris Snow -
>> http://uk.linkedin.com/pub/chris-snow-mba-tech-mgmt-cissp/6/0/316
>>
Re: Camel vs BPEL
Posted by Bing Lu <re...@gmail.com>.
thanks for the links. I'm trying to convince them why camel is better than
BPEL in the system integration world, any suggestions welcome
On Wed, Sep 12, 2012 at 5:37 PM, chris snow <ch...@gmail.com> wrote:
> you may find these links useful:
>
>
> http://fusesource.com/apache-camel-conference-2012/videos/camelone-2012-kai-wahner-video
>
> http://camel.465427.n5.nabble.com/Camel-EAI-patterns-vs-BPEL-processes-td5713573.html
>
>
> On Wed, Sep 12, 2012 at 10:25 PM, realice <re...@gmail.com> wrote:
> > Hi, can anyone give some really good convincing stuff that why should we
> use
> > camel over BPEL? I'm trying to convince somebody here to use camel
> instead
> > of oracle SOA 11g that has BPEL engine as so called 'orchestrator'. any
> > references, materials are good, and especially like to have some input
> from
> > the gurus
> >
> > many thanks
> >
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Chris Snow -
> http://uk.linkedin.com/pub/chris-snow-mba-tech-mgmt-cissp/6/0/316
>
Re: Camel vs BPEL
Posted by chris snow <ch...@gmail.com>.
you may find these links useful:
http://fusesource.com/apache-camel-conference-2012/videos/camelone-2012-kai-wahner-video
http://camel.465427.n5.nabble.com/Camel-EAI-patterns-vs-BPEL-processes-td5713573.html
On Wed, Sep 12, 2012 at 10:25 PM, realice <re...@gmail.com> wrote:
> Hi, can anyone give some really good convincing stuff that why should we use
> camel over BPEL? I'm trying to convince somebody here to use camel instead
> of oracle SOA 11g that has BPEL engine as so called 'orchestrator'. any
> references, materials are good, and especially like to have some input from
> the gurus
>
> many thanks
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Chris Snow - http://uk.linkedin.com/pub/chris-snow-mba-tech-mgmt-cissp/6/0/316
Re: Camel vs BPEL
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Mostly a social issue, but I totally agree.
Also keep in mind when you compare options that Camel is a framework,
not a product and BPEL in this context actually means not the spec, but
a specific box-wrapped interpretation of it sold as a product.
$0.02 + tax
Hadrian
On 09/14/2012 09:55 AM, Donald Whytock wrote:
> Something that's gelled from conversations I've had at my workplace is
> that there's a perception difference between commercial software and
> FOSS. Yes, I was one of those that, in this very thread, said
> "Camel's a lot cheaper". But that's at least partly because I for one
> use it in personal hobbies and would avoid buying something
> commercial.
>
> In the corporate world, though, free software isn't free. It requires
> paying people to understand it, implement it, maintain it, etc. These
> costs can be estimated, but estimates are estimates; there's nothing
> guaranteed.
>
> Commercial vendors, on the other hand, don't offer estimates. They
> offer invoices. You can literally buy a box of Oracle, off the shelf
> in better neighborhoods. How much Oracle do you want? Okay, that'll
> be $X.99 plus tax. It's a nice, simple answer that a vendor in a suit
> can present to a manager and have the manager understand it.
>
> Microsoft does that too. I believe that's the reason a company that
> already uses Java might find itself trending toward .NET.
>
> Yes, POC might help, especially in the form of working in-use
> applications. But if you don't have that already, someone might go
> buy a box of BPEL while you're building it.
>
> Good luck.
>
> Don
>
> On Fri, Sep 14, 2012 at 9:11 AM, Henryk Konsek <he...@gmail.com> wrote:
>>> Hi, can anyone give some really good convincing stuff that why should we use
>>> camel over BPEL?
>>
>> Call me stupid, but BPEL is too complex for me. :)
>>
>> If I want to orchestrate two WS endpoints and perform some
>> transformation on the data, I would like to express this with a few
>> lines of DSL.
>>
>> I'm technical guy and one of the things I'm paid for is to estimate
>> the cost of deploying given technical solution. In my opinion
>> investing into the BPEL is expensive. BPEL is complicated and
>> inflexible. Only abusive volume of legacy BPEL code will convince me
>> to suggest somebody to stick to the BPEL.
>>
>> I don't see any value in the BPEL complexity.
>>
>> --
>> Henryk Konsek
>> http://henryk-konsek.blogspot.com
Re: Camel vs BPEL
Posted by Henryk Konsek <he...@gmail.com>.
> To be honest, I see companies paying extraordinary sums to get hold of TIBCO,
> Oracle, WebMethods, etc. consultants. So they end up paying license +
> knowledge. With Camel, they only invest in knowledge.
Yeah, actually you always need to invest in knowledge. Thinking that
company might avoid that by buying product box, generates even more
costs than investing in the knowledge in the first place. Using Oracle
or Tibco without investment in learning people works only for the most
trivial use cases.
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: Camel vs BPEL
Posted by Raul Kripalani <ra...@evosent.com>.
To be honest, I see companies paying extraordinary sums to get hold of TIBCO,
Oracle, WebMethods, etc. consultants. So they end up paying license +
knowledge. With Camel, they only invest in knowledge. Sorry, but I can't say
I share your views in this sense ;)
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214p5719460.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel vs BPEL
Posted by Donald Whytock <dw...@gmail.com>.
Something that's gelled from conversations I've had at my workplace is
that there's a perception difference between commercial software and
FOSS. Yes, I was one of those that, in this very thread, said
"Camel's a lot cheaper". But that's at least partly because I for one
use it in personal hobbies and would avoid buying something
commercial.
In the corporate world, though, free software isn't free. It requires
paying people to understand it, implement it, maintain it, etc. These
costs can be estimated, but estimates are estimates; there's nothing
guaranteed.
Commercial vendors, on the other hand, don't offer estimates. They
offer invoices. You can literally buy a box of Oracle, off the shelf
in better neighborhoods. How much Oracle do you want? Okay, that'll
be $X.99 plus tax. It's a nice, simple answer that a vendor in a suit
can present to a manager and have the manager understand it.
Microsoft does that too. I believe that's the reason a company that
already uses Java might find itself trending toward .NET.
Yes, POC might help, especially in the form of working in-use
applications. But if you don't have that already, someone might go
buy a box of BPEL while you're building it.
Good luck.
Don
On Fri, Sep 14, 2012 at 9:11 AM, Henryk Konsek <he...@gmail.com> wrote:
>> Hi, can anyone give some really good convincing stuff that why should we use
>> camel over BPEL?
>
> Call me stupid, but BPEL is too complex for me. :)
>
> If I want to orchestrate two WS endpoints and perform some
> transformation on the data, I would like to express this with a few
> lines of DSL.
>
> I'm technical guy and one of the things I'm paid for is to estimate
> the cost of deploying given technical solution. In my opinion
> investing into the BPEL is expensive. BPEL is complicated and
> inflexible. Only abusive volume of legacy BPEL code will convince me
> to suggest somebody to stick to the BPEL.
>
> I don't see any value in the BPEL complexity.
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
Re: Camel vs BPEL
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 14, 2012 at 7:55 PM, Bruno Borges <br...@gmail.com> wrote:
> IMHO,
>
> BPEL is about Business Process, and Camel is about Message Processing,
> although both can be used for the same thing (business or message).
>
> But what about human tasks in the middle? Persistence is important because
> your process may not be atomic.
> So if you go for Camel or any other product (MuleESB comes to mind), you
> will have to implement all these business process control and persistence
> on your own.
>
Yes Camel and BPEL is not the same.
This is also what Kai says in his great presentation. There was a link
in one of the first posts.
However in my past many jobs I have seem people not being aware of
this, and thinking BPEL is their
one-stop magic solution for all the integration related issues.
> jm2c
>
> *Bruno Borges*
> (11) 99564-9058
> *www.brunoborges.com*
>
>
>
> On Fri, Sep 14, 2012 at 2:45 PM, Omar Atia <om...@its.ws> wrote:
>
>> Adding to this BPEL is slow in performance for heavy load activities.
>>
>> Camel is the best solution you go for , even spring DSL configuration you
>> can do the same.
>>
>> -----Original Message-----
>> From: Henryk Konsek [mailto:hekonsek@gmail.com]
>> Sent: Friday, September 14, 2012 4:12 PM
>> To: users@camel.apache.org
>> Subject: Re: Camel vs BPEL
>>
>> > Hi, can anyone give some really good convincing stuff that why should
>> > we use camel over BPEL?
>>
>> Call me stupid, but BPEL is too complex for me. :)
>>
>> If I want to orchestrate two WS endpoints and perform some transformation
>> on the data, I would like to express this with a few lines of DSL.
>>
>> I'm technical guy and one of the things I'm paid for is to estimate the
>> cost of deploying given technical solution. In my opinion investing into
>> the BPEL is expensive. BPEL is complicated and inflexible. Only abusive
>> volume of legacy BPEL code will convince me to suggest somebody to stick to
>> the BPEL.
>>
>> I don't see any value in the BPEL complexity.
>>
>> --
>> Henryk Konsek
>> http://henryk-konsek.blogspot.com
>>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Camel vs BPEL
Posted by Raul Kripalani <ra...@evosent.com>.
For persistence and transactionality, you can use cascading JMS queues to
link your process steps in a sequence, such that messages will only be
ACK'ed or transactions will commit if that step of the process succeeded.
And for human task processing, BPEL doesn't provide a solution anyway. Some
extensions such as BPEL4People and WS-HumanTask aimed to define a standard
interface for workflow engines to plug into BPEL processes. However, the
solution that ended up gaining more traction in this area was BPMN2.
Do you have any steps involving humans or manual workflow in your processes?
Regards,
Raúl.
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214p5719459.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel vs BPEL
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Finally somebody who pointed out the real difference. Thanks Bruno.
Camel is stateless, WS-BPEL is stateful! If you need to deal with state,
which is usually the case, Camel will only partially help. You'll have
to deal with persistence and correlation yourself. For simple projects,
it's next to trivial, for larger ones, not so much.
OTOH, BPEL only knows/cares of WS, using it together with Camel extends
the reach of your business process orders of magnitude. So in some cases
Camel can substitute BPEL, in most others it complements it really well.
Hadrian
On 09/14/2012 01:55 PM, Bruno Borges wrote:
> IMHO,
>
> BPEL is about Business Process, and Camel is about Message Processing,
> although both can be used for the same thing (business or message).
>
> But what about human tasks in the middle? Persistence is important because
> your process may not be atomic.
> So if you go for Camel or any other product (MuleESB comes to mind), you
> will have to implement all these business process control and persistence
> on your own.
>
> jm2c
>
> *Bruno Borges*
> (11) 99564-9058
> *www.brunoborges.com*
>
>
>
> On Fri, Sep 14, 2012 at 2:45 PM, Omar Atia <om...@its.ws> wrote:
>
>> Adding to this BPEL is slow in performance for heavy load activities.
>>
>> Camel is the best solution you go for , even spring DSL configuration you
>> can do the same.
>>
>> -----Original Message-----
>> From: Henryk Konsek [mailto:hekonsek@gmail.com]
>> Sent: Friday, September 14, 2012 4:12 PM
>> To: users@camel.apache.org
>> Subject: Re: Camel vs BPEL
>>
>>> Hi, can anyone give some really good convincing stuff that why should
>>> we use camel over BPEL?
>>
>> Call me stupid, but BPEL is too complex for me. :)
>>
>> If I want to orchestrate two WS endpoints and perform some transformation
>> on the data, I would like to express this with a few lines of DSL.
>>
>> I'm technical guy and one of the things I'm paid for is to estimate the
>> cost of deploying given technical solution. In my opinion investing into
>> the BPEL is expensive. BPEL is complicated and inflexible. Only abusive
>> volume of legacy BPEL code will convince me to suggest somebody to stick to
>> the BPEL.
>>
>> I don't see any value in the BPEL complexity.
>>
>> --
>> Henryk Konsek
>> http://henryk-konsek.blogspot.com
>>
>
Re: Camel vs BPEL
Posted by Bruno Borges <br...@gmail.com>.
IMHO,
BPEL is about Business Process, and Camel is about Message Processing,
although both can be used for the same thing (business or message).
But what about human tasks in the middle? Persistence is important because
your process may not be atomic.
So if you go for Camel or any other product (MuleESB comes to mind), you
will have to implement all these business process control and persistence
on your own.
jm2c
*Bruno Borges*
(11) 99564-9058
*www.brunoborges.com*
On Fri, Sep 14, 2012 at 2:45 PM, Omar Atia <om...@its.ws> wrote:
> Adding to this BPEL is slow in performance for heavy load activities.
>
> Camel is the best solution you go for , even spring DSL configuration you
> can do the same.
>
> -----Original Message-----
> From: Henryk Konsek [mailto:hekonsek@gmail.com]
> Sent: Friday, September 14, 2012 4:12 PM
> To: users@camel.apache.org
> Subject: Re: Camel vs BPEL
>
> > Hi, can anyone give some really good convincing stuff that why should
> > we use camel over BPEL?
>
> Call me stupid, but BPEL is too complex for me. :)
>
> If I want to orchestrate two WS endpoints and perform some transformation
> on the data, I would like to express this with a few lines of DSL.
>
> I'm technical guy and one of the things I'm paid for is to estimate the
> cost of deploying given technical solution. In my opinion investing into
> the BPEL is expensive. BPEL is complicated and inflexible. Only abusive
> volume of legacy BPEL code will convince me to suggest somebody to stick to
> the BPEL.
>
> I don't see any value in the BPEL complexity.
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
RE: Camel vs BPEL
Posted by Omar Atia <om...@its.ws>.
Adding to this BPEL is slow in performance for heavy load activities.
Camel is the best solution you go for , even spring DSL configuration you can do the same.
-----Original Message-----
From: Henryk Konsek [mailto:hekonsek@gmail.com]
Sent: Friday, September 14, 2012 4:12 PM
To: users@camel.apache.org
Subject: Re: Camel vs BPEL
> Hi, can anyone give some really good convincing stuff that why should
> we use camel over BPEL?
Call me stupid, but BPEL is too complex for me. :)
If I want to orchestrate two WS endpoints and perform some transformation on the data, I would like to express this with a few lines of DSL.
I'm technical guy and one of the things I'm paid for is to estimate the cost of deploying given technical solution. In my opinion investing into the BPEL is expensive. BPEL is complicated and inflexible. Only abusive volume of legacy BPEL code will convince me to suggest somebody to stick to the BPEL.
I don't see any value in the BPEL complexity.
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: Camel vs BPEL
Posted by Henryk Konsek <he...@gmail.com>.
> Hi, can anyone give some really good convincing stuff that why should we use
> camel over BPEL?
Call me stupid, but BPEL is too complex for me. :)
If I want to orchestrate two WS endpoints and perform some
transformation on the data, I would like to express this with a few
lines of DSL.
I'm technical guy and one of the things I'm paid for is to estimate
the cost of deploying given technical solution. In my opinion
investing into the BPEL is expensive. BPEL is complicated and
inflexible. Only abusive volume of legacy BPEL code will convince me
to suggest somebody to stick to the BPEL.
I don't see any value in the BPEL complexity.
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: Camel vs BPEL
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 14, 2012 at 2:20 AM, realice <re...@gmail.com> wrote:
> quick update-- my attempt to use the camel has been shutdown :(
>
> I argued with all my might and basically presented all the stuff you guys
> mentioned, but then again I'm just a mere developer, not like somebody
> higher up in the management chain who doesn't know anything but likes to
> make decisions
>
Yeah you are not the first. And you will not be the last.
Some corporations is good a wine-and-dine, and charming decision
makers on the golf course. (figure of speaking)
This is miles away from what any free and open source community can do.
In the end though. I always advise to setup a POC and give time to try
out the various products.
Often today you can download and try products. And for the
closed-source products, they usually
offer a trail version etc.
Though if your organization is already using Oracle and BPEL in other
products and have it running
in production, then it makes sense to continue down that path.
But don't forget IMHO from time to time to re-surface and re-validate
where the "market" is today.
In the end its your business and your $$$. And you need to spend them
wisely in todays tough business.
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214p5719325.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Camel vs BPEL
Posted by realice <re...@gmail.com>.
quick update-- my attempt to use the camel has been shutdown :(
I argued with all my might and basically presented all the stuff you guys
mentioned, but then again I'm just a mere developer, not like somebody
higher up in the management chain who doesn't know anything but likes to
make decisions
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214p5719325.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel vs BPEL
Posted by Christian Müller <ch...@gmail.com>.
At present, Camel supports more than 100 components:
http://camel.apache.org/components.html
Nor sure how many Oracle supports...
Best,
Christian
On Wed, Sep 12, 2012 at 11:25 PM, realice <re...@gmail.com> wrote:
> Hi, can anyone give some really good convincing stuff that why should we
> use
> camel over BPEL? I'm trying to convince somebody here to use camel instead
> of oracle SOA 11g that has BPEL engine as so called 'orchestrator'. any
> references, materials are good, and especially like to have some input from
> the gurus
>
> many thanks
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Re: Camel vs BPEL
Posted by Claus Ibsen <cl...@gmail.com>.
Anyone got that link to the blog post by a swedish company (I think it
was Jayway) that posted a couple of years ago, about the 15+ steps it
took them to figure out how to do a XSLT in Oracle, and that it took 3
lines of simple code in Camel.
Ah I found it here it is:
http://www.jayway.com/2010/05/07/xslt-transformations-in-oracle-service-bus/
And besides BPEL is a dead horse in the open source space. No innovation there.
BPMN 2.0 is the new kid on the block
http://en.wikipedia.org/wiki/Business_Process_Model_and_Notation
And there is JBoss jBPM and Activiti as good open source projects for that.
On Wed, Sep 12, 2012 at 11:25 PM, realice <re...@gmail.com> wrote:
> Hi, can anyone give some really good convincing stuff that why should we use
> camel over BPEL? I'm trying to convince somebody here to use camel instead
> of oracle SOA 11g that has BPEL engine as so called 'orchestrator'. any
> references, materials are good, and especially like to have some input from
> the gurus
>
> many thanks
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Camel vs BPEL
Posted by Christian Müller <ch...@gmail.com>.
Camel works with any type of content:
- XML
- CSV
- fixed length
- Java Objects
- Strings
- binary
- ...
Not sure if this is possible with BPEL or BPMN.
Best,
Christian
On Wed, Sep 12, 2012 at 11:25 PM, realice <re...@gmail.com> wrote:
> Hi, can anyone give some really good convincing stuff that why should we
> use
> camel over BPEL? I'm trying to convince somebody here to use camel instead
> of oracle SOA 11g that has BPEL engine as so called 'orchestrator'. any
> references, materials are good, and especially like to have some input from
> the gurus
>
> many thanks
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--