Rinat Abdullin

What about extending xLim2 with DSL implementations?

As you can see from the overview article, the minimal development cost of implementing first Domain Specific Language in your solution is:

Cost(generic_DSL_framework) + Cost(specific_DSL_implementation)

where initial cost of generic DSL framework could be close to zero, if you reuse Boo compiler and Rhino.DSL. And the cost of specific DSL implementation normally revolves around writing the appropriate base class with all the syntax specifications.

Now, when you have all this in place, development cost of adding another DSL implementation to your solution (in the optimistic scenario) would just depend on creating yet another base class.

So, if it looks so easy for us to add different Domain Specific Languages to our information management solution, what could we do?

• DSL for workflow definitions (WWF is just too heavy)
• DSL for the complex security rules
• Business rules DSL
• DSL for specifying Smart Client UI composition for different user roles (composite web UI could reuse this, too)
• Message routing rules

And remember, that you can compile these DSL implementations to .NET at build-time (this results in easier development) or at run-time (also adds flexibility of run-time configuration of the system).

Given all this efficient flexibility at low development cost (and possibly low maintenance costs), it is no wonder that Boo-based DSLs are being considered for the introduction into the architecture concept of building lightweight extensible information management systems.

Obviously, pros and cons of this step are yet to be researched, but I already could think of some big chunks of code, that could be thrown out of the existing xLim 2 implementations.

Tags: DSL, xLim

No comments yet.

Leave a comment