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

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.
8 Module 11: System Services


The Authentication Design Pattern
+Login()
+CheckAccess()
Authenticator
+Handle()
Resource
-Token
Client


The Authentication behavioral design pattern defines a many-to-one
relationship between objects so that one or more objects can request
authentication from a single object that will maintain a user database. This
pattern was first discussed in Module 3, “Logical Design and Behavioral
Design Patterns.” The pattern is discussed again here because it is a good

pattern to use to implement an authentication system service.
When you partition a system into a collection of classes that differ in regard to
who can use them, you must maintain a user database that will define whether a
user is allowed to use a particular class.
Pattern Element Description

Pattern name Authentication
Problem The system must authenticate clients and check access on each
method call from a client.
Solution Create an Authenticator class that provides a Login method.
When a user logs on to the system, the Login method returns a
token to the client that has the client’s credentials, role, and
timestamp. The Authenticator class also has a CheckAccess
method. Each time the client calls a method on a system object
(here called a resource), the client passes its token to the object.
The object passes the token to CheckAccess to determine if the
client has access privileges.
When to use Any application that is accessed by users from a non-trusted
source.
Any distributed application.
Any time user access varies independently from operating
system access.


Topic Objective
To provide an overview of
the Authentication design
pattern.
Lead-in
In this section, you will learn

about the Authentication
design pattern.
Module 11: System Services 9


Pattern Element Description

Benefits Secure user authentication.
Access control at each method call.
Session management.
Drawbacks Because the client stores the token, there is potential for
unauthorized users to obtain the token by monitoring network
traffic. When network lines that are not trusted are used (such as
the Internet), additional security measures should be employed,
such as Secure Sockets Layer (SSL).

As a system service, the Authentication pattern is mostly used by user services
and the facade layer. Other layers typically use different security schemes for
protecting access to resources. However, the Authentication pattern is just as
useful to other layers if the available security technology is not adequate for a
given scenario. Security functionality is ultimately provided by the operating
system, and the physical details of how authentication is implemented vary
quite a bit. Distributed Component Object Model (DCOM) authentication is
different from Internet Information Services (IIS) authentication, for example.
10 Module 11: System Services


#
##
# Physical Design of System Services

!
Crossing Layer Boundaries
!
Auditing
!
Authentication
!
Application Instrumentation
!
Key Considerations


The physical design of system service components poses challenges for
implementation: How can you design components that can interact with other
components in multiple layers? How can you design components that can
provide services for components in multiple layers?
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
the important physical
design considerations of
system services.
Module 11: System Services 11


Crossing Layer Boundaries
!

Multi-Service/Multi-Node Access
!
Multi-Layer/Multi-Node Access
!
Using COM+ to Implement System Services


In creating the physical design for system components, you might encounter
two types of challenges: multi-service/multi-node access and multi-layer/multi-
node access.
Multi-Service/Multi-Node Access
A system service can be used by multiple application layer services, such as the
user services layer, the facade layer, the business logic layer, the DAL, and data
services that can reside on multiple nodes. An example of such a challenge is
the physical design of the audit component. In these situations, issues arise with
respect to the location and architecture of the service. Where is the audit
component going to reside, and which services should it use to perform its task?
Multi-Layer/Multi-Node Access
To complete its task, a system service might need to access components from
multiple application layers, such as the user services layer, the facade layer, the
business logic layer, the DAL, and data services that can reside on multiple
nodes. An example of such a challenge is the physical design of the
authentication component. In these situations, issues arise with respect to the
security of the service. How is the authentication component going to access a
user service, and how is it going to access the DAL and the data services to
perform its task?
Using COM+ to Implement System Services
In general, the following approach will address most of the issues described
above.
Build the system services as COM+ components that reside in a separate

COM+ application. Since many layers that are implemented in separate COM+
applications will use the system services, you should put as few barriers as
possible between the other layers and the system services.
Topic Objective
To provide an overview of
crossing layer boundaries.
Lead-in
In this section, you will learn
the physical design issues
associated with crossing
layer boundaries.
12 Module 11: System Services


One barrier is the process boundary. If the COM+ application that houses the
system services is configured as a server application, it will not run in the same
process as the layers that use it. Therefore, you should configure the COM+
application as a library application so that it will run in the same process and
address space as the callers.
Another barrier is the threading model. If the system services are apartment
threaded, and are called by an object that uses a different apartment model
(such as neutral or free threaded), COM+ will run the system service in a
separate context from the caller, incurring additional overhead. The best model
to use for system services is the neutral threading model. This model will allow
the system service to interact with any other threading model from any other
layer without requiring a separate context.
Finally, you should configure security for the system services. Create roles for
each layer that can use the system services. Then map the identities of the
COM+ applications that represent those layers to the roles you created.
Module 11: System Services 13

Auditing
!
Storage Type
!
Storage Location
!
Component Location


