Security, Operational Management, and Communications Policies

Summary

• Introduction
• Designing Security Policies
  • General security guidelines
  • Authentication
  • Authorization
  • Secure Communication
  • Profile Management
  • Auditing
• Designing Operational Management Policies
  • Exception Management
  • Monitoring
  • Business Monitoring
  • Configuration
  • Metadata
• Designing Communication Policies
  • Choosing the Correct Communication Model
  • Synchronicity
  • Recommendations
• References

Introduction

Organizational policies are basically rules that determine how an application is secured, managed, and how different components communicate with each other, These policies and their effect on distributed application design are shown below:

For example, the security policy which determines how users are authenticated (among many others) can greatly influence the design of various parts of the system. Should users be authorized using Windows logon or using a custom authorization scheme? What about service agents that receive messages from external services - how secure are these incoming messages? Similar questions apply to communication and operational management - for example, how are going to monitor the health of remote servers? The answers to these questions greatly affects design decisions.

Security, operational, and management policies and their effect on the architecture of distributed applications are described below:

Designing Security Policies

The security policy is concerned with authentication, authorization, secure communication, auditing, and profile management as shown below:

The following sections are covered:

• General security guidelines
• Authentication
• Authorization
• Secure Communication
• Auditing
• Profile Management

General security guidelines

Consider the following general security guidelines when designing a security policy:

• Rely on tested and proven security systems. Designing and implementing a custom security system can be difficult and time-consuming.
• Never trust external input (i.e., from external services). Validate all input from users and external services.
• Assume that external systems are insecure.
• Apply the principle of least privilege. Do not enable more privileges than those minimally needed by the application.
• Reduce security risks by reducing application surface area. In other words, only expose functionality that will be used by others. Do not expose everything.
• Do not rely on security by obscurity. For example, changing a text file's extension from .txt to .obj will not make it secure.
• Follow the principle of programming for securability.
• Check at the gates. Do not let processes proceed further than the authorization routine if authorization fails.
• Lock your system internally and externally. Cowboy developers can pose as serious risks (unintentional of course) as malicious hackers.

Authentication

It should be a design goal that components see authorization as a transparent process. For example, it is considered a bad design if user information needs to be passed along components just for authorization. It should also be a design goal that the relevance of the user identity is reduced the further the activity is from the user interface. For example, in service-based solutions, some activities may not even be initiated by users. 

Consider the following user scenarios:

• User and application do not share common authentication mechanism. Here, you cannot flow an existing security context. You need to re-authenticate the user by passing the application the appropriate credentials.
• User and application are in trusted Windows domains. Here you need to chose a communication mechanism that flows Kerberos or NTLM tokens. DCOM provides this functionality.
• Caller and application share a non-Windows authentication mechanism. Here you need to flow tokens provided by the authentication mechanism. For example, you could pass these tokens in out-of-band data like SOAP headers.
• Caller and application run in the same context. This is the case for .NET calls where the .NET Framework keeps the existing CurrentPrincipal object on the thread.

Authentication in the Presentation Layer

Note these two important points regarding authentication in the presentation layer:

• UI needs to authenticate users if the application needs to perform authorization, auditing, or personalization. 
• UI process components should run in the same context as the UI itself so that all authentication tasks are delegate to UI processes.

Windows-based UI usually authenticate users with their Windows log-on identity. Whereas Web-based applications have a wide-range of authentication mechanism (integrated Windows authentication, passport authentication, forms-authentication, and so on.)

Authentication in Business Components

For business components, the caller may be of many types and with different identities. For example:

Given the different types of callers and the different possible identities, business components must consider how to authenticate the caller and how this authentication can affect authorization.

Authentication in Data Access Components

Data access components are typically not exposed for calling from external scripts or other applications so you can design them to rely on the security context of the caller (Principal object of the thread). In general, data access components authenticate with the database in two main ways:

• Using service accounts. For SQL Server databases, this account is often sa (and with no password!)
• Using caller impersonation. For example, if 'Joe' logs in to your application and access the database through data access components, these components will be impersonating 'Joe' when they log in to the database using Joe's credentials.

