Introducing Domain Specific Languages

One of today’s new buzzwords in IT is Software Factories.

This Microsoft initiative is likely to change the way that developers build software in the near future. The Software Factories initiative and vision doesn’t stand on its own, however. It’s initially supported by a set of new tools like Visual Studio 2005 Team System, the Guidance Automation Toolkit, and the DSL Tools. In this article, we will discuss Domain Specific Languages as they are one of the pillars of Software Factories. What is their role in Software Factories? How can they help you develop software? Is this just more hype or will Domain Specific Languages really change the way we build software in the not too far future? Let’s find out on the next pages.

This article will start with a brief discussion of the Microsoft Software Factories initiative together with the first wave of accompanying products. We will discuss the role that these individual products play in the Software Factories initiative and show you how they relate to each other. We will use this knowledge as a context for positioning Domain Specific Languages and the Microsoft DSL Tools. We will guide you through this new technology by using a real-life example of a Domain Specific Language that we can use to model services contracts in a service-oriented world when building distributed solutions.

Software Factories

When we have a close and objective look at the industry we are working in, we cannot but conclude that our software industry doesn’t do a very good job compared to most other industries-especially those with a long history of engineering.

Overview

The way we are building software today often leads to projects running out of budget, shipping products of poor quality and therefore leads to overall unsatisfied consumers. So, it could be argued that its time for the software industry to grow up. This is exactly where the Microsoft Software Factories initiative comes in.

The theory behind Software Factories is discussed in the book called Software Factories [1]. It describes how the software industry can change the way we are working, how to build software by assembling reusable components, how to move from craftsmanship to industrialization and therefore how to increase the capacity and performance of the software industry as a whole. All of this sounds great but what does this mean for us as architects and developers?

Let’s have a look how we can translate the theory behind Software Factories to a real life scenario. The basic idea is that the “general purpose” development environment (in the .NET world this usually is Visual Studio) will be customized by the architects and developers in a company. This environment will gradually be tuned for their specific business. The development environment (Visual Studio) provides the mechanism to facilitate the customization. The development team provides the effort that is necessary to customize it. Over time, developers will find it easier to do their development tasks because more of it becomes automated. In the end, it’s the optimized development environment that we call a Software Factory.

Normally, the Software Factory is optimized for a specific type of software. This means the development environment provides developers with components, patterns, architectural rules, and semi-finished products that they can use to compose software. All of them are valid within their own specific domain. Think of a Software Factory as a product line in a real factory that is tailored for assembling a specific type of product, like a car.

Keep in mind that the Software Factory will not deliver all pieces of the puzzle-custom code is still needed-but it is the intention that Software Factories speed up development and hopefully improves long-term quality dramatically.

Before we can optimize the environment we are working in we need to have a good understanding of the type of software we are building. That means we have to identify the so-called artifacts that our software can be composed off. Think of artifacts as individual parts in our software that can be various items in the range of configuration files, source code, and even frameworks. This list of artifacts is like a recipe for a meal and is called the Software Factory Schema. This Software Factory Schema also describes the relations between the different products in the list so we know how to use them together to actually cook the meal. The Software Factory Schema only sums up and describes the artifacts; the real implementations of the products, mentioned in the Software Factory Schema, form the Software Factory Template. Think of this as a set of patterns, frameworks, templates, guidelines, etc. In the end, it’s the Software Factory Template that we use to configure a tool like Visual Studio 2005 Team System to transform it into an optimized environment for building a specific product family.

At this moment we are just in the very early stages of Software Factories. Very slowly, some early examples ([2], [3]) become available. We have to see how they evolve and if Software Factories will meet the expectations of the future.

Accompanying Tools

Now that you know that the Visual Studio environment acts as the placeholder for all Software Factory components, let’s look at some other complementary products to complete the big picture. Remember, Visual Studio provides the customization mechanism that will be used by the tools we will discuss now.

