Various layers of multi-tier application

User interface (UI) components: Most solutions need to provide a way for users to interact with the application. User interfaces are implemented using Windows Forms, Microsoft ASP.NET pages, controls.

User process components. In many cases, a user interaction with the system follows a predictable process. For example, in a retail application one could implement a procedure for viewing product data that has the user select a category from a list of available product categories and then select an individual product in the chosen category to view its details. To help synchronize and orchestrate user interactions, it can be useful to drive the process using separate user process components. This way the process flow and state management logic is not hard-coded in the user interface elements themselves, and the same basic user interaction "engine" can be reused by multiple user interfaces.

Business workflows. After the required data is collected by a user process, the data can be used to perform a business process. For example, in a retail system would need to calculate the total value of the order, validate the credit card details, process the credit card payment, and arrange delivery of the goods. This process could take an indeterminate amount of time to complete, so the required tasks and the data required to perform them would have to be managed. Business workflows define and coordinate long-running, multi-step business processes.

Business components. Regardless of whether a business process consists of a single step or an orchestrated workflow, an application will probably require components that implement business rules and perform business tasks. For example, in a retail application, you would need to implement the functionality that calculates the total price of the goods ordered and adds the appropriate delivery charge. Business components implement the business logic of the application.

Service agents. When a business component needs to use functionality provided in an external service, one may need to provide some code to manage the semantics of communicating with that particular service. For example, the business components of the retail application described earlier could use a service agent to manage communication with the credit card authorization service, and use a second service agent to handle conversations with the courier service. Service agents isolate the idiosyncrasies of calling diverse services from your application, and can provide additional services, such as basic mapping between the format of the data exposed by the service and the format your application requires.

Service interfaces. To expose business logic as a service, one must create service interfaces that support the communication contracts (message-based communication, formats, protocols, security, exceptions, and so on) its different consumers require. For example, the credit card authorization service must expose a service interface that describes the functionality offered by the service and the required communication semantics for calling it. Service interfaces are sometimes referred to as business facades.

Data access logic components. Most applications and services will need to access a data store at some point during a business process. For example, the retail application needs to retrieve product data from a database to display product details to the user, and it needs to insert order details into the database when a user places an order. It makes sense to abstract the logic necessary to access data in a separate layer of data access logic components. Doing so centralizes data access functionality and makes it easier to configure and maintain.

Business entity components: Most applications require data to be passed between components. For example, in the retail application a list of products must be passed from the data access logic components to the user interface components so that the product list can be displayed to the users. The data is used to represent real-world business entities, such as products or orders. The business entities that are used internally in the application are usually data structures, such as DataSets, DataReaders, or Extensible Markup Language (XML) streams, but they can also be implemented using custom object-oriented classes that represent the real-world entities your application has to work with, such as a product or an order.

Components for security, operational management, and communication: Your application will probably also use components to perform exception management, to authorize users to perform certain tasks, and to communicate with other services and applications.