Thursday, August 18, 2005

Now that I am in the process of building my own DSL for modelling services I started thinking about the usage of DSL’s a little more. Suddenly I see all kind of opportunities for new DSL’s but also some issues so I thought why not share them with you and ask for your opinion.

 

Thinking about the “service DSL” I am experimenting with a little further, a possible next step would be to build a language that models the cross cutting concerns for services.

 

Suppose we have all (or at least some J) our crosscutting concerns modelled in a DSL and we are able to simply configure a service with the crosscutting concerns by using the DSL designer and “drop” the crosscutting concerns on the service area. (For now, let’s assume it is possible to attach the crosscutting concern to the service by only using a configuration file without the need to make any changes in code.)

 

A language like this would make it relatively easy to generate the necessary config file that actually attaches the crosscutting concerns to the services that are “hosted” in the WSE pipeline, Indigo Windows Communication Foundation or some other piece of infrastructure.

 

Although being able to attach crosscutting concerns to services would be great for creating the initial configuration file the next step is of course to also maintain these “settings” for production software. Unfortunately there are some burdens on our (my) way to make this happen. For example, the current release of the DSL tools only support “one-way” generation. This makes it impossible to generate a model based on an existing configuration file. I assume this will change in the future. Is it Microsoft? Similar functionality is already available in the VS.NET class designer.

 

A second issue might be the hosting of the DSL. Until now the DSL designers can only be hosted within the Visual Studio.Net IDE. If Microsoft isn’t going to change this in the future, IT Pro, responsible for the running the services in production, have to use the Visual Studio.Net environment to maintain their configuration files. Forcing the IT Pro department to use Visual Studio.NET for maintaining and supporting software (configuration) might sound strange but this might become reality sooner or later. If we believe Microsoft IT Pro will start using VS.Net to create and maintain their logical data centre models in the near future. On the other hand it might be good to have some sort of a light weight hosting environment for DSL’s.

 

A third thing that comes to mind is the “size of the DSL” and the possibility to share concepts between DSL’s. One of the goals of a DSL is to target a certain problem domain. In my example, we have a DSL for modelling services and one for attaching crosscutting concerns to services. Both languages share common issues and therefore in theory can be integrated in one language. But wait, this would mean that our IT Pro department that is only supposed to use the “crosscutting concern part” of the language also has the possibility to use the “modelling services” part of the language. Modelling (and building) services is definitely no responsibility of IT Pro and thus integrating the two different features (modelling and crosscutting concerns) into one language might seem reasonable from an domain perspective but doesn’t reflect the responsibilities of the IT Pro employee very well.

 

An obvious option is to keep the two features in separate languages. In this case however we have the “service concept” that is part of both languages. Of course we can model (and maintain) this concept in both languages but is that what we want?! The ideal situation would be to have the possibility to “import” concepts from one DSL into another DSL and have the capability to use some sort of access control on the details of a concept. In this example we could have one DSL targeting “services” but make sure the IT Pro department can only use the “service concept” for attaching crosscutting concerns to services and cannot view (and use) all details that the developer can use to model the service.

 

Of course the above issues are described by using the “service” domain I am experimenting with but I assume they can be translated to a more general case.

 

What do you think, should we “worry” about issues as “one way” generating, DSL hosting environments and sharing concepts between DSL’s or just focus on things we can do with the current DSL technology?