Another totally new tool is the Guidance Automation Toolkit (GAT, [4]). You can use this toolkit create guidance packages that you can load into Visual Studio. A guidance package is an integrated set of reusable scripts, patterns, and code snippets that you can use in Visual Studio 2005. By using GAT we can automate repetitive and often boring activities. We can deliver things like wizards, artifact generation and context-aware guidance that help developers work in the Software Factory. The ultimate goal of GAT is to increase the productivity of our software development process and eliminate the rote and menial tasks as much as possible by making guidance and automation available in Visual Studio.

The last piece in the Software Factory tools puzzle is the Microsoft DSL Tools. This toolkit makes it possible to create Domain Specific Languages that we can use in our Software Factory. As you will see in the remainder of this article, Domain Specific Languages and the DSL Tools are yet another way to automate and improve the software development process for certain aspects of a system.

Software Factories Ecosystem

Before we continue with Domain Specific Languages in some more detail, let’s summarize the Software Factories ecosystem. Figure 1 displays the individual tools and concepts grouped together that we call the Software Factories ecosystem. The Software Factory Schema describes the artifacts that are relevant for a specific problem domain. These artifacts, in turn, are implemented as frameworks, source code, configuration files, and Domain Specific Languages. The frameworks, code, and configuration files are used in the Guidance Automation Toolkit to create a guidance package; the Domain Specific Languages are implemented with the DSL Tools. It’s the guidance package and the Domain Specific Language together and loaded in the Visual Studio Team System environment that form the actual Software Factory. Of course this is today’s state and the entire story about tooling may change with upcoming releases of Visual Studio.

Domain Specific Languages

Now that we have a have a high level understanding of the Microsoft Software Factories initiative and the available tools in this area, we will focus on Domain Specific Languages for the rest of this article.

Definition

A Domain Specific Language is a custom language that targets a small problem domain. It describes the problem at a higher abstraction level than general purpose languages do. It just provides another view of the same problem.

That’s it, nothing more, nothing less. Let us explain a little why we think this is a proper definition of a Domain Specific Language. First of all, a Domain Specific Language can only be used to describe a specific problem. This is a big difference compared to a general purpose language like C# where we can describe all sorts of problems. It is the limited focus of a Domain Specific Language that makes it possible to describe the problem in abstractions that make sense to the problem. Because of these abstractions, the problem is easier to understand for a larger group of people. The underlying problem, however, remains just the same.

But wait, we haven’t heard the word ‘Microsoft’ or ‘DSL Tools’ in this definition, right? That’s correct. Domain Specific Languages can live perfectly without any Microsoft tooling. In fact, Domain Specific Languages have existed for quite some time now and are valid not only in the Software Factories context. Technologies like SQL, XSD, and even Windows Forms are all simple to more complex examples of Domain Specific Languages that most of us are quite familiar with. And that said, they are far from always being a graphical thing [5].

But with the availability of the DSL Tools [6] it becomes relatively easy for a developer or architect to build a Domain Specific Language. It’s the DSL Tools that also provide a way to add a graphical representation and appropriate designer to the Domain Specific Language. All of this is great but these are not the core features of a Domain Specific Language. However, these are the features that will probably increase the adoption of Domain Specific Languages and give it a boost. The presence of the DSL Tools and the primary role that Domain Specific Languages play in the Microsoft Software Factories initiative makes Domain Specific Languages something new to hype.

Advantages

With this understanding of the concept of Domain Specific Languages, let’s look at some of their obvious advantages. In other words, why should we as a developer or architect use them for our design and development?

First of all, a Domain Specific Language provides a clear view of the problem domain we are writing software or parts of software for. By using a Domain Specific Language-and especially one that comes with a graphical designer-we are forced to focus our attention on the important concepts in the domain. Only the concepts that exist within the Domain Specific Language are valid candidates for discussion during the design phase of our software. This doesn’t mean that only one Domain Specific Language is used for building a software component. It is possible to use several Domain Specific Languages that together cover the whole problem domain. Also, a Domain Specific Language helps us create valid relations between the concepts. Relations between concepts that don’t make sense are simply not allowed in the language and/or designer. Because of this limited set of concepts and possible relations we will see that we stimulate standardization in the design of our software components.

