Default layout mechanisms offered by DSL Tools are not challenged by VS’s 2010 edition. It's not a reason to be disappointed but to acknowledge efforts produced into other areas such as extensibility. DSL Tools wisely called for help to offer alternative solutions that are far more than blinded workarounds. Indeed, the solution chosen is supporting WPF.

DSL Tools knew benefit from the announced marriage between this technology and Visual Studio.

This being said, to illustrate this choice, this post proposes to migrate the AirTraffic example published few months ago. This sample presented a mechanism to support WPF right from the 2008 version.

And the result is really encouraging, and allows thinking that WPF support isn't reduced to form based design.

Below are the steps to embed AirTraffic into VS:

• Migrate your model by using the really cool dsl migration utility (I still wonder why this is not included right into VS conversion wizards)
• Create a minimal WPF Designer dsl project
• Leverage renewed copy and paste mechanism and simply copy the original project artifacts into the new WPF Designer DSL project
• Copy and paste custom code and specific dsl parameters (Customize connection builder).

• Transform all templates
• Focus on UI project and especially ViewControl class
  • Extract code from AirReader wpf application, migrate only graph control.
• Light a candle or give slaps when you are in front of minor bugs.
  • Reference required assemblies for ui project into dsl package, too.
  • Bind the collection view on a list wrapping the LinkedElementCollection of Airports. Indeed, unfortunately the LinkedElementCollection isn't an ObservableCollection but implements the old school interface IBindingList. This unfortunately excludes most features exposed by CollectionViewSource such as Filter however collection binding from data templates works as expected.
