TN_1100: Understanding Applications and the Application Diagram

Bill Gibson, Program Manager
Microsoft Corporation

The term ‘application’ is one of many overloaded terms in computing. This note discusses how the term is used within Visual Studio Team Edition for Software Architects. It explains what applications are, how they are created, what they are composed of, and how they relate to Visual Studio projects.

The Wikipedia has this to say about applications:

Application software (also called end-user programs) includes database programs, word processors and spreadsheets. Figuratively speaking, application software sits on top of systems software because it is unable to run without the operating system and system utilities.

While this description is useful, it still doesn’t define the scope of an application. In an enterprise context, an application is commonly considered to be a significant, largely self-contained collection of user-oriented programs, for example, there might be a customer relationship management application or a Payroll application. However, it is also common to use the term to refer to a single element within such an application, so there might be several user interface applications in the Payroll application. While application has both coarse-grained and fine-grained usage, the terms ‘system’ or ‘subsystem’ tend to be used to describe intermediate groupings—we might refer to the front-end and back-end systems of an application.

System Definition Model

The System Definition Model views the world as being composed of systems. Systems are independently deployable and configurable collections of resources. SDM supports both atomic and composite systems; atomic systems are composed of resources, while composite systems are composed of other systems. Systems can be hosted on other systems, creating ‘layers’ of systems–-the topmost layer is commonly referred to as the applications layer. This matches the Wikipedia description well. For a further discussion of SDM, see Understanding the System Definition Model, and of the layering of systems, see The Four Layers of Systems in the System Definition Model.

In SDM terms, the Payroll application is a composite system, composed of lower-level atomic systems that are composed of resources—the binaries and other resource files. In the Distributed System Designers, the term ‘application’ is used formally to refer to atomic systems in the applications layer. The term ‘application system’ or more simply ‘system’ is used for composite systems. Thus Application Designer is used to define applications, and System Designer to define systems.

Applications as Collections of Resources

Let us analyze what it means for an application to be a collection of resources. The first point is that the application is the collection, not any one of its resources. Consider an example: a Windows client application may include an assembly that provides the user interface, a class library that provides business logic, and another class library that contains data access logic that retrieves a database connection string from a configuration entry in the app.config file. In this example, the application is a composite of four resources – the user interface .exe file, the business logic .dll file, the data access .dll file, and the app.config file. All these resources must be deployed for the application to function. While the application is not simply the Windows project or its .exe, there is a special relationship between the application and the Windows .exe/project—it is the root resource of the application. This relationship is important as it allows us to reverse-engineer an application definition from suitable types of resources that are commonly recognized as roots of applications. In addition, since there is no manifestation of the application in the Visual Studio project system, the SDM file that describes the application is put into the project directory of the root resource so that it travels with it. Class libraries and other files may be used in many applications, but the root resource tends to be the root of only one application.

Shared Resources and Connections to Other Applications

While an application is a set of resources that can be independently configured and deployed, this does not to imply that applications can necessarily function independently of each other. In addition to the services required from its hosting environment, an application may depend on application-layer resources shared with other applications or require the services of other applications.

For example, a shared assembly implementing a set of commonly used financial routines might be deployed into the global assembly cache (GAC) and used by many applications. As another example, a Catalog application may require access to data in the Product database and the services of the Tax Web service.

Given that applications can be independently deployed to different machines, and it is typically unknown in advance where applications will be deployed to, connections between applications need to be explicit yet configurable. This is handled by introducing the notion of endpoints on applications. At one end of a connection, the provider endpoint represents an addressable connection point at which an application makes services available. At the other end, the consumer endpoint represents a configurable connection point that allows the application requiring the services to connect to the provider endpoint of the other.

Figure 1 Application endpoints and connections

In the example in Figure 1, a Windows application, Loan Advisor, needs to access the Loan Origination Web services of the ASP.NET Loan Origination Service which will be running on a server. The consumer endpoint created on the Loan Advisor application maps to the Web reference and the configuration entry associated with it.

Delegation to Resources

In the same way that a proxy endpoint on a system delegates communications to an endpoint on a member system or application, an application endpoint delegates communications to an endpoint on some member resource. Typically, a consumer endpoint is manifested by a combination of a configuration file entry and a programming construct, such as a Web service proxy class. A provider endpoint is similarly manifested by some addressable artifact such as an .asmx file, together with some programming construct representing the implementation of the services, such as a Web service class.

Configuring the connection between application endpoints is then handled in one of two ways:

• By connecting the endpoints in the context of a composite system, which defines how the applications will be configured when the system is deployed.

• If the applications are deployed independently of each other, by the intervention of an operator or from some deployment script during deployment.

For a more detailed discussion about delegation and systems see, The Role of the System Designer.

Application Diagram

With this understanding of applications, we can better grasp the significance of the application diagram. This diagram is a view of the applications defined in the solution combined with a view of their current configuration. The application definitions we see are created by reverse-engineering from resource definitions—typically projects—in the solution, or they are added directly to the diagram from the Toolbox.

Applications for which synchronization with code is supported are added from the Toolbox in an unimplemented state. In this state, the definition of the application is stored inside the application diagram .ad file. When these are implemented the definition is transferred to an .sdm file inside the root project. If an application is added by reverse engineering projects that are added to the solution then the definition is created in an .sdm file in the project at that time.

On the application diagram, connectons from implemented applications reflect the actual configuration of the consumer endpoints in the projects concerned.

The implementation state of applications is indicated by the drop shadow on the application shape. Implemented applications have the drop shadow indicating they have more ‘substance’. As a rule, if an application is implemented all its endpoints are implemented also. If an endpoint on an implemented application is not implemented it is highlighted by a warning icon. This commonly occurs to consumer endpoints if the connected provider application has not yet been implemented. In this case, when you implement the provider application the Application Designer will automatically implement any such connected consumer endpoints or you can implement the endpoint manually by selecting it and choosing Implement from its context menu.

Figure 2 An application diagram with internal and external applications, implemented and unimplemented applications and unimplemented consumer endpoints

‘External’ applications can also be added to the application diagram. These represent applications that do not exist in the solution and that are already deployed or will be deployed separately. Adding an external application to the application diagram makes it easy to create consumer endpoints and the corresponding resources (such as Web references and proxy classes) on other applications.

Other kinds of applications can be added, which, while part of the model, do not impact implementation. These include generic applications used to represent any untyped applications or systems, as well as any custom applications created with the SDM SDK. External applications, generic applications and any custom applications are represented in .sdm files stored as solution items. It is possible to design utilities that work out-of-band with the design surface that synchronize the definitions of these applications with code or other artifacts. However, this will be unknown to the designers.

Re-configuring and Testing Applications

As the connections on implemented applications in the application diagram represent the current configuration of the application in the development environment, it is easy to use the Application Designer to reconfigure and test different connection configurations once you have implemented the applications. Deleting a connection on the application diagram typically nullifies the configuration entry in the resource backing the consumer endpoint. Reconnecting the consumer endpoint to another compatible provider endpoint sets the consumer configuration entry to the new provider endpoint’s address. Thus you can disconnect and reconnect applications and see the effect the next time you press F5 to debug the solution. These actions only affect the current deployment configuration, so they have no impact on connections in any system diagrams that include those applications. Connections in a system diagram describe the intended configuration in that system context only.

Summary

Applications are a packaging abstraction, representing collections of resources that must be deployed and configured together. Applications can offer services via addressable provider endpoints and consume the services of other applications via configurable consumer endpoints. The application diagram represents applications in the solution and their current configuration in the development environment. Systems describe how applications should be configured for deployment into other environments.