Mediation Router as flow orchestrator inside Fuse ESB?

[[e-mail]]

Hi,

I'm trying to understand the suitability of Camel as an alternative to a BPEL container inside ServiceMix. Is it possible for a Camel route deployed inside ServiceMix to act essentially as an orchestrator? The specific use case I have in mind is:

from("jbi:service:http://fromage.com/swiss/endpoint-A").

// 1) transform the incoming request to some intermediate enterprise schema

// 2) invoke another web service, either as a jbi endpoint ("endpoint-B") or directly

// 3) check to see that a certain value is present in the response

// 4) if not, then throw a SOAP fault from the WSDL of endpoint-A

// 5) else, transform the incoming request to some other enterprise schema

// 6) send the enterprise version of the request...

to("jbi:service:http://fromage.com/gouda/endpoint-C");

So, whomever would invoke this flow would either get an HTTP 202 (everything OK, request accepted) or the SOAP fault that is defined in their WSDL contract.

I understand that maybe a Bean could encapsulate this kind of branch logic and that BPEL might be the better way to go. I'm just trying to see how far the DSL can stretch in this use case.

Thanks!

Edited by: pdmackinnon on Jan 15, 2008 9:37 AM

[hzbarcea_hzbarcea]

Hi Pete,

Camel sure can be used for your scenario.  Like you said you may have to write your own beans for transforming your data, but depending on what you need to do you might get away with camel-script or something similar.

BPEL has one clear advantage over camel and that is long running transactions.  A BPEL engine keeps track of and persists running process instances that may span over days, weeks, months.  That would be the only scenario where I would use bpel.  Other than that I would chose Camel for the following reasons:

• bpel depends on wsdl, camel does not.  i.e. with camel you may accept messages from sources not supported by a ws stack such as say, quartz.  On top of that the way endpoints are defined in camel is much simpler, more natural.  It can get quite messy to define partner links in bpel for say, again, things like quartz.

• when it comes down to exceptions, bpel sucks.  the syntax is complicated and many a time you might get results different than what you expect with a naive usage of the syntax.

• bpel is harder to debug, no good tools afaik.

In your particular case it looks like you want something like (if I read your request correctly):

from(endpoint-A).process(bean).to(endpoint-B).

  choice(when(xpath("/yourvalue = 'something'")).process(enterprisebean).to(enterprise-endpoint).

  otherwise().exception(YourSoapException)

I hope this helps,

Hadrian

[hzbarcea_hzbarcea]

Hi Pete,

Camel sure can be used for your scenario.  Like you said you may have to write your own beans for transforming your data, but depending on what you need to do you might get away with camel-script or something similar.

BPEL has one clear advantage over camel and that is long running transactions.  A BPEL engine keeps track of and persists running process instances that may span over days, weeks, months.  That would be the only scenario where I would use bpel.  Other than that I would chose Camel for the following reasons:

bpel depends on wsdl, camel does not.  i.e. with camel you may accept messages from sources not supported by a ws stack such as say, quartz.  On top of that the way endpoints are defined in camel is much simpler, more natural.  It can get quite messy to define partner links in bpel for say, again, things like quartz.

• when it comes down to exceptions, bpel sucks.  the syntax is complicated and many a time you might get results different than what you expect with a naive usage of the syntax.

• bpel is harder to debug, no good tools afaik.

In your particular case it looks like you want something like (if I read your request correctly):

from(endpoint-A).process(bean).to(endpoint-B).

  choice(when(xpath("/yourvalue = 'something'")).process(enterprisebean).to(enterprise-endpoint).

  otherwise().exception(YourSoapException)

I hope this helps,

Hadrian