Tài liệu Module 11: System Services ppt

Contents
Overview 1
Introduction to System Services 2
Logical Design of System Services 6
Physical Design of System Services 10
Market Purchasing 19
Best Practices 22
Lab 11: System Services 23
Review 27

Module 11: System
Services

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, BizTalk, 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 11: System Services iii


Instructor Notes
This module provides students with an introduction to system services. This
module focuses on the system services layer. The system services layer works
with parts of the application that provide system service or system
infrastructure functionality. Typically, any layer within the architecture can use
the system services layer. Examples include page caching, auditing, and
searching.
After completing this module, students will be able to:
!
Describe the logical design of a system services layer.
!
Describe the functionality of authentication.
!
Describe the functionality of a search.
!
Describe the functionality of an audit.
!
Describe application instrumentation.
!
Describe the physical design of a system services layer and how to apply the
technologies presented in this module.

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_11.ppt
!
Module 11: System Services
!
Lab 11: System Services

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

Presentation:
75 Minutes

Lab:
30 Minutes
iv Module 11: System Services


Module Strategy

Use the following strategy to present this module:
!
Introduction to System Services
The purpose of this section is to introduce students to the system services
layer. The system services layer works with parts of the application that
provide system service or system infrastructure functionality. Explain the
business problem by using the example of authentication, and then use the
same example to illustrate the business requirements in the next topic.
!
Logical Design of System Services
The purpose of this section is to introduce the Authentication design pattern
that was created as a part of this course.
Discuss the design pattern in detail. Solicit comments from the students
about the value they think this pattern adds to a logical design. For a
discussion point, ask students what other system services might be good
candidates as design patterns.
!
Physical Design of System Services
The purpose of this section is to identify the considerations in the physical
design of system services. These considerations include crossing layer
boundaries, auditing, authentication, and application instrumentation.
In the topic “Application Instrumentation,” focus on the use of Microsoft

Windows
®
Management Instrumentation (WMI). Also mention that WMI is
the Microsoft implementation of Web-Based Enterprise Management
(WBEM).
WBEM is an industry initiative undertaken by the Distributed Management
Task Force (DMTF) to provide enterprise system managers with a standard

low-cost solution for their management needs. WBEM facilitates a number
of tasks, ranging from workstation configuration to full-scale enterprise
management across multiple platforms.
The WBEM initiative has created a specification for the Common
Information Model (CIM), which is an extensible data model for
representing objects that exist in typical management environments. WBEM
has also created a specification for the Managed Object Format (MOF)
language for defining and storing modeled data.
WMI uses CIM to represent systems, applications, networks, devices, and
other managed components in an enterprise environment.
!
Market Purchasing
The purpose of this section is to discuss the logical and physical designs of
the system services of Market Purchasing and to provide a justification for
the choices made. Market Purchasing uses an error logging system service.
You can demonstrate the error logging system service by shutting down the
MSSQLServer service and then running Market Purchasing. Because the
database is unavailable, Market Purchasing will report errors, and the log
service will write errors to \Program Files\Market\ErrorLog.txt. You can
then show students the format of the errors in the log file.
Module 11: System Services v


!
Best Practices
The main message in this section is to emphasize the need to incorporate
authentication, auditing, and management instrumentation capabilities in a
solution.
Lab Strategy
!

Lab 11: System Services
The purpose of Lab 11 is to teach students how to design system services.
Students might present answers that differ from those included in the lab.
This is acceptable as long as the student answers are justified and are well
thought out. Discuss with students their answers to Lab 11.

THISPAGE INTENTIONALLY LEFT BLANK

Module 11: System Services 1


#
##
#

Overview
!
Introduction to System Services
!
Logical Design of System Services
!
Physical Design of System Services
!
Market Purchasing
!
Best Practices


This module is about the system services layer. The system services layer
works with parts of the application that provide system service or system

infrastructure functionality. Typically, any layer in the architecture can use the
system services layer. Examples of system services include page caching,
auditing, and searching.
After completing this module, you will be able to:
!
Describe the logical design of a system services layer.
!
Describe the functionality of authentication.
!
Describe the functionality of an audit.
!
Describe application instrumentation.
!
Describe the physical design of a system services layer and how to use the
technologies presented in this module.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about the system services
layer and how to create a
logical design and a
physical design for it.
2 Module 11: System Services


#

##
#

Introduction to System Services
!
The Business Problem
!
Business Requirements