Another related advantage of a Domain Specific Language is the higher level of abstraction we are dealing with. How often do design sessions end up in long discussions about nitty gritty details that are definitely not important in the design phase of the project, at least not at early stages? A Domain Specific Language not only helps us focus on a limited set of concepts; the concepts are also described at a higher abstraction level. As you will see later in this article, it is much easier to talk about service contracts in terms of ServiceInterface and ServiceOperations than using the WSDL specification for this same discussion. In addition, it is much easier to share designs of software components you crafted in a Domain Specific Language designer between team members than sharing pictures you took of a design you created on a whiteboard.

Last but not least, when we have fully adopted the usage of the Domain Specific Languages in our development process, we will notice that we can increase our productivity considerably. Not only because of the time saved in the design phase of our software, but also because of the time we can save by generating artifacts like, for example, C# source code. A very interesting side effect of generating code is the quality boost and increase of standardization this can have on our source code. This, of course (or hopefully?), results in fewer bugs, code that is easier to maintain, and developers that no longer have to code the boring stuff but can concentrate on the much more interesting parts. Be honest-isn’t that what we want?

All that Glistens Is Not Gold

Because Domain Specific Languages related to .NET and Visual Studio are in their very early stages, it is likely that the majority of us don’t have any experience with building and using Domain Specific Languages.

The Microsoft DSL Tools are very new and therefore probably immature. They might miss some important features; therefore, to be successful in this Domain Specific Language area it’s not enough to just install the tools and go for it. We have to think about the consequences and issues very carefully and make sure we fully integrate Domain Specific Languages in our development process.

Pending Discrepancies

Assume we build a complete Domain Specific Language with the Microsoft DSL Tools. The architect and developers use the Domain Specific Language to create fabulous models within Visual Studio 2005 and they can even generate some useful artifacts to speed up the development. Now what? How do we treat the model compared to the generated artifacts? Which one is leading? How do we keep them in sync? These are all valid questions that need to be answered.

First of all, which one is leading: the model or the artifacts that get generated? This one is easy, we would argue the model. But why? The primary task of the Domain Specific Language is to describe the problem domain in a higher level of abstraction. A Domain Specific Language helps people better understand the concepts and the possible relations between them that exists in a specific problem domain. The model is the end result and acts as the input for the artifact generation. Although it might be tempting, we would not recommend manipulating the generated artifacts by hand without changing the model first.

Now that we are dealing with a Domain Specific Language-and thus with a higher level of abstraction-we must learn to treat the model and not the code as the primary source. This might be a mental switch, especially for developers, and therefore we must try to keep the relation between the model and generated artifacts as tight as possible.

Seeking Cadence

This leads us to another important issue: how do we keep the model and artifacts in sync? One of the simplest approaches would be to periodically re-generate the artifacts. You could even use an automatic build procedure. All manual changes that might have been made in the artifacts simply get overridden. Although this is an effective way it is definitely not the most elegant one. One issue with this approach is that it might not work for all types of artifacts. In the case of a C# file that is generated out of the Domain Specific Language, we can use the partial class technique to separate the generated code from any custom code we want to add later during development. By doing this we can still make changes in the model and re-generate the artifacts without loosing our manual changes. It becomes a little more difficult when we are dealing with a Word document that is one of the Domain Specific Language artifacts.

Another and maybe better approach is to have round-tripping implemented for a Domain Specific Language. This assures a tight coupling between the models we create and the artifacts that are generated out of the model. With this approach we solve the issue that models and artifacts might get out of sync. Round-tripping isn’t supported out of the box in the initial release of the DSL Tools. However, you can (probably) implement it by writing custom code. For a lot of us developers, things like this might sound very tempting and they will start right-away building these kinds of features into their Domain Specific Language.

However, we think it is better not to focus too much on technical features and/or limitations of the current release of the DSL Tools. The DSL Tools will evolve over time and therefore we think it is more important to focus on understanding Domain Specific Languages and the integration of them in your development process.