In general, it is best to use a limited set of service accounts that represent roles of user types. For example, in an e-commerce application, you could use could selectively log-on as OrderProcessingAccount, RefundAccount, or ReturnsAccount and assign each such account the appropriate database permissions. 

Authentication in Business Entity Components

If your business entity components will not be used by other applications (as part of an object model), then you do not need to present an authentication boundary. In this case, they should rely on the current security context (provided by System.Security.Principal.WindowsPrincipal object) for authentication.

If your business entity components will be used by other applications (as part of an object model), then you do need to present an authentication boundary, perhaps in the form of an extra component that helps the client to 'log-on' from code and if you are not relying on platform authentication, sets the security context required by these objects 

Authorization

In simple terms, authorization determines who can do what. To properly design an authorization policy, you need to take into account two issues:

• User permissions and rights.
  User permissions and rights determine what a user account is permitted to do in the context of an application. Technically, permissions refer to allowable actions on resources (i.e, delete a file) whereas rights refer to system tasks the user is allowed to perform (i.e., shutting down the server). User permissions and rights can be assigned on an individual user-by-user basis or can be logically grouped into groups and roles.
  
• Code access security.
  Code access security is concerned with what an assembly can do. For example, a .NET assembly can be configured in such a way that any attempt to delete files will raise a security exception.

In some cases, you may need to implement custom authorization checks. For example, you may only users that are managers can be authorized to change system settings. These types of authorization checks are better performed by the application as programmatic checks. You may even implement these checks using declaratively using attributes or configuration settings.

Designing Custom Application-Level Authorization Schemes

Having a custom authorization scheme is a common requirement. Consider the following guidelines when designing a custom application-level authorization scheme:

• Expose all authorization logic through a principal object that implement System.Security.Principal.IPrincipal interface. These objects will be created with a particular identity supplied as a constructor argument. The identity (for example WindowsIdentity) associated with the Principal object should then be used to locate the correct authorization data from some data store - typically a database. Implementing the IPrincipal interface has many advantages, for example, IPrincipal.IsInRole method lets your application use PrincipalPersmission attributes and provides a consistent development model that allows you to use other authenticate and authorization schemes in the future. See Principal and Identity Objects in .NET Security section under Role-Based Security. Also see WindowsIdentity and WindowsPrincipal in MSDN.
• Authenticate communication with the authorization database. The application should access the authorization database with a read-only account. Only access the authorization database with read/write accounts through parts of your application that are required to modify the authorization databases (for example, adding data for new users.) 
• Authorization data should refer to users through some private ID. This means that user credentials and authentication identifiers should be decoupled from the authorization data schema. This lets you change authentication schemes in the future and lets users change their user IDs.
• Cache for performance. For example, you may decide to cache authorization data (i.e., role membership) instead of accessing the store every time.
• Provide offline capabilities for disconnected clients.
• Ensure that only your application assemblies can create and invoke your principal objects through the use of StrongNameIdentityPermission attribute.

Users and Roles in Applications

An application interacting with services may have separate user accounts and role definitions - unless they were developed in an enterprise where users and groups were defined organization-wide. When dealing with interacting services, it is recommended that users are authenticated and authorized at a service-wide granularity. For example, if your application interacts with 5 different services, then service-wide granularity means defining roles such as StandardPartner, PremierPartner, and so on. Using service-wide granularity allows your application to grow and work with many partners in the future without affecting code or design.

Security Contexts at System Boundary

A custom principal on a given thread does not flow across processes or through remoting channels. At system boundaries, you usually have to set the security system yourself and this involves the following:

• Create the appropriate identity object passing its constructor the required information (user ID, etc.)
• Create the principal object passing in the identity instance as a constructor argument.

See Principal and Identity Objects in .NET Security section under Role-Based Security

Authorization in UI Components

Authorization in UI components is required if you need to:

