Monday, September 12, 2005

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…

posted on 9/12/2005 8:15:21 PM UTC  #   
 Monday, August 29, 2005

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…

posted on 8/29/2005 8:42:59 PM UTC  #   
 Wednesday, August 24, 2005

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…

 

posted on 8/24/2005 7:57:56 PM UTC  #   
 Thursday, August 18, 2005

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?

 

posted on 8/18/2005 7:43:07 PM UTC  #   
 Tuesday, August 16, 2005

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…

posted on 8/16/2005 7:38:31 PM UTC  #   
 Saturday, August 06, 2005

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…

 

posted on 8/6/2005 7:43:14 PM UTC  #   
 Thursday, August 04, 2005

I found some spare cycles to continue my DSL experiment.

I wasn’t happy with the initial version of my domain model, so I decided to make some changes in it. Although the model isn’t the most important part of the experiment I figured that it should at least be possible to compile it to continue the experiment.

 

After making some changes in the domain model, I ran into several problems when I tried to get the designer file in synch with the domain model. As a result executing the “translate template” step caused a lot of errors that I was not able to solve.

 

Let me try to explain what happened. Suppose we have the following model:

 

 

 

 

 

When I used the “modelisoft add in” to get the designer file (.dsldd) in synch with the model I received the following warning:

 

Warning : in MelCollection of shapemap for 'ResponseMessage', Concept

> 'ServiceOperation' has a role 'ResponseMessage' but it is not

Aggregate

 

I figured that I made some fundamental errors in my model but couldn’t find anything about it in the accompanying DSL Tools walkthrough documents. After some time I decided to contact Alan Cameron Wills who is a member of the DSL Tools team and is very active on the DSL Tools forum. Within half an hour he responded and solved my problem. Thanks Alan!

 

He told me that in the current version of the DSL Tools there’s the following restriction:

 All concepts of all shapes that appear on the diagram must be embeddings of the root class.

In practise this means that models should be very flat. What I had to do is create an embedding relation (solid line in the diagram below) from “service” (root of the model) to “RequestMessage” and “ResponseMessage”. After that I had to change the right-hand roles “Min” attribute to 1 and change the “Accepts” attribute of the left-hand roles to “All”

(changes are within red lines)

 

Maybe a bit strange but it works!

 

After applying the suggested solution my model looks like:

 

 

Note: the model isn’t finished yet. This picture is just to explain this restriction!

 

Alan also mentioned that the future release of the DSL Tools will have a much better “modelling experience”, till then we have to use the above described solution to get around this restriction.

posted on 8/4/2005 5:37:26 PM UTC  #   
 Wednesday, August 03, 2005

After installing the DSL toolkit it is relatively easy to create and maintain the “domain model file” by drag and drop items on the designer that comes with the toolkit. After that, however, you have to get the “designer model file” in synch with the “domain model file”. This file is used to generate C# code that makes it possible to use your language in the experimental build version of Visual Studio.Net.

 

Getting this designer file in synch, really is a pain in the ass! It is a lot of work and for people not very familiar with the designer file structure (yet) it’s very likely to make mistakes with it. I assume Microsoft didn't have the time to solve this issue for this release of the DSL Toolkit but I hope they will solve it for the final release!?

 

Fortunately I found this Visual Studio add-in that makes it real easy to keep the two files in synch. Modelisoft, thank you for making my life a little less painful!

According to this posting of Daniel Cazzulino, Visual Studio Add-ins are dead. This might be true but this add-in is definitely alive and kicking!

posted on 8/3/2005 6:18:55 AM UTC  #   
 Monday, August 01, 2005

Found some time to continue with my little experiment today.

 

After executing the installation of the earlier mentioned toolkits I was ready to perform my first steps in this totally new world. Installation all went fine, so that a good thing. One of the things I started with was reading the so called walkthrough documents (at this moment four docs are available). Unfortunately these documents are the only documentation that I can find for the DSL Toolkit. This is probably because of the CTP status of the toolkit but I assume this will get better in time. Although the walkthrough docs provide some guidance I think it is a bit poor. The docs mainly tell you which button to “click” but do not provide you with real background information about the DSL concepts. Definitely some room for improvement in this area!

 

My first experiences with building the example stated in the first “walkthrough” document, were a struggle. Most of this was because I didn’t take the time to execute all of the steps stated in the document. (I guess this is just a normal “men” thing to first start trying it yourself and only read the manual when you f.cked up). Second time I followed the docs very carefully but I was left with some errors. Luckily I found this posting on “”Xenopz Blog” that helped me with some remaining issues and that couldn’t be resolved by just reading the manual.

 

After some time I decided to start with the “Blank Language” template and start building my own DSL. This template provide you with two classes (“ConceptA” and “ConceptB”) and some relationships between them.

