It started as project Batman, than it became Service BAT and now, the official name is just confirmed as Web Service Software Factory. A little long, so let's just call it Service Factory!

We can finally start talking about it! The last couple of days Jason started giving some hints about changing the way we are developing service oriented applications. Christian is even thinking a little further and dreams about a possible relation with this?? All a little confusing but definitely interesting. It’s time to shred some light and start talking about Service BAT!!

The last few months I have been participating in this very cool project of the Microsoft P&P team coded named Service BAT (Baseline Architecture Toolkit). I believe this delivery is likely to change the way you are building services for the .NET platform.

So what is it? Service BAT is a toolkit that provides architectural guidance, tools, patterns, wizards, etc. to help you designing and building services using Windows Communication Foundation and ASMX. The Guidance Automation Toolkit is used to integrate all of this very nicely into Visual Studio.NET 2005. One of the great things of Service BAT is the level of customization. Service BAT doesn’t force to do anything you don’t like. You can customize most parts of Service BAT to make it meet your requirements.

Please note that this is just a very limited description; it’s really much more than this but you have to find out for yourself.

In the next few days I (and hopefully some others) will provide some more details. There is a public community for Service BAT that you can check out. An early code drop will follow in a few days.

For now, just a few screenshots of (an early drop) of Service BAT. More details will follow but this is the (very) short story that belongs to the screenshots.

The Service BAT architecture is based on separation of concerns (responsibilities). This separation is also translated in the Visual Studio solution structure. You can base your service development on one of the templates that Service BAT provides.

You can choose for a full blown template that will provide you with a complete solution structure including a lot of projects or you can choose for an empty solution structure and decide for your self what projects (responsibilities) you need in your solution structure (service). You can than add specific types of projects to your solution. All project types correspond to a set of responsibilities. For example we have a project type that holds and provide guidance for datacontracts, one for service contracts (interface), etc.

Service BAT provides you with recipes (actions) that you can execute. The recipes that are available for a project type are based on the responsibilities of a project type. As you can see in the screenshot below the “datacontract” project type provides you with guidance and tools to create a datacontract. You choose between creating a datacontract  by using a wizard, Code Snippets or create one out of an existing XSD.

(Later you will see that you can add responsibilities to a project type as part of the customization of Service BAT.)

As said, just a very quick and incomplete explanation of some of the features of Service BAT. Hope this makes you interested enough to check out the Service BAT community. Go download the early drop as soon as it is available and let us know what you think in the community!

I was playing a little bit further with the DSL Tools and tried to add some icons to the custom commands (menus) I created. With the help of Jezz I managed to get this working.

First of all we tried to use custom bmp images in the commands. Unfortunately there appears to be a bug somewhere in the VS shell that prevented us from using custom bmp images. One option to work around this is use Guidance Automation Toolkit for adding the custom commands, we decided to follow another approach and use one of the icons from the office resources. If you can live with this limitation (approx. 7000 icons), you might be interested in the information below.

First you need to decide which icon you want to use in the menu. Therefore, you need the so called FaceID of the icon that you want to use. There are several tools or Office add-ins that can be downloaded from the internet to help you determine the FaceID of an icon (I used this one).

For this example we will use FaceID 2497.

Now we know the FaceID of the icon we want to use, we can open the “C:\Program Files\Visual Studio 2005 SDK\2005.10\VisualStudioIntegration\Common\Inc\office10\msobtnid.h” file in VS.NET.

This file contains all ID’s for the Office icons. For this example, we search the file for FaceID 2497. We will find a line that looks like:

#define msotcidExploreWebPage          2497   //(43,25) Label: 'E&xplore Web Page'

From this line we get the declaration of the FaceID. In this case this is “msotcidExploreWebPage”

In VS.NET we now open our DSL solution and open the “Designer\CtcComponents\GeneratedCmd.dslddt” file.

Somewhere after the include of the “GeneratedCmd.dslddi” file we can add the following line.

#define OI_GENERATEDIAGRAM guidOfficeIcon:msotcidExploreWebPage

Of course you can change the “OI_GENERATEDIAGRAM” in whatever you want. Change the declaration (“msotcidExploreWebPage”) to the appropriate value for your icon, leave the “guidOfficeIcon” in!