• Enable or disable controls for user input.
• Hide or show data.

If the user is not supposed to see certain piece of information, then the most secure option is to avoid passing this information to the UI components in the first place. Also note that you should set code access permissions on the UI assemblies if you do not want those assemblies (or the local components they) to access certain resources such as files.

Authorization in User Process Components

Because user process components manage data and control flow between user processes, perform authorization at this level if you need to:

• Whether a user can start a specific user process. For example, only a manager can cancel an order.
• Add/remove steps to user in a user process depending on who is executing it. For example, salespersons should see their region's data only whereas managers can be presented with a 'choose region' dialog box from which data for any region can be requested.

Obviously the above restrictions need to be applied to UI elements. If the dialog box is the 'root' dialog box, then the appropriate menu entries need to be disabled or hidden. If the dialog box is the 'parent' from which other dialog boxes will be launches, then the dialog box must hide or disable UI elements for actions that users are not allowed to do.

Note that you can set authorization declaratively for user processes by adding PrincipalPermission attributes to the classes and methods that implement them. User process components are typically consumed from UI components so you can use code access security to restrict who is calling user process components.

Authorization in Business Components

Note the following guidelines:

• If many communication mechanisms will be used ( .NET Remoting, Web Services, etc. ), try to make the business-process authorization independent of user context. This is because certain communication mechanisms may not let you impersonate the user.
• Use role-based security as much as possible rather than relying on accounts.

Authorization in Service Agents / Service Interfaces

Because service agents are the gateways through which calls to external services are made, you should add authorization to these components whenever you want specific users or roles from accessing them. Note that external services may also implement their own authorization schemes.

Authorization in Data Access Components

Data access components are the last components that expose business functionality before the application data, so they should perform any needed fine-grained authorization before accessing data. Perform authorization at this level if you need to:

• Protect access to critical functions exposed by the data store.
• Share these components with other business components that you may not fully trust.

As usual, to perform authorization you can use .NET PrincipalPermission attribute if you are using Windows authentication or on .NET roles and attributes if you are not relying on Windows security context.

Authorization in Business Entity Components

You can enforce authorization in business entity components for proactive checks, but the final check should be performed business process components and data access components. You might also want to restrict access to business entity components from a code-access point. Doing so ensures that your business entities are only invoked by trusted code.

Secure Communication

In addition to authenticating and authorizing users, you must also ensure that inter-tier communication is secure - this ensures that the application is secure against attacks in which data is sniffed or tampered with while it is being transmitted. You have the following options for secure communications:

• Securing the Whole Channel
  
  • SSL (Secure Sockets Layer):  This is the recommended option for HTTP channels. It is a widely accepted standard and is usually accepted to open SSL ports on the firewall. SSL is recommended when exposing a service interface to the Web.
  • IPSec: Use this mechanism when both endpoints are well-known and are under your control. IPSec is mostly used when making calls between services or physical application tiers within the same organization.
  • VPN (Virtual Private Network): Implementing VPN requires extensive infrastructure support. It is most useful for providing employees/partners an internal network from the Internet.
  • Custom secure channel: Not recommended at all.
    
• Securing Data
  
  • Signing Data: Any tampering with data can be easily detected.
  • Encrypting messages: The whole messages becomes unreadable if the network packet becomes compromised.
  • Encrypting selective parts of the message: Use this when only a small part of the message is sensitive to being exposed.

Digital signatures usually involve calculating a value (called hash) of the signed part of the message, encrypting the hash using the private key of the signer, and then including this encrypted hash in the message header. The receiver decrypts the signature using the public key of the signer and it compares the resulting hash with the one it calculates from the signed part of the message. If the hashes match, it means that the message has not been tampered with. If the do not match, the message has been corrupted or tampered with. For example, with XML Web Services, you can implement XML digital signatures in SOAP headers using the SignedXml class.

Securing a communication channel will affect performance. Therefore, only scope channel security to those areas where it is needed - such as securing specific URIs, specific ASP.NET pages, or sensitive business data.

