DDJ: So talk a little more about System Definition Models.
RH: If you open up Team System, and you say, "I want to create a new application diagram," and you start dropping web services on the designer, the little application designer file that you're saving is just a mess of hideous XML. That's actually an SDM document. There's a full-blown SDM specification. There's an SDM SDK that you can download. They're not just pretty pictures. There's actually intelligence in there, and they can perform validation and be transformed into other, more tangible artifacts.
DDJ: So what are the kinds of pretty pictures that you can make with VSTS? There are obviously class diagrams, but what other diagrams are supported?
RH: First of all, the class designer is technically not part of Team System. It's found in the professional edition of Visual Studio, but it is arguably a DSL. It turns pretty pictures into .NET code, and back again.
As far as Team System goes, there are four distributed system designers. The way I like to go through them is to start with the Logical Datacenter Designer. This is where an infrastructure architect would model the deployment environment, whether it's going to be deployed to a single box in the garage, or a whole rack of servers and domains and firewalls in a big datacenter somewhere. But, it's logical, and that throws a lot of people. You're not putting down ports and firewalls, and routers and hubs. You're using logical concepts like servers, zones, endpoints, and communication pathways.
The second designer would be for the application architect, using the Application Designer (AD). This is what people walk up to the whiteboard and do. They draw five squares, the first two are clients, the next two are web services, and the last one is a database. They connect them with arrows, make them different colors, and the like. This is your standard designer for connected systems. They can be Windows clients, web clients, and web services. There are some prototypes for BizTalk, Office, or other generic applications. There are more prototypes coming and the SDK allows you to customize as well. You can also get a Microsoft Operation Manager prototype. This is probably the most popular of the modeling tools.
Then you can compose those applications into systems. Maybe you have three web services running on three separate servers, and this comprises the proverbial "stock ticker" system. With the Distributed System Designer, you can lasso those three web services, give them a friendly name, and give them settings and constraints at a higher level. And then you can talk about deploying the system, even though it's composed of three applications. This is sort of the stealth designer—it's not one that everyone uses, but it's very important when modeling composable systems.
DDJ: This system designer isn't where you're architecting the internal details, but you're aggregating applications into larger units. What about deployment? How do you verify that your deployment is going to work?
RH: That's the last designer, which is the Deployment Designer. You bring up your systems on the left, and by systems, I mean applications, web services, databases, things like that. And then you bind them to servers. You might drag and drop your two web applications onto a server called "Zeus," where Zeus is your public Internet box. Then you might grab five web services and drop them onto a server called "Apollo." Maybe Apollo is inside of your firewall. And then drag and drop your database onto a SQL Server named "Pudding." If you ever try to drop something onto a server, and you get the "no smoking" icon, it means that it's not valid to bind that application to that server because of rules that you've set up in those SDM documents. The rules might say, "You told me that this server doesn't allow HTTP access, so you can't put a web application here."
