Note that the information on this page is the BETA 1 of a guide that is now released. See http://www.codeplex.com/AppArchGuide for the latest PDF and HTML content.

Chapter 13 – Business Layers Guidelines

- J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat

Overview

This chapter describes the design process for business layers, and contains key guidelines that cover the important aspects you should consider when designing business layers and business components. These guidelines are organized into categories that include designing business layers and implementing appropriate functionality such as security, caching, exception management, logging, and validation. These represent the key areas for business layer design where mistakes occur most often.

BuisnessLayer.PNG

Business Components

The following list explains the roles and responsibilities of the main components within the business layer:
  • Application Facade. (Optional). An application façade combines multiple business operations into single message-based operation. You might access the application façade from the presentation layer using different communication technologies.
  • Business components. After a user process collects the data it requires, the data can be operated on using business rules. The rules will describe how the data should be manipulated and transformed as dictated by the business itself. The rules may be simple or complex, depending on the business itself. The rules can be updated as the business requirements evolve.
  • Business entity components. Business entities are used to pass data between components. The data represents real-world business entities, such as products and orders. The business entities that the application uses internally are usually data structures such as DataSets, Extensible Markup Language (XML) streams. Alternatively, they can 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.
  • Business workflow. Many business processes involve multiple steps that must be performed in the correct order and orchestrated. Business workflows define and coordinate long-running, multi-step business processes, and can be implemented using business process management tools.

Approach

When designing a business layer, you must also take into account the design requirements for the main constituents of the layer, such as business components, business entities and business workflow components. This section briefly explains the main activities involved in designing each of the components and the business layer itself.

Business Layer. When designing the business layer, you must perform the following key activities:
  • Identify the consumers of your business layer.
  • Determine how you will expose your business layer.
  • Determine the security requirements for your business layer.
  • Determine the validation requirements and strategy for your business layer.
  • Determine the caching strategy for your business layer.
  • Determine the exception management strategy for your business layer.

Business Components. When designing the business components, you must perform the following key activities:
  • Identify business components your application will use.
  • Make key decisions about location, coupling and interactions for business components.
  • Choose appropriate transaction support.
  • Identify how you business rules are handled.
  • Identify patterns that fit the requirements

Business entities. When designing the business entities, you must perform the following key activities:
  • Identify common data formats for the business entities.
  • Choose the data format.
  • Optionally, choose a design for your custom objects.
  • Optionally, determine what serialization support you will need.

Business Workflow. When designing the business workflow, you must perform the following key activities:
  • Identify workflow style using scenarios.
  • Choose an authoring mode.
  • Determine how rules will be handled.
  • Choose a workflow solution.
  • Design business components to support workflow.

Design Considerations

When designing a business layer, the goal of a software architect is to minimize the complexity by separating tasks into different areas of concern. For example, business processing, business workflow, and business entities all represent different areas of concern. Within each area, the components you design should focus on that specific area and should not include code related to other areas of concern.

When designing the business layer, consider following guidelines:
  • Decide if you need a separate business layer. It is always a good idea to use a separate business layer where possible to improve the maintainability of your application
  • Identify the responsibilities of your business layer. Use a business layer for processing complex business rules, transforming data, applying policies, and for validation.
  • Do not mix different types of components in your business layer. Use a business layer to decouple business logic from presentation and data access code, and to simplify the testing of business logic.
  • Reuse common business logic. Use a business layer to centralize common business logic functions and promote reuse.
  • Identify the consumers of your business layer. This will help to determine how you expose you business layer. For example, if your business layer will be used by your presentation layer and by an external application, you may choose to expose your business layer through a Web service.
  • Reduce round trips when accessing a remote business layer. If you are using a message-based interface, consider using coarse-grained packages for data, such as Data Transfer Objects. In addition, consider implementing a remote façade for the business layer interface.
  • Avoid tight coupling between layers. Use abstraction when creating an interface for the business layer. The abstraction can be implemented using public object interfaces, common interface definitions, abstract base classes, or messaging. For Web applications, consider a message-based interface between the presentation layer and the business layer.

Business Layer Frame

