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…