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

Module 11: System Services Contents Overview Introduction to System Services Logical Design of System Services Physical Design of System Services 10 Market Purchasing 19 Best Practices 22 Lab 11: System Services 23 Review 27 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 Presentation: 75 Minutes Lab: 30 Minutes 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 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 ! 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 v THISPAGE INTENTIONALLY LEFT BLANK Module 11: System Services # Overview Topic Objective To provide an overview of the module topics and objectives ! Introduction to System Services Lead-in ! Logical Design of System Services ! Physical Design of System Services ! Market Purchasing ! Best Practices In this module, you will learn about the system services layer and how to create a logical design and a physical design for it 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 Module 11: System Services # Introduction to System Services Topic Objective To provide an overview of the section topics and objectives ! The Business Problem Lead-in ! Business Requirements In this section, you will learn what makes up a system services layer 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 Module 11: System Services The Business Problem Topic Objective To provide background about the business problem User Services 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 Facade Layer Web Services Facade Business Facade Disconnected Business Logic Layer System Services Connected Business Logic Layer DAL Transactional DAL Nontransactional DAL 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 Module 11: System Services Business Requirements 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 ! 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 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 Topic Objective To provide an overview of the physical design of authentication ! Composite Component Lead-in ! Component Location In this section, you will learn how to create the physical design of authentication 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 16 Module 11: System Services Application Instrumentation Topic Objective To provide an overview of the physical design of application instrumentation Database Database Application Application Web Browser Web Browser ODBC ODBC ActiveX® ActiveX® Controls Controls Lead-in In this section, you will learn how to create the physical design of application instrumentation Management Management Application Application CIM Object Manager CIM Object Manager CIM Repository CIM Repository Provider Provider Provider Provider Provider Provider 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 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 Topic Objective To provide the key considerations for the logical and physical designs of system services ! Primary Focus $ In this topic, you will learn about the key considerations in the logical and physical designs of system services ! Usefulness $ Lead-in 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 Module 11: System Services # Market Purchasing Topic Objective To provide an overview of the section topics and objectives ! Market Purchasing Logical Design Lead-in ! Market Purchasing Physical Design In this section, you will learn how the logical and physical designs were applied to the Market Purchasing system services In this section, you will learn how the logical and physical design guidelines were applied to the system services of Market Purchasing 19 20 Module 11: System Services Market Purchasing Logical Design Topic Objective To provide an overview of logical design for the Market Purchasing system services ! A log system service handles the logging of component errors ! The log service is a type of auditing service Lead-in In this slide, you will learn how the logical design for the Market Purchasing system services was implemented Logging errors is a system service for Market Purchasing because it must be available to all components in any layer at any time The log service is synchronized to prevent concurrent access to the log file The log service is a type of auditing service Module 11: System Services 21 Market Purchasing Physical Design Topic Objective To provide an overview of the physical design for the Market Purchasing system services Market Purchasing System Services COM+ Application Lead-in In this slide, you will learn how the physical design for the Market Purchasing system services was implemented mpsys.Log Log The physical design of system services for Market Purchasing, as shown in the preceding slide, incorporates several principles: ! The log service is implemented in a single COM+ dynamic-link library (DLL) called mpsys.Log that is registered in a single COM+ application called Market Purchasing System Services ! The mpsys.Log maintains a log file and records information to the log file when called by components The name of the file is passed to the component by means of the constructor string Therefore, the administrator can declaratively change the file name and the location of the log 22 Module 11: System Services Best Practices Topic Objective To provide a discussion of the best practices for the logical and physical designs of system services ! ! In this slide, you will learn the three best practices for the design of system services Provide each Web-based application with an extensible authentication mechanism ! Lead-in Use an audit system service in your logical design Instrument applications so that they can be uniformly managed There are three important best practices that emerge pertaining to the logical and physical designs of system services: ! Use an audit system service in your logical design Applications need a trace capability, and auditing provides this capability ! Provide each Web-based application with an extensible authentication mechanism Web-user management that goes beyond management of domain users requires a special capability for authentication ! Instrument applications so that they can be uniformly managed Reducing the cost of application management is an important consideration in application development Instrumentation can help make applications easier to manage Module 11: System Services Lab 11: System Services Topic Objective To introduce the lab Lead-in In this lab, you will you will design a logging system service Explain the lab objectives Objectives After completing this lab, you will be able to: ! Implement logical and physical designs for system services ! Identify appropriate technology to use for a log service Prerequisites Before working on this lab, you must: ! Complete Module 11, “System Services.” ! Complete Lab 10, “Data Services.” Note The solution for this lab is in the install folder\Labs\Lab11\Solution folder Estimated time to complete this lab: 30 minutes 23 24 Module 11: System Services Exercise Implementing System Services for Logging In this exercise, you will design a logging system service In every use case, it is necessary to log activity that was performed in the use case for audit purposes In the case of Market Purchasing, logging is used whenever an error occurs Information about the error, such as the component that is the source of the error and the method that detected the error, is logged to a file This service must be available to all components ! Design a logical class • Design a logical class that will log to a data file an error reported by a component Only one class can write to the file at a time Identify the behavioral design pattern that can be used in this class The class should include the necessary method to write to a file Students will discuss their answers in Exercise 2, in the procedure “Examine the Market Purchasing solution,” step Module 11: System Services 25 Exercise Updating the Logical and Physical Designs In this exercise, you will examine the solution for the logging system service You will also update the logical and physical designs of Market Purchasing to reflect the solution ! Examine the Market Purchasing solution Examine the following solution to the System Audit use case: sys_Log Behavioral Patterns None Methods WriteToLog What differences, if any, are there between your answer and this solution? Discuss the differences with others or with your instructor ! Modify the Market Purchasing logical design Click Start, point to Programs, and then click Microsoft Visio On the File menu, click Open, and then open the Market Purchasing.vsd file This file is in the install folder\Labs\Lab11\Start folder In the right pane, click the LD – System Services tab Add the sys_Log class and its method Save the design ! Derive the physical design Which COM+ classes and applications should implement the sys_Log class? Market Purchasing implements the sys_Log class in a COM+ class called mpsys.Log This class is registered in a COM+ application called Market Purchasing System Services 26 Module 11: System Services How should the COM+ classes be configured? They should be configured to not use transactions or to require a new transaction This is because the sys_Log class should not be involved in the calling component’s transaction, otherwise the log will be rolled back when the component aborts the transaction Which threading model should the COM+ classes use? Ideally, the log component should use the neutral threading model so that it can run with any client component threading model without marshalling overhead The Market Purchasing log component is written in Microsoft Visual Basic® 6.0, so it does not support neutral threading Should the COM+ application in which the log class is registered run as a server application or a library application? In general, system services should run as library applications so that they run more efficiently with multiple clients in multiple processes However, the log component logs errors It might not be a good idea to run it in a client’s process in which an error recently occurred Also, it should not be called so often that performance suffers Therefore, the Market Purchasing system services application is configured as a server application ! Modify the Market Purchasing physical design In the right pane, click the PD – System Services tab Add the COM+ application or applications that you derived to implement system services to the physical design Add the component or components that you derived to implement the sys_Log class to the physical design Save the design Module 11: System Services Review Topic Objective To reinforce module objectives by reviewing key points ! Describe the logical design of a system services layer Lead-in ! 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 The review questions cover some of the key concepts taught in the module What are the primary services of system services? Authentication Audit Application instrumentation What design pattern can be used for system services? Authentication What are the two challenges of crossing layer boundaries? Multi-service/multi-node access Multi-layer/multi-node access What other types of functionality would you add for system services? Help Common configuration information Backup and restore Stop process (used in preparation for shutting down a computer) Recover from hardware or software failures 27 THIS PAGE INTENTIONALLY LEFT BLANK ... Stewart Module 11: System Services iii Instructor Notes Presentation: 75 Minutes Lab: 30 Minutes This module provides students with an introduction to system services This module focuses on the system. .. 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... BLANK Module 11: System Services # Overview Topic Objective To provide an overview of the module topics and objectives ! Introduction to System Services Lead-in ! Logical Design of System Services