Microsoft provides a complete range of products that allow companies to develop and deploy n-tier applications. What's been lacking in the move from client-server applications to Internet applications to logical n-tier designs is some guidance on what functions should logically reside in each tier and how they can be stitched together to form a cohesive application that has reusable parts.
To help guide you through such a movement, I've identified the core component functions for each tier. While discussing these components, I'll offer some basic recommendations for planning applications based on a three-tier logical design.
The presentation tierMost developers think of the presentation tier as simply the Web or Windows forms that collect and validate information from the users of the application. But creating monolithic forms that also contain the process and state management functionality needed by the user interface (UI) requires that you duplicate these functions for each potential client device. To promote reusability and reduce code duplication, the presentation tier should be decomposed into two component types. The first component is the user interface, which consists of the forms required to process incoming information or display information retrieved from the business tier. But information about the state of a process (e.g., order entry or invoice processing) should be maintained in a separate user process (UP) component. The UP component can drive and manage the user process whether it's initiated from a Web client, Windows client, or device. The business tier
Components in the business tier receive requests from UP components. The requests are translated into actions controlled by the defined workflow according to the established rules, which are coded into the components. They are also responsible for interfacing with external systems to give the UP components the perception of a unified layer from which they can consume a standard set of services. The functions of the business tier can be decomposed into three key component types: business workflow (BW), business rules (BR), and service agents (SA). BW components manage the series of events required to complete a business transaction. These events may occur in a short period of time or could be long-running transactions. The commerce server pipeline (CSP) is an example of a BW component. The CSP takes the order basket managed by the UP component and then walks it through a series of steps including credit card validation, shipping management, and taxation. When completed, it returns an order ID to the UP component that can be displayed by a UI component. Long-running transactions can be managed either by Windows services configured to watch queues or database tables and respond to changes by driving workflow events, or by servers such as BizTalk that have a complex orchestration engine that performs similar functions. BW components manage the process, but they use BR components to enforce rules or perform specific tasks. If developed correctly, different BW components from different applications will consume the same BR components. Many times, the functions required by an application have already been implemented in other corporate or partner systems. Rather than duplicating effort, you may choose to consume these services from your business tier. To make all of your component interfaces consistent, you should develop a set of SAs that consume outside services and create this common façade. That way, whether the outside service is a Web service, a CICS session on a mainframe, or even an EJB component, the internal representation is a consistent .NET component interface. The data tier
Although the implementation of data access (DA) components is fairly simple, the debate over how to use them properly is still hotly contested. On one side, you have the DBAs who believe that all business rules should exist in stored procedures and triggers. On the other, you have developers who believe the sole function of the database should be to optimize data access. As a system architect, I side with the latter group. I've seen too many systems that became unmanageable and lost their performance edge over time because the server became too bogged down in business-rules processing. Most n-tier analysts now agree that the function of the DA component should be to simply provide create, read, update, and delete (CRUD) functionality to the BR components and participate in the transactions that they initiate. The other key element to consider in your n-tier design is how you pass data between the tiers. The business entity (BE) component encapsulates all of the data that passes between the tiers and may also include data validation (in the case of a dataset or object). Deciding on the type of BE used to move data will be one of the most significant decisions you make when initially designing your system. Given the new set of tools that Microsoft provides, it is easier than ever to actually create the components from which you will compose your application. But you still need to take the time to design each component and the methodology for passing BEs between them.
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
