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

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.. The other architecture layers

Contents

Overview 1

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

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

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 MicrosoftWindows® 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

! 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

# 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

In this module, you will learn

about the system services

layer and how to create a

logical design and a

physical design for it

# 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

In this section, you will learn

what makes up a system

services layer

The Business Problem

DAL

Connected Business Logic Layer

Disconnected Business Logic Layer

Facade Layer

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

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

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

# 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

In this section, you will learn

about the important logical

design considerations of

system services

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

The Authentication Design Pattern

+Login() +CheckAccess()

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

In this section, you will learn

about the Authentication

design pattern

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

# Physical Design of System Services

! Crossing Layer Boundaries

In this section, you will learn

the important physical

design considerations of

system services

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