The Distributed System Designers

The Distributed System Designers

The Distributed System Designers are a set of design tools in Visual Studio 2005 Team System Edition for Software Architects that help reduce the complexity of developing and deploying service-oriented applications.

Application architects visualize their service-oriented applications, and developers work with the generated code while keeping the code changes synchronized with the visual design. Infrastructure architects create logical abstractions of their datacenters. Prior to actual deployment, these architects validate the application design against the constraints of the logical datacenter design. Reports generated from this validation help to document the application's deployment.

There are four Distributed System Designers:

• Logical Datacenter Designer

  This designer creates diagrams of interconnected application Hosts. These Hosts represent the logical structure of a datacenter for the purpose of communicating those aspects of the datacenter architecture that constrain the design and configuration of the application.

• Application Designer

  This designer allows developers and architects to define applications that will be configured into systems for deployment.

• System Designer

  This designer composes applications into systems, for deployment and reusability.

• Deployment Designer

  This designer describes a deployment of a system to a logical datacenter, which is accomplished by binding applications within the system to logical servers (application Hosts) modeled in the logical datacenter diagram.

Logical datacenter diagrams and application diagrams can be created independently, by different users, and in any order. When starting a new software project, it might make sense to begin with the logical datacenter diagram. You would start with this diagram because, more than likely, that infrastructure will already exist or your company will already have established Windows versions and policies in place. I realize that this isn't the case for all environments. Not as common are the environments in which the company knows what the application architecture is first and then designs the datacenter and all constraints to accommodate. This would be a great company to build software for, wouldn't it? In either case, you'll need to ensure that both the logical datacenter and application diagrams have been created before using the Deployment Designer.

NOTE
In the past, the tools typically used by architects to design and document a datacenter didn't integrate well with the tools used by application architects and developers. Visual Studio 2005 Team System breaks this mold.

Security

The Distributed System Designers will support constraining and validating your design against many different security models, both Microsoft and industry recognized, including the following:

• Internet Information Server (IIS) Security

• ASP.NET Security

In addition, for each Host and service component relationship, Team System has enabled pre-built constraints, such as ensuring that an application component requiring Windows authentication will deploy only to an IIS server that supports Windows authentication. You can also author user-defined constraints as well as specify custom settings for the security requirements of your own organization. Your simple and custom constraints may be validated by the Distributed System Designers.

Interoperability

A popular architecture choice today is one of a service-oriented architecture (SOA). These types of architectures are built on loosely coupled, autonomous, service-based applications communicating via well-defined messages and often across trust boundaries. In the future Microsoft will be shipping a variety of technologies to make it easier for you to build and manage these types of systems and to extend the capabilities of the underlying platform. Until then, we can still implement solid SOA architectures by creating ASP.NET Web services.

Unified Modeling Language (UML)

Many people who read the views of Microsoft on model-driven development assume that the emphasis on Domain Specific Languages somehow equates to an anti-UML position. This assumption is not true. Before UML, there was an unproductive diversity of modeling approaches, and their convergence into UML 1.0 was a significant step forward in using models in software development. However, for whatever reasons, the existence of UML and UML-based tools has not significantly changed the way developers build applications. Nor has it significantly contributed to developer productivity. In fact, Microsoft ships one of the most-used UML tools, which is based on Microsoft Visio®. Anonymous surveys of customers and developers have shown that a very small population claims to use UML tools in support of their tasks; most usage clusters around use cases and class diagrams. On top of that, only a tiny fraction actually uses UML tools to generate code.

This fact was one of the driving forces behind the model-driven development tools in Visual Studio Team Edition for Software Architects. Microsoft really wanted to take tasks that developers and architects find difficult and provide ways for modeling tools to add value and assistance.

NOTE
In fact, developers at Microsoft are enthusiastic supporters of UML notation and diagrams. A walk around the developers' offices in any corridor reveals whiteboards covered with UML class diagrams and sequence diagrams. Developers use UML notation in specification documents and in many other diagrams prepared for presentations.

To support the need for developers to produce documentation and conceptual sketches, Microsoft will continue to ship the UML toolset with Visual Studio 2005. For instructions on how to generate code from your Visio UML diagrams and make use of it in your Visual Studio 2005 project, refer to Chapter 3.

UML diagrams are rarely a point-perfect compliable program source. That's a key difference for developers. Any artifact that contributes to actual software development must be capable of digital manipulation. Source code has a well-defined syntax and a comprehensible semantics, and can be manipulated consistently by compilers, debuggers, and refectory programs. To be useful to developers, a model must have the same status as source code. A model must also have a precise syntax, a comprehensible semantics, and well-defined mappings to source code or other well-defined models. It must be more than just documentation.

A diagram created with Team System's Application Designer is not just documentation, although it can serve that purpose. Instead, it allows a developer (or architect) to focus on one aspect of the system, such as the connectivity between services in a service-based architecture. The architect can design this aspect of the system before building projects, WSDL files, code, and schemas, or he or she can ask the tool to document connectivity between services if those artifacts already exist.

Custom Assemblies

The Application Designer is used for modeling the structure of the applications. This structure is made up of deployable units of functionality. The connections between these applications are made via communication protocols supported by the applications. If custom assemblies are part of the application, they are simply deployed with the application, as long as they are properly referenced in the project. You won't see them referenced on the diagram. Microsoft is considering adding a feature for a future release that will allow you to drill into the implementation of an application.

NOTE
Although it's not technically a Visual Studio 2005 Team System tool, the Class Designer can be used to design any class or service you want. You'll learn more about the Class Designer in the next chapter.

Other Languages

Visual Studio 2005, as you are aware, supports numerous languages—many more than Microsoft itself produces. With regard to Visual Studio 2005 Team System, Microsoft has targeted features toward what it believes is the audience most likely to use them in association with building Web services. In other words, the application diagram will support implementing Windows applications, Web applications, and Web services in Microsoft Visual Basic® and Microsoft Visual C#®. The Class Designer supports these languages as well. Other languages can be used in your Visual Studio solution as referenced Web services or existing code libraries (assemblies).

Existing Code Libraries

You can reuse any existing code or code libraries inside the Application Designer, as long as you wrap them up as a Web service. If this is too much effort, or if your application architecture doesn't call for Web services, you can leave the code libraries and not model them on the design surface. They won't be directly referenced, but they will be referenced by any project you build using Visual Studio. If you are wrapping existing libraries as Web services, you can simply drag and drop an ASP.NET WebService application prototype or an ExternalWebService prototype onto the design surface.

Web Services, J2EE, BizTalk Server, and SQL Server

Interaction with existing Web services can be modeled by adding External Web Services to the application diagram. You must specify the location of the WSDL file that describes each Web service. You will then be able to connect other applications to it. Connecting an application to an external Web service will result in a Web reference being generated in code. Keep in mind that this Web reference won't automatically update if the underlying Web service ever changes. You can update it from the diagram using the right-click menu on the application, however.

Within the Application Designer, you can also model existing J2EE services as external Web services. You'll need to have access to the J2EE service's WSDL document.

Microsoft BizTalk® applications are also callable as Web services. This takes advantage of the fact that BizTalk 2004 and 2006 can easily expose their orchestrations as ASP.NET Web services. These Web services provide the WSDL documentation automatically. You model a BizTalk application by using the BizTalkWebService application prototype.

While there is no native support for Microsoft SQL Server™ 2005 Web service access you can use the External Web Service prototype to describe access to these services. You would not use an External Database prototype in this case.