Secure Communication in UI Components

UI components communicate only with the user. With Web Services, use SSL whenever sensitive data (credit card numbers, online banking, logon forms, etc.) are transmitted. Because user process components typically reside with UI components, there is no need to secure the channel between them.

Secure Communication in Service Agents and Service Interfaces

It is always a requirement for service agents to establish the appropriate channel security between itself and the invoked service. For example, if a service agent requires an SSL channel with an external service, then it is the service agent that should implement this functionality. This approach makes it easy to encapsulate secure communication mechanisms without affecting business components and workflows.

Secure Communication in Data Access Components

Data access components typically rely on data helper components to establish connections with the data store. Therefore, it is the responsibility of data helper components to establish secure communication with the data store. In particular, data helper components can encapsulate the following:

• Logic to choose the appropriate security provider for the data store.
• Implementation of SOAP encryption mechanisms.
• Code to establish a connection over SSL.

Profile Management

User profile is user information that the application can use to customize its look/behavior when used by that user. A user profile may include UI preferences (background color, font, etc.) and data about the user (region, address etc.) Profile information can be exposed as a collection by the Principal object. If profile information contains sensitive data, you may consider encrypting it.

Auditing

A general definition of auditing is the ability to track user and business activity in an application for security purposes. In fact, auditing can be thought of as secure logging. When implementing auditing solutions ensure that audit entries are tamper-proof or at least tamper-evident (achieved with digital signatures).  The auditing mechanism may have to use document signing, platform authentication, and code-access security to ensure that spurious entries can be logged by malicious code.

If the audited action needs to be associated with a specific user, the auditing interface may be exposed as a utility function or as a method of the application's Principal object.

Auditing in UI

Activities in UI are not usually audited (unless in financial trading applications). UI may want to audit certain global events like logging-in, logging-off, password changes, and all security exceptions. Because user process components represent user activities, it is not common to audit them.

Auditing in Business Components

Business components are prime candidates for auditing. You always want to know who performed key business activities and when were they performed. If you are auditing within the context of a transaction, the auditing component should also start a parallel transaction so that failures in the original transaction do not roll back the audit entry. 

Auditing in Data Access Components

Data access components are prime candidates for fine-grained auditing. Because data access components usually invoke stored procedures, you may also want to audit inside the data base. See Auditing SQL Server Activity article in MSDN.

Designing Operational Management Policies

Operational management policy is concerned with the ongoing data-to-day running of the application. Operational management policy covers issues such as exception management, monitoring, configuration, and service location as shown below:

The following sections are covered:

• Exception Management
• Monitoring
• Business Monitoring
• Configuration
• Metadata

Exception Management

Exception management can be defined as: the process of throwing and catching exceptions, designing exception classes, flowing exception information across application components and layers, and publishing exception information.

In general, all applications must implement some kind of exception handling to catch runtime errors. Exceptions should be caught and resolved if possible. If an exception cannot be resolved, the application should display a meaningful message to the user and provide a way to log/publish the exception information for debugging purposes.

Exception Management has been discussed fully in the following sections:

• Error Handling
• Exception in Components
• Error Handling in ASP.NET

The following sections discuss the various aspects of exception management:

• Catching and Throwing Exceptions
• Designing Exception Classes
• Flowing Exception Information
• Logging Exception Information

Catching and Throwing Exceptions

The general advice on catching exceptions during a function call is to catch exceptions if your code can use the exception type and data to determine what to do next. It is advisable to catch exceptions at layer boundaries in order to wrap them with exception types that are relevant to the callers. You can throw a new exception and optionally preserve the original exception as an InnerException member of the new exception object you are throwing.

Designing Exception Classes

Exceptions classes should derive from ApplicationException class. Your application may need its own exception object model (i.e.,  exception hierarchy), where each business components might have a number of relevant exception classes specific to that business component. Within this exception hierarchy, you may then decide to enrich the exception by adding appropriate more data such as user name, IP address, .NET Framework version, and so on.