To summarize, we believe that Domain Specific Languages and the models based on them must become a first class citizen in your design and development process. At the end of the day, you want to make sure that the models still reflect the actual software. You don’t want your model to be outdated documentation for your sources. If that is what you want, you can stick with UML, frankly. The model should lead; you don’t want to make manual changes in the generated code if round-tripping is not supported so you must put the models under source control just like the rest of your code. All of these procedures and guidelines can, of course, be part of your overall Software Factory.

A Real Life Example

Now that you understand some Domain Specific Language concepts it’s time to get real and build a small example of a Domain Specific Language. Please note that this article doesn’t cover all the details of building a Domain Specific Language with the DSL Tools. There will be plenty of articles and books that will guide you through all the details. Our example Domain Specific Language will demonstrate the kind of problems you can model with a Domain Specific Language. Our example will demonstrate the power of Domain Specific Languages.

Services Everywhere

Most developers are familiar with Web services. We all know by now how to build a Web service within Visual Studio-basically just set the [WebMethod] attribute on a class’ methods. After that you rely on ASMX to expose the service contract to the public world. While this approach might work for some developers, our experiences in the past made very clear that this might not always be the best way. Thinking about service contracts evolved over time and resulted in another, probably better, approach for designing service contracts called contract-first. This article will not cover all the details of the contract-first approach but let’s remember for now that a special flavor of contract-first-called schema-based contract-first-uses XSD schemas and WSDL for designing service contracts. Within this approach you first model your data and messages by using a schema language (like XSD) and after that you define your service interface and service operations in WSDL. From those interoperable metadata artifacts a developer can then create platform and programming language-specific code (Figure 2).

Figure 2: Schema-based contract-first modeling of Web services.

While proved and popular and often applied in enterprise scenarios, this approach is really tedious without the right tooling [7].

This is exactly where our sample Domain Specific Language comes in. Let’s be honest-there is limited tool support for crafting WSDL and not many of us feel comfortable writing WSDL by hand. Therefore, let us introduce a Domain Specific Language for designing service contracts named “Service Description Language” because WSDL and related technologies are not the right level of abstractions to achieve the goal.

Problem Domain

Our example will create a Domain Specific Language that helps us design service contracts. The artifact that is generated by this Domain Specific Language is a service contract description that is represented as WS-I BP 1.1-compliant WSDL. By using this Domain Specific Language we will be able to create WSDL files but now on a higher abstraction level that is understandable and more natural for developers.

Guided Approach

To be successful in building your own Domain Specific Language, we think it is important to stick to some sort of an approach so you don’t get lost in all kind of technical details of the DSL Tools in the design phase of your Domain Specific Language.

Therefore we suggest the following steps:

Describe the domain concepts;
Describe the artifacts you are planning for the Domain Specific Language;
Build your domain model;
Build the designer for your Domain Specific Language;
Build the artifact generator;
Implement validations and constraints;
Test and deploy the Domain Specific Language;

This article uses some of these steps to demonstrate a number of concepts of Domain Specific Languages and our Service Description Language in particular. Please note that our approach isn’t as formalized as it might look like. We recognize that building a Domain Specific Language might need a few iterations and refinements during the development process. This approach helps you achieve this understanding.

Describing Domain Concepts

The first thing you have to do when building a Domain Specific Language is make sure you understand the problem that you are trying to model exactly and thoroughly. In our example this is service contracts and its relation to WSDL. Let’s have a quick look at some concepts in the Domain Specific Language and describe them in a little more detail.

Let’s start with the ServiceInterface concept which is the high-level abstraction of the service contract. The ServiceInterface describes which operations and accompanying messages are exposed by the service. It’s the ServiceInterface that actually describes what can be done with the service.

