camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: How to extend the Spring DSL ?
Date Thu, 10 Feb 2011 12:12:55 GMT
On 10 February 2011 11:25, sebastien.petrucci
<> wrote:
> Thank you for your answer.
> I just would like to better explain what I'm doing.
> I work on a product which is an integration platform for the financial
> world. This product is used in some banks and coporates. Our product is
> built on top of another commercial ESB, for which we provide a number of
> specific extensions (custom connectors, message validation, statefull
> routing ...)
> As we want to rethink our product and move away from our current ESB, I'm
> currently evaluating the various solutions available on the market. So far,
> I've seen some of the bigger products (like Oracle SOA) as well as lower
> level integration frameworks like Apache Camel or Spring Integration.
> To me, Camel has some trully some valuable assets ... the most important
> being its simple and intuitive (java or XML) DSL. It really brings an added
> value on multiple levels (dev, clarity, supportability, learning curve,
> ....) that the other solutions don't have.
> I truly thing that, it would be a KILLER FEATURE to make the DSL somehow
> extendable.
> That would allow users to wrap their custom components and expose them as
> verbs, directly in the DSL ! This way, you can specialize Camel to suit your
> needs, preferred practices and components, ... in an elegant way. To my
> knowledge, nobody on the market proposes that !
> Please consider this as a possible enhencement for the future of Camel.
> In the meantime, I will continue my attempts to extend the Spring XML DSL
> without impacting camel-spring.

Note that there's nothing to stop you having custom DSLs outside of
Camel's core. Making an extensible Java + XML + Scala DSL is gonna be
hard (e.g. XSD pain) and quickly loses the value proposition of the
DSL since for tooling a DSL must be static; but its easy right now to
extend those (making new XSDs importing Camel's XSD, or deriving from
the Java builders etc). This is how we do Camel BAM today...

Though its worth questioning, do you really want new verbs or nouns?
Often folks want to drop in their own components into Camel; wrap up
some service or functionality as a black box then route into it or
from it with standard Camel; for this the Camel Component / Endpoint
abstraction seems a perfect fit.

Its very trivial to make something which acts as a regular Camel
Component; you've then logical names or 'verbs' for the individual
endpoints/ports/features the component supports. You can then use
regular Camel DSL to send events/messages into or out of any part of
the component; so you can easily extend vanilla Camel to add any kind
of service or feature; so long as you can represent it as a bean or

e.g. in your example you could do...

  <from uri="..." />
  <to uri="mycompany:semantic-validation/somePackage"/>
  <to uri="...">

Twitter: jstrachan

Open Source Integration

View raw message