It is common now to derive two main branches of exceptions - business exceptions and technical exceptions. This design makes it easier to catch and publish the appropriate types of exceptions in different parts of the application.

Flowing Exception Information

Exceptions should always flow upstream, and therefore, need to be serializable to flow upstream across tiers. This is especially important as exceptions reach a UI or service agent boundary and you do not want to present the exception information as it happened. For example, what if the exception was due to an incorrect user name in a database connection string? You want to flow exception information across tiers (hence serializable) and at the same time modify the exception so that the user can understand it without exposing sensitive business or technical information.

Logging Exception Information

If an exception occurs, the appropriate staff must be notified. Technical exceptions should be go to technical support staff whereas business exceptions should go to managers and helpdesk staff. Each type of audience will want to know more about the environment in which the exception had occurred.

You should also publish relevant information for each audience through channels that communicate with the tools used by them. For example, technical exceptions going to technical support staff may published via WMI events, whereas business exceptions going to managers may be sent by email or a page/text message. In all cases, exceptions should be logged to a central repository like the event log or even a database.

Exception Management in UI

UI process components will need to handle exceptions flowing from business processes and data access components, and decide whether to:

• Retry the operation.
• Expose the issue to the user.
• Stop and restart, or continue with the UI flow of the application.

UI components on the other hand should publish their UI exceptions to help isolate problems, especially in rich client applications.

Exception Management in Business Process Components

Handling exceptions in business components often requires catching exceptions and errors returned by business objects and encapsulating them into an exception that can be understood by the user. Business components need to handle exceptions coming from data access components. These include:

• Technical exceptions - for example, an invalid database connection string.
• Business exceptions - for example, a foreign-key constraint has been violated.

Obviously, business components should not hide these exceptions, but should propagate them to the caller. This could otherwise mislead business processes in terms of transactional state and make the user believe that certain operations were successful.

Business components should rains new exceptions when:

• A caller is trying to perform an operation with insufficient or incorrect data - for example, authorizing credit card payment when no expiry date had been provided.
• A constraint violation occurs when performing an operation - for example, unable to commit data to the database.

As for business entities, these may be called from the UI or from other business components. It is therefore, that you raise/propagate exceptions that can be consumed by both. 

Exception Management in Data Access Components

Data access components often handle two main types of exceptions:

• Technical exceptions due to technical errors  - for example,  connecting to the database or invoking the data store.
• Business exceptions due to business errors - for example, a stored procedure failed to commit an order due because the product ID was invalid.

If the running activities are transactional, then obviously all exceptions should abort the current transaction. Also note that handling exceptions in data access components often requires catching exceptions and errors returned by the underlying data store and mapping then to the exception schema used in the rest of the application. Data access components should propagate exceptions wrapping them in exception types that make sense to their clients. Wrapping exceptions in two main types (business and technical) improves exception handling structure and exception publishing logic for the potentially diverse callers.

The functionality to map data source exceptions (i.e., SqlException) to your .NET-based application exception schema should be implemented in the data access component. Performing mapping involves one or more of the following:

• Mapping service-specific error code or HRESULT into an exception of the appropriate type in .NET
• Extracting verbose error information through the data source API and adding information to the appropriate fields of the exception being created. 

Monitoring

Monitoring is about instrumenting the application to give operations and support staff the ability to check application health, compliance with service-level agreements, and scaling/capacity management. See Monitoring in .NET Distributed Application Design in MSDN. 

There are the following types of monitoring:

• Health Monitoring
  Are the components running correctly with no hangs, crashes, processes exits, leaked memory, etc?
  
• SLA Compliance
  Are business processes running within the expected parameters? Is your application/service meeting your caller's performance requirements?
  
• Scale Monitoring
  Is performance predictable from available resources? Are computers sharing workload as expected?
  
• Business Monitoring
  Are the business processed efficient? How long do they take to process workload?

These different questions can be answered by monitoring the right parts of the application. Also note that not all types of monitoring need to be active at all times. The following discuss different aspects of monitoring in a .NET distributed application:

Monitoring in User Process Components

Monitoring user process components can provide useful statistics to improve application UI design and efficiency. The following are some examples of what statistics can be provided by monitoring user process components:

• Average total duration for a given user process.
• What user processes are started and never finished. This information can be used to design UI that let the user decide whether to start the process at all and may be even provide functionality to cancel these processes.

Monitoring in Business Process Components

Health monitoring of business components and workflows is critical because it is where transaction outcome is known, and where data store problems are channeled. Most business-level monitoring is done in business layers

Monitoring in Data Access Components

Because data access components participate in transactions and talk to the database, they are important candidates for monitoring. Monitoring data access components allows you to track long-running queries, object lifetime duration, activity throughput, latency, memory, and other useful indicators. For example, whenever you connect to a database, monitor connection usage, connection pooling statistics, and connection security statistics. It can also be quite helpful to monitor transactional aborts because these can be very expensive to the application as a whole.

Configuration

Configurable applications should use configuration data stored in .NET configuration files at the user, machine, and application levels. Custom configuration data can be defined with any schema and accesses using the .NET ConfigurationSettings class. 

It is very important to consider configuration security - for example, most developers store database connection strings in clear text in .NET configuration files. You should restrict access to the proper operators and you may also consider digitally signing information to make sure that information has not been tampered with.

Configuration data can be stored in many places:

• Application XML configuration files
  This model is easy to implement and allows clients to work offline. In client-server environments, the recommended approach is to push configuration data from some central repository. Note that reloading an application configuration data requires an AppDomain restart (ASP.NET will automatically restart its AppDomain when it detects changes.) Application configuration is stored in XML and this may be an unacceptable security issue/
  
• Database
  This is a common storage location for application configuration data, and even more so for application metadata. Consider caching as hitting the database often results in performance issues.
  
• Active Directory
  Storing application metadata in Active Directory makes the data available for clients on the domain. Active Directory may be secured with Windows ACL.
  
• Constructor settings
  This option is only valid for Enterprise Srevices-based components (COM+).
  
• Others. These include Windows Registry, Windows Local Security Authority (WSLA), and custom implementations.

Accessing application configuration and metadata often results in performance hits, especially if the data is stored remotely. To prevent this, you can cache data in memory. When caching data in memory, issues relating to cache refresh to cash expiry need to be considered carefully. 

The requirements of various layers are as follows:

• Presentation layers often require configuration data for location information (location of business and data access components) and for connection information (database connection strings and file paths).
• Service agents require configuration data for connection information (location of external Web Services).
• Data access components require configuration data for connection information (database connection string) and other database related activities (replication, routing, mapping of logical to physical names, etc.)

Metadata

The idea behind metadata is to provide the application with information about itself and its data to make the application more flexible as run-time conditions change. Designing the application to use metadata in certain places enables the application to adopt to changes without costly development/deployment changes. There are two main times when metadata can be used in an application:

• Design time
  For example, you may use database metadata to generate code, stored procedures, .NET classes and maybe even interface components for common patterns. The resulting components behave more predictably and are less prone to errors, but require specialized knowledge and initial development time for creating templates
  
• Run time
  For example, you make decide to take column names (headers) for grids from table metadata so that they are not hard-coded in the application. The application may also use database metadata to determine (at run-time, of course) relationships between various tables. However, using metadata at run-time can be expensive especially during the initial 'discovery' phase where metadata is being retrieved and examined. Metadata can then be cached as long as caching issues like expiry and refresh are considered.

The following sections illustrate potential uses of metadata:

• Metadata in UI Components
  Here metadata can be used to specify column headers, error messages, menu hierarchies, and other information that do not affect the business of the application.
• Metadata in UI Process Components
  Here metadata can be used in different ways - for example, what user process exist and what menu items trigger them.
• Metadata in Business Components
  Metadata can be used in business components to model simple rules or patterns. For example, metadata can be used in a pipeline engine to determine what classes and methods to call in a sequence.
