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…