Module 6: Business Logic for Connected Components

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

be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, ActiveX, BackOffice, FrontPage, Microsoft Press, MSDN, MS-DOS,
PowerPoint, Visio, Visual Basic, Visual C++, Visual InterDev, Visual J++, Visual Studio, Win32,
Windows, and Windows NT are either registered trademarks or trademarks of Microsoft
Corporation in the U.S.A. and/or other countries.

Other product and company names mentioned herein may be the trademarks of their respective
owners.

Program Managers: Rhy Mednick, Susie Parrent
Instructional Designer: Susie Parrent
Subject Matter Experts: David Chesnut, Sam Gill (TechnoWiz), Michel Pahud
Media Management: David Mahlmann
Editing Manager: Lynette Skinner
Editor: Mick Alberts, Jennifer Linn
Production Manager: Miracle Davis
Print Coordinators: Linda Lu Cannon (Write Stuff), Marlene Lambert (Online Training
Solutions, Inc.)
Build Coordinator: Eric Wagoner
Graphic Artist: Scott Serna

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.

!
Describe how the Market Purchasing application uses design patterns and
COM+ technology in its logical and physical designs.

Materials and Preparation
This section provides the materials and preparation tasks that you need to teach
this module.
Required Materials
To teach this module, you need the following materials:
!
Microsoft
®
PowerPoint
®
file 1910A_06.ppt
!
Module 6: Business Logic for Connected Components
!
Lab 6: Business Logic for Connected Components

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the lab.

Presentation:
75 Minutes

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

patterns.
In the topic “Business Rules,” review the CRUD elements and emphasize
that it is the only mechanism that exists for discovering business rules in a
systematic fashion.
!
Physical Design of Connected Business Logic
The purpose of this section is to introduce students to the two important
challenges in the physical design of connected business logic: packaging
and deployment and managing state.
!
Market Purchasing
The purpose of this section is to review the logical and physical designs of
Market Purchasing and to explain the justification for the choices made. The
logical design of connected business logic classes is based on the entities
derived for the application.
You can show how Market Purchasing is implemented by starting
Component Services and presenting the Market Purchasing Business Logic
COM+ application.
!
Best Practices
The main messages in the best practices for the business logic are that you
need to have a fail-safe mechanism for discovering the business rules and
that you need to package these rules into COM+ components and COM+
applications that enhance reusability.

Module 6: Business Logic for Connected Components v


Lab Strategy
!

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

Every enterprise has a set of business rules that define the way a business
performs data entry and modifications. For example, an enterprise can 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: connected physical design
or disconnected physical design. Connectivity between business logic
components is defined in terms of both space (spatial) and time (temporal). In
this module, you will be introduced to the connected business logic.
The disconnected business logic will be presented in Module 7, “Business
Logic for Disconnected Components.”
After completing this module, you will be able to:
!
Describe the logical design of the connected business logic layer and how to
take advantage of design patterns.
!
Describe how to design and configure COM+ components in the physical
design for transactions, security, activation, synchronization, and state
management.
!
Describe how the Market Purchasing application uses design patterns and
COM+ technology in its logical and physical designs.

Topic Objective
To provide an overview of
the module topics and
objectives.

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 Requirements


Connected 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

evaluate the technologies that you will use while creating the logical design.
In the physical design, you will examine the technology used to implement the
business logic. You will also explore techniques and recommendations that will
allow you to take advantage of those technologies.
The technologies you will cover in this module include COM+ transactions,
security, activation, synchronization, and the Shared Property Manager.
In this section, you will learn about the business problem and the business
requirements.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
about what makes up a
business logic layer, and in
particular, a connected
business logic layer.
Module 6: Business Logic for Connected Components 3


The Business Problem
Data Access Layer
Connected Business
Logic Layer
Disconnected
Business Logic Layer
Facade Layer
Web Services Facade Business Facade
Transactional DAL

Nontransactional DAL
User Services


Business 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:
!

Receive requests from the business or Web services facade layer.
!
Process the requests according to the coded business logic.
!
Use the DAL to fetch or send data to the data services layer.
!
Pass the results of the processing back to the facade layer.
Topic Objective
To provide background
about the business problem.
Lead-in
In this topic, you will learn
about the business problem
facing designers who have
to implement a business
logic layer.
4 Module 6: Business Logic for Connected Components


Business Requirements
!
Connected vs. Disconnected Business Logic
!
ACID Test


Business logic components can exist in other applications. The application you
are working on can interact with the business logic of other applications. The
interaction between business logic components of different applications can be
separated in both space and time.

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.

