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.
|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 Studiobasically 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 honestthere is limited tool support for crafting WSDLand 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.
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 filesbut now on a higher abstraction level that is both more understandable and more natural for developers.
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.