code magazine - article_ introducing domain specific languages
TRANSCRIPT
-
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/
http://www.thinktecture.com/mailto:[email protected]://weblogs.asp.net/cweyer/http://www.thinktecture.com/http://weblogs.asp.net/cweyer/http://www.thinktecture.com/ -
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
2/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
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 .
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] -
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
3/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 3
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.
-
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
4/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 4
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 -
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
5/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 5
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
-
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
6/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 6
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/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
7/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 7
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
-
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
8/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 8
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).
-
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
9/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 9
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 -
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
10/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 10
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
&
-
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
11/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 1
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
http://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%203.png -
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
12/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 12
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.
-
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
13/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 13
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
http://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%204.png -
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
14/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 14
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.
http://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%205.png -
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
15/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 15
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 -
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
16/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 16
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 -
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
17/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 17
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.
http://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%2011.pnghttp://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%2010.png -
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
18/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 18
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
http://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%2013.pnghttp://www.code-magazine.com/ShowLargeArticleImage.aspx?QuickID=0607051&Image=Figure%2012.png -
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
19/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
www.code-magazine.com/articleprint.aspx?quickid=0607051&printmode=true 19
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 -
7/30/2019 CODE Magazine - Article_ Introducing Domain Specific Languages
20/20
9/2/13 CODE Magazine - Article: Introducing Domain Specific Languages
[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