Next, we open the “Designer\CtcComponents\CustomCmd.ctc” file and find our customer command. This line should look something like this (in your case, of course with other name and text)

guidCmdSet:cmdIdGenerateModel, guidMenu:grpidContextMain, 0x0200, OI_NOID,  BUTTON,            DIS_DEF,       "Generate Model from WSDL";

We can change the “OI_NOID” into “OI_GENERATEDIAGRAM” (your value here)

Last, we have to open the “Designer\Shell\Package.dslddt” file.

To make sure VS.NET resets its menu cache after the first build we need to increment the second integer in this line:

[ProvideMenuResource(1000, 15)]

Build and run the solution and the icon will appear in your command.

Doesn’t this look pretty? 

My friend Jezz started a new series about the work he is doing on building a Toolkit for developing enterprise distributed applications and services. I know some off the details of his work and this is quite interesting. Jezz is just like my pasionate abouth DSL, GAT, and all related stuff. Let’s see what he has to say in his coming posts...

I have just updated my blog to DasBlog 1.8. If something doesn't work anymore please let me know!

Finally! A little more information is available of the DSL Tools modelling API! In this post George Mathew provide us with (some) details on the improvements the DSL Tools team made in the modelling API.

As you might have noticed from my previous posts, we have a quite a lot of custom code in our Domain Specific Language that uses this modelling API. Therefore changes in the modelling API will reflect in some additional work for us also. Hopefully not to much!

According to George, creating new Domain Classes can now be done by using the ‘new’ keyword. Isn’t that great? (and obvious J). The good new is that also the “old” mechanism is supported in the new API. Hmmm, I think I will definitely upgrade my code to use the ‘new’.

Great work, waiting for more news George!

It’s been a long time since my last post. I have been busy lately working on a few pretty cool things. Unfortunately cannot talk about most of the things yet. But, there’s one thing I can talk about and that is the “ever lasting story” of our Domain Specific Language for designing service contracts.

We still plan to make it available for download as soon as the RTM of the DSL Tools is available. In the meantime we are adding some nice features that hopefully improve the usability of the Domain Specific Language. Of course, we have to make some (hopefully not to many) changes to make our custom code work against the changes API of the RTM of the DSL Tools.

For now, let me show you some images of some of the features and/or improvements we have been working on. Just to show you this language isn’t dead yet!

First of all, as you can see in the image below, we included some nice images in the ToolBox. Not that difficult but I like the Toolbox a little better now.

Further we added some custom menus. One of them to fire the “WSDL generation” another one to fire the “generating model out of WSDL file” option.

Below you can see an example of two custom menus that are available when right clicking a MessageShape in our model. When pressing the “Select Message XSD location” (description will probably change!) you get a FileDialog box to select an XSD file that describes the Message. After you selected the XSD, the “schemalocation” property of the MessageShape in the model gets populated with the reference to the XSD.

A next thing you can do is right click the MessageShape again and this time you can select the “Select Message from XSD” option. As you can see in the image below, this action results in a new window that pops up and that is populated with all the message definitions in the XSD that you selected in the previous action. You can also click on the messages to see the DataContracts that are referenced in the message.

After selecting a message the MessageShape in the model gets populated with the name of the selected message and the DataContracts belonging to the message are also added to the MessageShape. Maybe no rocket science, but it hopefully makes the Language a little easier to use.

To be continued...

The new November DSL Tools CTP comes with a totally new Validation Framework. This framework can be used to write constraints for domain classes in your domain model. After trying it out I must admit that the framework makes writing constraints very easy! All validation errors popup in the “Error List” windows in VS.NET, all of this is very cool!

However, I was a bit confused. I assumed that whenever a constraint was violated on a domain class in my model this was reflected in the “IsValid” property of the ModelElement and the “Store” that represents my model. None of this is true! While the Error List window shows some constraints violations the “IsValid” of the “Store” (and the ModelElement) returns “true”.

Because I need this information in a piece of custom code in the DSL I had to look a little further. I noticed that it is possible execute the validation myself from within the custom code. Have a look at the following code snippet where I am using the “ValidationControler” class to execute the validations. (don’t forget: using Microsoft.VisualStudio.Modeling.Validation;)

ValidationController controller = new ValidationController();

bool isValid = controller.Validate(this.Store,ValidationCategory.Save);

