The MessageHeader concept in our DSL has an attribute “SchemaLocation” (the same is true for Message and DataContract). This property is a reference to the XSD description of the MessageHeader. Another property of the Message concept is the “Namespace” property. The value of this property is used in the WSDL that is generated out of the Domain model of our DSL. In an attempt to make our DSL as user friendly as possible I decided to set the “Namespace” property automatically as soon as the “SchemaLocation” is populated.

To make this possible I wrote a propagation rule (one of the customization features of the DSL Tools) to make this happen.

Below you can see the code that is needed for a propagation rule. I stored this code in a separate .cs file in a folder called “custom” that I created in the designer project. The rule inherits from “ChangeRule”. The implementation isn’t that difficult (note: just demo code)

Because the code that actually retrieves the “Namespace” out of the XSD file is stored in another assembly that isn’t part of the DSL assemblies, I had to add the assembly to the GAC to make it work.

To make sure the rule gets fired we need to add a variable to the “GeneratedMetaModelTypes” class. This class is reflected on to dynamically load rules. The variable is the reference to the new propagation rule described above. The following code snippet will do the trick.

Internal static partial class GeneratedMetaModelTypes
{
        internal static Type DomainModelMessageHeaderPropertiesChangesRule =
                                    typeof(DomainModelMessageHeaderPropertiesChangesRule);
}

As you can see in the image below (I know this image doesn’t prove a lot!) the “Namespace” property gets set after we populate the “SchemaLocation” property of the MessageHeader with a valid value.

To be continued...

Because we made some good progress with building the core functionality of our DSL I decided to spend some time on the customization options of the DSL Toolkit.

I tried some of the customizations described in this document that can be found on the DSL Tools forum and also implemented the “ToolTipText” for all of the shapes and connectors by using the code that is described in this post of Pedro Silva.

Another thing that I found was necessary was changing the color scheme of the Shapes. I decided to use some RGB colors and found out that using an “RGB color code” in the designer.dlsdd file isn't an option. It wasn't too hard to found out how this can be achieved by writing some lines of custom code. As you can see in the code snippet below it is just a matter of overriding the FillColor property in a partial class for the Shape.

public partial class ServiceOperationShape
{

    public override Color FillColor
    {
        get
        {
            return Color.FromArgb(132, 150, 172); 
        }
            
    }

}

The Message concept in our DSL is holding an embedding relation for the DataContract and MessageHeader concept. Therefore our MessageShape is a compartment shape this means for these two compartments there isn’t a possibility to override the FillColor property in a partial class.

We had to find another way to changes the color. It turns out that compartments can be reached in custom code by using the “compartmentDescriptions” collection on the parent shape. As you can see in the code snippet below I used the “OnInitialized” of the MessageShape (parent) to set the “TitleFillColor” property of the two compartments in the MessageShape to an RGB color code. (Maybe there is a better place to set the color but this does work. Another option would be the “ OnShapeInserted“)

public partial class MessageShape

{

      public override void OnInitialized()

      {

            ...

MessageShape.compartmentDescriptions[0].TitleFillColor = Color.FromArgb(132,150,173);

MessageShape.compartmentDescriptions[1].TitleFillColor = Color.FromArgb(189,162,123);

      }

}

As you can see in the image below the color of the compartments are changed (compared to the colors in some previous posts). Also a “TooltipText” is displayed when moving the mouse over the connector shape. The tooltipText is composed out of the information of the two shapes that are connected by the connector.

To be continued...

Great news! The DSL Team just released a guide that describes how to customize the features and capabilities of the DSL Toolkit (September CTP). Thanks guys!

This guide describes for example how to use custom code to create: “transparent text decorators”, straight lines, shadow and gradients, container object, etc. All techniques that can dramatically improve the modelling experience of your DSL.

A lot of other interesting features are covered in this document including the explaining code samples. Of course al of this is subject to change in the next releases of the Toolkit. But if you don’t like that, don’t use CTP products and wait for the V1 release!

Anyone interested in this guide, go get it following this link to the DSL Toolkit forum.

Have fun and expect a lot of the features described in this guide in the DSL we are building.

It’s been some time since I wrote about the progress of the DSL we are working on. Not because there is no progress anymore but mostly because I am very busy with my regular work so I simply have no time left to write a post. It’s still my intention to have the DSL fully operational by the time V1 of the DSL Toolkit is available and so far I don’t see any reasons why this wouldn’t be possible.

