camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <ja...@fusesource.com>
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
<sebastien.petrucci@gmail.com> 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...
http://camel.apache.org/bam.html

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
endpoint.

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

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

-- 
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

Mime
View raw message