This code lives in the “ServiceDescriptionDiagram” class in the DSL. From there I have a reference to the “Store” that I can use in the “Validate” method. The methode has some other overloads that makes it, for example, possible to validate an ModelElement. The good thing is that this piece of code actually returns the right value (based on the violated constraints in my model). In the code above the value of “isValid” is false whenever a constraint is violated.

I am not sure (yet) why the IsValid property on the “Store”, “ModelElement” and “ShapeElement” doesn’t reflect the current state of any violated validation. It might have something to do with the “ValidationCategory” that is part of the validation process. This category can be specified on a constraint to tell the validation framework when a constraint should be validated. Current options are “Menu”, “Save”, “Open” and “Custom”.  It looks like no information about a model or class being valid is stored in the underlying datastore of the model. I assume there is a very “valid” reason for this!

For continuing our DSL, this isn’t a problem at all. We can use the “ValidationController” at any place in our DSL to decide if the model is valid enough to start generating artifacts.

To be continued...

Some days ago I received an email of somebody asking me if I am (still) using T4 templates within the DSL we are building. After reading some of my latest post he got the idea that a lot of the features we are building aren’t implemented in Text templates (T4). He asked me if there is a special reason for that and if I think the T4 templates are useful enough for writing (parts of) your DSL.

Actually it is true that a lot of the things I am currently working on is implemented in pure C# code and is hooked into the diagram itself by using techniques described in earlier posts. For me this works just great.

The thing I like about integrating as many features as possible directly in the diagram itself is that it requires no user actions (selecting menu items) to “execute the feature”. For example, in our DSL you don’t have to select a menu item to translate a Service that is modelled in our Designer into WSDL. This is done on the fly whenever a change is made in the designer and the diagram is still a valid representation of a Service. All of this is done by events that get triggered “automatically” through the designer. Another option was to implement the WSDL generation into T4 templates and let the user trigger the execution of the T4 template through a menu item.

It’s not that I don’t like writing T4 templates! Actually I do like the templates. I have to admit that there are some improvements possible in the “writing experiences” of these templates but I am sure this will improve in future builds of the DSL Tools. I can imagine that we will use the T4 templates for some other artifacts that get generated out of our domain model. To be honest, the WSDL generation for our DSL is besides the “pure C#” version also available in a T4 template. Translating the “pure C#” version into a T4 template (and vice versa) was done in a few minutes.

So, to answer the question in the email that starts me writing this post. A lot of the functionality in our DSL is built in “pure C#” directly hooked into the diagram, but that doesn’t mean that I don’t like T4 templates or think they are not useful! In fact, they will be part of our DSL. I think you have to find out for yourself what features and/or customizations you need in your DSL and what can be best implemented in pure C# and what can be best implemented in T4 templates.

I noticed that George Mathew (team member DSL Tools) wrote one of his first posts on his blog about new features in the Text Templates (T4) of the DSL Tools. Maybe he (or other team members) has some thoughts or better explanation on when to use the T4 templates and when to implement things directly into the designer or diagram?

In an earlier post I mentioned I am using the “OnTransactionCommiting” on the Diagram class to implement some logic (generating WSDL) for the DSL we are writing. My remark at that point was that the event is triggered a lot and therefore might not be the best place to implement time consuming logic. At that point I didn’t pay a lot of attention to the “TransactionCommitEventArgs” parameter of the event. After some further investigation I found out that the “Transaction” (that can be reached through the TransactionCommitedEventArgs) has a logical name that “indicates” what is happening in the diagram and what (user) action triggered this event.

For example, when changing the value of a property named “WSDLDescription” in the diagram, the name of the Transaction is “Set WSDLDescription”, when first loading a diagram the name of the Transaction is “LoadDocData”, etc. The code snippet below gives you an idea how to limit unnecessary (custom) code executions that you might implement in the “OnTransactionCommiting”.

public override void OnTransactionCommitting(TransactionCommitEventArgs e)
{
   base.OnTransactionCommitting(e);

   if ( e.Transaction.Name.ToUpper() == "SET WSDLDESCRIPTION")
   {

      //only execute in case of a change in the WSDLDescription property
      DoStuff();
   }
}

This actually means that I have much more control than I initially thought and therefore makes the “OnTransactionCommiting” a usefull event to implement some other logic too.

To be continued…