Next we have the ServiceOperation concept, which defines an operation in the ServiceInterface. The ServiceOperation describes the message exchange patterns and the accompanying messages for the operation. In other words, it defines the input and optional output message for the operation. (The sample DSL only supports two basic message exchange patterns from WSDL: one-way and request-response.) This leaves us with the next concept, the Message. A Message is a placeholder for the data structures that are used in the ServiceOperations. In real life, Messages are often described in an XSD schema and referenced in WSDL. Since the Message holds the definition of the data structures, this is where the concept of a DataContract comes in. A DataContract represents the data structure itself-think of it as the data on the wire. Just like Messages, you often define DataContracts in an XSD schema. A Message consists of one or more DataContracts. Please note that the DataContract concept in our example Domain Specific Language doesn’t necessarily relate to the Windows Communication Foundation DataContract [8].

Figure 3: Initial solution projects for building a custom DSL.

Another concept that is embedded in the Message is the MessageHeader. You use the MessageHeader to store out-of-band data that has to flow with the message. For example, you might have user credentials that need to travel with the message to the ServiceOperation.

How did we find the concepts in our service contract domain? We had a close look at elements that can be identified in WSDL and we made sure we understood their purpose. Remember that in our example, WSDL and service contracts are the problem domain. After we looked at the elements, we tried to describe them at a higher abstraction level that makes sense to developers and architects who design and build services.

It is exactly this step in the approach that is extremely important when starting to build your own Domain Specific Language-Don’t start modelling before you know what you are trying to solve.

Table 1 gives you an overview of the concepts that exist in our Service Description Language together with their WSDL counterparts. It’s eventually the WSDL part that gets generated out of the Domain Specific Language.

Describing Artifacts

The next step in building a Domain Specific Language is describing the artifact(s) you are planning to use in your Domain Specific Language. Of course, you also need good knowledge of the artifacts to be able to describe the domain concepts in the first step, but in this step you formalize the artifacts in more detail. For example, when you think a piece of C# code is the artifact of your Domain Specific Language, you write a first version of this C# code in this step. The reason for this is that you can use this formalized artifact to validate the domain concepts you defined in the first step. For our example we just had a close look at the WSDL specification and the WS-I BP 1.1 [9]. An example of a valid and proven WSDL was enough to act as our formalized artifact. Remember that artifacts or the number of artifacts change during the development phase of your Domain Specific Language.

Building Domain Models

Based on a clear understanding of the problem domain and the knowledge of what an initial version of our artifacts looks like, let’s really start building our Domain Specific Language. To do this we need Visual Studio 2005 Team System and the Microsoft DSL Tools installed on our machine.

Note that any code or screenshots in this article are based on the November 2005 CTP release of the DSL Tools. Although significant changes are expected in the final release of the DSL Tools, we think this will have little impact on the content of this article because we don’t provide step-by-step guidance for how to build a Domain Specific Language with the DSL Tools.

Getting Started

To get started you first have to create a new solution within Visual Studio that is based on the “Domain Specific Language” template. A wizard will guide you through this process and will ask some details like name, namespace, and file extension for your language. After you’ve completed the wizard, Visual Studio will load with a solution that you can build your Domain Specific Language in.

We will use the domain model designer within Visual Studio to graphically build the domain model for our language. Figure 4 shows the domain model of the Service Description Language. The current state of the domain model only reflects the concepts we need for describing the service contract itself. Of course, this domain model can evolve over time to cover more service-related topics.

As you will see when you try this yourself, creating a domain model is just a matter of dragging elements from the toolbox to the designer area. In this step, we’ll represent the domain concepts that we defined earlier for our Domain Specific Language as classes in the domain model. You can add custom properties to classes and make them participate in relationships. As the name probably implies, you can use a Relationship to relate domain concepts with each other.

Figure 4 shows that we created a relationship from the ServiceOperation concept to the Message concept in our Service Description Language. We also created relationships from the Message concept to the DataContract and MessageHeader concept. If you have a close look at the latter relationships in the screenshot you can see they are represented by a solid line. The relationship between the ServiceOperation and Message concepts is represented by a dotted line. The difference between both is caused by the type of relationships we used in both cases.

