There is a lot of noise right now around DSLs (Domain Specific Languages) and the notion that people can easily build new languages that are centered around a specific vocabulary that makes sense for the problem domain. While I think we’ll probably be in DSL hell in about 2 years where there thousands of new languages for doing everything and nothing, there is one DSL I would like to propose for Service Composition.
On the Mule project we need a DSL to make Java-based configuration more usable and intuitive. We are about to embark on this part of the project, but it seems to me that we need to stop and think about the bigger picture.
The notion of “service”, “component”, ‘’interface“, “endpoint”, “router”, “filter”, “policy”, etc are common concepts that appear in different flavours in all products targeted for the SOA space. It would seem logical to define a common DSL for constructing services. Using these concepts.
I see two possible ways of defining this DSL –
- Define a set of Java APIs for building services. This would consist of a set of Interfaces, some helper builders, and well-defined extension guidelines. The problem with this is that it is Java-specific; we really want to write services in other languages such as C# and Ruby.
- Define the DSL in pseudo code with clear guidelines of how to implement the DSL interface in any language. The actual DSL interface would still need to be implemented for a specific technology, but no matter what technology or platform I am using the DSL is familiar to me.
My preference would be for #2 as it would be platform agnostic and have a much better chance for adoption but it also has the added benefit that it would create an universally accepted glossary of concepts for constructing SOA. I should point out that SCA has a similar goal but is Xml-centric. SCA seems to a step in the right direction but we’re not seeing the mass-adoption yet to make SCA stick. I really think there is room for a DSL here.
I would really like to flesh out this idea since we at Mule could really use it and I think it would benefit the wider community.