• Metadata in Data Access Components
  Data access components can expose the schema of the returned data and its metadata in the form of XSD.
• Metadata in Business Entity Components
  It is recommended to expose business entity metadata to consumers where it is helpful to have information about the available business entities to assist in tasks such as:
  • Filling column headers in tables.
  • Displaying descriptions of attributes for tool tips.
  • Validating business entity data values so UI can actively enforce them.

Designing Communication Policies

Communications policy define how components in your application will communicate with each other. As shown below, communications policy deal with issues such as synchronicity, format, and protocol:

The following topics are covered:

• Choosing the Correct Communication Model
• Synchronicity
• Recommendations

Choosing the Correct Communication Model

Start by thinking carefully whether or not components need to communicate using messages or using a more tightly coupled and connected approach such as DCOM or .NET Remoting. While connected communication is easier to design and implement, it has limitations in terms of scalability, availability, and manageability.

Inter- and Intra-Application Communication

Inter-application and intra-application have the same scope as Inter-net and Intra-net; Inter refers to external communication while Intra refers to internal communication. Inter-application communication should be implemented using message-based communication such as SOAP-based Web Services or MSMQ. Intra-application communication may require a communication mechanism that provide high performance and specific capabilities such as transaction or security flow. In general, it is recommended that message-based communication be used whenever possible including communication between the different layers of a .NET distributed application.

Different requirements and constraints for inter-application and intra-applications communication will drive most technology decisions. In some cases, there might be no constraints on having tightly-coupled components that all communicate via .NET Remoting. In other cases, it may be useful to view the different tiers of an applications as services with the same loose-coupling found among unrelated services. The following figure illustrates these concepts

This diagram shows that the application's server-side components (1) are designed as a service that is accessed via a message bus (2). The presentation tier (3) uses same communication as other services (4). These services (4) potentially call other external services (6). Service agents (5) invoke other services (6) via the message bus. On the other hand, communication with data components (7) is implemented using other communication mechanisms. Viewing tiers as services may pose several design challenges:

• The business layer may relay on having context such as security information provided by the user interface.
• The message bus (communication mechanism) has to support all requirements of intra-application communication such as transaction overflow, efficient transfer of large loads, high throughput, and transfer of rich exception information.

If service integration is a small part of the application architecture, you may want to use Web Services for integration purposes only and use .NET Remoting for intra-application communication.  In the figure below, presentation, business and data tiers communicate with each other using .NET Remoting. The use of standards-based and message-based communication is left for integration purposes between service interfaces, service agents, and external services:

Message-Based communication

Message-based communication provides the best choice of communication for integration, especially when messages are asynchronous. Using asynchronous message-based communication offers the following advantages:

• Scalability and Availability
  Message-based communication provides better scalability and availability because you can better utilize hardware resources and isolate your application from software or infrastructure failures.
  
• Location Transparency
  Message-based communication provides true transparency of remote functionality because it does not assume that a connection is present. Asynchronous messages can always be sent.
  
• Similarity to business models
  Real-world business processes are mostly modeled asynchronously in terms of exchanges between parties and users.
  
• Transport Transparency
  A correctly designed message-based communication should be able to easily take advantage of new messaging technologies as they appear.

On the other hand, using asynchronous message-based communication offers the following disadvantages:

• Deterministic outcome
  In synchronous (or connected scenarios), you know whether a request succeeded or failed at the end of it. In message-based communication you need to consider extra states in which no message has been received. This means managing conversation state in addition to the normal business logic - for example, you may have to store messages in a queue pending receipt of responses. 
  
• Message correlation
  Because there is no automatic pairing of messages sent and received, you will need to implement a correlation mechanism between messages and business processing (i.e., response or action for the message).
  
• Message Delay
  Messages may arrive later than expected. You have to implement the business logic such that it can deal with messages that never arrive. You should also design the message receipt logic to make sure that the message is still valid when received.
  
• Transaction Flow
  Message-based communication implies a different transactional model. You will need to manage conversations involving multiple exchanges in a long-running transaction, and expose the appropriate compensation activities.
  
