The site is currently in read-only mode for maintenance. Posting of new items will be available again shortly.
I have decided to have a little go at creating a Team Foundation Server Event Handler in .NET 3.5 that is resilient and scalable. I will be using as many of the features of Team Suite as I can, but bear with me as there are a few things that are new to me. I am going to create everything under source control in CodePlex.
For a full list of articles in this series: check this link.
The first toy I am going to play with is the Team Edition for the Architecture components of Team Suite. This will hopefully allow me to create a system that has a bit of foresight and planning associated with it. I have played with these features before, but I have not, up until now, used them in battle.
I have created a blank solution in my TFS Event Handler Codeplex project, so it is time to create the "Distributed System Diagram" that I will use to define the architecture of the system.
When you create the diagrams, they are added to the Solution and not a specific project. These diagrams will be linked to the code that we will eventually create, allowing us to view these diagrams even if we have made changes. They will update automatically with any architectural changes that I have made after coding has started.
The logical place to start is with the Application Diagram, and this is highlighted by default. The other diagrams are useful as well. The Logical Datacenter diagram will allow you to assign parts of the application to different servers and control the communication between these servers. The System Diagram is used to define logical systems that communicate with each other.
You get a number of diagrammatic options in the toolbox. The Applications section lists all of the types of applications that are going to be in your solution and represents the projects that are going to be created under your solution. If you add a Windows Application, for example, you will get a Windows Application project within your Visual Studio solution. It is worth noting that there is no need to think about "individual projects like what assemblies am I going to need", or "how will I arrange my namespaces" at this point. All we are interested in is the main building blocks of the application.
The first applications that I know that I am going to need are Web Service applications to handle incoming events from the Team Foundation Server and a web service that will allow us to configure any option for this part of the system and the subscriptions to team servers.
Now that I have added a web service, you can see that it is just a different type of Web Application. This will need some configuring to be what we want. I have chosen to only handle two of the events that TFS throws,
CheckInEvent. There are many other events that could be handled, but these two are probably the most common.
The completed service looks quite simple, but we now need to configure it to allow it to work effectively. If you leave everything as defaults, you end up having a hundred things to change later, so it is way better to get it out of the way and polish it at this stage. There are different settings available for each application and endpoint type, so the best thing to do is to look through all of the options and see what is what. You can see from the image that I have configured all of the options on the service end point and I repeated this on all of the endpoints. Many of these settings are used when we generate the code at the end of this process.
The second application is the decision service. It has a MSMQ service endpoint called EventReciever that the notification service passes all of the events that it has received to. This service will then execute all of the events against the Workflow service that will perform any activities associated with the event. The reason for the EventReciever service is to make the system more robust. Because the EventReciever is an MSMQ service, the Notification Service can still send messages to it even when it is down.
The final end point to add is a web based administration system for the workflow system. I have added all of the links between the applications that define the communication between the services. The ability to create these diagrams is not limited to being done at the start of the process; you can add this diagram to any solution, and it will have all of your applications and links defined already. This is because there is a direct link between the solution and the diagrams. You can change either and affect both with the change, and this does not just apply to these architecture diagrams but to the Class diagrams that are part of the Team Edition for Development.
With the application diagram done, I can now do a number of things. One of which is to implement "All Application" which will build my main projects for me.
What I am going to do first take you through the "Define Deployment" and "Design Application System" options to get a better understanding of the capabilities of the system. Before I can do this, I will need to create a Logical Datacenter diagram to define what infrastructure is available, namely a single server that may or may not be the same server that the Team Foundation Server is installed on.
In creating the Logical Datacenter, I realized that I had made a mistake in my diagram of the system and I had not allowed for the additional web interfaces for the application. I have updated the diagram to reflect the problems I encountered. The diagram now has a separate web administration application that talks to both of the main admin services to get information and to make changes to the way that the system operates.
It has two web end points, one for administering the workflow in the event handler and the other for administering the subscriptions for the notification service.
This is one of the best advertisements for this way of working as you spot more of the mistakes at this point and not half way through coding.
Logical Datacenter Diagram
The logical datacenter diagram is very simple for this application as I want it to run initially in a single server environment. At the moment, I have no need for a database, but it can easily be added to the system at a later date, I could even separate out the services from the website without having to change much of anything as far as the developers are concerned, it just impacts the architects.
The options that you get are mainly self-explanatory, you can add "Zones" which are your firewall areas and put your servers with these areas. You can then add endpoints and their links through the firewalls to show how communication occurs. You can add all of your firewall rules into the system so it more readily replicates your network.
For this application, I only have one zone and one line of communication as all other communication takes place on the server.
You could have a much more complicated infrastructure, but for this application, it is unnecessary.
The deployment diagram allows you to place all of your applications onto the diagram so you can define the communication lines and determine whether the applications can talk to each other in the desired way.
In this case, we only have one Zone and one server, with HTTP inbound for the web sites. You can see from the diagram that I have added all of the applications to the one server.
If you have a complicated system with more than a few applications, you will want to break up the diagram into manageable systems so that you can see the input and output of the system. You could say that there is a Core system that contains the web services, and that only two of the web services are accessible outside of the system. If you add the applications to a System diagram and right click on a web service, you get the option to create a "Proxy endpoint" that sites at the edge of the system but is linked to the main service.
I can now create a From End System diagram that has the website and only a definition of the Core system without any of the internal components.
You can see the result in the diagram. In a much larger system, it allows you to view the components and the interaction of the components from a variety of differing angles to see how the whole thing interacts.
The last part of this is to initiate the implementation of all the applications that I have created. This will create the projects under a solution that can then be used to build the final application.
As you an see, without doing any code or creating any projects within VS manually, I have a full solution. That is, my job as the architect is over, unless there are any changes from development. This would now be handed over to the developers for completion.
Note: I have found that using this method, you can only create ASMX services, and not WCF. This will hopefully (please) be sorted for RTM of Visual Studio 2008.
More articles and industry insight can be found here.
Technorati Tags: Visual Studio Team System, Visual Studio 2008, Team Edition for Architects, TFSEventHandler, Microsoft .NET Framework, Software Industrial Revolution.