Category Common Issues
Authentication Applying authentication in a business layer when not required.
Designing a custom authentication mechanism.
Failing to use single-sign-on where appropriate.
Authorization Using incorrect granularity for roles.
Using impersonation and delegation when not required.
Mixing authorization code and business processing code.
Business Components Overloading business components, by mixing unrelated functionality.
Mixing data access logic within business logic in business components.
Not considering the use of message-based interfaces to expose business components.
Business Entities Using the Domain Model when not appropriate.
Choosing incorrect data formats for your business entities.
Not considering serialization requirements.
Caching Caching volatile data.
Caching too much data in the business layer.
Failing to cache data in a ready-to-use format.
Caching sensitive data in unencrypted form.
Coupling and Cohesion Tight coupling across layers.
No clear separation of concerns within the business layer.
Failing to use a message-based interface between layers.
Concurrency and Transactions Not preventing concurrent access to static data, that is not read-only.
Not choosing the correct data concurrency model.
Using long running transactions that hold locks on data.
Data Access Accessing the database directly from business layer.
Mixing data access logic within business logic in business components.
Exception Management Revealing sensitive information to the end user.
Using exceptions for application logic.
Not logging sufficient detail from exceptions.
Logging and Instrumentation Failing to add adequate instrumentation to business components.
Failing to log system-critical and business-critical events.
Not suppressing logging failures.
Service Interface Breaking the service interface.
Implementing business rules in the service interface.
Failing to consider interoperability requirements.
Validation Relying on validation that occurs in the presentation layer.
Not validating all aspects of parameters, such as “Range”, “Type” and “Format”.
Not reusing the validation logic.
Workflows Not considering application management requirements.
Choosing an incorrect workflow pattern.
Not considering how to handle all exception states.
Choosing an incorrect workflow technology.

Authentication

Designing an effective authentication strategy for your business layer is important for the security and reliability of your application. Failing to design a good authentication strategy can leave your application vulnerable to spoofing attacks, dictionary attacks, session hijacking, and other types of attack.

When designing an authentication strategy, consider following guidelines:
  • If the business layer and presentation layer trust each other and reside on the same tier, avoid using authentication within the business layer.
  • If the business layer is deployed on a separate tier or is shared by other applications, authenticate users.
  • If your business layer will be used in multiple applications in a trusted environment, consider implementing a single-sign-on mechanism.
  • Decide if you need to flow the caller's identity to the business layer.
  • Use a trusted subsystem for access to back-end services to maximize the use of pooled database connections.
  • Avoid designing custom authentication mechanisms.
  • If using web services, consider using IP Filtering to restrict call only from the presentation layer.

Authorization

Designing an effective authorization strategy for your business layer is important for the security and reliability of your application. Failing to design a good authorization strategy can leave your application vulnerable to information disclosure, data tampering, and elevation of privileges.

When designing an authorization strategy, consider following guidelines:
  • Consider implementing roles to achieve the appropriate level of granularity.
  • Protect resources by applying authorization to callers based on their identity, account groups, or roles.
  • Use role-based authorization for business decisions.
  • Use resource-based authorization for system auditing.
  • Use claims-based authorization when you need to support federated authorization based on a mixture of information such as identity, role, permissions, rights, and other factors.
  • Avoid using impersonation and delegation as it can significantly affect performance and scaling. It is generally more expensive to impersonate a client on a call than to make the call directly.
  • Avoid mixing authorization code with business process code.

Business Components

Business components implement business rules in diverse patterns, and accept and return simple or complex data structures. Your business components should expose functionality in a way that is agnostic to the data stores and services required to perform the work. Compose your business components in meaningful and transactionally-consistent ways. Designing business components is an important task. If you fail to design business components correctly, the result is likely to be code that is impossible to maintain.

When designing business components, consider following guidelines:
  • Avoid overloading of components by adding unrelated or mixed functionality.
  • Avoid mixing data access logic and business logic within your business components.
  • Design components to be highly cohesive.
  • Consider using message-based communication to invoke business components.
  • Ensure that processes exposed through a service interfaces are idempotent.
  • Ensure that the data format for business components inputs and outputs is consistent.
  • Expose functionality in a way that is agnostic to the data stores and services needed to perform the work. This promotes a loosely-coupled design.
  • Consider using business process components to implement your business rules.
  • If your application has volatile business rules, store them in a rules engine.
  • If the business process involves multiple steps and long-running transactions, consider using workflow components.
  • Implement sufficient and appropriate management instrumentation within the components.

Business Entities

Business entities store data values and expose them through properties; they provide stateful programmatic access to the business data and related functionality. Therefore, designing or choosing appropriate business entities is vitally important for maximizing the performance and efficiency of your business layer.

When designing business entities, consider following guidelines:
  • Avoid using the Domain Model pattern for business entities when it is not appropriate.
  • Choose appropriate data formats for your business entities.
  • Consider the serialization requirements of your business entities.
  • Consider using lightweight Domain Objects to represent the business entities.
  • If the tables in the database represent business entities, consider using the Table Module pattern.
  • Minimize the number of calls made across physical tiers. For example, use the Data Transfer Object (DTO) pattern.