Lead-in
In this topic, you will learn
about the business
requirements for business
logic.
Module 6: Business Logic for Connected Components 5


#
##
#

Technologies
!
Transactions
!
Security
!
Synchronization
!
Activation
!
State


To understand the technologies associated with the physical design of business
logic components, you must understand the underlying technology of COM+
applications.
The following topics will be covered in detail:
!

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

nontransactional business logic classes.
!
Identify functional composition.
!
Map transactional attributes.


When a client call enters the system, the business logic layer is where the
transactions begin. Consequently, you must identify how those transactions will
be structured and design the business logic components appropriately. The
following approach is recommended for identifying the transactional nature of
your business logic components and for configuring those components for
transactions.
Identify Transactional Business Logic
The first step is to separate transactional classes from nontransactional classes.
Transactional classes contain business logic that performs work on behalf of the
user and updates data. Examples include business logic that creates new
requisitions or records the receipt of an item.
An example of a nontransactional business logic class is a reporting component
that builds a report from information in the database based on a set of business
rules. Because it is only reporting by reading data, it does not require a
transaction to manage its work.
Identify Functional Composition
The next step is to identify groups of classes that rely on each other to complete
one client request (or use case). In these groups, one class is the root of the
transaction; it is the class called from the facade. The other classes are
subordinate to the root class and are called from the root class.
For example, suppose a checking account class contains business logic to create
a customer checking account. As part of creating the account, it must obtain a
new checking account number. Another class is responsible for generating the

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

nontransactional.
Supported You probably will not use this attribute often. It indicates that
the class will participate in a transaction if one exists, but that it
does not require one. Module 9, “The Transactional Data
Access Layer,” will explore using this setting for atomic
operations in the DAL.
Required This attribute should be set for any root object and any
subordinate object.
Requires New You probably will not use this attribute often. When
identifying the functional composition of classes, use this
attribute when a subordinate class must have a separate
transaction. One example is logging information. Consider a
credit card class that must authorize a purchase for a user. As
part of the authorization, another class is called that logs the
fact that the user attempted a purchase at a certain time and
location. If the authorization fails due to unavailable credit, the
log must still record a history of where the card was used. In
this case, the logging class would require a separate transaction
so that it could still succeed independently of the original
transaction.

Note
8 Module 6: Business Logic for Connected Components


Security
!
Securing the Business Logic
$
The business logic layer should only be accessed by

facades
$
Business logic components should trust each other
!
Granting Access to Facades
!
Using Multiple COM+ Applications
!
Authentication Level


Security 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

business components will not be checked. Consequently, using just one COM+
application for the business logic components is a good approach. If you need
to create multiple COM+ applications for the business logic components, you
will need to create a security role in each COM+ application that grants access
to the other COM+ applications.
Finally, you will need to create and assign a Microsoft
®
Windows
®
2000 user
account for the business logic COM+ application identity. As a result, the
identity can be assigned to roles for the DAL, which will be discussed in
Module 8, “The Nontransactional Data Access Layer.”
Topic Objective
To provide background
about security.
Lead-in
In this topic, you will learn
about security in COM+.
Module 6: Business Logic for Connected Components 9


Granting Access to Facades
Only the facades are allowed to access the business logic layer. For this reason,
you will need to create a role for each facade and add that role to the COM+
application.
For example, in the Market Purchasing application, the business logic
components reside in a COM+ application called Market Purchasing Business
Logic. The Web facade resides in a COM+ application called Market
Purchasing Web Facade. To enable security, a role would be created in the

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

operations. Use the following table as a guideline.
Authentication level Guidelines

None No authentication is used. This authentication level
should not be used for secured business logic.
Connect When a connection is made to a business logic object,
authentication is enforced. However, no authentication
occurs afterward. As a result, the client could pass a
pointer referring the object to another unauthorized
client. Consequently, this level is not recommended for
business logic.
Call Authentication is enforced for every method call. This
level is the minimum amount of security that should be
used for business logic.
Packet Authentication is enforced for every method call, and
the data passed is checked to ensure that it is from the
caller. This authentication level is also a good level of
security for the business logic layer.
Packet integrity Authentication is enforced for every method call, and
the data passed is checked to ensure that it was not
altered en route. This level of security is useful for any
methods in which changing the parameter data could
trick the method into performing an undesirable task.
For example, a hacker could intercept a method call tha
t
creates user accounts and modify the data to create a
valid account for the hacker.
Packet privacy Authentication is enforced for every method call, and
the data passed is encrypted to prevent it from being
sniffed and read. This security level is good to use for

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.