This weekend I looked into the Spring MVC framework, and got a bit disappointed with the vast amount of XML configuration that was needed to create a simple starter application.
Then I stumbled upon Apache Camel earlier today, and got a bit happier from the possibility of easy configuration in the Java world.
First, the XML config;
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:start"/>
<loadBalance>
<roundRobin/> <!-- This only support for Camel 1.5 -->
<to uri="mock:x"/>
<to uri="mock:y"/>
<to uri="mock:z"/>
</loadBalance>
</route>
</camelContext>This is of course horrible; I suppose that the amount of XML for a moderately-sized application would, if printed, fill a binder. (And why is the <roundrobin/> placed where it is? Should't it be an attribute of the loadBalance element?)
Then the Java fluent builder;
from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");This is much better. It's quite readable, at least if you can read Java. However, the structure of the configuration, that we can understand quite easily in the XML case, is lost.
This issue is fixed in the Scala DSL;
"direct:a" ==> {
loadbalance roundrobin {
to ("mock:a")
to ("mock:b")
to ("mock:c")
}
}We get a structured and free-form configuration at the same time. It's readable for me, who have quite limited Scala knowledge. My only issue right now is the curlys. I like the way the DSL uses pattern matching in Scala ("direct:a" ==> {...}) fits into this.
If I'd do it in Ruby, I could imagine it something like this:
configure "direct:a" do |route| route style :roundrobin route to "mock:a" "mock:b" "mock:c" end
Readable, structured and sweet.
4 kommentarer:
The Java obsession with XML- and property file configuration is infuriating, and it has been perpetuated in recent years by Springs success, Spring which ironically enough came to be because of the tediousness of XML configuration in the EJB spec..
Luckily things seem to be moving away towards a more Java oriented way (have a look at Google Guice) in most areas, so hopefully we'll be rid of it sooner rather than later.
I think of XML as being a binary format. It shouldn't be read, let alone written by humans. If we then need to debug a solution and look at the XML it we can feed it through an invisible and super-fast parser (i.e. glasses), and it's readable, for that time only.
In the .NET world, the Fluent NHibernate project looks promising, using c# code and lambdas to create the map, instead of describing it in XML or cluttering the model with attributes.
I agree - the Scala DSL looks the cutest so far.
We've tried on Apache Camel to provide an AST to working with integration patterns so that folks can experiment with different representations (be it Java, XML, Scala, Ruby, Groovy or even a real external DSL).
Do you fancy contributing to a Ruby DSL? Have a look at the code for the Scala one, there's not that much code required, its basically just a factory of objects in the org.apache.camel.model package (which is the AST)
http://camel.apache.org/maven/camel-core/apidocs/
So, James, you think it's time I put the money where my mouth is? ;)
I'd give it a solid try, but I've got another project in the pipe right now.
Post a Comment