Figure 4: Graphical domain model of the sample DSL.

The dotted line represents a “reference relationship” between ServiceOperation and Message. In plain English, this relation means a ServiceOperation “knows about” or “is using” a Message. The solid line represents an “embedding relationship” between a Message and a DataContract and or MessageHeader. This means that the DataContract (or MessageHeader) is part of the Message. In other words a Message consists of a DataContract and MessageHeader. As you will see later on in this article, the difference between the two types of relationships will also show up in the designer for the DSL.

As you will notice when experimenting with the DSL Tools, the domain model is persisted as XML and is stored in a file with extension .dsld and can be found in the DomainModel project in the Visual Studio solution. This will change in the RTM release of the DSL Tools.

Without going into too much detail, you saw how to translate the identified domain concepts into a domain model within the DSL Tools. Let’s look at how to continue building our language.

Building a Designer

Now let’s build a designer for the language. As we said earlier in this article, the graphical designer does not make any language a Domain Specific Language, but since providing a graphical designer for a Domain Specific Language is part of the DSL Tools we will be more than happy to use this feature.

Just like the definition of the domain model, the designer definition is stored as an XML file with a .dsldd extension and can be found in the Designer project of the Visual Studio solution. Unfortunately it isn’t possible to graphically maintain this designer definition in the November CTP of the DSL Tools. Also there is no strict relation between the domain model definition and the designer definition. Therefore you have to make sure you keep both files in sync by hand, which can be a tedious task. All of this will change in the RTM release of the DSL Tools.

Figure 5 shows a snippet of the designer definition file where we describe the MessageShape in the language. The MessageShape is the graphical representation of the Message concept in the Service Description Language. As you can see, the MessageShape is a so-called CompartmentShape and also holds the definition for the DataContractShape and the MessageHeaderShape. (Think of the embedding relation between the Message, DataContract, and MessageHeaders concepts.) Also note that we added two extra ShapeIcon elements, named RightArrow and LeftArrow, to the definition of the MessageShape. We’ll explain a little later why we needed to do that.

Figure 5: XML snippet of the designer markup.

Using the Domain Specific Language

Now that we have completed our domain model and designer definition we are ready to use the language for the first time. To do this we can simply choose “Start debugging (F5)” from within Visual Studio Team System. This results in a new, so-called experimental environment of Visual Studio were we can use our language. We will create a new model based on the Domain Specific Language template, in our case this is the Service Description template. We’ll add a new empty model based on this template to the Visual Studio project so we’re ready to graphically model the service contract for any service we would like.

Modelling a Service

Figure 6 shows the concepts that are available for modelling the service contract. You might notice the absence of the DataContract and MessageHeader concepts. These concepts are represented as compartment shapes “inside” the MessageShape. Therefore we cannot create them stand alone from a message and thus there is no need for these concepts to appear in the toolbox.

Figure 7 illustrates that we can simply right-click on the DataContract placeholder in the MessageShape to add a DataContract to it. The same is true for adding a MessageHeader. This is all default behavior of the DSL Tools designer that we created for our language.

Figure 7: Modelling a message with DataContracts.

After playing around a little with our Domain Specific Language we modelled the service contract for a sample “RestaurantService.” As you can see in Figure 8 the service has one ServiceInterface named RestaurantServiceInterface that exposes three ServiceOperations named GetRestaurants, AddRestaurant, and RateRestaurant. When we have a look at the GetRestaurants service operation we can see that it has an incoming message named GetRestaurants and an outgoing message named GetRestaurantResponse. At this point you can also see where we needed the two extra ShapeIcons that we described earlier. What we didn’t show then is that we added a MessageType property to our Message concept. MessageType is an enumeration with InboundMessage and OutboundMessage as possible values. Based on the value of this property on the Message level we decide which icon to show in the MessageShape. The icons are specified in the ShapeIcon elements in the designer definition mentioned earlier.

Figure 8: A RestaurantService modelled with the sample DSL.

Customizations

