Inspired by the several sessions of Tech-Ed Europe I decided to spend some effort on Domain Specific Languages (DSL) and Guidance Automation Toolkit (GAT). Although I have done some reading on Software Factories the area of building a Software Factory is quite new for me. Therefore I thought it would be interesting (for me and my current employer) to see the capabilities of these new technologies that are first members of Microsofts Software Factories initiative. To make it a little more appealing than just creating some sort of “Hello World” example I decided to try to combine it with some of my “day to day” work (which is architecting systems). Because I am definitely no expert in DSL’s I also decided to share some of my thoughts and issues to hopefully get some feedback to push me in the right directions.

Here is the idea: build a Domain Specific Language (DSL) to model “services”, perform some code generation and use GAT to provide some context-specific menus and templates within Visual Studio.Net IDE to speed up development based on the DSL.

Doesn’t sound too difficult so let’s give it a try. One of the things I do know about building a Software Factory is that you have to define what (reusable) parts can be identified within the domain. You also have to make sure the complete implementation details for all of the parts you are trying to model in a DSL and automate with GAT are available (and proven!).

For now, let’s assume these conditions are met. I will describe some of the parts I think are members of the service domain. Because my focus is on getting familiar with DSL and GAT, I will not describe all parts (and details) within the domain. As soon as I am totally up to speed with DSL and GAT (and still find it interesting) I will complete the model to make it a little more useful.

One of the most obvious parts that can be identified within this domain is the actual “service” itself. When translating this to a DSL this can be the “root” of the DSL. The service is composed out of other parts that I will call “service components” (it’s just a name).

Some of the service components I identified for this example:

• Service Interface; operations that are exposed by the service (service contract).
• Service Operation; definition of a service operation.
• Transport Interface; the representation of the service interface targeted at a specific technology (web service, enterprise service, remoting.)
• Message; definition of the messages exposed by service operation
• Service implementation; the actual implementation of the business logic
• Service Adapter; layer between the transport interface and the service implementation.

The above service components are all in their most basic form and they might not even cover the whole service domain. For example, it is very likely that in reality the message contains a data definition that is implemented as a data class based on an XSD definition. For now (this example) I will forget about al of these details. In this example a message is just represented by a class with a name that can be used as either input or output for a service operation.

I think, I will soon find out what parts (or details) I am missing here when I start modelling my DSL. During the modelling phase I will add only the absolute necessary properties and relationships.

The next step will be to prepare the environment by installing the DSL Toolkit and the Visual Studio 2005 SDK for Beta 2 and than we are ready to start experimenting with DSL.

To be continued…