CODE Magazine - Article_ Introducing Domain Specific Languages

7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages

1/20

9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages

www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true

Introducing Domain SpecificLanguages

One of todays 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 doesnt stand on its own, however. Its 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? Lets

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 doesnt

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?

Lets have a look how we can translate the theory behind Software

Factories to a real life scenario. The basic idea is that the general

By: Christian Weyer

Christian Weyer is co-founde r of thinktecture(http://www.thinktecture.com/),a company that helpssof tware a rchitects and

develope rs to build projectswith .NET and distributedapplications technologies.He is a recognized XML,Web services, and se rvice-orientation e xpe rt. As aMicrosoft MVP for SolutionArchitecture and one of thefew independent Microso ftReg ional Directors, he ha smade a name for himself inthe developers andarchitects community. Hehas worked fo r many yearswith Microsoft technologie slike COM/DCOM, COM+ and

.NET. Christian has spokenat many well-knowndeveloper conferences andforums worldwide and is apublished author, editor,and writer of numerousarticles for various Germanand international technicalmagazines. Visit his Weblogathttp://weblogs.asp.net/cweyer/to find out more about Webservices and service-oriented integration andprogramming, not just onthe .NET platform.

Website:http://www.thinktecture.com/

Weblog:http://weblogs.asp.net/cweyer/

[email protected]
http://www.thinktecture.com/mailto:[email protected]://weblogs.asp.net/cweyer/http://www.thinktecture.com/http://weblogs.asp.net/cweyer/http://www.thinktecture.com/


2/20


www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 2

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, its 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, its 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, lets 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

By: Edward Bakker

Edward is working as asof tware architect forLogicaCMG, a majorinternational force in ITservices and wirelesstelecoms. You can contacthim by sending a mail [email protected] visit his weblog athttp://www.edwardbakker.nl .

[email protected]

Fast Facts

Microsoft Software

Factories, part of

Visual Studio 2005

Team System, is a set

of tools, models,

softwaredevelopment

methods and

practices, that will

help you use the VSTS

environment to

support the rapid

development of a

specific type of

application.
mailto:[email protected]://www.edwardbakker.nl/mailto://[email protected]


3/20



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 MicrosoftDSL 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, lets 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 Schemadescribes 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. Its 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 todays state and the entire story about tooling may

change with upcoming releases of Visual Studio.


4/20



Figure 1: The Software Factories ecosystem.

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.

Thats 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
http://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%201.gif


5/20



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 havent heard the word Microsoft or DSL Tools in this

definition, right? Thats 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, andeven 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. Its

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 thatDomain Specific Languages play in the Microsoft Software Factories

initiat ive makes Domain Specific Languages something new to hype.

Advantages

With this understanding of the concept of Domain Specific Languages,

lets 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. Byusing 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 doesnt 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 dont 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 stimulatestandardization 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


6/20



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, forexample, 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-isnt 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 dont

have any experience with building and using Domain SpecificLanguages.

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 its 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 theMicrosoft 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 thepossible 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


7/20



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 withthis 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 aregenerated out of the model. With this approach we solve the issue

that models and artifacts might get out of sync. Round-tripping isnt

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 Spec ific 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 andthe 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 dont 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 dont 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 SoftwareFactory.

A Real Life Example

Now that you understand some Domain Specific Language concepts its

time to get real and build a small example of a Domain Specific

Language. Please note that this article doesnt 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


8/20



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. Thinkingabout 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 lets 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).


9/20



Figure 2: Schema-based contract-f irst 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.

Lets 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
http://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%202.png


10/20



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 dontget 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 isnt 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. Lets have a quick look at some

concepts in the Domain Specific Language and describe them in a little

more detail.

Lets 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 theservice. Its 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

&


11/20



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

DataContractcomes 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 doesnt 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-Dont 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.

Its 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


12/20



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, lets

really start building our Domain Specific Language. To do this we need

Visual Studio 2005 Team System and the Microsoft DSL Tools installedon 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

dont 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 VisualStudio 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 youve

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, well 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 Messageconcept 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.


13/20



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.

Lets look at how to continue building our language.

Building a Designer

Now lets 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 .dslddextension and can be found in the

Designer project of the Visual Studio solution. Unfortunately it isnt


14/20



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 ServiceDescription 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. Well 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. Well add a new empty model

based on this template to the Visual Studio project so were 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.


15/20



Figure 6: Toolbox items for sample DSL.

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 didnt show then is that we added a MessageType

property to our Message concept. MessageType is an enumerationwith 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.
http://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%207.pnghttp://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%206.png


16/20



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 simplyright-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 didnt 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 nowhave 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.
http://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%209.jpghttp://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%208.png


17/20



Figure 10: Selecting the message XSD file.

With the XML schema that contains a description of our messagesselected, 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.


18/20



Figure 12: Selecting a message element.

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 DSLs feature

set.

Generating Artifacts


19/20



Now that weve 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 textwith 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 Microsofts vision and idea of Software Factories. The languageis 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

didnt 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 didnt 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 thatcan 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. Dont 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. Well also post

more details and the download in our blogs.

Links

[1] Software Factories: Assembling Applications with Patterns, Models,

Frameworks, and Tools;

http://www.wiley.com/WileyCDA/WileyTitle/productCd-

0471202843.html

[2] A Software Factory Approach to HL7 Version 3 Solutions;

http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/dnbda/html/hl7softfac.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/hl7softfac.asphttp://www.wiley.com/WileyCDA/WileyTitle/productCd-0471202843.html


20/20


[3] Web Service Software Factory;

http://www.gotdotnet.com/codegallery/CodeGallery.aspx?

id=6fde9247-53a8-4879-853d-500cd2d97a83

[4] Guidance Automation Toolkit;

http://msdn.microsoft.com/vstudio/teamsystem/workshop/gat/

[5] Language Workbenches: The Killer-App for Domain Specific

Languages?;

http://www.martinfowler.com/articles/languageWorkbench.html

[6] DSL Tools; http://msdn.microsoft.com/vstudio/DSLTools/

[7] Introducing Contract-First Web Services; http://www.code-

magazine.com/Article.aspx?quickid=0507061

[8] Distributed .NET-Learn the ABCs of Programming Windows

Communication Foundation;

http://msdn.microsoft .com/msdnmag/issues/06/02/WindowsCommunicationFoundation/default.aspx

[9] WS-I Basic Profile 1.1; http://www.ws-i.org/Profiles/BasicProfile-

1.1-2004-08-24.html

[10] CodeSmith; http://www.codesmithtools.com/

Christian Weyer

Table 1: WSDL concepts in the sample DSL.

DSL Concepts WSDL Element

ServiceInterface

ServiceOperation

Message

DataContract (definition)

MessageHeader (definition),
http://www.codesmithtools.com/http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.htmlhttp://msdn.microsoft.com/msdnmag/issues/06/02/WindowsCommunicationFoundation/default.aspxhttp://www.code-magazine.com/Article.aspx?quickid=0507061http://msdn.microsoft.com/vstudio/DSLTools/http://www.martinfowler.com/articles/languageWorkbench.htmlhttp://msdn.microsoft.com/vstudio/teamsystem/workshop/gat/http://www.gotdotnet.com/codegallery/CodeGallery.aspx?id=6fde9247-53a8-4879-853d-500cd2d97a83

CODE Magazine - Article_ Introducing Domain Specific Languages

Documents

Transcript of CODE Magazine - Article_ Introducing Domain Specific Languages