I've done my fair share of technology presentations, and recently a lot of those have centered around the designers in Visual Studio Team System (aka Whitehorse). Now when you do a presentation, it's hard to really exercise the technology. You tend to stick to specific scripts, and avoid concepts that are complex, and take too long to explain (unless you want your audience to fall asleep).

 

As a result, I was both excited, and a little bit worried, when one of my corporate customers asked me to help them architect and design a new series of applications they were going to build using VSTS. Excited, because I was finally going to get a chance to really exercise this cool technology, and a bit worried, because I wondered just how much value it would actually add to the design process, and whether it would really work as promised (it still a beta after all).

 

This blog is the first in a series where I'm going to try to explain how I went about using Whitehorse, and how effective I found it.

 

The customer had already developed an enterprise architecture which covered off the major applications they needed to build in the coming months, and also provided a whole lot of guidelines around how those applications should be architected (leading towards a SOA). The customer also already had some applications deployed using VS 2003, in an existing datacenter environment.

 

We started by identifying a candidate application. This was a retail POS application which was going to be browser based, and would provide retail customer management, and order creation/update. At the back-end, this functionality was all provided by SAP. We planned to integrate with SAP via SAP Web Services.

 

We started by laying out our initial application design. You can see the initial design below. The various applications are laid out in tiers, with a presentation tier containing the POS web site (CustomerSalesOrder), an application tier containing process level services (StoreOpsPS), another application tier containing the more atomic web services (SAPFacade, StoreOpEvents, and InfrastructureServices), and a data tier.

 

 

The key applications for the retail POS system are the CustomerSalesOrder web site, and the StoreOpsPS higher level services. As we started looking at those more closely, we realised that there were going to be some common services which would be shared by various applications. We decided to group these as InfrastructureServices, and these included things like auditing, authentication etc. We also wanted to be able to add integration with other systems easily, so we decided to implement an event publisher (StoreOpsEventPublisher), which applications could subscribe to. This was not required for the initial application, but we felt it would come in handy later on.

 

At this stage, we did not have access to the SAP system, so we mimicked that with a ASP.NET Web Service called SAPWS. We put a couple of Web Services into this proxy based on the SAP documentation. Later we'll replace this with the actual SAP web services.

 

At this stage, we talked to the infrastructure team, and got them to help us lay out the existing infrastructure using the Logical Datacenter Designer. That diagram is shown here

 

 

As you can see, they have two logical tiers, with presentation and application in the WebZone, and then several "data" tiers (SAPZone, DatabaseZone, and MainframeZone). From my perspective, although SAP and the mainframe have application logic, I only access them as data servers.

 

One thing that was not immediately apparent to me was that I needed to actually connect up endpoints even within a zone. So, when I first built this it would not validate against my Application Design, because I hadn't specified the LocalWS, or the EventQueue (OK, so I should RTFM). I found that I could connect up various Web Services, database connections, and generic connections, and then set constraints around them. For example I was able to specify that the protocol for the EventQueue had to be MSMQ. Cool.

 

At this point, I created a deployment diagram, and then spent some time putting all the applications into the appropriate servers, and linking up these within and across the zones. This took an hour or so, mainly due to my incomplete understanding of how it all worked. I also laid out the operations on each of the Web Services, ready for these to be created.

 

So, after all this, did Whitehorse help me design this system? At this stage in the process, I'd have to admit the benefit was still marginal. It did help, in that it forced the various interested parties to cooperate, and design not only how the application was going to work, but also how it was going to be deployed, but at this stage, we could have done all this with Visio.

 

HOWEVER, stay tuned for my next blog, when I'll describe how we continued to work with these design views, and make them much richer than they are here...