FoodMovers: Building Distributed Applications using Microsoft Visual Studio .NET

Brian Travis

Architag International Corporation

November 2003

Applies to:
    Microsoft® Visual Studio® .NET Enterprise Architect Edition

Summary: Through this project of six sections, you will learn how Microsoft Visual Studio .NET Enterprise Architect Edition can be used to design, create, deploy, and maintain enterprise-strength distributed applications. (3 printed pages)

Section 1, Introducing the Architect
Section 2, Templates, Policies, Database, and Service Interface Design
Section 3, Developing Service-Oriented Architectures
Section 4, Legacy and Business Partner Integration: Using Service-Oriented Architecture for Integration
Section 5, Extensions: Building Blocks for Extra Functionality
Section 6, Going Live: Instrumentation, Testing, and Deployment

In this project, you'll be introduced to a fictitious enterprise, FoodMovers Distribution Company, which is a distributor of grocery products to small and medium-sized grocery stores. Like all companies, distributors have internal IT issues. But, in addition to that, FoodMovers is also required to work with very large companies (food manufacturers and other distributors), as well as very small companies (mom-and-pop corner grocery stores). Microsoft® Visual Studio® .NET has the tools to create interfaces to all of these parties, using several technologies, including Web services, secure transactions, reliable, scaleable database access, and more.

Section 1, Introducing the Architect

This first section discusses the architect-centered development process essential to modern distributed systems. It discusses briefly the evolution of system development, from a process-centric view, to an era of data-centrism, and finally, to the new service-centric view of information management.

The section describes the players, their enterprise architectures, and the types of interfaces they will need to do business together. The key to this interoperability is the concept of exposing services, rather than applications or data. These services provide an access point to existing legacy applications behind the firewall, as well as providing appropriate, secure access to external business partners.

This section also introduces you to FoodMovers, an organization that has problems with interconnecting its internal systems as well as interfacing with external business partners.

Section 2, Templates, Policies, Database, and Service Interface Design

The tools included in the Microsoft .NET Framework and Visual Studio .NET Enterprise Architect Edition provide rich support for data of any type. Data in the .NET Framework is handled with a single data layer, which is part of the common language runtime namespace. This data layer treats all data the same, whether the data comes in the form of Microsoft SQL Server™ data tables, XML documents, or external Web services. To the .NET Framework, data is data.

Enterprise Templates and Policy files can also be developed, which give programmers information for building their applications and assuring that all developers work with the same organizational development policies.

This section describes the process of creating database definitions and enterprise template files. It also discusses the FoodMovers data access strategy and shows how you can implement the data layers described in this first section. Finally, the section discusses the architecture of the deployed system, including firewalls, farms, and clustered servers.

Section 3, Developing Service-Oriented Architectures

Getting legacy applications to work together is one of the most time-consuming and expensive areas for the modern IT department. In the past 40 years, many different systems have been created that do not play nicely with each other. Getting these systems to talk is critical if an organization is to expose their internal business processes to internal departments as well as to their trusted external partners.

In this section, you will learn more about the concept of service-oriented architectures (SOA), which provide a scaleable, reliable, secure interface for external as well as internal systems.

The section then begins to develop each of the four internal service interfaces: the Inventory Manager, Warehouse Manager, Order Manager, and Update Manager. Each of these applications can be accessed by internal systems or through an external interface to your business partners.

Section 4, Legacy and Business Partner Integration: Using Service-Oriented Architecture for Integration

Old systems and new systems need to live together and, most importantly, to communicate important business data with each another. However, programs do not always support and understand each other's data formats, communications protocols, and languages. Also, some programs provide people with a view of the system. These user interfaces are designed to be consumed by people, not by other programs. Furthermore, programs that must communicate live in different organizations. How are you to integrate all of these systems?

This section discusses routes to accessing information services and the methods used to access them. Then it demonstrates how to develop the EDI and XML interfaces with the suppliers, Good Old Soup Company and Hearty Soup Company, and the order interface for the stores.

Section 5, Extensions: Building Blocks for Extra Functionality

By now, you will have created a system using the tools in Visual Studio .NET Enterprise Architect Edition. But you will have just a basic system. What about security? What about attachments? What about updates? What about administration? You could develop these yourself, but it would be nice if there was an alternative to custom development of these pretty standard pieces.

What you need is a concept of interchangeable parts for software development. This has been tried again and again with varying success. The C programming language came with a standard library (stdlib) of functions, such as printf and sscanf, that most C programmers gladly used rather than writing their own. Later, the Microsoft Foundation Class (MFC) for C++ development was made available to programmers working in an object-oriented Microsoft® Windows® environment. Who wants to write a dialog box function if there is one available that does mostly what is needed?

This section discusses the Web services version of interchangeable parts, which take the form of standard extensions that are becoming available in the Web services universe. These extensions are part of Microsoft's Web Services Enhancements for Microsoft .NET (WSE). WSE extensions are building blocks that can be integrated into a Web service quickly and easily. You will add attachments and security to your system to show how the building-block approach works.

Section 6, Going Live: Instrumentation, Testing, and Deployment

Once the architecture is designed and the code framework is created using Visual Studio, it is time to describe the plan for deployment and administration. In addition, there are several areas of implementation that need to be addressed before a robust, reliable, and secure architecture is deployed.

First, you need to develop a plan for "instrumentation." By placing "sensors" in your application, you can use instruments to provide a dashboard of your deployed system. Then you will need to exercise the system in two areas, text and staging, before finally deploying the system in a production environment.

This section details a plan for exception and event management, and introduce the concept of "exception mining," which provides a method for wading through the information stream coming from the application to find events that need attention.