oftware Factories are one of today’s new buzzwords in IT. 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 including Visual Studio 2005 Team System, the Guidance Automation Toolkit, and the DSL Tools. This article discusses domain-specific languages, one of the pillars of Software Factories. We’ll try to answer such questions as: 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?
This article starts 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, guiding you through this new technology using a real-life example of a domain-specific language that models service contracts in a service-oriented world to aid in building distributed solutions.
Software Factories
When we take a close and objective look at the industry we are working in, we cannot help 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 over budget, shipping products of poor quality, and overall to unsatisfied consumers. So, it could be argued that it’s 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, which 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 it becomes increasingly 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 these are valid within their own specific domain. Think of a Software Factory as a product line in a real factory tailored to assemble a specific type of product, such as a car.
Keep in mind that the Software Factory will not deliver all pieces of the puzzle?you’ll still need custom code?but the intention is that Software Factories will both speed up development and improve long-term quality dramatically.
Before we can optimize our working environment 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 of. Think of artifacts as individual parts in our software, such as items in 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, such as A Software Factory Approach to HL7 Version 3 Solutions, or Web service Software Factory have become available. We have to see how they evolve to know whether 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). You can use this toolkit to create guidance packages that you can load into Visual Studio. A guidance package in Visual Studio 2005 is an integrated set of reusable scripts, patterns, and code snippets. GATs automate repetitive and often boring activities, delivering features such as wizards, artifact generation, and context-aware guidance that help developers work in the Software Factory. The ultimate goal of the GAT is to increase software development process productivity and eliminate rote and menial tasks as much as possible by making guidance and automation available in Visual Studio.
 | ? |
| Figure 1. The Software Factories Ecosystem. The figure shows tools and concepts grouped to form a Software Factories ecosystem. |
The last piece in the Software Factory tools puzzle is Microsoft’s 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 artifacts 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. Together the guidance package and the domain-specific language are loaded into the Visual Studio Team System environment, forming the actual Software Factory. Of course this is today’s state and the entire tooling story may change with upcoming releases of Visual Studio.
We will focus on domain-specific languages for the rest of this article.
Domain-specific Languages
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, providing 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. That’s a big difference compared to a general purpose language such as C#, which 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 words “Microsoft” or “DSL Tools” in this definition, right? That’s correct. Domain-specific languages don’t depend on any Microsoft tooling. In fact, domain-specific languages have existed for quite some time now and aren’t valid only in the Software Factories context. Technologies such as SQL, XSD, and even Windows Forms provide a range of examples of domain-specific languages with which most of us are quite familiar. With that said, note that DSLs aren’t always graphical (see Martin Fowler’s article, Language Workbenches: The Killer-App for Domain-specific Languages?).
But the availability of the DSL Tools makes ot relatively easy for a developer or architect to build a domain-specific language. DSL Tools also provide a way to add a graphical representation and an appropriate designer to your domain-specific language. All of this is great?but those aren’t the core features of a domain-specific language; however, they 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 DSLs for design and development?
First of all, a domain-specific language provides a clear view of the problem domain for which we are writing software (or parts of software). Using a DSL?and especially one that comes with a graphical designer?forces us 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 necessarily mean you’d use only one domain-specific language to build a software component. It’s 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 concepts. Relations between concepts that don’t make sense are simply not allowed in the language and/or designer. This limited set of concepts and possible relations stimulates standardization in software component design.
Another related advantage of a domain-specific language lies in the higher level of abstraction. Design sessions often 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 to use the WSDL specification for this same discussion. In addition, it is much easier to share software component designs crafted in a domain-specific language designer between team members than to share pictures you took of a design you created on a whiteboard.
Last but not least, fully adopting domain-specific languages in our development process will increases productivity considerably, not only because of design-time savings, but also because of the time we can save by generating artifacts such as C# source code. A very interesting side effect of code generation is that it provides a quality boost and increase in standardization. This, of course should result in fewer bugs, code that is easier to maintain. Developers 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 infancy, 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 consequences and issues very carefully and make sure we fully integrate Domain-specific Languages into 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 regenerate 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 effective, it’s definitely not the most elegant solution. First, this approach might not work for all types of artifacts. In the case of a C# file generated from 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 make changes in the model and still regenerate the artifacts without losing any 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 implement round-tripping 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. This approach solves the possibility of the models and artifacts getting 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. Features such as round-tripping are tempting and many developers will start building these kinds of features into their domain-specific language right away. 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; therefore we think it is more important to focus on understanding domain-specific languages integrating 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 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 and demonstrate the power of domain-specific languages.
Services Everywhere
 | ? |
| Figure 2. Contract-first Modeling: Here’s a graphical representation of schema-based, contract-first modeling of Web services. |
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 for now, remember 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 (see Figure 2).
While the contract-first approach has proven popular and is often applied in enterprise scenarios, the approach is really tedious without the right tooling. For more information see the article Introducing Contract-First Web services.
This is exactly where our sample domain-specific language comes in. Let’s be honest?there is limited tool support for crafting WSDL?and few people feel comfortable writing WSDL by hand. Therefore, it’s an ideal opportunity to 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
This example creates a domain-specific language that helps us design service contracts. The artifact generated by this domain-specific language is a service contract description that is represented as WS-I BP 1.1-compliant WSDL. Using this domain-specific language, we will be able to create WSDL files?but now on a higher abstraction level that is both more 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 an approach that prevents you from getting lost in the technical details of the DSL Tools while designing 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 appear. We recognize that building a domain-specific language might multiple 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 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.
 | ? |
| Figure 3. Solution Explorer View: Here are the 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 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 modeling 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.
Table 1. The table shows WSDL concepts in the sample DSL.
DSL Concepts | WSDL Element |
ServiceInterface | |
ServiceOperation | |
Message | |
DataContract (definition) | |
MessageHeader (definition) |
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. 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 you need Visual Studio 2005 Team System and the Microsoft DSL Tools installed on your 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, this should 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.
 | ? |
| Figure 4. Sample DSL Domain Model: Here’s a graphical version of the domain model for the sample DSL. |
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.
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.
 | ? |
| Figure 5: Designer Markup: The figure shows an XML snippet of the designer markup. |
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.
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” (press F5) from within Visual Studio Team System, which 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 to prepare for graphically modeling the service contract for any service we would like.
Modeling a Service
Figure 6 shows the concepts available for modeling 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 so there’s 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 8. Model Service: Here’s a RestaurantService modeled with the sample DSL. |
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.
Customizations
 | ? |
| Figure 9. Custom UI Property Editor: Attaching an XSD to a Message. |
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.
When we click the button a file dialog box pops up (see 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.
|
|
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.
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 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.
|
|
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 modeling our service contract using the modeling 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 and are processed by a text transformation engine that is part of the DSL Tools. This is the same engine 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 modeling 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.
