Contents
Overview 1
Introduction to Connected
Business Logic 2
Technologies 5
Logical Design of Connected
Business Logic 16
Physical Design of Connected
Business Logic 20
Market Purchasing 25
Best Practices 28
Lab 6: Business Logic for Connected
Components 29
Review 35

Module 6: Business
Logic for Connected
Components

Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may

Test Lead: Eric Myers
Manufacturing Manager: John Williams
Group Product Manager: Juan Fernando Rivera
Lead Product Manager, System Services and Infrastructure: Edward Dudenhoefer
Manufacturing Manager: Rick Terek
Operations Coordinator: John Williams
Manufacturing Support: Laura King; Kathy Hershey
Lead Product Manager, Release Management: Bo Galford
Group Manager, Courseware Infrastructure: David Bramble
General Manager: Robert Stewart

Module 6: Business Logic for Connected Components iii Instructor Notes
This module provides students with an introduction to business logic. Every
enterprise has a set of business rules that define the way the business performs
data entry and modifications. These rules are embedded into the business logic.
Business logic can either be connected or disconnected in terms of time and
space. In this module, you will be introduced to connected business logic.
Disconnected business logic will be presented in Module 7, “Business Logic for
Disconnected Components.”
After completing this module, students will be able to:
!
Describe the logical design of the connected business logic layer and how to
use design patterns.
!
Describe how to design and configure COM+ components in the physical
design for transactions, security, activation, synchronization, and state
management.

Lab:
60 Minutes
iv Module 6: Business Logic for Connected Components Module Strategy
Use the following strategy to present this module:
!
Introduction to Connected Business Logic
The purpose of this section is to introduce students to the business logic
layer. Every enterprise has a set of business rules that define the way a
business performs data entry and modifications. For example, an enterprise
might have a business rule that would allow a manager to approve
requisitions up to a predefined dollar amount. The business rules that govern
data transformation—creation, retrieval, update, and delete (CRUD)—are
embedded in the business logic layer. In general, there are two types of
physical designs for a business logic layer, depending on whether the
physical design allows the business logic layer components to send
messages to each other directly or not: connected physical design and
disconnected physical design. Connectivity between business logic
components is defined in terms of both space (spatial) and time (temporal).
!
Technologies
The purpose of this section is to introduce students to COM+ transaction
technologies, and in particular to security, synchronization, activation, and
state.
!
Logical Design of Connected Business Logic
The purpose of this section is to introduce students to the two important
challenges in the logical design of business logic: business rules and design

Lab 6: Business Logic for Connected Components
The purpose of Lab 6 is for students to learn to design business logic and
apply the State behavioral design pattern. Students probably will not derive
answers that correspond exactly to the Market Purchasing design. This is
acceptable as long as the student answers are justified and reflect the
principles discussed in the module. Discuss with students their answers to
Lab 6.

Module 6: Business Logic for Connected Components 1 #
##
#

Overview
!
Introduction to Connected Business Logic
!
Technologies
!
Logical Design of Connected Business Logic
!
Physical Design of Connected Business Logic
!
Market Purchasing
!
Best Practices
Lead-in
In this module, you will learn
about the business logic
layer and how to create a
logical design and a
physical design for it.
2 Module 6: Business Logic for Connected Components #
##
#

Introduction to Connected Business Logic
!
The Business Problem
!
Business RequirementsConnected business logic is implemented to operate in a synchronous manner.
When a client request is processed, the client waits until the business logic
completes the request. Disconnected business logic is implemented to operate
in an asynchronous manner. A client request may be queued until a later time
when it can be processed.
This module deals specifically with connected business logic. In this module,
you will explore how to create a logical and a physical design for the business
logic layer.
In the logical design, you will examine what business logic is and how to
capture it in design by using design patterns. You will also learn how to

Nontransactional DAL
User ServicesBusiness logic (also called business rules) captures the rules, constraints, and
policies of the business. Rules and constraints are best expressed as simple
statements. For example, a requestor does not need manager approval for
requisitions of less than $1,000. Also, a requisition can only apply to a single
vendor.
Policy is the order in which work must be processed, or how the work should be
structured. For example, a requisition must first obtain funds approval before
obtaining manager approval. Also, a requisition must consist of one or more
line items each containing certain fields of information.
Business logic is therefore all of the rules, constraints, and policies that manage
a business system and keep it in working order. The problem with business
logic is that it is strongly tied to the business itself, which is constantly
changing. What would happen if requisitions could have multiple vendors? Or
what would happen if the amount for which a manager must approve a
requisition were increased to $2,000?
You should not have to rewrite the entire application every time a business rule
changes. For that reason, the business logic must be decoupled as much as
possible from the rest of the system. As a result, facades are used in the
enterprise architecture. A facade isolates the user services from changes in the
business logic. In a similar fashion, the data access layer (DAL) also prevents
changes in the business logic from propagating to the data services. The DAL
also prevents changes in the data services from propagating to the business
logic. This approach minimizes the amount of rework involved when business
logic changes.
The key functions of the business logic layer are to:
!

