Reflexiones sobre internal vs external DSL

Me toco durante Diciembre evaluar 3 formas de implementar ruteo y transformación de mensajes usando Sun OpenESB .  Sun provee 3 formas distintas de hacerlo:

• con la versión de producción actual:
• usando BPEL y llamadas a servicios vía WSDL para operaciones más complejas.
• usando Apache Camel dentro de OpenESB
• con la versión en desarrollo, llamada fuji, usando el Integration Flow Language (IFL).

IFL es un DSL externo y Camel usa DSL internos basados en Java , Spring-XML o Scala .  Comparando las soluciones pude hacerme una opinión sobre el DSL interno vs externo.

Primero algunos comentarios

• XML es un pésimo lenguaje para definir un DSL.  Una de las gracias de un DSL es que debe ser fácilmente legible y XML no permite eso porque agrega mucha sintaxis que no aportan nada para un ojo humano.

• IFL como DSL externo esta bien construido: 
• la sintaxis es super simple porque no tiene todos los adornos del lenguaje subyacente que hacen ilegibles un DSL sobre XML y que molestan en caso de Java..  
• Sun no incluyo en IFL sintaxis para programación más compleja, como por ejemplo para enriquecer un mensaje. En su lugar permite encapsular código jRuby que puede llamar a servicio Java vía Web Service.  El defecto de esta solución es que requiere usar muchos lenguajes distintos (IFL, Ruby, WSDL, Java).

• Camel usa 3 tipos de DSL internos:
• sobre Spring-XML: es ilegible.
• sobre Java: Java tiene una sintaxis inflexible para ser usado como base de un DSL interno:  principalmente el uso del punto y de los paréntesis para llamar a métodos   
• sobre Scala: creo que es un buen ejemplo de lo potente de la sintaxis Scala

• Los DSL internos de Camel basados sobre Java o Scala, permiten llamar todas las bibliotecas del lenguaje sin pasar por una interfaz WSDL o un lenguaje de scripting.  Es una ventaja considerable para anticiparse a la necesidad de crear extensiones.

Mi posición sobre interno vs externo

Los ESB son un ejemplo donde hay que pensar de antemano en como crear extensiones.  Es entonces, un buen caso de uso para probar lo potente del concepto DSL.

Por su simplicidad, me parece correcta la solución de DSL interno de Apache Camel.  Como el ESB va a ser configurado por un programador, la poca sintaxis Scala necesaria (como la definición de paquete y los import) no molesta mucho.

Si tuviera que implementar un DSL, mi primera opción sería entonces un DSL interno.