Mailing-List: contact camel-dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of james.strachan@gmail.com
 designates 64.233.184.233 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=Q5p1wp10C/rlv04k9gqFmEp5zmbSJvMkr+45kbg+O3la8/O59RF7RjuOr1+8PBFzJN
         dDoGJ3+/2Ug7hzdBnsngfcdh734khfV2IZimOoatj4hSDHPAPzTIX6uUvEXo9JEFP9nW
         dBFIPVOYA8dowJGlrFNXlQtidikcfOjnQ8A10=
Message-ID: <ec6e67fd0809010622g28faf14dibd4351a6a653737c@mail.gmail.com>
Date: Mon, 1 Sep 2008 14:22:14 +0100
From: "James Strachan" <james.strachan@gmail.com>
To: camel-dev@activemq.apache.org
Subject: Re: camel spring xml restructure
In-Reply-To: <48B997A8.6080604@cox.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4C1FB9C00D24A140906239533638C4D20536F751@EXVS04.exserver.dk>
	 <48B997A8.6080604@cox.net>

2008/8/30 Vadim Chekan <vchekan@cox.net>:
> Claus,
>
> I'm glad you see the problem. Arguably, difficulties with routing
> configurations is one of the the biggest obstacles on wider Camel adoption.
> There is nothing more frustrating than knowing exactly what you want in
> terms of EIP but spending many hours with so minor issue as syntax.
>
> Interesting enough, I was thinking about it yesterday too and my conclusion
> is such that it is very difficult to achieve smooth configuration using xml.
> It is not the tool for the job. I mean it can do it (it does it currently)
> and we can keep improving it but will we get the easiest possible way of
> configuring camel routes?
> I'll skip large philosophical discussion but in my opinion xml sometimes
> becomes victim of its own success and programmers try to stretch its
> application beyond the reasons because "xml is so great, I would add it to
> my salad if I could" :)
>
> Basically we are trying to define Abstract Syntax Tree in xml serialized
> form. People don't usually think in terms of AST.

Totally agree BTW. FWIW I'd always envisioned we'd have multiple DSLs;
Java, XML, Groovy, Ruby, Scala and even a real DSL - hopefully all
using the same AST underneath...
http://activemq.apache.org/camel/maven/camel-core/apidocs/org/apache/camel/model/package-summary.html

allowing folks to create routes using one language and save them in
another DSL if folks wanted to etc.


> We can give a whirl an idea of Domain Specific Language (DSL). I have some
> under my belt and it is not too difficult. The result would look like this
> (syntax can be any, but I'm trying to be java script alike):
>
> routes {
>  route {
>    from 'queue:Incoming'
>    process {
>      bean 'org.my.company.camel' 'MyFunction'
>      aggregator()
>    }
>    if (header('myHeader') == 'value1') {
>      to 'queue:Outgoing'
>    } else {
>      to 'queue:Alternative'
>    }
>  }
> }

Have you looked at the Scala DSL? Its pretty close to this already! :)
http://activemq.apache.org/camel/scala-dsl.html
http://activemq.apache.org/camel/scala-dsl-eip.html

> I thought about juel (or others evaluators).
> I see a problem that those languagas will dictate syntax which may be not
> optimal for camel route definition domain.
> Another and bigger problem is that external language will not detect camel
> invalid constructions. For example creating serializer but not assigning it
> data format would be invalid in camel but from Juel point of view it would
> be perfectly ok.

Yeah - we need to make sure we validate as much of the AST up front as
we can along with giving great error messages.


> Having our own syntax parser will let us detect any syntax deviations and
> provide user with very clear and informative error messages for example "
> 'bean' or 'aggregator' are expected inside in 'process' ".
>
> Another benefit we get is Backus-Naur Form (BNF) file which is human
> readable and is very easy to use in documentation. As opposite to xml schema
> which can be used for learning purposes but I would not risk claiming it a
> recommended way.
>
> Here are fragments of BNF as I see it:
> route :
>        ROUTE
>        | from_list process_list to_list
>        ;
> ...
> process_list :
>        /* can be empty*/
>        | process
>        | process process_list /* works as pipiline */
>        ;
>
> process :
>        /* can be empty */
>        | BEAN LITERAL
>        | MULTICAST '{ process_list '}'
>        | PIPELINE '{' process_list '}'
>        | SPLIT LITERAL
>        | AGGREGATE expression
>        | AGGREGATE
>        | resequence
>        ;
>
> resequence :
>        BATCH RESEQUENCE
>        | BATCH RESEQUENCE expression
>        | BATCH RESEQUENCE NUMBER NUMBER
>        | BATCH RESEQUENCE NUMBER NUMBER '(' expression_list ')'
>        | STREAM RESEQUENCE resequence_options
>        | STREAM RESEQUENCE resequence_options '(' expression ')'
>        ;
>
> to_list :
>        to
>        | to to_list
>        ;
>
> to :
>        LITERAL
>        | IF '(' bool_expression ')' THEN to
>        | IF '(' bool_expression ')' THEN to ELSE to
>        ;
>
> If you guys think it worth a try I can mock up a prototype.
> I think I would build an AST and then have another process which would
> traverse AST and invoke RouteBuilder to build the actual route.
> This way we preserve backward compatibility with existing ways of building
> routes.
>
> This route builder would be a separate plugin in order to be as little
> invasive as possible.
>
> AST can be used in future to build graph representation of camel routes
> without building the actual routes. I recall James recent comment that
> building route for display purpose only (without running it) added some
> complexity.
>
> Let me know what do you think folks.

I've always fancied a real DSL as well :). As you mention - the
hardest part of any real DSL is what language is used for
predicates/expressions. e.g. do we let any language be used...

xpath( /foo/bar )

or something?

But it'd be great to try make one. Incidentally if you do fancy
experimenting with this; have a look at the xtext library in eclipse.
I created a little prototype project here...

https://svn.apache.org/repos/asf/activemq/camel/ide/camel-eclipse/

which attempts to take an Antlr grammar for the DSL and auto-create
both a parser but also an eclipse based editor for the language. It
takes an Antlr grammer here...

https://svn.apache.org/repos/asf/activemq/camel/ide/camel-eclipse/camel.routing/src/camel.xtxt

which as you can see is kinda basic :)

Having both a nice textual DSL along with an IDE to edit it would rock :)

Its well worth looking at the Scala DSL which looks great; maybe they
could both look and feel kinda similar? FWIW the only thing I don't
like with the scala DSL is the use of _ which is a bit odd - but thats
a scala thing

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com