The purpose of auditing is to isolate the causes for a failure, to maintain the
identity of initiators of different use cases, and to identify any object sequence
anomalies. The auditing system service will receive log requests from many
components that are members of different application layer sets.
In general, servers running Windows 2000 and Microsoft BackOffice
®
use the
operating system application log (Event Viewer) for this type of activity. An
enterprise application, however, might create too many entries to be handled
efficiently by a system application log.
Since the operating system facility cannot be used, several issues in the physical
design of auditing must be addressed: storage type, storage location, and
component location.
Storage Type
Three types of storage are possible for an audit store: XML, a Structured Query
Language (SQL) table, and a Microsoft Messaging Services queue.
In an XML implementation, the schema of the data stored in the log can vary
and can accommodate different types of components. The physical design
might allow for two XML files: one file that contains the schema definitions

and the other that contains the actual data. This design, however, would require
significant development effort.
The SQL table design is straightforward but restricts all of the logging to a
preset schema.
The Messaging Services queue design is the preferred solution because it
allows decoupling of the final storage location from an interim storage location
that is highly reliable and available. This solution can benefit from all of the
advantages of Messaging Services, such as durability, transactional queues, and
so on.
Topic Objective
To provide an overview of
the physical design for
auditing.
Lead-in
In this topic, you will learn
how to create the physical
design for auditing.
14 Module 11: System Services


Storage Location
The second issue is the location where the log will be stored. The main concern
in the location of a log is the requirement to avoid a single point of failure. If
the system fails, it is easier to isolate the causes of the failure if the log
continues to operate.
Component Location
The third issue is the location of the audit component. The audit component
should define a new transaction and should therefore be implemented as its own
COM+ application. This implementation ensures that audits are always
recorded.

Module 11: System Services 15


Authentication
!
Composite Component
!
Component Location


The purpose of authentication is to provide a system service to allow users to
identify themselves to the application.
In general, the operating system provides logon facilities that include a
graphical interface for authentication. The operating system also generally
provides facilities that interact with authentication service providers that
perform this logon functionality.
There are cases, however, in which membership is maintained by the enterprise
application. In these cases it is necessary to design a user interface, a user
service, and a data service that make up the authentication system service.
The physical design of the authentication system service is reduced to designing
a component that is a composite component of the physical design of three
other components: the user interface, the user services, and the data service.
Another issue is the location of the authentication component. You should
locate this component as close as possible to the user, which is in the user
services.
Topic Objective
To provide an overview of
the physical design of
authentication.
Lead-in

In this section, you will learn
how to create the physical
design of authentication.
16 Module 11: System Services


Application Instrumentation
CIM Object Manager
CIM Object Manager
Provider
Provider
Provider
Provider
Provider
Provider CIM Repository
CIM Repository
Database
Application
Database
Application
ODBC
ODBC
Web Browser
Web Browser
Management
Application
Management
Application
ActiveX
®

Controls
ActiveX
®
Controls


The architecture of the Windows Management Instrumentation (WMI)
technology consists of the following components: management applications,
managed objects, providers, and management infrastructure. Management
infrastructure consists of the WMI software (Winmgmt.exe) and the Common
Information Model (CIM) repository.
Management Applications
Management applications are services that process or display data from
managed objects. A management application can perform a variety of tasks,
such as measuring performance, reporting outages, and correlating data. A
typical application uses a Microsoft Management Console (MMC) snap-in that
displays the application-related management data.
Managed Objects
Physical components that are modeled with the Common Information Model
(CIM) are accessed by management applications through WMI. In a typical
application, a managed object is a system service designed to display
application-specific management data.
Providers
Providers are components that use the Component Object Model (COM)
application programming interface (API) to supply WMI with data from
managed objects, to handle requests on behalf of management applications, and
to generate notifications of events. The WMI software development kit (SDK)
supplies several standard providers, such as a registry provider, for accessing
information from the system registry. This is the typical provider used for an
enterprise application.

Topic Objective
To provide an overview of
the physical design of
application instrumentation.
Lead-in
In this section, you will learn
how to create the physical
design of application
instrumentation.
Module 11: System Services 17


Management Infrastructure
The management infrastructure consists of WMI and the CIM repository. WMI
enables users to handle communications between management applications and
providers. Users store their static data in the CIM repository.
18 Module 11: System Services


Key Considerations
!
Primary Focus
$
Usefulness
$
Usability
!
Secondary Focus
$
Scalability

$
Availability
$
Robustness


Primary Focus
The primary focus in the logical and physical designs of system services is to
look for services that enhance an application’s:
!
Usefulness.
!
Usability.

Audit, authentication, and application instrumentation are examples of how you
can enhance usefulness and usability. These were discussed earlier in this
module. A Help facility is another example of a useful service.
Secondary Focus
The secondary issues that concern system services are services that:
!
Enhance the scalability of an application.
!
Promote high availability.
!
Promote robustness.

Topic Objective
To provide the key
considerations for the logical
and physical designs of

system services.
Lead-in
In this topic, you will learn
about the key
considerations in the logical
and physical designs of
system services.
Module 11: System Services 19


#
##
# Market Purchasing
!
Market Purchasing Logical Design
!
Market Purchasing Physical Design


In this section, you will learn how the logical and physical design guidelines
were applied to the system services of Market Purchasing.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
how the logical and physical
designs were applied to the
Market Purchasing system

services.