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…