Connected vs. Disconnected Business Logic
Connected business components interact both synchronously and spatially.
Disconnected business components are those whose interactions are separated
by space (running on other nodes) and time.
This module will focus on the connected business logic components.
ACID Test
“ACID” is an acronym that stands for atomicity, consistency, isolation, and
durability. The ACID properties are considered a standard that any transactional
system must meet to ensure the integrity and semantics of transactional changes
to data.
!
Atomicity means that all the work inside the transaction is performed as one
unit. Either all of it succeeds or all of it fails.
!
Consistency means that the transaction will not violate business rules or data
integrity, and that the data is left in a consistent state after the transaction is
complete.
!
Isolation means that temporary changes made during the transaction are not
visible to other clients or transactions. Isolation imposes severe restrictions
on the concurrency of transactions. When a transaction begins, no other
transaction can start until the current transaction finishes.
!
Durability means that the changes made by the transaction persist in a
manner to survive system failures.

Topic Objective
To provide background
about the business
requirements.

Transactions
!
Security
!
Synchronization
!
Activation
!
State

Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
about the technologies that
can be used in the physical
design of a connected
business logic layer.
6 Module 6: Business Logic for Connected Components Transactions
!
Identify transactional business logic.
$
Transactions begin in the business logic layer.
$
Separate transaction business logic classes from

new number. Then the checking account class must record the initial deposit
made by the customer to the new account. Yet another class handles the deposit
into the new account. In this example, the checking account class is the root of
the transaction, and the other two classes are subordinate and are participating
in the transaction to assist the root class in creating a checking account.
Topic Objective
To provide background
about transactions.
Lead-in
In this topic, you will learn
about transactions in
COM+.
Module 6: Business Logic for Connected Components 7
The two subordinate classes may themselves be roots of other client
requests. As the customer makes deposits over time, those transactions may be
handled solely by the deposit class, which would now be a root class.

Map Transactional Attributes
After you have identified all groups of classes that are involved in transactions,
you are ready to map them to the COM+ transaction attributes. The following
table describes the COM+ transaction attributes that you can set for a class.
Attribute Description

Disabled Use this attribute only for legacy COM classes that do not
support transactions. If a legacy component must support
transactions, consider upgrading it to work with COM+.
Not Supported Use this attribute for all classes that were identified as

facades
$
Business logic components should trust each other
!
Granting Access to Facades
!
Using Multiple COM+ Applications
!
Authentication LevelSecurity must be enforced at each layer in a distributed application.
Fundamentally, all COM+ applications should implement security so that only
authorized clients can call those applications.
The business logic layer only has two valid users: the business facade and the
Web facade. All other users should be prevented from accessing the business
logic layer. This security approach enables all users of the system
(administrators, managers, or requestors) to access their appropriate
functionality through the facades. It also simplifies the security scheme.
Creating special accounts for administrators, programmers, or power users to
bypass the facades and access the business logic directly complicates the
security management, and also opens potential back doors into the system.
Securing the Business Logic
Security is enforced when an application boundary is crossed. For that reason,
the business logic components should be placed in a COM+ application that is
separate from the other layers. The COM+ application should also be
configured to enforce security by enabling the Enforce access checks for this
application check box in the COM+ application properties dialog box.
For simplicity, all business components should trust each other. As long as the
business components reside in the same COM+ application, calls between

Market Purchasing Business Logic application called Web Facade, and the
Market Purchasing Web Facade’s identity (FCDWEB) would be added to the
role. Next, the role would be mapped to all the appropriate interfaces and
methods that the Web facade is allowed to access.
Using Multiple COM+ Applications
Although the simplest approach for business logic components is to place them
all in one COM+ application, you will sometimes need to use more than one
COM+ application.
For example, if there is a strong grouping of certain business logic components
that is separate from the others, they could be placed in a separate COM+
application. Perhaps one group of business logic components handles vendor
logic, while another group handles accounting. If the dependency between these
two groups is low, it might make sense to place them in separate COM+
applications. As a result, they can be deployed on separate computers, which
might increase scalability.
These types of groupings might not be discovered until after deployment. Using
tools such as Visual Studio
®
Analyzer can help determine how groups of
components are being used. Components can easily be transferred from one
COM+ application to another without needing to be recompiled. Consequently,
these decisions can be left until deployment time.
10 Module 6: Business Logic for Connected Components Authentication Level
There are several levels of authentication that you can configure for the
business logic components. The authentication level is set at the COM+
application level. There is no general recommendation for which setting you
should use. The setting will depend on the sensitivity of the business logic

extremely sensitive information (such as credit card
numbers) that is being passed in method calls.

If you require packet integrity or packet privacy for any business components,
consider placing those components in a separate COM+ application. Requiring
this level of authentication for every business logic component is expensive and
will reduce the system performance.