Caching

Designing an appropriate caching strategy for your business layer is important for the performance and responsiveness of your application. Use caching to optimize reference data lookups, avoid network round trips, and avoid unnecessary and duplicated processing. As part of your caching strategy, you must decide when and how to load the cache data. To avoid client delays, load the cache asynchronously or by using a batch process.

When designing a caching strategy, consider following guidelines:
  • Evaluate the amount of data cached within the business layer. Caching excessive data can be counter-productive.
  • Cache static data that will be regularly reused within the business layer.
  • Consider caching data that cannot be retrieved from the database quickly and efficiently.
  • Consider caching data in a ready-to-use format within your business layer.
  • Avoid caching sensitive data if possible, or design a mechanism to protect sensitive data in the cache.
  • Consider how Web farm deployment will affect the design of your business layer caching solution.

Coupling and Cohesion

When designing components for your business layer, ensure that they are highly cohesive, and implement loose coupling between layers. This helps to improve the scalability of your application.

When designing for coupling and cohesion, consider following guidelines:
  • Avoid tight coupling between layers. The business layer should know only about the layer below (the data access layer), and not the layer above (the presentation layer or external applications that access the business layer directly).
  • Use a message-based interface for your business layer.
  • Design your business layer components to be highly cohesive.
  • Avoid mixing data access logic with business logic in your business components.

Concurrency and Transactions

When designing for concurrency and transactions, it is important to identify the appropriate concurrency model and determine how you will manage transactions. You can choose between an optimistic model and a pessimistic model for concurrency.

When designing for concurrency and transactions, consider the following guidelines:
  • If you have business critical operations, consider wrapping them in transactions.
  • Use connection-based transactions when accessing a single data source.
  • Consider transaction boundaries, so that retries and composition are possible.
  • Where you cannot use transactions, implement compensating methods to revert the data store to its previous state.
  • Avoid holding locks for long periods; for example, when using long-running atomic transactions.
  • Consider compensating locks for long-running transactions.
  • Consider whether you will use optimistic or pessimistic locking.
  • Choose an appropriate transaction isolation level.

Data Access

Designing an effective data access strategy for your business layer is important to maximize maintainability and the separation of concerns.

When designing a data access strategy, consider the following guidelines:
  • Avoid mixing data access code and business logic within your business components.
  • Avoid directly accessing the database from your business layer
  • Consider using a separate data access layer for access to the data base.

Exception Management

Designing an effective exception management solution for your business layer is important for the security and reliability of your application. Failing to do so can leave your application vulnerable to Denial of Service (DoS) attacks, and may allow it to reveal sensitive and critical information about your application. Raising and handling exceptions is an expensive operation, and it is important that your exception management design takes into account the impact on performance.

When designing an exception management strategy, consider following guidelines:
  • Do not use exceptions to control business logic.
  • Differentiate between boundary exceptions and internal exceptions.
  • Centralize your approach for handling boundary exceptions.
  • Consider if you need to transform exceptions at the boundary.
  • Design an appropriate exception propagation strategy.
  • Design a strategy for handling unhandled exceptions.
  • Design an appropriate exception logging strategy.
  • Design an appropriate notification strategy for critical errors and exceptions
  • Do not allow exceptions to reveal sensitive information.

Logging and Instrumentation

Designing a good logging and instrumentation solution for your business layer is important for the security and reliability of your application. Failing to do so can leave your application vulnerable to repudiation threats, where users deny their actions. Log files may also be required to prove wrongdoing in legal proceedings. Auditing is generally considered most authoritative if the log information is generated at the precise time of resource access, and by the same routine that accesses the resource.

When designing a logging and instrumentation strategy, consider following guidelines:
  • Centralize logging and instrumentation for your business layer.
  • Choose an appropriate log sink.
  • Include instrumentation for system-critical and business-critical events in your business components.
  • Audit and log all access to functions within business layer.
  • Do not store business-sensitive information in the log files.
  • Ensure that a logging failure does not impact normal business layer functionality.

Service Interface

When designing a service interface, you must to consider the granularity of the service and interoperability requirements.

When designing a service interface, consider following guidelines:
  • Design your services interfaces in such a way that changes to the business logic do not affect the interface.
  • If the business logic may be accessed in different ways by different clients, consider implementing multiple service interfaces.
  • Consider implement caching, mappings, and type conversion in the interface if required by the component.
  • Do not implement business rules in a service interface.
  • Use standard formats for parameters to enable maximum compatibility with different clients.
  • Design service interfaces for maximum interoperability with other platforms and services.
  • Choose an appropriate technology for implementing your services.
  • Choose appropriate transport protocols and message formats for your services.