• Don't run the project yet unless you want to define a model from the xml editor.
• Keep the faith by developing a tool window to enrich the model displayed by your superb graph.
• Add a WPF UserControl to the Dsl Package project
• Inherit from ModelExplorerToolWindow class.

    [CLSCompliant(false)]
    [GuidAttribute("F4DD2E3D-CCD3-47B0-B64F-0D52A69AC7FA")]
    public partial class AirTrafficSearchToolWindow : ModelExplorerToolWindow
    {
        #region ctors

        public AirTrafficSearchToolWindow(IServiceProvider serviceProvider)
            : base(serviceProvider)
        {
            InitializeComponent();
        }

        #endregion

        #region methods

        protected override void OnDocumentWindowChanged(ModelingDocView oldView, ModelingDocView newView)
        {
            base.OnDocumentWindowChanged(oldView, newView);
            var l_modelingDocData = this.DocData as ModelingDocData;
            if (l_modelingDocData == null)
            {
                return;
            }
            AirTrafficBrowser.DataContext = l_modelingDocData.Store.ElementDirectory.FindElements(false)[0];
        }

• Weep for joy in front of WPF support offered by Visual Studio
  • Update the xaml associated to your new control by replacing the root element with ModelExplorerToolWindow
    

<dslfx:ModelExplorerToolWindow 
    x:Class="Mexedge.AirTraffic.AirTrafficSearchToolWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:dslfx="clr-namespace:Microsoft.VisualStudio.Modeling.Shell;assembly=Microsoft.VisualStudio.Modeling.Sdk.Shell.10.0"
    xmlns:atp="clr-namespace:Microsoft.Samples.KMoore.WPFSamples.AnimatingTilePanel;assembly=J832.Wpf.BagOTricksLib"
    xmlns:dd="clr-namespace:Bea.Wpf.DragAndDrop;assembly=Bea.Wpf.DragAndDrop"
    xmlns:dsl="clr-namespace:Mexedge.AirTraffic;assembly=Mexedge.AirTraffic.Dsl"
    xmlns:local="clr-namespace:Mexedge.AirTraffic">
    <StackPanel Grid.Column="0" Margin="5" x:Name="AirTrafficBrowser" Background="#FF000635">
        <StackPanel.Resources>

• Extract the code dedicated to the left panel of the AirReader application.
• Invest a minimum on drag and drop mechanism and congratulate Bea Stollnitz work because the investment is really minimal thanks to her very detailed post.
  • You can safely stop bubbling event after custom handling.
• Declare your user control as a standard tool window from Package class.

    [ProvideToolWindow(typeof(AirTrafficSearchToolWindow))]
    [ProvideToolWindowVisibility(typeof(AirTrafficSearchToolWindow), Constants.AirTrafficEditorFactoryId)]
    internal sealed partial class AirTrafficPackage
    {
        protected override void Initialize()
        {
            base.Initialize();
            this.AddToolWindow(typeof(AirTrafficSearchToolWindow));

Definitively, it would be a shame to reduce WPF use to form based design. And, the time of old school model explorer is running out.

Of course, a screencast showing the end result is available here.

The code will be available soon once updated to Visual Studio 2010 RC.

Introduction

DSL Tools are becoming more popular everyday and naturally questions are increasing in volume on MSDN forums dedicated to Visual Studio Extensibility. However, this fact is not the only reason to advocate that DSL Tools gained in maturity. It is better for now to focus on a recurring request in the form of multiple views of a single diagram. This is mainly derived from the fact that models implemented using DSL Tools are getting bigger and bigger by the day and it becomes quickly important to be able to occult some aspects of the model while putting the emphasis on others. The goal of this article is to present a solution to implement such functionality.

Alan Cameron Wills told us

As soon as 2005, Alan Cameron Wills suggested a way to put in place this mechanism as an answer to a question on the above mentioned forum. However, while the answer clearly paved the way of the solution presented here, he omitted a few steps when described the procedure. In conjunction with the sparse level of documentation available around this area, this probably explains why no one came up with a solution yet.

With this starting point, a few alternative ways have been pursued. One based on the creation of a DocData instance for each diagram that needs to be displayed has been successful… until one of Alan's missing steps reminds you that this might be more complex than originally anticipated. The revelator has been the discovery of the ProvideEditorLogicalView attribute that can decorates the Package class. This new attribute tends to think that Alan's suggestion might be incomplete and only regret the low level of documentation around this area. Using this attribute activates 2 mechanisms: OpenView (method defined in DocData base class), MapLogicalView (method owned by EditorFactory).

As we will explain in this article, the efforts required to enable multiple diagrams are not limited to only overriding these two methods. Some actions will necessary on both DSL Tools and Visual Studio sides. This implies therefore working on two projects: Dsl and DslPackage.

A lot of choices will be made during the implementation of multiple diagrams and will be explained during the course of this article. The readers are invited to submit their though and opinions on these choices.

DslPackage

Developments made in this project are focused mostly around 3 classes. Not surprisingly, it is about customizing classes related to document management within Visual Studio: EditorFactory, DocView and DocData. The mechanisms involved by DSL Tools make a large use of these and even generate an implementation of them.

EditorFactory

The work required on this class is only overriding 2 methods:

• The first one was mentioned earlier and is about taking advantage of the MapLogicalView method in order to support multiple diagrams on a single model.
• The second one is about using the previous override (MapLogicalView) in order to indicate to the class representing a document view which diagram is associated with it. By default, none is defined.

MapLogicalView

A first question arises: « Should a logical view be associated to each diagram type that will be defined on top of the default diagram generated by the DSL Tools?”.

The short answer is no. This is not a unique identifier that will associate a logical view with the diagram to display, this is the context associated to the display request. A single identifier thus a single logical view is used in our case.

Therefore the mechanism relies on the second parameter of the MapLogicalView method. This parameter is essential in order to find which diagram to display. Indeed, the purpose of this method is to return a string that identifies a logical view specified via an id and a context. In our sample, we return the context as a string.

Even if the solution proposed relies on a single view identifier, each diagram instance will have a dedicated document view instance as described in the next paragraph.

if (logicalView == Constants.LogicalView1)
{
   return (string)viewContext;
}

CreateDocView

The purpose of this method is to create a document view based on several parameters, one of them being provided by the call to the MapLogicalView method.

It also allows specifying the text that will be displayed in the tab title that will host the view and therefore the diagram.

The goal is to specialize a view based on the diagram to display, this method now returns an instance of the DocView class taking into account the result of the MapLogicalView method. The DocView class must therefore expose a new constructor handling this new parameter.

editorCaption = string.Format(" [{0}]", physicalView);
return new ExtendedClassDiagramDocView(docData, this.ServiceProvider, physicalView);

DocView

The work required in this area is limited to 2 actions :

• Develop a new constructor in order to handle the parameter returned by the MapLogicalView method,
• Override the LoadView method in order to use this new parameter

The first action does not require any further explanations and it is almost the case for the second. Indeed, in the context of the example provided, this is the name of the diagram that is returned by the MapLogicalView method that is being used as the identifier of the physical view. This being said, overriding the LoadView method is only about not using the first item in the list of diagrams loaded by DSL Tools but the one with the same name as the identifier.

l_diagram = string.IsNullOrEmpty(m_physicalView) ? l_diagramList[0] : l_diagramList.Find(delegate(Diagram diagram) 
{ return diagram.Name == m_physicalView; }); 
if (l_diagram != null)
{
    this.Diagram = l_diagram;
    return true;
}

This being said, a new question arises : Can a user create diagrams if the model has already been loaded?

The sample provided allow such a functionality. In order to allow this, when a new diagram is created it is synchronized with the model. Therefore if this new diagram displays elements of the model created by its own creation, the graphics associated to the elements will be created when the diagram is created or loaded. This synchronization mechanism relies on the definition of a rule with the Dsl project actived when creating a diagram element.

([RuleOn(typeof(Diagram), FireTime = TimeToFire.TopLevelCommit)]).

The details of this rule will be presented later on when dealing specifically with the Dsl project.

DocData

Today, DSL Tools allows saving model and its associated diagram in dedicated files. Supporting multiple diagrams supports the same level separation for each diagram. Therefore, a file is created for each new diagram. However, it is good to maintain the same user experience within Visual Studio. A visual link should help identifying the file in which the model is saved and the files where the diagrams are saved. Offering the same user experience can lead to navigation issues if the number of diagrams thus the number of associated files reach high numbers. Furthermore, opening a “diagram” file, as opposed to a “model” file, does not trigger a dedicated visual designer. Because the diagrams are saved using XML, Visual Studio uses its default XML editor. It is therefore not relevant to allow opening this kind of files via a double click in the solution explorer. It is also important to maintain features that are now mainstream such as “Save as” or “Include”.

To answer each of these requirements, it has been decided to leverage the OpenXML format and specially its dedicated library that is now offered in the .Net Framework through the System.IO.Packaging namespace. All the files related to the diagrams will therefore be saved inside a single file. The later on top of saving the diagrams on disk will also compress these. As demonstrated in the sample accompanying this article, the users will only face, even though we introduce multiple diagrams, only two files one with a “diagramx” extension similar to the new file extension convention used within Microsoft Office products.

This being said DocData class does not have to handle the serialization mechanism involved in the DSL Tools. It delegate this work to the SerializationHelper class that will be details later on.

The modifications required on the DocData class on top of overloading the OpenView class are twofold:

• Adapt the mechanism managing the.diagram files in order to handle .diagramx. It is nothing more than copying one mechanism and apply it to the second,
• Call within the load and save methods the serialization mechanisms supporting multiple diagrams as described earlier.

The actions impact very sparingly the default behavior of the DocData class therefore readers are invited to refer to the source code provided in the sample should they require further details.

OpenView

As mentioned earlier, diagrams can be instantiated on the fly even if the model has been modified. Therefore, this is when the OpenView method is called that a check is done in order to identify which type of diagram is to be displayed. If the diagram in question does not exist yet, an instance will be created within this method. To do so, only the parameter specifying the logical view context is taken into account. This parameter is used to determine which type of diagram is to be instantiated.

Of course, a next release of the solution exposed here could include a more elaborated mechanism to link a type of diagram to string (dedicated attribute decorating the class associated to a diagram etc…) and not only rely on the name property of the diagram. This would allow adding new parameters to the diagram instantiation.

It is important to note that this should happen within a DSL Tools transaction because this new diagram instance has to be inserted into the DSL Tools store.

Following this instantiation, the OpenView method exposed by the base class is called therefore leveraging the Visual Studio mechanisms orchestrating the call to the methods mentioned earlier (MapLogicalView etc…).

The most curious readers will notice that the DocData class provided in the DSL Tools API: ModelingDocData specifies its own implementation of the OpenView method. Because the DocData class generated by the DSL Tools inherits from it, it leverage this implementation by default. Using this one would constraint us to use the diagram instance to be displayed as the visualization context. This is an option that be used later on. We have every reasons to think that the DSL Tools development team wanted to offer multiple diagrams support. Digging into one of the first betas available confirms this though.

public override void OpenView(Guid logicalView, object viewContext)
{
    string l_viewContext = (string)viewContext;
    Diagram l_diagram = this.Store.ElementDirectory.FindElements<Diagram>().SingleOrDefault<Diagram>(diagram => diagram.Name == l_viewContext);
    if (l_diagram == null)
    {
        using (Transaction transaction = this.Store.TransactionManager.BeginTransaction("DocData.OpenView", true))
        {
            if (l_viewContext == "Flow")
            {
                l_diagram = new FlowDiagram(this.Store, new PropertyAssignment(Diagram.NameDomainPropertyId, l_viewContext));

            }
            else if (l_viewContext == "Package")
            {
                l_diagram = new PackageDiagram(this.Store, new PropertyAssignment(Diagram.NameDomainPropertyId, l_viewContext));
            }
            else
            {
                throw new NotImplementedException();
            }
            l_diagram.ModelElement = this.RootElement;
            transaction.Commit();
        }
    }
    base.OpenView(logicalView, viewContext);
}

ProjectItem Templates

The previous paragraph introduced it, a new file with diagramx extension is to replace the default .diagram file in order to enable multiple diagram. This involves modifying the item project models produced by the Dsl solution in order to replace .diagram in diagramx.

The files to modify are xxx.diagram, CSharp.tt and VisualBasic.tt.

Package

The work done on the DslPackage project will be complete once the two actions on the Package class will be done:

• Decorate the Package class with the LogicalView attribute as described in the introduction, this enables multiple views of the same model.
• Decorate the Package class with the RelatedFiles attribute in order to support the new .diagramx extension.

[ProvideEditorLogicalViewAttribute(typeof(ExtendedClassDiagramEditorFactory), Constants.LogicalView1Value, IsTrusted = true)]
[ProvideRelatedFile("." + Constants.DesignerFileExtension, Constants.DiagramxExtension,
 ProjectSystem = ProvideRelatedFileAttribute.CSharpProjectGuid,
 FileOptions = RelatedFileType.FileName)]
[ProvideRelatedFile("." + Constants.DesignerFileExtension, Constants.DiagramxExtension,
 ProjectSystem = ProvideRelatedFileAttribute.VisualBasicProjectGuid,
 FileOptions = RelatedFileType.FileName)]
internal sealed partial class ExtendedClassDiagramPackage
{
}

Dsl

The actions undertaken on the DslPackage paved the way to supporting multiple views of a single model within Visual Studio. As mentioned, these actions are not enough and require modifying the Dsl project as well. The first one is to extend the serialization mechanisms in order to take into account multiple diagrams and OpenXml to save them on disk. These mechanisms are leveraged within the DocData class and exposed by the serialization helper class.

SerialisationHelper

The modifications to this class won’t involve overrides but introduce new methods: LoadModelAndDiagrams, SaveModelAndDiagrams and SaveDiagrams.

Readers would certainly notice that numerous developments mentioned since the beginning of this article could have been generated. This will be one of the remarks mentioned in the conclusion of this article.

LoadModelAndDiagrams

This new method simply uses the default logic generated by the DSL Tools and only clearly separates what is related to loading the model and what is related to loading a diagram (which has its own dedicated method). The first advantage of this is to easily call it for each diagram.

The last issue to resolve is that all the files associated with the multiple diagrams are compressed into a single file. This is a no brainer when leveraging the System.IO.Packaging namespace offered in WindowsBase.dll as described below.

// Load the model
ModelElement l_rootElement = this.LoadModel(serializationResult, store, modelFileName, schemaResolver, validationController);

// Use OpenXml Api
using (Package pkgOutputDoc = Package.Open(diagramxFileName, FileMode.Open, FileAccess.Read))
{
    foreach (var packagePart in pkgOutputDoc.GetParts())
    {
    this.LoadDiagram(serializationResult, store, l_rootElement, packagePart.GetStream(FileMode.Open, FileAccess.Read), schemaResolver, validationController);
    }
}

As you probably have noticed, it is required to create our own SerializationvalidationObserver class in order to follow the way the method generated by DSL Tools works. Indeed, the generated implementation for this class is set to private thus preventing us from reusing it.

SaveModelAndDiagrams

This paragraph starting with a similar remark than the previous one : it is a shame that the InternalSaveModel and InternalSaveDiagram are set to private. This forced us to duplicate them in order to be able use the functionalities they provide in the SaveModelAndDiagram.

There is no fancy work done in this method, the only highlight would be the use once again of the System.IO.Packaging namespace in order to produce only file for all the diagrams.

using (Package pkgOutputDoc = Package.Open(diagramxFileName, FileMode.Create, FileAccess.ReadWrite))
{
    foreach (var memoryStream in l_memoryStreamDictionary.Keys)
    {
        byte[] l_bytes = memoryStream.ToArray();
        Uri uri = new Uri(string.Format("/diagrams/{0}", l_memoryStreamDictionary[memoryStream]), UriKind.Relative);
        PackagePart part = pkgOutputDoc.CreatePart(uri, System.Net.Mime.MediaTypeNames.Text.Xml, CompressionOption.Maximum);
        using (var partStream = part.GetStream(FileMode.Create, FileAccess.Write))
        {
            partStream.Write(l_bytes, 0, l_bytes.Length);
        }
    }
}

Serializer

So far, we did not mentioned how a new diagram is defined. Far from wanting to maintain an unbearable suspense, this paragraph partially lifts the veil. A new diagram will inherit from the default diagram generated by the DSL Tools. This choice implies a few pros:

• It allows using the DSL Tools visual designer to define the graphical elements associated with the model, the user experience is therefore just slightly changed.
• It allows using the default underlying mechanisms involved with the diagram management and specially its serialization.

However this decision involves modifying the serializer associated to the default diagram (ClassDiagramSerializer in the sample code). Indeed, when reloading a diagram the correct diagram type must be reloaded.

To do so, it has been decided to add to the Xml representation a new attribute named type. It indicates which type of diagram is to be instantiated. The management of this new attribute requires to overload the WritePropertiesAsAttributes method.

Of course, other solutions could have been chosen such as associating a dedicated element name for each type of diagram, similarly to what is done usually in XAML.

WritePropertiesAsAttributes

To activate the call to the overloaded method, it is required to add at least one DomainProperty to the default diagram.

Then, we only need to use to WriteAttributeString method exposed by the XmlWriter class (an instance of the writer is provided as a parameter of this method)

protected override void WritePropertiesAsAttributes(SerializationContext serializationContext, ModelElement element, XmlWriter writer)
{
    writer.WriteAttributeString("type", element.GetType().FullName);
    base.WritePropertiesAsAttributes(serializationContext, element, writer);
}

CreateInstance

If a diagram’s Xml representation now indicates its type, we need to use this information when instantiating a diagram using its representation.

To do so, it is required to override the CreateInstance method of the Serializer associated to the default diagram.

protected override ModelElement CreateInstance(SerializationContext serializationContext, XmlReader reader, Partition partition)
{
    String l_typeAttribute = reader.GetAttribute("type");
    Assembly l_assembly = this.GetType().Assembly;
    Type l_type = l_assembly.GetType(l_typeAttribute);
    ModelElement l_diagram = (ModelElement)Activator.CreateInstance(l_type, partition);
    return l_diagram;
}

FixUpDiagramOnElementAddedRule

All the mechanisms allowing saving and loading a diagram have been created. As described in the previous chapter, it is also required to modify the synchronization mechanisms that provide an up to date view of the diagram event if the underlying model has been modified.

By default, DSL Tools relies on a mechanism based on a generate rules: FixUpDiagram.

As we have done in some other areas during this article, we have to modify this mechanism in order to support multiple diagrams. Unfortunately, this modification is not trivial, it is easier to deactivate the default rule and create new one to handle our needs.

The modification mostly revolves around on a single method : GetParentForRelationship. For those who are fans of Reflector, the generated version of the GetParentRelationship method selects the first associated diagram. This cannot be sufficient when several diagrams need to be updated. This is why a new method has been developed that takes a diagram instance as an input parameter and searches its associated parent. ..

GetParentForRelationship

This method does not rely on any specificity related to the defined Dsl language. It could even be provided within the DSL Tools SDK. As mentioned, it must take into account, when searching for a parent element, the instance of the diagram provided as a parameter.

if (shape != null && shape.Diagram == diagram)
{
    sourceShape = shape;
    break;
}

It could also not return any parent, indeed a diagram can have no element or relation to display.

if (sourceShape == null || targetShape == null)
{
   return null;
}

ElementAdded

The modification to operate here is to provide a diagram instance to the GetParentForRelationship method. This will be done for every diagrams in the In Memory Store (IMS).

if (childElement is ElementLink)
{
    ReadOnlyCollection<Diagram> diagrams = childElement.Store.ElementDirectory.FindElements<Diagram>();
    for (int i = 0; i < diagrams.Count; i++)
    {
        parentElement = GetParentForRelationship(diagrams[i], (ElementLink)childElement);
        if (parentElement != null)
        {
            DslDiagrams::Diagram.FixUpDiagram(parentElement, childElement);
        }
    }
}

Fixup

This method uses the same logic as the ElementAdded method but only on the diagram instance provided in parameter. This static method will be used by the rule triggered when a new diagram is added. This rule aims to synchronizing the diagram with the model.

The other methods exposed by this class are exact copies of those provided by the FixupDiagram class generated by the DSL Tools. This requirement highlights the fact that a set of T4 templates could greatly ease the process of supporting multiple diagrams .

DiagramAddRule

The sample provided with this article allows creating a new diagram after loading the model. This functionality requires the activation of several mechanisms among which the synchronization of the diagram with the model.

This synchronisation is based on the FixUp rule presented earlier. However, it is not about browsing all the model elements and apply them the FixUp rule with the newly created diagram instance. It has to be done based on the nature of the elements and on their graphical representation within the diagram. In the sample provided, the elements representing an association DomainRelationship are dealt with only after all the others.

[RuleOn(typeof(Diagram), FireTime = TimeToFire.TopLevelCommit)]
internal sealed class DiagramAddRule : AddRule
{
    public override void ElementAdded(ElementAddedEventArgs e)
    { 
        for (int i = 0; i < l_modelElementList.Count; i++)
        {
            ModelElement item = l_modelElementList[i];
            if (item.GetDomainClass().DomainModel.Id == l_domainModelInfo.Id && item.Id != l_diagram.ModelElement.Id && !(item is ModelRootHasTypes))
            {
                FixUpDiagramOnElementAddedRule.Fixup(l_diagram, item);
            }
        }
        for (int i = 0; i < l_elementLinkList.Count; i++)
        {
            ModelElement item = l_elementLinkList[i];
            if (item.GetDomainClass().DomainModel.Id == l_domainModelInfo.Id && item.Id != l_diagram.ModelElement.Id && !(item is ModelRootHasTypes))
            {
                FixUpDiagramOnElementAddedRule.Fixup(l_diagram, item);
            }
        }
    }
}

Defining a new diagram

All the plumbing required to support multiple diagrams are now completed.

It is time to present the steps required to define a new diagram on top of the default one. The steps listed below are based on the sample provided.

1. Open Solution Explorer
2. Right-click on the CustomCode folder of the Dsl project, Add Class
3. Enter the name of your diagram.
4. Modify the namespace if required.
5. Inherits from the ClassDiagram class.
6. To declare your new class to DSL Tools,
   1. Decorate your class with DomainObjectId attribute by specifying only a new guid.

      [DomainObjectId("xx-xx-xx-xx-xx")]

   2. Add your class to the custom type collection returned by GetCustomDomainModelTypes method of your DomainModel class.

      public partial class ExtendedClassDiagramDomainModel
      {
          protected override Type[] GetCustomDomainModelTypes()
          {
              return new Type[]
              {
                  typeof(xxx),
              };

7. Override the ShouldAddShapeForElement method to filter the model elements displayed by this diagram.
8. Customize your diagram by following DSL Tools guidelines. Use the DslDefinition editor to define shapes that will be used in your new diagram.

Conclusion

The sample provided here is like a wink to Visual Studio 2010. Similarly to VS10, it comes to the rescue of the lonesome class designer which was one of Visual Studio 2005’s highlights.

That being said, the sample does not generate any code. This is not the only discriminator, if Visual Studio 2010 has also used the DSL Tools, they are not based on a single diagram but leverages the Bus Designer known as Codename Backplane that will ship with the next version of Visual Studio. Even if it can be an answer to the issue being addressed in this article, a lot of questions arises regarding the rules definition, the usage of overriding mechanisms as well as the developer user experience. It seems that most of the underlying mechanisms are already provided in the DSL Tools to support multiple diagrams on a single model. Will users have both, complementary, solutions provided out of the box by Microsoft at some point?

What’s next

The solution presented here is part of the Panoptes project. Because this project does not require collaborative tools it has not been ported to Codeplex. All the code developed within this project is included in this article. In addition to what has been detailed in the previous chapters, a filtering mechanism on the toolbox has also been implemented.

The next step is the development of a set of T4 templates in order to improve the user experience. As indicated before, all the code produced here could be generated. Once these templates created, adding a new Domain Specific language Designer project template leveraging the revised T4 templates.

By this time, maybe such a feature will be provided out of the box by the DSL Tools. Chances are that such a feature would lead to an extended Dsl Definition Designer supporting the definition of multiple diagrams (by providing dedicated swimlanes?).

In parallel to these «industrialization » improvements, new functionalities could also be developed such as filtering the property grid based on the diagram displayed or activating drag and drop between diagrams.

If this article ignites some vocations in contributing to this project, Codeplex can be a place of choice to extend on this.

Download the complete solution here.

A screencast showing a scenario taking advantage of the functionalities presented in this paper is available here.

The pdf version of this article is available here.

Preamble

Mary Jo Foley revealed the love story between Microsoft and modeling a few months ago. But the information that must retain our attention is that Oslo will be certainly the city chosen for this honeymoon. Indeed, a few years ago Microsoft did the first move when appointing famous modeling engineers and developing DSL Tools in order to seduce this model on the first date. Since then, Microsoft never stopped declaring its love and even promoted it as an essential pillar of its SOA strategy.

So, for connected system developers, having a look at DSL tools seems to be a good way to understand the perspectives that Oslo can bring into the SOA panorama.

That being said, this post targets DSL model prototyping.

Introduction

Everybody knows patterns promoted by the famous Gang of Four, when defining a model the same problematic applies. Some concepts are based on the same structure or a concept can be an aggregate of existing concepts. It would be very useful to be able to define reusable patterns in DSL as we can do for code.

This post will present a solution to integrate such mechanisms into your DSL tools projects. DSL tools offer many customization points that we will use to accomplish our goal. Unlike technologies such as WCF, WPF or WF, DSL tools offers customization points rather than extensibility mechanisms. The promised feature codenamed Backplane (designer bus) or Oslo will maybe change this situation.

This post will present a solution to integrate such mechanisms into your DSL Tools projects.

DSL Tools offers many customization points, we'll use them to respond to our needs.

Unlike technologies such as WF or WCF, with DSL Tools we use more customization mechanisms than extensibility mechanisms. The promised Backplane feature (designer bus) and even Oslo may lead Microsoft to change its orientation towards this and introduce more extensibility rather than customization.

How to

DSL Tools offers basic features to support prototyping that are used essentially to customize dragging and dropping of a dsl toolbox item onto a diagram.

These features are essentially based on a single class: ElementGroupPrototype.

We must not interact directly with this class. A builder design pattern was set up in order to produce a prototype. ElementGroup class must be used instead because it provides a more convenient developer experience. This class has basic methods to build your prototype from selected model elements: Add, AddGraph, AddRange. The AddGraph method adds automatically embedded children and associated relationships of the added model element. Prototyping can be seen as a clone to whom a specific property is set with an autogenerated value. Indeed, when you merge your elementgroupprototype on your model, the created model element takes into account if one of its properties has an associated ElementNameProvider allowing assigning a unique value to this property.

These features can be used to enable copy and paste operations as well. It will be our first step, it allows to easily adopt prototype mechanisms.

We won’t dig into the details about this as it's already described into the "Domain-Specific Development with Visual Studio DSL Tools" book that must be considered as a bible for people using DSL Tools (See page 419 "Implementing Copy and Paste").[1]

An implementation of these operations is available as well within the library developed by the DslFactory community; this library named "DslFactory Utilities" is available on Codeplex. We will take into account various fore mentioned work. We'll add the cut operation support and enable all these operations from the visual studio standard edit menu.

The next step will be to customize the ModelExplorer window, especially the contained tree view in order to add our own nodes and mechanisms to list user defined prototypes.

Finally, we will take advantage of DSL tools prototype serialization to persist prototypes on disk thus allowing offering a similar mechanism as code snippets does.

We'll use a DSL Tools solution based on the Domain-Specific Language Designer Class Diagrams template in order to present this solution. We add to this template solution a folder named “CustomCode” in the “DSL” and “DSL package” projects

Download

Download the complete solution here.

A screencast showing a scenario taking advantage of the functionalities presented in this paper is available here.

The pdf version of this article is available here.

Enable cut, copy and paste operations

Here is the step by step procedure:

· Define copy, cut and paste operation logic,

· Register these operations in order to be able to call them via the standard and contextual menus.

Declare your new commands

1. Open Solution Explorer.

2. Go to the DslPackage project.

3. Open the Commands.vsct file.

4. Define a button for each operation

<Button guid="guidCmdSet" id="cmdidCopy" priority="0x0902" type="Button">
  <Parent guid="guidCmdSet" id="grpidContextMain"/>
  <CommandFlag>DefaultDisabled</CommandFlag>
  <CommandFlag>DefaultInvisible</CommandFlag>
  <CommandFlag>DynamicVisibility</CommandFlag>
  <Strings>
    <ButtonText>Copy</ButtonText>
  </Strings>
</Button>

5. Declare its associated symbols.

5.a Open the GeneratedCode/Constants.cs

5.b Copy the value of the Constants.xxxCommandSetId constant.

5.c Assign it to the value attribute of the GuidSymbol xml element

<GuidSymbol name="guidCmdSet" value="{xxxx-xxx-xx-xx-xxx}" >
  <IDSymbol name="cmdidCopy" value="0x804"/>
</GuidSymbol>

6. Create a static Commands class to reference the information associated to your new commands.

6.a Right-click on the CustomCode folder of the DslPackage project, Add Class

6.b Enter "Commands" as name.

6.c For each command, declare the constant integer used as value for the value attribute of the IDSymbol xml element associated to the command.

internal static class Commands
{
    private const int CopyCommandId = 0x804;
    private const int CutCommandId = 0x805;
    private const int PasteCommandId = 0x806;

    public static readonly CommandID Copy;
    public static readonly CommandID Paste;
    public static readonly CommandID Cut;

    static Commands()
    {
        Copy = new CommandID(Constants.xxxCommandSetId, CopyCommandId);
        Paste = new CommandID(Constants.xxxCommandSetId, PasteCommandId);
        Cut = new CommandID(Constants.xxxCommandSetId, CutCommandId);
    }
}

Implement your commands

7. Open or create a partial class of your CommandSet in the "CustomCode" folder.

8. Develop for each operation an handler in order to display (or hide) the command depending on the context and an handler that executes the command when it is selected.

private void OnStatusCopyOrCut(object sender, EventArgs e)
{
    MenuCommand command = sender as MenuCommand;
    command.Visible = command.Enabled = 
        ((this.CurrentSelection.Count > 0) && 
        !(this.GetSelectedObject(0) is Diagram));
}
private void OnMenuCopy(object sender, EventArgs e)
{
    Diagram l_diagram = this.CurrentDocView.CurrentDiagram;
    ElementGroup l_elementGroup = new ElementGroup(l_diagram.Partition);

    foreach (object selectedObject in this.CurrentSelection)
    {
       ShapeElement l_shapeElement = selectedObject as ShapeElement;
       if (l_shapeElement != null && 
           l_shapeElement.ModelElement != null && 
           l_shapeElement.ModelElement is ModelType)
       {
          l_elementGroup.AddGraph(l_shapeElement.ModelElement, true);
       }
     }
     if (l_elementGroup.RootElements.Count == 0) return;
     IDataObject data = new DataObject();
     data.SetData(l_elementGroup.CreatePrototype());
     Clipboard.SetDataObject(
        data,
        false,
        10,
        50);
}

For the copy and cut operations, we display commands only if the current selection contains objects other than current Diagram.

For the paste operations, we could check if the clipboard data content can be merged with the current diagram.

The cut operation logic adds to the copy operation logic a step that deletes the copied elements.

As you can see, if you downloaded the complete solution, we added to our partial CommandSet class 2 additional things:

• An operation GetSelectedObject to get a selected object from its index in the current selection list.
• A property CurrentStore to easily access the current IMS.

9. Override the GetMenuCommands() method to add your new commands to the context menu.

9.a Instantiate a DynamicStatusMenuCommand for each operation.

protected override IList<MenuCommand> GetMenuCommands()
{
  IList<MenuCommand> l_commandList = base.GetMenuCommands();

  DynamicStatusMenuCommand l_cmdCopy = 
     new DynamicStatusMenuCommand(
       new EventHandler(OnStatusCopyOrCut),
       new EventHandler(OnMenuCopy),
       Commands.Copy);
  
  l_commandList.Add(l_cmdCopy);
  ...
  return l_commandList;
}

In the introduction, we wanted to enable the standard Visual Studio cut, copy, paste commands on our shapes. The only remaining difficulty is to identify the commands associated to them. They are available in the well known System.ComponentModel.Design.StandardCommands

By now, you must only instantiate a new DynamicStatusMenuCommand class by using the relevant StandardCommands field for each command (StandardCommands.Copy etc…).

Deploy your new commands

It is required to increment the Menu Resource Index for DSL Tools to take into account your new commands.

10. Open GeneratedCode\Package.tt

11. Increment the second integer of the ProvideMenuResource attribute.

[VSShell::ProvideMenuResource("1000.ctmenu", 2)]

12. Transform all templates

13. Rebuild.

14. Enjoy

Figure 1 - Visual Studio Edit Menu

Conclusion

So, it works fine but the current behavior is very restricted not only because operations are enabled only for ModelType and its derived types. When you copy a class that contains operations, they are not copied. It’s the expected behavior, indeed, by default; the copy propagation is not enabled. So, if you want to change this behavior, you only need to set to true the property PropagatesCopy of ModelClass Domain Role of ClassHasOperations relationship.

Figure 2 PropagesCopy property

The recommendation is to allow a fine grained customization of the prototype creation from a domain class. To do this, you can define an interface IPrototypable to declare the domain class that support copy operation and to allow the customization of the creation of an ElementGroupPrototype from it.

internal interface IPrototypable
{
    ElementGroupPrototype GetPrototype();
}

To implement this interface by a desired domain class, it’s only required to create a dedicated partial class and to implement the default prototype logic:

public ElementGroupPrototype GetPrototype()
{
    ElementGroup l_elementGroup = new ElementGroup(this.Store);
    l_elementGroup.AddGraph(this, true);
    return l_elementGroup.CreatePrototype();
}

Customize the model explorer

Add your own nodes

The model explorer user interface is based on a tree view; the idea here is to add custom nodes to the treeview in order to list user-defined prototypes.

Unfortunately, if it’s possible to customize the existing nodes (label, image, visibility), no real mechanism are offered to add our own nodes. However, a workaround exists: the treeview loading mechanism is done by a single method: RefreshBrowserView()

If it was a virtual method, we could override it to add our own nodes (This one is going straight to connect.microsoft.com, so feel free to vote for it). In the mean time, you can have a look at the methods that use it thanks to Reflector: ModelExplorerToolWindow. OnDocumentWindowChanged, and ModelExplorerTreeContainer.ElementEventsEndedEventHandlerImpl.

We can override the first method to add a call to our own refresh browser view logic. The second method is a callback registered for ElementEventsEnded IMS event, we can add or own callback for this event.

To add custom nodes to the model explorer, there is only one constraint, custom node class must inherit from Microsoft.VisualStudio.Modeling.Shell.ExplorerTreeNode. It is required to call the method ProvideNodeText in order to populate the Text property of your node if it is not set it in its constructor.

Below is a basic implementation of a custom node:

public class DefaultTreeNode : ExplorerTreeNode
{
        public DefaultTreeNode(String name, String text)
        {
            if (name == null)
            {
                throw new ArgumentNullException("name");
            }
            if (text == null)
            {
                throw new ArgumentNullException("text");
            }
            this.Name = name;
            this.Text = text;
        }
        protected override string ProvideNodeText()
        {
            return this.Text;
        }
}

1. Go to the DslPackage project

2. Open or create a partial class of your ModelExplorerTreeContainer (ModelExplorer) in the "CustomCode" folder.

3. Add it this method :

internal void RefreshBrowserViewExt() 
{ 
// Add your custom logic here 
}

4. Add your custom logic to load your nodes in the model explorer.

5. Create a callback that calls your previously created method.

private void ElementEventsEndedEventHandlerImplExt(object sender, ElementEventsEndedEventArgs e)
{
    this.RefreshBrowserViewExt();
}

6. Override SubscribeToImsEvent method and add your own callback in order to call your custom refresh browser logic.

protected override void SubscribeToImsEvent(Store newStore)
{
    base.SubscribeToImsEvent(newStore);
    // HACK : Check above if the store is null.
    newStore.EventManagerDirectory.ElementEventsEnded.Add(
        new EventHandler<ElementEventsEndedEventArgs>(
        this.ElementEventsEndedEventHandlerImplExt)
        );
}

7. Override UnsubscribeToImsEvent method to remove your callback.

protected override void UnsubscribeToImsEvent(Store oldStore)
{
  base.UnsubscribeToImsEvent(oldStore);
  if (oldStore != null)
  {
      oldStore.EventManagerDirectory.ElementEventsEnded.Remove(
       new EventHandler<ElementEventsEndedEventArgs>(
       this.ElementEventsEndedEventHandlerImplExt));
  }
}

8. Open or create a partial class of your ModelExplorerToolWindow in the "CustomCode" folder of the DslPackage.

9. Override OnDocumentWindowChanged method in order to call your custom refresh browser logic view.

protected override void OnDocumentWindowChanged(
            ModelingDocView oldView, ModelingDocView newView)
{
   base.OnDocumentWindowChanged(oldView, newView);
   ((YourModelExplorer)this.TreeContainer).RefreshBrowserViewExt();
}

Add your own model explorer commands

You can add your own commands in the context menu associated to the model explorer.

The only differences between this and doing it for the context menu associated to the current diagram are:

• The ids to use: guidCommonModelingMenu and cmdidMenuExplorerCommand.
• The mandatory definition of a guid symbol associated to the command

1. Go to the DslPackage project.

2. Open the Commands.vsct file.

3. Define a button for your operation using the relevant ids.

<Button guid=" guidMenuExplorerCommand" 
       id="cmdidMenuExplorerCommand" priority="0x0902" type="Button">
  <Parent guid="guidCommonModelingMenu" id="grpidExplorerMenuGroup"/>
  <CommandFlag>DefaultDisabled</CommandFlag>
  <CommandFlag>DefaultInvisible</CommandFlag>
  <CommandFlag>DynamicVisibility</CommandFlag>
  <Strings>
    <ButtonText>My command</ButtonText>
  </Strings>
</Button>

4. Declare the symbol associated to it.

<GuidSymbol name=" guidMenuExplorerCommand " value="{xxxx048E-739A-474A-94CC-CDA7347C52E7}" >
  <IDSymbol name=" cmdidMenuExplorerCommand " value="0x807"/>
</GuidSymbol>

5. Create a static Commands class to reference the information associated to your new commands.

a. Right-click on the CustomCode folder of the DslPackage project, Add Class

b. Enter "Commands" as name.

c. Declare the constant guid used as value for the value attribute of the GuidSymbol xml element associated to your command.

d. Declare the constant integer used as value for the value attribute of the IDSymbol xml element associated to your command.

6. Open or create a partial class of your ModelExplorerTreeContainer (ModelExplorer) in the "CustomCode" folder.

7. For each command implement a handler in order to display (or hide) the command depending on the context and a handler that is executed if the command is selected.

8. Override the AddCommandHandlers method to add your new commands to the model explorer context menu.

public override void AddCommandHandlers(IMenuCommandService menuCommandService)
{
    base.AddCommandHandlers(menuCommandService);

    DynamicStatusMenuCommand l_cmdMyCmd = new DynamicStatusMenuCommand(
        new EventHandler(OnStatusCmd),
        new EventHandler(OnMenuCmd),
        Commands.MyCmd);
    menuCommandService.AddCommand(l_ cmdMyCmd);
}

9. Open the GeneratedCode\Package.tt

10. Increment the second integer of the ProvideMenuResource attribute.

[VSShell::ProvideMenuResource("1000.ctmenu", 3)]

11. Transform all templates

12. Rebuild

13. Enjoy

Define prototype mechanism

Here we’re going to offer to users a mechanism to prototype a model element. To do this, we use the logic presented to enable copy operations and to customize the model explorer.

The customization of the model explorer must allow:

Adding custom node when a user defines a prototype.

Handling drag and drop on prototype node from the model explorer.

Saving user-defined prototypes beyond the scope of visual studio instance (persisted on disk).

Add custom node when a user defines a prototype

1. Create a serializable class Pattern

a. Right-click on the CustomCode folder of the DslPackage project, Add Class

b. Set its name to "Pattern".

2. Add to it two properties : Name (String) and Prototype (ElementGroupPrototype)

    [Serializable]
    public sealed class Pattern
    {
        public String Name { get; set; }
        public ElementGroupPrototype Prototype { get; set; }

        public Pattern(String name, ElementGroupPrototype prototype)
        {
            this.Name = name;
            this.Prototype = prototype;
        }
   }

3. Implement an ExplorerTreeNode dedicated to your class.

public class PatternTreeNode : ExplorerTreeNode
{
   private Pattern m_pattern;

   public PatternTreeNode(Pattern pattern)
   {
       if (pattern == null)
       {
           throw new ArgumentNullException("pattern");
       }
       m_pattern = pattern;
       this.Name = pattern.Name;
   }

   public Pattern Pattern
   {
       get { return m_pattern; }
   }

   protected override string ProvideNodeText()
   {
       return m_pattern.Name;
   }
}

4. Open or create a partial class of your ModelExplorerTreeContainer (ModelExplorer) in the "CustomCode" folder.

5. Add private field to store Pattern objects.

private List<Pattern> m_patternList = new List<Pattern>();

6. Code an Add and Remove method to manage the pattern list and to update the model explorer

 internal void AddPatternTreeNode(String name, ElementGroupPrototype prototype)
 {
     string l_name = name;
     if (string.IsNullOrEmpty(name))
     {
         l_name = this.GetNewPatternName();
     }
     Pattern l_pattern = new Pattern(l_name, prototype);
     this.AddPatternTreeNode(l_pattern);
     m_patternList.Add(l_pattern);
 }
 private void AddPatternTreeNode(Pattern pattern)
 {
     TreeNode l_rootTreeNode = this.ObjectModelBrowser.TopNode;
     TreeNode l_prototypesTreeNode = l_rootTreeNode.Nodes["Prototypes"];
     PatternTreeNode l_patternTreeNode = new PatternTreeNode(pattern);
     l_patternTreeNode.UpdateNodeText();
     this.InsertTreeNode(l_prototypesTreeNode.Nodes, l_patternTreeNode);
 }
 private void RemovePatternTreeNode(PatternTreeNode patternTreeNode)
 {
     patternTreeNode.Remove();
     m_patternList.Remove(patternTreeNode.Pattern);
 }

7. Load into the Model Explorer your list of patterns by using a specific RefreshBrowserViewExt method

internal void RefreshBrowserViewExt()
{
    this.ObjectModelBrowser.BeginUpdate();
    if (this.ObjectModelBrowser.TopNode != null)
    {
        TreeNode l_rootTreeNode = this.ObjectModelBrowser.TopNode;
        DefaultTreeNode l_defaultTreeNode = new DefaultTreeNode("Prototypes");
        this.InsertTreeNode(l_rootTreeNode.Nodes, l_defaultTreeNode);
        l_defaultTreeNode.UpdateNodeText();
        for (int i = 0; i < m_patternList.Count; i++)
        {
            this.AddPatternTreeNodeToObjectModelBrowser(m_patternList[i]);
        }
        l_defaultTreeNode.Expand();
    }
    this.ObjectModelBrowser.EndUpdate();
}

8. Similar to what has been done for copy operations; add to your diagram’s context menua method to prototype the user’s selection. The only difference is that it is not the Clipboard that will receive the created ElemtGroupPrototype but the ModelExplorer. To get a pointer to our ModelExplorer, we add a strongly typed property to our ModelExplorerToolWindow that casts its generic TreeContainer property.

private void OnMenuPrototype(object sender, EventArgs e)
{
    Diagram l_diagram = this.CurrentDocView.CurrentDiagram;
    ElementGroup l_elementGroup = new ElementGroup(l_diagram.Partition);
    foreach (object selectedObject in this.CurrentSelection)
    {
        // Pick out shapes representing Component model elements.
        ShapeElement l_shapeElement = selectedObject as ShapeElement;
        if (l_shapeElement != null && l_shapeElement.ModelElement != null && 
            l_shapeElement.ModelElement is ModelType)
        {
            l_elementGroup.AddGraph(l_shapeElement.ModelElement, true);
        }
    }
    this.PrototypeExplorerToolWindow.PrototypeExplorer.AddPatternTreeNode(
            null, l_elementGroup.CreatePrototype());
}

9. Don’t forget to increment the second integer of the ProvideMenuResource attribute.

Figure 3 Diagram Context menu

Implement prototype node drag and drop from the model explorer

The tree control contained in the ModelExplorer is simply the well known System.Windows.Forms.TreeView control. Thus , it offers the same features such as drag and drop.

To customize its behavior, you can override your ModelExplorer's OnCreateControol method ( due to ContainerControl base class inheritance )

1. Open or create a partial class of your ModelExplorerTreeContainer (ModelExplorer) in the "CustomCode" folder.

2. Override the OnCreateControl () method to customize the tree control.

protected override void OnCreateControl()
{
   base.OnCreateControl();
   this.ObjectModelBrowser.LabelEdit = true;
   this.ObjectModelBrowser.KeyUp += new KeyEventHandler(ObjectModelBrowser_KeyUp);
   this.ObjectModelBrowser.ItemDrag += new ItemDragEventHandler(ObjectModelBrowser_ItemDrag);
   this.ObjectModelBrowser.AfterLabelEdit += new 
     NodeLabelEditEventHandler(ObjectModelBrowser_AfterLabelEdit);
}

3. Implement the desired logic for each event handled. We decide to offer:

• Prototype deletion by selecting it and pressing the delete key.
• Prototype renaming by clicking on it.
• Prototype drag and drop (as you can see it, it’s straightforward to activate it, thanks to ElementGroupPrototype).

private void ObjectModelBrowser_KeyUp(object sender, KeyEventArgs e)
{
   if (!e.Handled && e.KeyValue == (int)Keys.Delete)
   {
                TreeNode l_treeNode = this.ObjectModelBrowser.SelectedNode;
                if (l_treeNode != null && l_treeNode is PatternTreeNode)
                {
                    this.RemovePatternTreeNode((PatternTreeNode)l_treeNode);
                }
   }
}
private void ObjectModelBrowser_ItemDrag(object sender, ItemDragEventArgs e)
{
  if (e.Item is PatternTreeNode)
  {
   this.ObjectModelBrowser.SelectedNode = (TreeNode)e.Item;
   this.ObjectModelBrowser.DoDragDrop(
     ((PatternTreeNode)e.Item).Pattern.Prototype, DragDropEffects.Copy);
  }
}
private void ObjectModelBrowser_AfterLabelEdit(object sender, NodeLabelEditEventArgs e)
{
  if (e.Node is PatternTreeNode)
  {
    ((PatternTreeNode)e.Node).Pattern.Name = e.Label;
  }
}

Figure 4 Customized model explorer

Save user-defined prototypes beyond the scope of visual studio instance.

Saving user-defined prototypes is only a matter of serializing it. Indeed, ElementGroupPrototype can transit through the Clipboard. So, the serialization mechanism is already supported. We use it to save them in a basic file.

1. Create a static class to manage serialization (and deserialisation) of user-defined prototype list into a file.

a. Right-click on the CustomCode folder of the DslPackage project, Add Class

b. Enter “UserDefinedPrototypeSerializationHelper" as its name.

2. Add a method to implement serialization and deserialization mechanism.

internal static void Serialize(List<Pattern> patternList, string file)
{
  if (!Directory.Exists(Path.GetDirectoryName(file)))
  {
    Directory.CreateDirectory(Path.GetDirectoryName(file));
  }
  using (Stream stream = File.Open(file, FileMode.Create))
  {
    BinaryFormatter l_binaryFormatter = new BinaryFormatter();
    l_binaryFormatter.Serialize(stream, patternList);
  }
}

internal static List<Pattern> DeSerializeObject(string file)
{
  List<Pattern> l_patternList = null;
  using (Stream stream = File.Open(file, FileMode.Open))
  {
    BinaryFormatter l_binaryFormatter = new BinaryFormatter();
    l_patternList = (List<Pattern>)l_binaryFormatter.Deserialize(stream);
  }
  return (l_patternList == null ? new List<Pattern>() : l_patternList);
}

3. The deserialization mechanism used in the experimental hive requires that you provie a specific a AssemblyResolve mechanism in order to resolve dsl assemblies.

static UserDefinedPrototypeSerializationHelper()
{
            AppDomain.CurrentDomain.AssemblyResolve += 
               new ResolveEventHandler(CurrentDomain_AssemblyResolve);
}

private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
  if (args.Name.IndexOf("DslPackage") > 0)
  {
    return typeof(UserDefinedPrototypeSerializationHelper).Assembly;
  }
  else if (args.Name.IndexOf("Dsl") > 0)
  {
    return typeof(YourDomainModel).Assembly;
  }
  return null;
}

4. Open or create a partial class of your ModelExplorerTreeContainer (ModelExplorer) in the "CustomCode" folder.

5. Add specific code to the overridden method OnCreateControl () to deserialize saved user-defined prototypes and to load it into the ModelExplorer.

protected override void OnCreateControl()
{
    String l_fileName = this.GetPrototypeFileName();
    if (File.Exists(l_fileName))
    {
        m_patternList = PrototypeSerializationHelper.DeSerializeObject(l_fileName);
    }
    base.OnCreateControl();
    this.ObjectModelBrowser.LabelEdit = true;
    …

6. Override the Dispose method to save when the user-defined prototypes into a file when the ModelExplorer is closed.

protected override void Dispose(bool disposing)
{
     if (disposing)
     {
         String l_fileName = this.GetPrototypeFileName();
         UserDefinedPrototypeSerializationHelper.Serialize(m_patternList, l_fileName);
     }
     base.Dispose(disposing);
}

Going further

This article lists a fair amount of customization mechanisms and promotes ElementGroupPrototype class. It’s possible, of course to go further. You can add export and import feature on prototypes in order to share them in a similar way as visual studio templates or code snippets. If the fact that you can associate an ElementNameProvider to only one property is too limitating, one can use an interface (IPrototypable to broaden the customization of the model element created. For instance, customizing the property grid associated to the prototype allows defining a description to it.

It would be very useful if the Model Explorer could support domain class namespaces (as model element base classes).

Add to toolbox

Before ending this article, we add to the ModelExplorer context menu a specific command to allow adding to the toolbox and user-defined prototype.

1. Implement an “Add to toolbox” command (See paragraph entitled “Add your own model explorer commands”)

2. Use IToolboxService service mechanism in the execution logic of your command and take advantage of ModelingToolboxItem class to create and add to the toolbox an item dedicated to your prototype.

private void OnMenuAddToToolBox(object sender, EventArgs e)
{
  IToolboxService l_toolBoxService = 
        (IToolboxService)this.ServiceProvider.GetService(typeof(IToolboxService));

  if (this.ObjectModelBrowser.SelectedNode is PatternTreeNode)
  {
    Pattern l_pattern = ((PatternTreeNode)this.ObjectModelBrowser.SelectedNode).Pattern;

    ModelingToolboxItem l_modelingToolboxItem = new ModelingToolboxItem(
             l_pattern.Name, 1,  l_pattern.Name, 
            (Bitmap)ImageHelper.GetImage(
PrototypeDomainModel.SingletonResourceManager.GetObject("ModelClassToolboxBitmap")), 
                         "Prototypes", "Prototypes", "", "Prototype", l_pattern.Prototype, 
                        new ToolboxItemFilterAttribute[] {                            new ToolboxItemFilterAttribute(PrototypeToolboxHelper.ToolboxFilterString, ToolboxItemFilterType.Require)  });

    l_toolBoxService.AddToolboxItem(l_modelingToolboxItem, "Prototypes");
  }
}

Figure 5 Customized toolbox

Workaround

Unfortunately, the treeview control has unexpected behavior when you want to customize the status of a context menu command.

If you want command displayed only for a specific tree node, you basically use SelectedNode property of ObjectModelBrowser (on the ModelExplorer instance). But this property doesn’t return the relevant selected node if you do not select the node with a left click before right clicking it to display the context menut.

To work around this problem, one can implement a specific callback for the AfterSelect event raised by the treeview that uses the selection service.

1. Open or create a partial class of your ModelExplorerTreeContainer (ModelExplorer) in the "CustomCode" folder.

2. Add specific code to the overrided OnCreateControl () method to add a callback for AfterSelect event raised by the contained treeview (ObjectModelBrowser).

protected override void OnCreateControl()
{
  String l_fileName = this.GetPrototypeFileName();
  if (File.Exists(l_fileName))
  {
    m_patternList = UserDefinedPrototypeSerializationHelper.DeSerializeObject(l_fileName);
  }
  base.OnCreateControl();
  this.ObjectModelBrowser.LabelEdit = true;
  this.ObjectModelBrowser.KeyUp += new KeyEventHandler(ObjectModelBrowser_KeyUp);
  this.ObjectModelBrowser.ItemDrag += 
  new ItemDragEventHandler(ObjectModelBrowser_ItemDrag);
            this.ObjectModelBrowser.AfterLabelEdit += 
  new NodeLabelEditEventHandler(ObjectModelBrowser_AfterLabelEdit);
            this.ObjectModelBrowser.AfterSelect += 
  new TreeViewEventHandler(ObjectModelBrowser_AfterSelect);
}

3. Implement your callback by using the selection service to customize the selection mechanism associated to our custom tree node.

private void ObjectModelBrowser_AfterSelect(object sender, TreeViewEventArgs e)
{
    if (e.Node is PatternTreeNode)
    {
        this.SelectionService.SetSelectedComponents(
          new object[] {((PatternTreeNode)e.Node).Pattern});
    }
}

Support prototype auto-layout on drag and drop

When you drag and drop a prototype or when you copy and paste a model element, the associated shapes created by this action are displayed by default on the same position.

To avoid this, one can call AutoLayoutShapeElements method of the diagram on which modelelements are dropped.

Here is below a code extract to accomplish this task.

1. Open Solution Explorer.

2. Go to the Dsl project.

3. Open or create a partial class of your Diagram in the "CustomCode" folder.

4. Override the OnDragDrop method to layout automatically dropped elements.

Take into account model element namespace

There are multiple ways to customize the model explorer; one of them is to define a new tool window.

You can act on the default model explorer representation and take into account the namespace associated to the domain class of a model element.

A smart Class designer

The sample solution coming along with this paper is, as described in the introduction, based on the class diagram DSL template. If one of Rosario’s promises is to offer a set of new diagrams built on DSL tools, it would be very useful if these diagrams provide prototyping capability. For instance, a class diagram could assist developers by offering by default a set of code design patterns (gang of four…) and offering a simple sharing capability between users following code snippet footsteps.

[1] You can as well navigate on the dedicated MSDN Forum to Visual Studio extensibility.

Download the complete solution here.

A screencast showing a scenario taking advantage of the functionalities presented in this paper is available here.

The pdf version of this article is available here.

Introduction

As outlined in the first part of this article, referencing services greatly extends their visibility and promotes their capitalization. When most of the time services are deployed somewhere and accessible from a fairly static location, it happens that, to cater particular business needs that we will be outlined later on this post, some services requires to be discoverable in order to be accessed transparently regardless of their particular location at the time. This document covers such a requirement by exposing how to combine open standards and WCF to publish services in such a way that they can be discovered dynamically at runtime based on custom business criteria.

Service Referencing

Dynamic service referencing and discovery in general are complementary to static referencing and address different business requirements.

Dynamic Service Discovery

Requirements

Prior to take advantage of discovering services at run time, two major points must be addressed and settled. First, because discovery has a cost that is not negligible it must be used only to address particular business needs. Then, it must be handled with the scope of a business contract. This contract defines the way the service can be discovered as well as the options available for interacting with it.

Discovery is costly

By nature, discovery is costly either on the network because discovery requests will have to be sent across the whole network using multicast or either on pure processing because the discovery will add a few extra steps in the way you access a service. By using discovery, you cannot just have the service’s access points in your configuration or in a repository (remember part I of this paper).

A full use case of taking advantage of discovery requires those steps:

· Send a request on the network for services matching a business requirement,

· Receive all the responses from the services,

· Select the most relevant one,

· Act accordingly which means extracting the selected service’s metadata in order to dynamically generate a proxy in order to communicate with this service.

As you can see these are extra steps that increase the client side effort required to communicate with a service. Compared to just using Visual Studio’s “Add web/service reference”, it becomes obvious that it would be foolish to use discovery all over the place just for the sake of calling dynamically services. This highlight once again the fact that discovery must respond to a business requirement and must be evaluated as such before deciding on using it.

Discoverability driven by business need

Taking the decision to expose a service as discoverable must be done in the light of a business requirement. The overhead induced by such discoverability must be balanced with the benefits you get out of it. Some business scenarios require services to be discoverable because they’re occasionally up, they are nomad and are not always accessible at the same location and so on… We will quickly describe few scenarios later on this paper.

Existing service selection solutions: BAS/TPM

Existing products and technologies already address service selection based on a set of business rules; a product such as Microsoft Biztalk offers Trading Partner Management (TPM) as well as Business Activity Services (BAS) that allows selecting business partners. This mechanism rests on well defined static business contracts as well as a predefined set of rules. This is similar to what discovery requires in the sense that business contracts must be settled first before starting discovering services. The rules equivalent used by BAS/TPM is represented as criteria. Where BAS/TPM offers dynamic selection of existing, referenced services endpoints, discovery allows going one step further and adds dynamic communication between client and service.

Business contract settled

The first thing to complete before even thinking about launching Visual Studio to hit the discovery API and start discovering dynamically services is to clearly define the business contracts responsible to formalize the way a client can interact with such a service. This also helps identifying if the service in question should even be discoverable at all. Doing this preliminary step with discovery in mind will help you evaluate which operations should be discoverable and can, and probably will, have an impact on the way you design and decompose your business contracts. This is a crucial step to complete in order to ensure a proper use of discovery and avoid useless discovery overhead on operations that do not require it.

Negotiation phase finalized

The approach taken here in relation to the discovery requires that a “negotiation process” occurred prior to starting discovering services. Those services are already well known, they are driven by a well known business contract, and the only unknown piece of information at the time of discovery is the location of the service responding to a particular business need. The lever allowing switching between existing services are defined by search criteria as explained bellow.

Search criteria defined (Extended search criteria with business context which is not included in business contract)

Discovering services is all about being able to specify custom, business oriented criteria that are relevant to the discovery. Those criteria must be though through and evaluated in such a way that they can conveniently be set in place, computed and interpreted. At the same level that one must define the business contracts that will dictate the way services are exposed as discoverable, one must define the search criteria that will be used to discover such services.

Use cases

Because, as outlined previously, one must be careful to where to take advantage of discovery, it is important to outline a few sample use cases where discovery can help addressing business requirements. The most obvious advantage of using discovery features in your environment is to reduce the effort required to register your services within an information system as well as provide business attributes in order to easily discover relevant services based on business criteria.

Goal: Reduce registration effort

Here are three sample use cases that highlight the benefits of using discovery to either reducing registration service effort, cope with services occasionally connected as well as nomad users that requires to connect to specific, context driven, services.

Nomad services

A salesman visiting clients worldwide often has to connect to the office VPN to either download or upload data in order to do day to day work. By taking advantage of discovery as well as his geographical position, he can transparently find to the most relevant local branch to connect to in order to

Disconnected services

When dealing with occasionally connected services, it is important, in order to offer the best quality of service, to be able to find active services that respond to particular business requirements. Using discovery in such scenario, allows querying the information system for active services addressing a particular business requirement. This query mechanism can be sharpened to include specific business or technical parameters to ease the look up process and provide a transparent experience from a consumer point of view.

N3RD – Command Center

During wild fires in south of France, firemen have to deploy a remote command center close to the incident. Because of time constraints, there is no time to waste to setup and register this new, temporary, command center. This is where discovery comes into place; it allows the remote command center to register onto the network so the calls related to the fire are routed automatically to this new virtual station and not to the existing fire stations. Once the fire is over, this temporary, remote command center is then switched off and disappears from the information system. No calls can be routed anymore to this command center.

Video demonstration

A demo video of WS-discovery in action is available here.

This demo addresses the N3RD Command Center use case described above and contains 3 parts:

1. The client runs a probe match on the network and several stations respond to it. (Client doesn't know which fire station must be selected).

2. Fire stations respond to the client request and indicate their respective geographical position. The client then picks the closest one.

3. The client sends a custom probe message indicating its geographical position, only services located within a 3 miles range respond to the request. The client picks the closest one.

In the last part, we used header injection in the address in order to call dynamically the service.

Standardization

There are multiple ways to technically address such a capability. Where anyone could implement its own solution to this problem it is critical to offer the most open solution. This is all about discovery therefore if you want your services to be discoverable the worst path to follow would be to implement a custom proprietary discovery protocol. In the same way, open standards allow exposing services metadata, so regardless of the platform you are working with; you can query, read and interpret those metadata. The same concern is true for discovery, being discoverable requires following standards so third parties or different platforms can still discover your services.

Business service must focus on business it serves

Adding to a service the capability of being discoverable must not interfere with the business purpose of the service. Such a capability must not require any specific code on the service itself and must be able to be plugged side by side with the service it exposes as discoverable. The implementation that we will describe later on takes into account this fact.

Dynamic discovery is a technical service

Discovery is a purely technical process allowing addressing business requirements. Such a capability must not interfere with the business in any way. The discoverability footprint must be reduced to the maximum in order to ensure proper business throughput.

Use a specification with large adoption

Discovery is all about the ability to be discoverable for the services requiring to be exposed as such. It is therefore crucial to follow standards in order to ease interoperability with existing technologies or products. There are numerous standards driven by consortiums that helps standardization and promotes interoperability. Within the WS-* galaxy, there is one specification targeting discovery: WS-Discovery.

WS-Discovery

The implementation presented here is based on Vipul Modi’s work published here that offers a very good baseline for building an effective and extendable business oriented service discovery.

This specification, driven by few major actors of the IT world such as BEA, Microsoft, Intel, Canon etc…, defines a multicast discovery protocol to locate services. As a WS-* specification, it quickly becomes the de facto protocol when dealing with dynamic service discovery. The implementation presented bellow follows this specification and ensure a wide openness with existing platforms as well as the largest scope to provide the widest discoverability. The full WS-Discovery specification is available here.

Maturity

This specification is already widely available for device discovery thanks to UPnp, SSDP and Windows Rally initiative. Windows Vista uses this standard for discovering devices capabilities and offering or exposing relevant functionalities. For example, when displaying your network neighborhood, your residential gateway can expose its configuration page so Windows Vista can add an extra contextual menu allowing opening up the gateway’s configuration regardless of its actual IP address.

Smart implementation

This discovery process as outlined in the WS-Discovery specification follows the famous Publish - Subscribe pattern where a discoverable service joining the network sends a multicast Hello message notifying all the listening parties that it is available. In the same way, before shutting the service down, it notifies the same listening parties that it is leaving and will therefore not be available to serve requests anymore by sending a Bye message. During the time the service is available and discoverable, it is able to responds to discovery messages sent across the network, again following WS-Discovery specifications. This technical capability must not interfere with the business purpose of the service. Such a service cannot afford to take execution time to respond to discovery messages.

Relayed and diffused infrastructure

As mentioned above, a service cannot waste time servicing pure technical operations. Therefore, a dedicated mechanism must be setup to expose the discovery capability of the business service without interfering with the business value the service brings. In order to address that, a separate, purely technical, service is automatically created and started along with the business service. It runs as separate instance with the only purpose of exposing discovery and responding to discovery requests. The diagram bellow outlines the architecture put in place clearly separate business value from technical capability brought by WS-Discovery:

As this diagram suggest, there is a clear separation between the business scope of the service and client and the discovery process and the discovery process never interfere with the business operations.

Few messages exchanged

WS-Discovery is based on very simple, yet powerful, set of messages. By offering Hello and Bye messages, the publish/subscribe pattern can be easily implemented. In conjunction with those two messages, come two types of messages allowing querying for discoverable services: Probe and Resolve.

Identity card to extend

The specification describes a common identity card specifying a set of common attributes that a discoverable service must expose. As described in the class diagram bellow, these are: AnyAttributes, AnyElelments, EndpointAddressAugust2004, MetadataVersion, Scopes, Types and XAddress.

Extensibility driven

Thanks to WS-Discovery specification openness (with AnyAttribute and AnyElements) the messages are endlessly extensible to cater any specific business requirements. One of the goals of the WS-Discovery implementation exposed here was to provide the most convenient extensibility model in order to allow developer to easily define custom, business oriented messages that provides a friendly business centric client side discovery mechanism. The class diagram bellow describes this architecture:

As you can see, by inheriting from ServiceProperties class, it is trivial to declare a custom, business focused, specialization of it that exposes the geographical position of the service declared as discoverable. Using the same technique, messages can be specialized as EmergencySiteHello class suggests. Again, client side, the same technique is used to create business centric MatchCriteria that allows discovering services based on business attributes, see CallerMatchCriteria.

Going further

Microsoft Surface

Such a technology could greatly extend the applicative discoverabilities of Microsoft Surface. Any application can easily take advantage of this discovery mechanism based on business or technical contracts as well as custom criteria thus react appropriately with devices or applications in range of the Surface.

Going further than just a way to connect applications and devices, such a technology can open a broad new range of scenarios where opened applications could be modified or notified by discovered devices or services and provide a deeper interaction between human and machine.

ESB Toolkit (Resolve UUID)

A cornerstone of an enterprise service bus (ESB) is the service repository that it maintains. The notion of static and dynamic referencing address in this two part article can be directly applied to an ESB by taking advantage of both UDDI for the static service referencing and WS-Discovery for dynamic service discovery. The extra step that an ESB should offer is a dedicated proxy allowing taking advantage of WS-Discovery in order to provide a transparent communication initiation.

Getting started with our implementation

This article comes with a fully featured getting started kit walking you through two samples in order to get you started quickly with our implementation of WS-Discovery. The kit is available here

Links

The pdf version of this paper is here.
The demo video is here.

Format: wmv
Duration: --:--

Introduction

Not knowing precisely the services developed and deployed in an environment is not something anyone serious about service oriented architectures can afford. In this regards, business service cartography is a key pillar of SO architectures and valuable help to get insight on your business related developments. Being able to draw a map of your business, at any time, is a must to start capitalizing, industrializing and get enough insight to predict with maximum reliability the impact of change within an organization.

Beneath the notion of business services cartography lays two main directions of work:

The first one, which is the goal of the first part of this article, is driven by the necessity to formalize contractually business processes, services and operations and is seen as static referencing.

The second one, which will be addressed in our next article, addresses the agility required by such a capability in the form of dynamic referencing.

Static referencing

The notion behind static referencing rests on the fact that by coupling a repository to a negotiation process you can have enough materials to build the first blocks towards contractual business services definition.

When talking about services and repository, one of the first acronyms that come up is UDDI. Universal Description Discovery and Integration is the de-facto standard when it comes to web services repository. Because UDDI comes for free with any version of Windows Server 2003, it is an inexpensive way of building business repositories. Thanks to its very expandable categorization mechanism it is the ideal candidate to build your business service repository on. Even though, its API has its flaws, once you get your grip on the philosophy behind the concepts of tModels, Categories, Bindings and so on, you are ready to rumble. This is what will be covered later on in the implementation section of this paper. The business data being referenced within the UDDI repository has to be contextualized to reflect business cases.

Once the repository issue is sorted, the next step is to find a streamlined way to formalize a negotiation process. When you mention business process and Microsoft in the same sentence, developers like us think about Microsoft Biztalk straight away. Even if the first versions had their draws, we must say that Microsoft Biztalk with 2006 release made a good step forward and more importantly in the right direction. It is therefore a safe bet to rely on Business Activity Services (BAS) and its trading partner management (TPM) feature to handle the negotiation process associated to the business repository. The negotiation phase outlined here is not about “magically” discovering new business partners but to effectively choose the most appropriate one for a particular situation. All these suppliers are already referenced within the information system and well known.

In order to achieve the level of introspection, preciseness and completeness required to draw an effective cartography of your business, Microsoft released a new methodology, technologically agnostic, meant to help you conduct the tedious phase of defining and sometime discovering your business services cartography. This methodology, called Motion, is provided by Microsoft Consulting Services. This is far from being trivial to achieve but once completed it offers a very valuable source of data that helps you drive your business as well as quickly spot where to put your $$ on.

Uddi

Introduction

UDDI is an industry wide initiative based on XML technology aiming at facilitating the publication and discovery of web services on the web. This initiative driven by OASIS has been pushed by many major actors of the IT world such as Microsoft, IBM, BEA, HP and so on. To accelerate its adoption, they quickly provided public repositories implementing this technology on the web. Unfortunately, even if it had the advantage o f showcasing the technology, those public repositories cannot be seen as the source of new commercial partnerships between companies. Indeed, it is not enough to remove the technological constraints to pretend to automate this process; UDDI is best seen as a facilitator. A similar effort to what has been done on the technological point of view has to be realized on the business side. Companies addressing the same market should come up with a common formalization of their business if they want to go further into the discovery process and follow the footsteps of business initiatives such as RosettaNet. Standardization requires a massive investment, this is why before targeting the WWW, it can be valuable to address a smaller scope that is the company and use UDDI private repositories.

As a reminder, a UDDI repository is composed of:

· White pages: similarly to phone books, they list company details, contact information and other company identifiers.

· Yellow pages: they organize data published based on business information. These pages list all the business services.

· Green pages: they regroup all the technical information related to the referenced business services.

In a situation where it is about focusing on private repositories, the enterprise notion is replaced by the notion of departments or business units.

As outlined earlier, this paper does not intend to address business classifications therefore we will focus on what we described earlier as the “Green pages” and how to publish such information in relation to Windows Communication Foundation (WCF).

Service cartography

Publishing services offered by each departments of a company does not come for free. However, for a reasonable investment a first step towards companywide service cartography is possible.

Indeed, using private repositories will allow the company, once each department completed its publication process, to benefit from a central location with a description of each business services available within its information system.

A solution exists to ensure that each department maintains the private repositories up to date are to include two new steps within the development cycles. The first one that precedes the development phase constrains the business analysts to, before writing down specifications of a new service, ensure that none is already available within the company by search through the UDDI repository. This is during this phase that the investment made on the business classification takes all its sense because the analysts will take into account the business value of the services as well as their usage context. The first obvious advantage of such as procedure is to promote capitalization and reuse.

The second step is address during the deployment phase where it consists of publishing the new services developed. This task, accomplished by technicians, is all about publishing into the repository the business information provided by the analysts as well as the technical information related to the service such as its access points, security policies and so on.

Service dependencies

Departments within a company are not isolated from one another and usually do not work in an autonomous manner. Describing these dependencies can provide crucial information when it comes to address new business requests as well as modifying existing services offerings.

By formalizing those dependencies, companies can foresee the impact of a particular modification companywide and more easily estimate its impact. UDDI offers specific elements to define dependencies between companies therefore departments. However, these elements cannot be used to describe service dependencies. The solution is therefore to define dedicated elements.

Typical scenario

This scenario which is illustrated in the video provided with this article demonstrates the whole process of referencing services, how they can be searched, published and the extra level of information it offers to developers. The scenario is inspired by the reference implementation provided by the Web Service Software Factory team.

The action takes place at Global Bank where a new module needs to be implemented. This module requires getting customer related information as well as handling payments. Three personas from a typical development cycle are involved in this process.

Business analyst

He is responsible to check that no existing services are available prior start specifying as well as ensuring the relevance and accuracy of the business categorization information added to each WCF artifacts published in the UDDI repository. He is also responsible for defining the business context and business categorization to be applied to the services that he is specifying.

Service developer

The second actor involved is the service developer; he has the responsibility to develop the service as well as its publication into the UDDI repository. If business categorizations are already available, he can include them into the service configuration file in order to be picked up automatically when publishing the service. To do so, he uses the Visual Studio add in provided to publish directly from the IDE into UDDI (as shown in the video).

Client developer

Finally, the client developer can then use Visual Studio’s “add service reference” feature to search the UDDI repository and find the WCF service he needs and if WSDL information have been publishing let Visual Studio generate a proxy to communicate with the service.

The last step in this process that is not shown in the video is that the business analyst, once the service is published into UDDI repository, will add all the business related categorization information to make this service discoverable easily to maximize its reuse.

The video available with this article demonstrates the whole process: from the business analyst who first checks for existing services, then the service developer who publishes the new service into the UDDI repository and finally the client developer who uses UDDI to find services and their WSDL if any and just adds a service reference directly from Visual Studio.

Going further

Transactional context

Most attentive will have noted that the actual version of UDDI does not offer a transactional context. Even if this lack will probably be addressed in the future UDDI release, there is no reason to constrains ourselves to not transactional publication. By migrating the UDDI web services to WCF we could easily take advantage of the built-in transactional support thus offering a more reliable experience when it comes to publishing information into the UDDI repository.

Reporting

As soon as the repository is in place and that the first services have been published, it becomes trivial to extract reports presenting the number of business services, what is the department publishing the most services, what is the most used security policy, does these critical services are all secured and so on…

And why not expect a LINQ provider to ease the creation of the queries used to generate reports?

Extend service publication

It would be very useful to offer a mean to personalize the WCF binding representation mechanisms in the form of a categorization in order to take into account all its properties and not only Enum and bool. It could also be valuable to publish the WSDL document associated with a service by taking advantage of the import / export mechanisms offered by WCF. The first step could be that when loading the service description during the publication process, indicate in the WSDL/MEX address in the tModel’s overview document associated with the binding.

Service deployment

The deployment of services could be automated by developing dedicated actions within TFS team projects.

Wrap-up

The goal of this first part was to introduce the concept of business service cartography and how, with a minor investment, UDDI can address this problematic. The most expansive part of the business service cartography is not the server or the software to operate it but the level details that you are willing to put into the categorization of your business data. In the article, we propose our own interpretation of the WCF categorization and can be seen as a starting points to derivate it to suit your business description. This solution offers a technical vision of your information system in terms of WCF services and let you easily extract meaningful report as well as promoting reuse of existing services and capitalization instead of re developing the same services.

The add in provided is also a starting points to integrate the business cartography into the development cycle by facilitating the publication process.

However, be extremely careful, even if the most vicious of you could have thought about it, and even if all the information to do it is available, your UDDI repository is not intended to address dynamic discovery. As outlined in the introduction, UDDI is all about static referencing that can be automated but more importantly tightly linked to your development cycle. It is not about updating the repository information each and every time the service starts. The problematic of dynamic discovery will be covered in the next part of this article.

Downloads

Pdf version including technical implementation details is available here
Visual Studio addin installer is available here
Video is available here

 

 

Format: wmv
Duration: 15:34