I am now using the September CTP of the DSL Toolkit. Unfortunately the migration of the whole project took some more time than expected. I followed all steps of the (perfect) migration guide but still I got an error when trying to use the designer of my Language in the debug instance of Visual Studio.NET. It took me some time and a little help of the DSL Team to find out that my designer definition file contained some “shape definitions” that I wasn’t actually using anymore. These shapes were now part of a compartment shape in my language but I had forgotten to delete the definitions from the file. The May CTP build didn’t have any problems with this. The very cryptic error message (“package …. Has failed to load properly”) wasn’t very helpful for finding the problem. So solving this issue took some time. The good thing of course is to see that more and more validations are built in the Toolkit. I have good faith that the final release will provide more descriptive (helpful) error messages for these new validationsJ.

What are we working on now? Currently we are working on the “generating WSDL part”. This WSDL will be based on the service description that is modelled by using the DSL. For me this basically this comes down to writing some T4 templates to mix the “service description” (modelled in the language) with some pure C# code that Christian wrote to generate the WSDL. This work is almost done. From there we can do basically everything we want with code generation.

There isn’t much information available about writing T4 templates. Anybody interesting in writing these templates might find some help in this blog post of Gareth Jones (DSL Team) about the T4 syntax. A little information about how to navigate over your DSL model can be found here on the Domain Specific Language Tools forum.

Some directives that I needed within the templates:

To include files (create some sort of a function library):

<#@ include file="filename.extension" #>

To reference an assembly:

<#@ Assembly Name="System.Web.Services.dll" #>

To import a namespace:

<#@ import namespace="System.Web.Services.Description" #>

A lot more information about writing templates will be made available in the V1 release of the Toolkit. By then all the API that can be used for writing templates will be stable and no longer subject to change.

To be continued…

Currently I am working on code generation for the DSL we are building. The DSL Toolkit comes with some sort of a framework that can be used to build templates for generating artifacts (based on the model). In this release of the toolkit however, writing templates is a poor experience (just my opinion J). The templates are displayed as “text files” within the Visual Studio.NET 2005 IDE without any syntax coloring. This makes large templates very hard to read. As you can see in the image (small part of the template) below it is very hard to make a distinction between the C# code that is needed for generation the artifact and the C# snippets that are part of the artifact and thus part of the template. The image below is only a simple and small part of the templates so imagine a large template.

The good news is that the DSL team is working on (or at least thinking of) providing a richer template writing experience. Hopefully this will make it in the next CTP release of the DSL Toolkit! I definitely I can’t wait for a better coding experience!

Enough complaining. As you can see in the two images below, it is possible to generate some code based on a model. The template above also shows that navigation the model isn't too hard either (foreach ServiceArtifact in this.Service.ServiceArtifacts). The image shows the C# code that is generated based on the definition of the “service interface” in the DSL designer. No rocket science but it works. Of course, more code can be generated but this is just an example.

One of the artifacts that I will generate (based on the model) will be an xml representation of the modelled concepts and their relations. I think that might become handy if I want to use another code generator engine that isn’t based on the DSL Toolkit Templates and thus might not integrated very well with the DSL model. Hopefully this gives me some more flexibility when it comes to generating the artifacts in the future.

To be continued…

It’s time for another update on the progress of our DSL. Christian and I have been working on the underlying model of our Domain Specific Language we are building. We made some changes to make the model better reflect the “service design” domain.

For anyone interested in some background information on this topic (service design), go read this article of Christian. It explains some fundamental concepts that might help you understand the domain model a little better.

Please note that the model below is still work in progress. It is very likely that it will change in the near future. Some of the concepts and relations are based on restrictions in the current release of the DSL Toolkit and might not reflect the perfect “designing services” world. Also getting the code generation to work properly might force some changes in the underlying model. For now let’s have a quick look at the model and briefly discuss a few concepts. (I am sure in the end a more detailed explanation of the complete model will follow)

If you have seen the previous version of the model you notice the new “DataContract” concept in this version of the model. The “DataContract” describes the data that we need to exchange. In our language the “DataContract” is a reference to an XSD description of the data, therefore the “DataContract” concept has a name, “schemalocation” and a “namespace property”.

