Application Architecture for .NET: Designing Applications and Services
| Retired Content |
|---|
|
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. The latest version of this guidance is available here: http://www.microsoft.com/architectureguide. |
Appendices
December 2002
Summary: This appendix includes a product map that will help you determine the Microsoft products that will best help you build your solution. A glossary of terms relating to .NET application architecture is also included.
This chapter includes the following appendices:
- Appendix 2: Glossary
This appendix provides a glossary of technical terms relating to distributed application development.
- Appendix 3: Layered Architectures
This appendix explains the relationship between the layers described in this guide and other naming schemes commonly used in the computer industry.
Appendix 2: Glossary
Assembly
An assembly is a unit of deployment in an application based on the .NET framework.
Atomic Transaction
An atomic transaction is an operation in which either all steps in the operation succeed, or they all fail. Atomic transactions are commonly used to perform data modifications in a data store, where either all the data relating to the operation is successfully modified, or none of it is modified and the data remains as it was before the operation started.
Commutativity
Commutativity is a design pattern for an implementation in which messages will result in the same outcome, regardless of the order they are received in. For example, a commutative operation might involve two steps: "change product two's category to 'widget'" and "increase product two's price by 10%." It doesn't matter in what order these steps are performed; the net result is that product two is in the "widget" category and has had its price increased by 10%. Conversely, an operation in which the two steps are "change product two's category to 'widget'" and "increase the price of all widgets by 10%" is not commutative, because product two's price will be increased only if its category is changed before the price increase step is performed.
Component
In simple terms, a component is a part of an overall system. A more specific definition of component is a unit of functionality that can be amortized across multiple implementations. A component is usually implemented as a software object that exposes one or more interfaces and that implements logic.
Contract
A contract is a binding agreement between multiple parties that dictates the valid communication semantics. The contract determines the protocols used to communicate and the format of messages as well as the service level agreement and legal declarations.
Conversation
A conversation is the exchange of messages between a client application and a service that is required to complete a business task.
CRUD
CRUD is an abbreviation of Create, Read, Update, and Delete. It refers to the operations that can be performed in a data store. In SQL terms, Create, Read, Update, and Delete refer to INSERT, SELECT, UPDATE, and DELETE operations respectively.
Demilitarized Zone (DMZ)
A DMZ is the physical zone behind an Internet facing firewall and in front of a second level firewall that protects back-end systems and data. In a typical Internet application scenario, the DMZ is the physical virtual local area network (VLAN) on which the Web servers are deployed.
Dynamic Data Routing
Dynamic data routing is logic that is used to determine which database server to send a date retrieval or modification request to when the data is partitioned across multiple servers. DDR can be implemented using a hashing algorithm, a rule table, or some other partitioning scheme.
Emissary
An emissary is a generic term for a software component that communicates with an external resource on behalf of your application. The emissary abstracts the semantics of communicating with the external resource from your application, and it manages all aspects of the conversation, including the persistence of state for long-running processes.
Fiefdom
A fiefdom is a design pattern for a collection of services that encapsulate shared durable state and are deployed together. A fiefdom represents a boundary of trust, where the software components inside the fiefdom distrust those outside.
Firewall
A firewall is a software- or hardware-based security implementation that applies filtering rules to network traffic between two zones.
Idempotency
Idempotency means the ability to perform a particular action multiple times and still achieve the same result as you would when performing it once. An idempotent message such as an instruction to "change the price of product two to $10.00" will cause no side effect when received multiple times, whereas a non-idempotent message such as an instruction to "increase the price of product two by 10%" will produce a different result depending on how many times it is received.
Layer
A layer can be thought of as an architecture pattern in which components use services in layers below. Layering helps maintainability. The communication between two layers determines how well the application can be partitioned at that point for physical distribution across tiers. Strict layering schemes don't allow layers to access anything but the layers immediately below, while relaxed layering schemes allow a given layer to use any other layer below it.
Long-Running Transaction
A long-running transaction is an implementation of a business process or part of a business process that contains the logic to compensate for the activities that have already been executed in case of cancellation.
Message
A message is a unit of information transmitted electronically from one service to another.
Orchestration
Orchestration is the automation of a workflow. Microsoft BizTalk® Server provides an orchestration engine that can be used to orchestrate business workflows.
Policy
A policy is a set of rules with respect to security, operational management, and communication that is applicable in a specific zone.
Service
A service is a software component that can be used in part of an overall business process. Services support a message-based communication interface, through which a conversation takes place. A service encapsulates its own state and business data, and it can be communicated with only through the service interfaces it exposes.
Service Agent
A service agent is an emissary that is used to handle a conversation with an external service.
Service Interface
A service interface is an entry point for a service. It provides a public interface that callers can use to query the contract supported through the interface and make message-based method calls to the service.
Stateful
Stateful is the opposite of stateless. In a stateful conversation, information relating to aspects of previously exchanged data must be recorded to allow meaningful exchanges subsequently.
Stateless
Stateless refers to a conversation in which all messages between parties can be interpreted independently. No state is held between messages.
Two-Phase Commit
The two-phase commit protocol is used to ensure that multiple parties synchronize their state when a transactional operation is performed. The two-phase commit protocol can be used for atomic transactions as well as for business transactions.
Workflow
Workflow refers to a business process in which steps must be performed in a particular order, and predefined conditions must be met, before moving from one step to the next. For example, a workflow for purchasing goods might involve first validating the purchaser's credit card details, then ordering the goods from a supplier, and finally arranging delivery. The goods cannot be ordered until the credit card details are authorized, and delivery cannot be arranged until the goods have been received from the supplier.
Zone
A zone is a trust boundary, a communication boundary, and an operational boundary. The zone may map to a real-world entity, such as a company or department, or it may define a particular area within the physical deployment environment of the application, such as a Web farm or even just a process. Zones are useful mental models when determining application deployment and the relationship of application design to the infrastructure design.
Appendix 3: Layered Architectures
This guide has split an application into layers with distinct roles and functionalities with the goal of helping you maximize the maintainability of the code, optimize the way the application works when deployed in different ways, and provide a clear location where certain technology or design decisions must be made when building distributed applications based on the .NET Framework.
Splitting application functionality into layers has been done by the design pattern community. This table is intended to roughly illustrate how the component layers that are described in this guide map to the terminology for layers and design patterns used by some of these authors.
| This guide | Related patterns and layers |
|---|---|
| User Interface Components | Presentation Layer View Layer Client Layer |
| User Interface Processes | Application Controller Pattern Controller/Mediator Layer Application Model Layer |
| Service Interfaces | Remote Façade Pattern |
| Business Workflows | Domain Layer2 |
| Business Components | Domain Layer Transaction Script Pattern |
| Business Entities | Data Transfer Object1 Domain Model |
| Data Access Logic Components3 | Data Source Layer Infrastructure Layer Integration Layer |
| Service Agents3 | Data Source Layer Infrastructure Layer Integration Layer |
Notes on the table:
- Using the data transfer object design pattern for business entity components assumes you are using the business entities as the way you transfer data between layers, either by using ADO.NET DataSets or your custom serializable objects. Another use for business entities that goes beyond the data transfer object pattern is to build an object model or domain model for the whole application, encapsulating both business behavior and state.
- Business workflows can be thought of as a set of transaction script patterns that has the capability to track and persist state across incoming calls from asynchronous and synchronous callers. It is grouped under domain here because business workflows in the end implement business logic.
- Data access logic components and service agents may be used to encapsulate data mapping and aggregation/de-aggregation activities, in which case they can be referred to as a data mapping layer or data mapper, depending on the author.
Feedback and Support
Questions? Comments? Suggestions? To give feedback on this guide, please send an e-mail message to devfdbck@microsoft.com.
| Retired Content |
|---|
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. The latest version of this guidance is available here: http://www.microsoft.com/architectureguide. |