I started building my own DSL by simply renaming the two classes in the model (this is suggested in the walkthrough documents). One of the things that I find a little inconvenient (other words came up in mind first) in this is that after you changed the name of the classes and relationships in the designer you also have to perform some “find and replace” actions in one of the (many) xml files to make the designer for your language work. 

After some time this is what the first version of my model looks like.

During the creation I didn’t make any attempt to execute the “translate template” step or build the solution. Thinking back I’ am not sure if this is the smartest thing I could do.

 

My next step will be executing the “template translation” (to get the designer definition file in sink with the above domain model) and build and debug the language.

Haven’t tried this with this model but I expect some troubles with it. Getting the designer definition file in sink includes making manual changes in the (complicated) xml file. More on that later.

 

For, now Just a short explanation of the model (language):

At the root of the language I created the “service” class. Just below that you can see the “servicecomponent” class. I figured that all the other service components (interface, operation, etc.) might share some common needs (properties) in the future. Therefore all service components inherit from the “servicecomponent” class. 

The relation between the “servicecomponent” and the “servicecomponent” class is there to facilitate creating relationships between the several service components. Further you can see the “serviceAdpater” that acts as the class that couples the “serviceinterface” and “serviceimplementation” class. The “serviceinterface” class groups one ore more “serviceoperation” classes and is referenced by a “transportinterface” class. Finally the “serviceoperation” class references two “message” class to support the modelling of an input and output request for a service operation.

 

All still very limited, but it gave me a nice introduction in some of the possibilities of the DSL Toolkit. The above language can now be used in a so called “experimental build” environment to actually try the language and model a service. I haven’t tried that yet, so I’ am not sure what to expect!

 

When writing this post I suddenly realize that the two references from the “service operation” to the message class might not make sense. Maybe it is better to extend the message class with an attribute that indicates the type of the message (input or output). By using an enumeration for this I can make sure only the correct types can be selected. After that I can delete one of the referenced message classes and change the remaining reference to accept one or two messages.

 

To be continued…

posted on 8/1/2005 6:57:53 PM UTC  #   
 Friday, July 29, 2005

Inspired by the several sessions of Tech-Ed Europe I decided to spend some effort on Domain Specific Languages (DSL) and Guidance Automation Toolkit (GAT). Although I have done some reading on Software Factories the area of building a Software Factory is quite new for me. Therefore I thought it would be interesting (for me and my current employer) to see the capabilities of these new technologies that are first members of Microsofts Software Factories initiative. To make it a little more appealing than just creating some sort of “Hello World” example I decided to try to combine it with some of my “day to day” work (which is architecting systems). Because I am definitely no expert in DSL’s I also decided to share some of my thoughts and issues to hopefully get some feedback to push me in the right directions.

 

Here is the idea: build a Domain Specific Language (DSL) to model “services”, perform some code generation and use GAT to provide some context-specific menus and templates within Visual Studio.Net IDE to speed up development based on the DSL.

 

Doesn’t sound too difficult so let’s give it a try. One of the things I do know about building a Software Factory is that you have to define what (reusable) parts can be identified within the domain. You also have to make sure the complete implementation details for all of the parts you are trying to model in a DSL and automate with GAT are available (and proven!).

 

For now, let’s assume these conditions are met. I will describe some of the parts I think are members of the service domain. Because my focus is on getting familiar with DSL and GAT, I will not describe all parts (and details) within the domain. As soon as I am totally up to speed with DSL and GAT (and still find it interesting) I will complete the model to make it a little more useful.

 

One of the most obvious parts that can be identified within this domain is the actual “service” itself. When translating this to a DSL this can be the “root” of the DSL. The service is composed out of other parts that I will call “service components” (it’s just a name).

 

Some of the service components I identified for this example:

  • Service Interface; operations that are exposed by the service (service contract).
  • Service Operation; definition of a service operation.
  • Transport Interface; the representation of the service interface targeted at a specific technology (web service, enterprise service, remoting.)
  • Message; definition of the messages exposed by service operation
  • Service implementation; the actual implementation of the business logic
  • Service Adapter; layer between the transport interface and the service implementation.

 

The above service components are all in their most basic form and they might not even cover the whole service domain. For example, it is very likely that in reality the message contains a data definition that is implemented as a data class based on an XSD definition. For now (this example) I will forget about al of these details. In this example a message is just represented by a class with a name that can be used as either input or output for a service operation.

 

I think, I will soon find out what parts (or details) I am missing here when I start modelling my DSL. During the modelling phase I will add only the absolute necessary properties and relationships.

 

The next step will be to prepare the environment by installing the DSL Toolkit and the Visual Studio 2005 SDK for Beta 2 and than we are ready to start experimenting with DSL.

 

To be continued…

posted on 7/29/2005 11:07:58 AM UTC  #