The “Message” concept (previous “RequestMessage” and “ResponseMessage”) has an embedding relation (solid line in the model) to “DataContract”. The “Message” concept reflects the messages we need to exchange the data that we defined in the “DataContract”. A message can hold one or more “DataContracts”. Messages can be of the type “Inbound” or “Outbound”.

The “ServiceOperation” concept in the model reflects the definition of a  serviceoperation of the service. The “ServiceOperation” has a “MessageExchange” property that can be set to either “OneWay” or “RequestResponse”. Based on this property the serviceoperation will have a reference (dotted line in the model) to one or two “Messages”.

Another interesting (?) design decision in the model is the embedding relation from the “Service” concept to the “Message” concept. We want to explicitly display the “Message” and “DataContract” concepts on another level than the other “ServiceArtifact” concepts. As you can see in the picture below of the “ServiceDescription Explorer” (part of the designer of this language), there are two child notes below the “Service” (CustomerService) concept. The “Messages” node as the root for the messages and datacontracts and the “ServiceArtifacts” node acting as the root for all other items.

Ideally we would have displayed the messages and datacontracts under the appropriate serviceoperation in the “ServiceDescription Explorer”, but to get that to work we needed some changes in the relations between the concepts. In our case this would result in concepts participating in more than one embedding relation which is not allowed in the current release of the DSL Toolkit. This will probably change in the next upcoming CTP build!?

On the left of the “ServiceDescription Explorer” you see an example of these three concepts used in the designer based on this early preview of the model. Here we modelled a services operation (GetCustomerDetails) referencing one inbound message (GetCustomerDetailsRequest) and one outbound message (GetCustomerDetailResponse). Both messages hold one or more datacontracts in the message.

Hopefully this clears some things up for the “DataContract”, “Message” and “ServiceOperation” concepts. More information on the other concepts in another post. 

To be continued…

It’s been a while since I wrote about the progress of my DSL experiment. Why does it take so long? Is it so hard to build a DSL? Well, actually sometimes I think it is. It takes some time to really understand what is going on in all the files that are part of the DSL solution. Most of this is because of the technology preview status of the toolkit and therefore the limited documentation that is available. In the current release some of the files have to be maintained by hand which can only be done if you have a good understanding of the xml structure of the files. Most of this manual work will disappear in the next release of the toolkit. Luckily there is an active forum and the DSL Toolkit team that is willing to help!

But, let’s continue on the status. Three weeks ago Christian Weyer of Thinktecture contacted me to let me know he liked the work I am doing in my DSL experiment. As you can read in this post on his blog Christian is thinking about using DSL’s for modelling service interfaces and data contracts for some time. We decided to discuss this “service modelling” domain via email and to join forces and build this language together.

So, the last few weeks we discussed the artifacts that can be identified within the service domain and how to model them in our DSL. As a result some of the names of the concepts that I modelled in an early version of the language have changed to make them more descriptive and some new concepts are introduced. Currently I am making the last changes in the model. After that we have to finish the designer for the language and finally we can do some code generation. In another post I will show a next version of the model and hopefully explain some of the ideas behind it.

Hopes this clears thinks up. The experiment is not dead. Expect to hear of it a lot more in the coming days, weeks, months.

To be continued…

Now that I am in the process of building my own DSL for modelling services I started thinking about the usage of DSL’s a little more. Suddenly I see all kind of opportunities for new DSL’s but also some issues so I thought why not share them with you and ask for your opinion.

Thinking about the “service DSL” I am experimenting with a little further, a possible next step would be to build a language that models the cross cutting concerns for services.

Suppose we have all (or at least some J) our crosscutting concerns modelled in a DSL and we are able to simply configure a service with the crosscutting concerns by using the DSL designer and “drop” the crosscutting concerns on the service area. (For now, let’s assume it is possible to attach the crosscutting concern to the service by only using a configuration file without the need to make any changes in code.)

A language like this would make it relatively easy to generate the necessary config file that actually attaches the crosscutting concerns to the services that are “hosted” in the WSE pipeline, Indigo Windows Communication Foundation or some other piece of infrastructure.

Although being able to attach crosscutting concerns to services would be great for creating the initial configuration file the next step is of course to also maintain these “settings” for production software. Unfortunately there are some burdens on our (my) way to make this happen. For example, the current release of the DSL tools only support “one-way” generation. This makes it impossible to generate a model based on an existing configuration file. I assume this will change in the future. Is it Microsoft? Similar functionality is already available in the VS.NET class designer.