As you can see in Figure 8, all service operations have one or more DataContracts specified. We already demonstrated that you can simply right-click a MessageShape to manually add a DataContract to the message. Adding a DataContract in this way is out-of-the-box functionality that you get when creating embedding relations between concepts. However we decided to make the DSL a little more user-friendly and therefore built some additional functionality by using a piece of custom code. The default way to set a value of a property on a domain concept in the Domain Specific Language designer is to simply type the value of the property in the Visual Studio property grid. We didn’t like that too much, especially for the SchemaLocation property on our message concept. Therefore, we created a custom UiTypeEditor coupled with the SchemaLocation property of the message shape in our language. Figure 9 demonstrates that we now have the little ellipsis button (…) that appears in the Visual Studio property grid for the SchemaLocation property.

Figure 9: Attaching an XSD to a Message.

When we click the button a file dialog box pops up (Figure 10) that enables us to navigate to the XSD file that contains the parts of our message. In our example we select the RestaurantMessages.xsd file.

Figure 10: Selecting the message XSD file.

With the XML schema that contains a description of our messages selected, now we must select the actual message in the XSD file. To support this we created an extra menu item that is only available when right-clicking on a MessageShape. Figure 11 shows how we use this custom “Select message from XSD” menu item on the MessageShape to select a message from the XSD.

Figure 11: Custom menu item for the MessageShape.

When we select this menu item another window pops up that provides us with a nice overview of all the messages that are described in the selected XSD file. Figure 12 shows that the RestaurantMessages.xsd file we selected earlier describes four messages. We can now select a message and see the DataContracts that are referenced in that message. Please note that the DataContracts itself are not defined in the RestaurantMessages.xsd file but only referenced from another XSD file.

Figure 13: Properly populated message shape.

After selecting the rateRestaurant message in the “Select message” window the MessageShape in the model gets nicely populated with the correct name of the message, DataContracts, and all the appropriate references and type information of the message and DataContracts. All of the above functionality is added by using custom code. The DSL Tools API makes it relatively easy to add features you implemented in any .NET technology you find appropriate to extend the DSL’s feature set.

Generating Artifacts

Now that we’ve finished modelling our service contract using the modelling technique described above we can generate the artifact. In the Domain Specific Language we are describing in this article we want to generate a WS-I BP 1.1-compliant WSDL file that represents the service contract description. The out-of-the-box technique that comes with the DSL Tools for generating artifacts is T4 text templates. T4 text templates have a CodeSmith-like syntax [10] and are processed by a text transformation engine that is part of the DSL Tools. This is the same engine that is used for the Guidance Automation Toolkit. Basically it comes down to mixing boilerplate text with information that comes from models you create in the language. For our Domain Specific Language we choose not to use the T4 templates and instead generated our artifacts in plain C# code. We simply added custom code that uses the model information to communicate with our code to generate WSDL. This again demonstrates the customizations possibilities of the DSL Tools API.

Closing Thoughts

We described a sample and prototype Domain Specific Language that we created for generating service contract descriptions and how they fit into Microsoft’s vision and idea of Software Factories. The language is capable of generating WSDL based on the model we created in the language designer. At this moment the language only focuses on the WSDL part of the service contract and it heavily relies on XSD for describing the messages and data contracts. One feature that we didn’t describe in this article is the possibility to read an existing WSDL file and create a graphical representation of the service contract in the language designer.

Due to the very early beta-like state of the DSL Tools we didn’t go into too much detail about the actual building of a Domain Specific Language. We primarily wanted to demonstrate the power of Domain Specific Languages in general and provide you with an example that can you could build in the current release of the DSL Tools. In this respect it is important to note that the first release of the DSL Tools might miss a few of your requirements. Don’t let this fact discourage you from starting to build Domain Specific Languages. We demonstrated that you can address these potential missing features by writing some custom code.

We will make this Domain Specific Language for modelling service contracts available for download as soon as Microsoft releases the DSL Tools. At that point we will also provide some more technical details about the features we implemented in this language. We’ll also post more details and the download in our blogs.