• Repeated Messages
  You will need to handle cases where a message arrives more than once. One way of solving this problem is to require some sort of transaction ID to be supplied with each message and ignoring each subsequent message with the same ID.
  
• Message Sequence
  You may not receive messages in the sequence in which they were sent. You can handle this problem either using conversation state or in your business logic by making conversation depend on acknowledgments.

Scenarios for Message-Based communication

Design an interface to your application or service to be message-based when:

• You are implementing a business system with medium- to long-term investment.
• You are implementing a large scale system with high availability characteristics.
• You are building a service that should be isolated from other services.
• You expect the communication on both points to be sporadically unavailable. 

Synchronicity

It is common to think of message-based communication as an asynchronous model. However, message-based communication can also be encapsulated by a synchronous programming model (for example, using Web Services proxies generated by VisualStudio.Net) in which the clients waits for a message. Here the developer gains the advantages of message-based communication without having to deal with asynchronous programming complexities.

Technologies for Asynchronous Communication

A number of approaches can be used for asynchronous communications. Connected technologies such as .NET Remoting achieve asynchronicity using asynchronous delegates, whereas disconnected technologies such as MSMQ achieve asynchronicity using message-based communication. Of these approaches, queuing technologies offer the greatest advantages. For example, MSMQ provides a store-and-forward messaging transport for use in applications.

As an alternative to using queuing technologies, you can use proxies generated by XML Web Services in VisualStudio.NET. In this scenario, the proxy exposes a Begin<MethodName> and End<MethodName> for each method exposed by the Web Service. You can also implement asynchronous communication using .NET Remoting. See Using Asynchronous Calls in In-Depth Remoting section under .NET Remoting.

Technologies for Synchronous Communication

Answering the following questions will help you choose the proper synchronous communication technology based on your requirements:

1. Do you need to flow transactions and/or Windows identity?
   If yes, use DCOM. Host your components in Enterprise Services to take advantage of transactions.
   
2. Do you need broad reach?
   If yes, use XML Web Services with SOAP and HTTP. Move to question 4, otherwise move to question 3.
   
3. Do you need to authenticate the caller?
   If you need authentication you need to have an IIS endpoint. Otherwise,  you can use any .NET Remoting channel hosted in any process.
   
4. Do you need to implement a facade code to expose business functionality?
   If you need to wrap your business logic in an extra facade to perform validation, transformation, and may be even caching, you can use Web Services to easily implement functions callable by SOAP. Otherwise, you can expose types directly as Web Services.

For more information about deciding between XML Web Services and .NET Remoting, see .NET Remoting or Web Services article.

Recommendations

The application design should strive to use asynchronous communication as much as possible. In some cases however, it is reasonable for the client to expect a synchronous response. You can design your components such that they use asynchronous operations but they also provide a synchronous interface to callers. The basic design for achieving this is as follows:

• The client submits a synchronous request to a component.
• The component receives the request and creates a unique ID to identify this request (possibly backed by a database entry such as Oracle database queues).
• The components submits an asynchronous request to the server/service and waits for a response (possibly with a timeout period).
• If the component receives the response in time, it build the synchronous response and sends it back to the synchronous caller. If the component does not receive the response in time, it cancels the asynchronous request and sends an appropriate acknowledgment to the synchronous caller.

Also note that the format in which you send and receive data and the schema of the data you exchange are important factors when designing the communication policy. The following factors influence format and schema:

• Do you control both endpoints of the communication? If so, you can choose format and schema that meet your requirements in terms of performance and security but at the cost of broad interoperability. This is usually the case when you communicate across all tiers in your application and you consider the tiers to be strongly coupled.
• Do you want your service to be accessible to external callers? If so, you should use widely accepted standards for protocols (TCP), formats (SOAP), and even schemas. If your service's communication does not rely on standards, you may need to use bridges or extra layers between the endpoints.

References

• Monitoring in .NET Distributed Application Design