A second issue might be the hosting of the DSL. Until now the DSL designers can only be hosted within the Visual Studio.Net IDE. If Microsoft isn’t going to change this in the future, IT Pro, responsible for the running the services in production, have to use the Visual Studio.Net environment to maintain their configuration files. Forcing the IT Pro department to use Visual Studio.NET for maintaining and supporting software (configuration) might sound strange but this might become reality sooner or later. If we believe Microsoft IT Pro will start using VS.Net to create and maintain their logical data centre models in the near future. On the other hand it might be good to have some sort of a light weight hosting environment for DSL’s.

A third thing that comes to mind is the “size of the DSL” and the possibility to share concepts between DSL’s. One of the goals of a DSL is to target a certain problem domain. In my example, we have a DSL for modelling services and one for attaching crosscutting concerns to services. Both languages share common issues and therefore in theory can be integrated in one language. But wait, this would mean that our IT Pro department that is only supposed to use the “crosscutting concern part” of the language also has the possibility to use the “modelling services” part of the language. Modelling (and building) services is definitely no responsibility of IT Pro and thus integrating the two different features (modelling and crosscutting concerns) into one language might seem reasonable from an domain perspective but doesn’t reflect the responsibilities of the IT Pro employee very well.

An obvious option is to keep the two features in separate languages. In this case however we have the “service concept” that is part of both languages. Of course we can model (and maintain) this concept in both languages but is that what we want?! The ideal situation would be to have the possibility to “import” concepts from one DSL into another DSL and have the capability to use some sort of access control on the details of a concept. In this example we could have one DSL targeting “services” but make sure the IT Pro department can only use the “service concept” for attaching crosscutting concerns to services and cannot view (and use) all details that the developer can use to model the service.

Of course the above issues are described by using the “service” domain I am experimenting with but I assume they can be translated to a more general case.

What do you think, should we “worry” about issues as “one way” generating, DSL hosting environments and sharing concepts between DSL’s or just focus on things we can do with the current DSL technology?

Just a quick update:

I received two emails of people asking me if my little DSL experiment has stopped. The answer is NO!

Because of some positive feedback I decided to spend more time on the design of the language. At first, the model was mostly meant to help me understand the DSL toolkit, now I’ am actually trying to build a usable language.  

That’s why it is a bit quite on the topic, just because I don’t think it is very interesting to write about every small change in the language design.

In my opinion the experiment is getting more interesting and definitely more useful.

To be continued…

Although my model isn’t quit finished yet, I decided to see how my language behaves in the Visual Studio experimental build environment. You can enter this environment by executing “Start without Debugging” from the VS.Net “Debug” menu in the VS.Net environment you are designing your language in.

Within the experimental build environment I created a new “serviceoperation” class (GetCustomerDetails). After that I created a new “responsemessage” (GetCustomerDetailsResponse) class. And last, a relation between the “serviceoperation” and the “responsemessage”. The model for this looked something like this (actually the little collapse picture in the right corners wasn’t there at first).

To be honest I wasn’t quite happy whit the “modelling experience”. Besides the poor colours of the classes (which can be easily changed) I wasn’t sure if this is the best way of using the designer for this part of the language. Therefore I had another look at the possibilities and found out about “compartment shapes”. A compartment shape can be defined as a shape (class) that can host another shape (class).

Here is what I did; I changed my original “serviceoperation” class into a compartment shape that is capable of “hosting” a “reguestmessage” shape and an “reponsemessage” shape. To create a compartment shape you have to make some changes in the designer xml file. Not that straight forward but I’ am sure this will change in the next release of the toolkit!?

As you can see in the picture below the “serviceoperation” class now hold to “placeholders”. One for the “requestmessage” class and one for the “responsemessage” class.

By right clicking the response message placeholder you actually get a menu option to create the “responsemessage” class (see below). Till now my messages classes in my language only have a “name” attribute. I have to test what happens if my messages classes contains a little more attributes. I’ am not sure how this is represented in within the designer and how easy it is to view or change example the message attributes. I assume only the name if the message will be displayed in the serviceoperation class and by double clicking you can change the attributes but a little more effort is needed on this. (In the image below I right clicked the RequestMessage placeholder to add an new “requestmessage“ class).

For now, imagine yourself designing (and generating the code) your services with a language like this. I think it’s pretty cool!

To be continued…