On 10 February 2011 11:25, sebastien.petrucci <[email protected]> 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: [email protected] Web: http://fusesource.com Twitter: jstrachan Blog: http://macstrac.blogspot.com/ Open Source Integration