The system services layer interacts with other architecture layers to provide
generic services to an enterprise solution. The other architecture layers include
the user services layer, the facade layer, the business logic layer, and the data
access layer (DAL).
In this section, the system services layer will be placed in the proper context of
the business problem. This will be followed by a presentation on the logical
design of a system services layer that will focus on behavioral design patterns.
Finally, there will be a brief presentation on the physical design of a system
services layer.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
what makes up a system
services layer.
Module 11: System Services 3

The Business Problem
DAL
Connected Business
Logic Layer
Disconnected Business
Logic Layer
Facade Layer
Web Services Facade Business Facade
Transactional DAL
Nontransactional DAL
User Services
System
Services


As a system is designed, certain functionality is derived that must be accessible
from all parts of the system. For example, auditing is a functionality that is
common to many systems, and it is needed throughout the system. The business
logic layer is likely to use auditing to log any activities that it performs. The
DAL will also require auditing since it can be accessed directly from the facade
layers. Building auditing functionality into each layer of the system would be a
duplication of effort. Therefore, a system services layer is needed to identify
and design such functionality.
The system services layer works with parts of an application such as
authentication and instrumentation that provide system service or system
infrastructure functionality. Each of these system services can interact with user
services to provide the user interface, with business logic to apply rules, and
with the DAL to access the data services.
The system services can be also thought of as utility functions, such as audit,
that service all of the different layers of an application.

Topic Objective
To provide background
about the business problem.
Lead-in
In this section, you will learn
about the business problem
facing application designers
that leads to the need for a
system services layer.
4 Module 11: System Services


Business Requirements
!
Crossing Layer Boundaries
!
Authentication
!
Auditing
!
Application Instrumentation
Application Community
Windows 2000
Users


There are four business requirements of system services: the need to cross layer
boundaries, the need for authentication, the need for auditing, and the need for
application instrumentation in implementing a solution.
Crossing Layer Boundaries

The need to cross layer boundaries arises out of the need for system processes
to have a user services component, a facade component, a business logic
component, and a DAL component. An example would be logon, which can
have a user service, a facade component, a business logic component, and a
DAL component.
Authentication
The need for authentication in implementing system services arises out of the
need for the solution to maintain an auxiliary user management service beyond
the Microsoft
®
Windows
®
2000 domain service. The use of an auxiliary user
management service avoids the need for each external user of the system to be a
Windows 2000 domain user. The figure in the preceding slide depicts the
relationship between the larger application community and its subset of
Windows 2000 domain users.
Auditing
The need for auditing in implementing system services arises out of the need
for the solution to maintain its own audit trail of activities occurring in the
system, such as changes made to the data store or recording activities of
business logic components.
Topic Objective
To provide background
about the business
requirements for system
services.
Lead-in
In this section, you will learn
about the business

requirements for
implementing system
services.
Module 11: System Services 5


Application Instrumentation
The need for application instrumentation in implementing system services
arises out of the need for the solution to provide a mechanism for managing its
internal state and behavior variables.
In a subsequent section you will learn about the important physical design
features of crossing layer boundaries, authentication, auditing, and application
instrumentation.
6 Module 11: System Services


#
##
# Logical Design of System Services
!
The Audit System Service
!
The Authentication Design Pattern


In this section, you will learn about designing auditing as a system service. You
will also learn about designing authentication as a system service, and about a
new behavioral design pattern for implementing authentication.
If you are concerned about the need for creating new patterns, you should refer
to Chapter 1, “The Top Ten Misconceptions,” in Pattern Hatching, Design

Patterns Applied, by John Vlissides, Addison-Wesley, 1998.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
about the important logical
design considerations of
system services.
Module 11: System Services 7


The Audit System Service
!
Auditing is beneficial as a centralized system service.
!
Auditing can be implemented via the Queue behavioral
design pattern.


When you partition a system into a collection of cooperating classes, you need
to maintain an audit trail of the sequence of activities of the cooperating classes.
An auditing service can simplify the auditing process by providing one central
service for the application’s auditing needs. Sophisticated auditing services can
allow client components to specify the name of the log file, or even to use
Extensible Markup Language (XML) to write out log entries.
Auditing can be implemented by using a Queue pattern. A Queue pattern is a
many-to-many relationship in which the senders do not know their receivers.
The senders provide a message that contains all of the information that the

receivers need to act on. Auditing involves multiple clients posting log entries
to a receiver that is the auditing service itself. By using a durable queue,
processing of log entries can be queued until a batch process retrieves them.
Batching log entries in this manner improves system performance.

Topic Objective
To provide an overview of
the audit system service.
Lead-in
In this section, you will learn
about the audit system
service.