Module 6: Business Logic for Connected Components

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 ea

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

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

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

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

# 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

In this module, you will learn

about the business logic

layer and how to create a

logical design and a

physical design for it

# 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

In this section, you will learn

about what makes up a

business logic layer, and in

particular, a connected

business logic layer

The Business Problem

Data Access Layer

Connected Business Logic Layer

Disconnected Business Logic Layer

Facade Layer

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

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

In this topic, you will learn

about the business

requirements for business

logic

The following topics will be covered in detail:

In this section, you will learn

about the technologies that

can be used in the physical

design of a connected

business logic layer

Transactions

! Identify transactional business logic.

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

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

Security

! Securing the Business Logic

facades

! 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+

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

Authentication level Guidelines

should not be used for secured business logic

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

level is the minimum amount of security that should be used for business logic

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

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 thatcreates user accounts and modify the data to create a valid account for the hacker

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

COM+ controls synchronization through activities An activity can be thought

of as a logical thread that runs across apartment, process, and computer boundaries Consequently, when objects reside in the same activity, only one method on one object can be executing at any given time

Activities ensure synchronization by using locks When a method call is made

on an object inside an activity, the activity is locked No other method calls can

be made into that activity until the original method call returns

Activity boundaries for business logic objects will follow the same boundaries for transactions That is, if object A calls object B, and object B calls object C, and all objects are in the same transaction, then they will also be in the same activity

Transactions and synchronization are strongly coupled in COM+ because transactions must ensure consistency Writing code that allows concurrent execution and maintains consistency is difficult and prone to errors As a result, COM+ transactions always follow a synchronized programming model, which means that you write your code as if it is only called by one user at a time

Using Visual Basic

If you are writing your business logic components in Microsoft Visual Basic®, you should compile them as apartment-threaded components Then you should configure their classes in the COM+ application as requiring synchronization You do not need to write any special synchronization code for this purpose

Using Visual C++

If you are writing your business logic components in Microsoft Visual C++®, you should compile them to use the neutral-threading model The neutral-threading model offers better scalability and performance for COM+

components You must write your code so that there is no thread affinity Although you cannot use thread local storage in the neutral-threading model, you can raise COM exceptions by creating an error object that uses the

IErrorInfo interface COM exceptions are reported by using thread local

storage However, COM+ expects and handles COM errors appropriately regardless of the thread on which they are raised

After compiling the Visual C++ business logic components, you should configure their classes to require synchronization when added to the COM+ application

Requiring New Synchronization

In general, you will not mark business logic classes as requiring new synchronization New synchronization forces a class to instantiate in a different activity from the caller This requirement is an advantage if the object of that class is to be shared with concurrent activities because each activity can reference the object without locking it from the other activities However, in the context of transactions, this scenario is unlikely

to be used simultaneously by many clients from the facade However, it is unlikely that you will need these types of classes in the business logic layer

Because Visual Basic does not support creating free-threaded or threaded classes, you must create these classes by using Visual C++

neutral-Note

Activation

! Just-in-time Activation

! Object Pooling

The manner in which COM+ objects are created and used is an important design consideration Object creation and destruction can have a significant affect on the scalability of a system and on the programming model that it must follow

Just-in-time Activation

Just-in-time (JIT) activation will allow an object to only be in existence when a method call is being made When a client makes a method call to the object, COM+ activates the object by creating it Then the method call is processed When the method call returns and the object indicates that its work is done, it is deactivated by being destroyed COM+ maintains a proxy object on which the client has a reference As a result, the client is never aware that JIT activation is occurring

JIT activation helps a system scale by keeping objects alive only when they are necessary When an object is activated, it might consume network, memory, and database resources When it is deactivated, those resources are freed to be used by other objects

To use JIT activation, you must write your component to use either the

apartment- or neutral-threading model You must also set the done bit when returning from method calls To set the done bit, you can call

IContextState::SetDeactivateOnReturn, IObjectContext::SetComplete or

IObjectContext::SetAbort Alternatively, you can set the done bit

declaratively by turning on the Auto-Done property for each method

Topic Objective

To provide background

about activation

Lead-in

In this topic, you will learn

about activation in COM+

Object Pooling

COM+ allows you to create pools of objects When a client makes a method call, an object is pulled from the pool and handles the method call When the call returns and the object is deactivated; it is returned to the pool instead of being destroyed

Object pooling is useful if you have business objects that require a lot of construction time JIT activation will slow these objects down because they will spend a lot of time constructing and destructing themselves Placing them in an object pool removes the cost of construction and destruction

Object pooling can also be used to limit the number of objects active at any given time You can set a maximum object pool size When the maximum number of objects have been allocated to client requests, future requests are queued until objects are freed Controlling the maximum object pool size is useful if you have objects that use a limited resource, such as a limited number

of database connections or network connections

To use object pooling, you must create a neutral-threaded component Visual Basic does not support the neutral-threaded model, so you must currently create neutral-threaded components in Visual C+

You must also implement the IObjectControl interface COM+ will call this

interface on your component’s classes when activating and deactivating your

object In the IObjectControl::Activate method, you should perform any

necessary steps to initialize your object for use Note that you do not construct your object here; that happens in the constructor In the

IObjectControl::Deactivate method, you should clear and delete any variables

associated with the current method call The aim is to prevent variables from carrying values into the next transaction, which would violate the semantics of

isolation In the IObjectControl::CanBePooled method, you should return

True if you can still be pooled If your object has become unstable for some

reason, you should return False so that COM+ can destroy the object and create

a new one for the pool

State

! Use the stateless programming model.

! Cache data by using the Shared Property Manager.

As discussed previously, state should not be stored in business logic components Any state related to the business logic components should have been dealt with in the logical design The state should reside elsewhere or be passed as parameters to the classes as needed

As also discussed previously, some state makes sense For example, consider a lookup table that exists in a database that maps ZIP codes to city names If it is called frequently, it would be more efficient to cache this table in memory, rather than making repeat trips to the database to perform lookups

The Shared Property Manager (SPM) can be used to cache the lookup table The first object to access that table would initialize it by reading the table from the database and writing it to the Shared Property Manager

When designing caches into the physical design, realize that you must use the Shared Property Manager programming model As a result, the object that uses SPM first is responsible for initializing it Also, properties stored in SPM are accessible only from the same process If multiple processes must access the same data, another approach must be used (such as placing the components in the same COM+ application)

Topic Objective

To provide background

about state

Lead-in

In this topic, you will learn

about state in COM+