Validation

Designing an effective validation solution for your business layer is important for the security and reliability of your application. Failing to do so can leave your application vulnerable to cross-site scripting attacks, SQL injection attacks, buffer overflows, and other types of input attack. There is no comprehensive definition of what constitutes a valid input or malicious input. In addition, how your application uses input influences the risk of the exploit.

When designing a validation strategy, consider following guidelines:
  • When a designing validation solution, assume that all input is malicious.
  • Validate all input and method parameters within the business layer, even when input validation occurs in the presentation layer.
  • Centralize your validation approach if it can be reused.
  • Choose appropriate validation techniques.
  • Constrain, reject, and sanitize all input.

Workflows

Workflow components are used only when your application must support a series of tasks that are dependent on the information being processed. This information can be anything from data checked against business rules, to human interaction. When designing workflow components, it is important to consider how you will manage the workflows, and understand the options that are available.

When designing a workflow strategy, consider the following guidelines:
  • Implement workflows within components that involve a multi-step or long-running process.
  • Choose an appropriate workflow style depending on the application scenario.
  • Handle fault conditions within workflows, and expose suitable exceptions.
  • If the component must execute a specified set of steps sequentially and synchronously, consider using the pipeline pattern.
  • If the process steps can be executed asynchronously in any order, consider using the event pattern.

Deployment Considerations

When deploying a business layer, you must consider performance and security issues within the production environment.

When deploying a business layer, consider following guidelines:
  • Locate the business layer on the same physical tier as the presentation layer to maximize application performance.
  • If you must support a remote business layer, consider using TCP protocol to improve performance of the application.
  • Use IPSec to protect data passed between physical tiers for all business layers for all applications.
  • Use SSL to protect calls from business layer components to remote Web services.

Pattern Map

Category Relevant Patterns
Authentication Direct Authentication
Brokered Authentication
Federated Authentication (SSO)
Authorization Role Based Authorization
Resource Based Authorization
Claims Based Authorization
Trusted subsystem
Impersonation and Delegation
Business Components Transaction Script
Work Unit
Command
Application Façade
Chain of Responsibility
Business Entities Entity Translator
Domain Model
Table Module
Caching Cache Dependency
Coupling and Cohesion Adapter
Dependency Injection
Concurrency and Transactions Coarse Grained Lock
Implicit Lock
Optimistic Offline Lock
Pessimistic Offline Lock
Transaction Script
Capture Transaction Details
Exception Management Exception Shielding
Logging and Instrumentation Provider
Service Interface Service Interface
Service Layer
Façade
Workflows Data-driven workflow
Human workflow
Sequential workflow
State-driven workflow

Key patterns

  • Application Façade – Centralize and aggregate behavior to provide a uniform service layer.
  • Chain of Responsibility – Avoid coupling the sender of a request to its receiver by allowing more than one object to handle the request.
  • Command – Encapsulate request processing in a separate command object with a common execution interface.
  • Dependency Injection – Use a base class or an interface to define a shared abstraction and use this to inject object instances into components that interact with the shared abstraction interface.
  • Domain Model – Create a web of interconnected objects, where each object represents some meaningful individual, which can be as large as a corporation or as small as a single line on an order form.
  • Entity Translator – Implement an object that transforms message data types to business types for requests, and reverses the transformation for responses.
  • Façade – A unified interface over a set of operations that can reduce coupling between systems.
  • Service Interface – A programmatic interface that systems use to interact with other systems.
  • Service Layer – An architectural design pattern where the service interface and implementation are grouped into a single layer.
  • Table Module** – Create a single component that handles the business logic for all rows in a database table or view.

Technology Considerations

  • Use Windows Workflow to simplify development of workflows that automatically support secure, reliable, transacted data exchange, a broad choice of transport and encoding options, and provide built-in persistence and activity tracking.
  • Use BizTalk Server 2006 if you need to interact with non-Microsoft systems, perform EDI operations, or require very complex orchestrations.
  • Use MOSS only if your business layer is confined to a single SharePoint site and does not require access to information in other sites.
  • Use transaction scope (System.Transaction) to manage transactions that span multiple data sources.

Additional Resources

For more information on design patterns for business layers and components, see the following resources: For more information on performance in business layers and components, see the following resources: For more information on security issues in business layers and components, see the following resources:

Last edited Dec 16, 2008 at 8:18 AM by rboucher, version 4

Comments

No comments yet.