Tài liệu Module 12: Summary docx

Module 12: Summary Contents Overview Design Patterns and Design Tools in Logical Design Technology Usage in Physical Design Best Practices 13 Design Validation 14 Future Enhancements to Market Purchasing 17 Review 18 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 12: Summary Instructor Notes Presentation: 60 Minutes This module provides students with a summary of the important logical and physical design considerations for each of the layers in the Enterprise template Lab: 00 Minutes After completing this module, students will be able to: ! Summarize the logical design considerations for each of the layers of the Enterprise template and in particular the use of design patterns ! Summarize the physical design considerations for each of the layers of the Enterprise template and in particular the use of technology ! Review the key technologies that impact multiple layers ! Summarize the best practices for each of the layers of the Enterprise template ! Discuss future enhancements for Market Purchasing 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_12.ppt ! Module 12: Summary Preparation Tasks To prepare for this module, you should: ! Read all of the materials for this module iii iv Module 12: Summary Module Strategy Use the following strategy to present this module: ! Design Patterns and Design Tools in Logical Design The purpose of this section is to summarize the use of design patterns in the logical design of the various layers of the architecture template The review is done by design pattern category In the topic “Creational,” note that there are no design patterns that are useful In the topic “Structural,” note that there are three design patterns—Facade, Composite, and Adapter—that are useful In the topic “Behavioral,” note that there are three design patterns— Observer, Iterator, and State—that are useful In the topic “Other Patterns,” note that there are two design patterns— Authenticate and Queue—that are useful Also note that there are two modeling techniques that are useful: metaphor and entity relationship diagram (ERD) ! Technology Usage in Physical Design The purpose of this section is to summarize the use of technology in the three main functions of an application: external interactions, business logic, and state management For each technology, a summary of its advantages and disadvantages is presented In addition, this section reviews two technologies that are common to the physical design of all components: security and error handling In the topic “External Interactions,” note that there are six technologies reviewed: thin client, rich client, Message Queuing, Extensible Markup Language (XML), distributed Component Object Model (DCOM), and Simple Object Access Protocol (SOAP) In the topic “Business Logic,” note that there is only one technology under consideration: COM+ In the topic “Data Store,” note that there are only two technologies under consideration: Microsoft SQL Server™ and Active Directory™ ! Best Practices The purpose of this section is to summarize the best practices for the logical and physical designs of an application according to the various layers of the Enterprise template ! Design Validation The purpose of this section is to summarize the validation mechanisms for logical and physical designs ! Future Enhancements to Market Purchasing The purpose of this section is to emphasize that a good design must be easily extensible and that the concept of extensibility can be tested by the introduction of future enhancements to an application Module 12: Summary # Overview Topic Objective To provide an overview of the module topics and objectives ! ! Best Practices ! Design Validation ! In this module, you will review a summary of the material presented in this course Technology Usage in Physical Design ! Lead-in Design Patterns and Design Tools in Logical Design Future Enhancements to Market Purchasing This module presents a summary of the Enterprise template and highlights the important logical and physical design considerations for each of the layers in the Enterprise template After completing this module, you will be able to: ! Summarize the logical design considerations for each one of the layers of the Enterprise template and in particular the use of design patterns ! Summarize the physical design considerations for each one of the layers of the Enterprise template and in particular the use of technology ! Review the key technologies that affect multiple layers ! Summarize the best practices for each of the layers of the Enterprise template ! Discuss future enhancements for Market Purchasing Module 12: Summary # Design Patterns and Design Tools in Logical Design Topic Objective To provide an overview of the section topics and objectives Lead-in In this section, you will review the use of design patterns in the logical design of an application ! Creational ! Structural ! Behavioral ! Other Patterns The following review discusses how design patterns are used in architecture templates, and in particular how patterns are used to design objects for the various layers in these templates The review is categorized by design pattern type Module 12: Summary Creational Topic Objective To provide a summary of the use of creational design patterns Lead-in In this topic, you will see a summary of the use of creational design patterns in the logical designs of various architecture template layers Layer Design Pattern User Services None Facade None Business Logic None Data Access Layer None Data Services None System Services None The creational design patterns that are proposed by the book Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, which include Abstract Factory, Builder, Factory Method, Prototype, and Singleton, were reviewed for their application to the various Enterprise template layers The conclusion drawn was that none of these design patterns are necessary because the functionality that the design patterns provide is available through either the operating system or component services The only design pattern that posed an issue is the Singleton A Singleton ensures that a class has only one instance and provides a global point of access to it After careful consideration, the use of Singleton was rejected on the basis that it was conceptually wrong to create a logical design that would restrict concurrency 4 Module 12: Summary Structural Topic Objective To provide a summary of the use of structural design patterns Lead-in In this topic, you will see a summary of the use of structural design patterns in the logical designs of various architecture template layers Layer Design Pattern User Services None Facade Facade Business Logic Composite Data Access Layer Composite Adapter Data Services None System Services None There are eight structural design patterns in the Design Patterns book: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, and Proxy Three have proven to be useful in the logical design: Adapter, Composite, and Facade Unsurprisingly, the Facade pattern is the cornerstone for the Facade layer As discussed in detail in Module 5, “The Facade Layer,” the Facade pattern provides for a common secure interface to the internals of an application This interface allows user services to become impervious to changes in the internal structure of applications The Composite structural pattern is useful when an object such as a requisition can contain several objects, such as line item details Composite patterns are useful in the business logic layer and in the data access layer (DAL) Finally, the Adapter structural design pattern is useful in the logical design of DAL objects that need to create uniform access to different types of data Each DAL component translates the underlying data store into a format suitable for use in the rest of the system Module 12: Summary Behavioral Topic Objective To provide a summary of the use of behavioral design patterns Lead-in In this topic, you will see a summary of the use of behavioral design patterns in the logical designs of various architecture template layers Layer Design Pattern User Services None Facade None Business Logic Observer Iterator State Data Access Layer Iterator Data Services None System Services None There are eleven behavioral design patterns in the Design Patterns book: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, and Visitor Three have proven to be useful in the logical design: Iterator, Observer, and State The Iterator behavioral design pattern is useful when there is a need to browse through a collection of objects In general, following the lead of Sten and Per Sundblad in Scalable Visual Basic and MTS Applications, it is useful to modify the definitions of the patterns from the Design Patterns book and combine the functionality of the List class with that of the ListIterator class The Iterator design pattern is useful in the business logic layer and in the DAL The Observer behavioral pattern that manages the changes of state is very useful in the logical design of the business logic layer For example, it can be used where there are many instances when there is a one-to-many dependency between objects such that when one object changes its state, all its dependents are notified or updated automatically Finally, the State behavioral design pattern that also manages the changes of state is very useful in the logical design of the business logic layer, where there are many instances when the object behavior must change when its state changes Module 12: Summary Other Patterns Topic Objective To provide a summary of the use of new behavioral design patterns Lead-in In this topic, you will see a summary of the use of new behavioral design patterns in the logical designs of various architecture template layers Layer Design Pattern User Services Metaphor Facade None Business Logic Queue Data Access Layer None Data Services ERD System Services Authenticate In this course, the work from the Design Patterns book was extended to include two new behavioral design patterns: Queue, and Authenticate The Queue behavioral design pattern describes a frequent occurrence in enterprise applications: a many-to-many relationship between objects that cannot interact directly because of both spatial and temporal limitations This phenomenon typically occurs in the logical design of business logic that uses logic from one application in a second application The Authentication design pattern is usually implemented in the system services, and it 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 The user services can use many of the behavioral design patterns However, the most important part of user services is identifying a metaphor The metaphor is the underlying model for representing the interaction between a user and the information system that is supporting the user in the particular system The data services not have any design patterns useful for logical design The most appropriate tool to use is entity relationship diagrams (ERD) Module 12: Summary # Technology Usage in Physical Design Topic Objective To provide an overview of the section topics and objectives Lead-in In this section, you will review the important technology considerations in the physical design of enterprise applications ! External Interactions ! Business Logic ! State Management ! Security ! Error Handling This review of how technology is used in the physical design of the components that make up an enterprise application is categorized by the three important tasks of any application: external interactions, some business logic, and a mechanism for state management The external interactions are the part of an application that permits collaboration with users and other applications The business logic is the part of the application that is intelligent; it is capable of making decisions based on pre-defined rules Finally, state management is the mechanism that serves as an application’s memory This memory could be short-term or long-term, depending on the design This review looks at the technology according to these criteria rather than according to the Enterprise template layers, since the Enterprise template layers is only one approach for logical design of an application, while technology application to physical design can be used for any logical design For each category, the relevant technologies will be presented A brief summary of the advantages and disadvantages for each technology’s adoption in the physical design will also be presented In addition, this section includes a review of two technologies that are used in all layers of the Enterprise template: security and error handling These technologies apply to the physical designs of all components in an enterprise application 8 Module 12: Summary External Interactions Topic Objective Technology Advantage Disadvantage To provide a summary of the use of external interaction technologies Thin client $Any platform, any browser Poor use of client and network resources Lead-in Rich client $High use of resources Platform specific Message Queuing $Available on many platforms Compensating transactions XML $Can be used in all layers of the Enterprise template Standards are still emerging DCOM $Scalability Configuration management SOAP $Universality Unproven In this topic, you will see a summary of the use of external interaction technologies in the physical designs of components that make up an enterprise solution At present, there are six technologies that can be used to facilitate the cooperation between an application and its users and an application and its counterpart applications In the realm of interacting with outside applications and users, there are currently two groups of technologies, which have been labeled thin client and rich client You would choose a thin client for universality and a rich client for performance In the area of component interoperability, four technologies are proposed, three of which are in current use (Message Queuing, XML, and DCOM) and one that looks very promising: Simple Object Access Protocol (SOAP) Of those in current use, both Message Queuing and Distributed Component Object Model (DCOM) are well understood, but there are administration issues to consider The administration tasks include setting up queues, defining queue attributes, and configuring the components to use other components running on other nodes New Microsoft® back-end servers such as AppCenter server might reduce the administrative burden Extensible Markup Language (XML), while relatively new, holds excellent promise as a medium for the exchange of data A new Microsoft server, Microsoft BizTalk™, might facilitate the adoption of XML as a data exchange standard While SOAP has been covered in detail, it was not used in the Market Purchasing application It is still an unproven technology Module 12: Summary Business Logic Topic Objective To provide a summary of the use of business logic technologies Lead-in In this topic, you will see a summary of the use of business logic technologies in the physical designs of components that make up an enterprise solution Technology COM+ Advantage $Uniform application infrastructure and architecture Disadvantage Difficult to implement $Rapid application development $Easy to troubleshoot and maintain $Easy to build extensible applications Business logic resides in components Microsoft Windows® 2000 offers a component technology, COM+, that can embed the intelligence that an application is designed to have COM+ simplifies the burden of developing components by providing the facilities for many of the features that each component would have to take care of individually through services that are part of the operating system: component services In particular, services such as transaction, security, event handling, and queuing are all part of the contribution that COM+ offers to make application development easier The preceding slide lists four of the important factors in choosing COM+ as a component technology for developing applications: uniform application infrastructure and architecture, rapid application development, ease of troubleshooting and maintenance, and ease of building extensible applications One issue to be aware of when using COM+ is that it requires a complex programming model Often, knowledge of Interface Definition Language (IDL) is required to design and use interfaces Also, threading models can be difficult to implement properly Fortunately, languages with built-in COM+ support, such as Microsoft Visual Basic® and Microsoft Visual C++®, use smart pointers to help simplify the programming model However, an advanced understanding of COM+ is usually required to understand and implement it properly 10 Module 12: Summary State Management Topic Objective To provide a summary of the use of state management technologies Lead-in In this topic, you will see a summary of the use of state management technologies in the physical designs of components that make up an enterprise solution Technology Database Active Directory Advantage $Efficient in highvolume, highvolatility many-tomany relationships $Efficient in hierarchical, lowmaintenance data Disadvantage Indexing Immature modeling and data definition In this course, two state management technologies for storing durable data were covered in detail: database and directory services In addition, data can be stored by using technologies such as online analytical processing (OLAP) data stores and Microsoft Exchange folders OLAP data stores are used for decision support systems that require data warehousing and data mining capabilities Exchange folders are used for workflow applications that require a particular sequence that each item in the system must follow as it interacts with external users or applications Additional technologies are being introduced with Exchange 2000 that include Web folders, but at this time this technology has not yet been released In general, database as a storage mechanism should be chosen for data structures that are volatile and have pervasive relationships Data with many-tomany relationships is also better stored in a relational database For example, a table of groups has a many-to-many relationship with a table of employees One employee can belong to many groups, and one group can contain many employees Representing this type of relationship hierarchically would repeat instances of one entity under the other For example, if Sam belonged to the Programming group and the Consultant group, his name would appear twice in the hierarchy But he would only have one entry in an employee table Active Directory™ would be the preferred storage choice for data sets that are hierarchical and non-volatile This does not imply that hierarchical data sets cannot be stored in databases In the future, Microsoft SQL Server™ 2000 will provide mechanisms for the storage and retrieval of XML data structures that are hierarchical In addition, Biztalk Server will use SQL Server as a storage device for storing data that is exchanged between applications and that uses XML schemas Module 12: Summary 11 Security Topic Objective To provide a summary of the use of security Lead-in In this topic, you will see a summary of the use of security in the physical designs of components that make up an enterprise solution External source Authentication Declarative permissions Web user $ $ Selective user Other apps $ $ Procedural permissions $ Security is pervasive, yet it is very likely that security holes can be found in any physical design How is this contradiction possible? The lack of a cohesive security plan is the main cause of security holes A security plan begins by identifying the external sources for interactions with the application These sources can typically fall into one of three categories: Web users, selective users, and other applications For each of these categories, a definition of how it is going to be authenticated and what permissions are going to be assigned must be designed to reflect the type of activities each role is allowed to conduct within the application These permissions must be translated to security values that are defined for each COM+ application In the preceding slide, the boxes without check marks reflect holes in the security plan For example, according to the diagram in the slide, other applications are not authenticated and are not restricted in the actions that can be performed Therefore, someone could use another application to bypass security In this course, the implementation of security was covered in detail: authentication, component security, declarative, procedural, and so on For security to be complete, however, a cohesive plan must be included While authentication provides a barrier to entry, it is the assignment of permissions through roles that really restricts what external sources can within the system Typically, the restrictions are declarative, but in some cases when a component can be used by multiple external sources but with restrictions on the functionality that each external source can perform, procedural or programmatic security might be needed In this context, procedural security is a refinement over declarative security 12 Module 12: Summary Error Handling Topic Objective To provide a summary of the use of error handling Lead-in In this topic, you will see a summary of the use of error handling in the physical designs of components that make up an enterprise solution Error source Centralized System services $ Component services $ Components Local $ Errors can occur anywhere and everywhere: in the operating system, in the servers (SQL Server), in the services (directory, component), and in the components themselves In some cases, improperly handled errors are reported to users in a non-user friendly format without any remedial action In more severe cases, errors are ignored and corrupt the activities of an application or, even worse, corrupt the persistent data As in the case of security, an error-handling plan must be included in the physical design of application components The error-handling plan should categorize errors according to their source and propose where and how they should be trapped and handled In the preceding slide is a depiction of an error-handling matrix This matrix is an over-simplification of the real matrix that needs to be prepared The real matrix must include on the y-axis all possible errors under each category For example, error 1205 in SQL Server notifies that a transaction was the victim of a deadlock condition and that the transaction was rolled back Very few users know what a deadlock is and what it means to be a victim of one, so there is a need to provide the proper handling of an error in the appropriate component Module 5, “The Facade Layer,” discusses how to create robust COM+ components, but, as is pointed out in the module, the discussion should not be limited just to facade layer components All components, including user services, facade, business logic, DALs, data services, and system services, require error handling In order to avoid duplicate handling on the one hand and gaps on the other, an error plan should provide details about which errors are handled through a centralized error-handling capability and which errors are handled locally If the errors are handled locally, the plan should say which component is handling them In general, centralized error handling should be designed for generic errors, and localized error handling should be designed for specific errors The specific error handling should be designed in the components closest to the source Module 12: Summary 13 Best Practices Logical Topic Objective To provide a summary of best practices Lead-in In this topic, you will see a summary of the best practices of physical design, as gleaned from the contents of all of the modules for all layers in an enterprise solution Physical User services Metaphor Rich client Facade Decoupling user services from business logic Incorporate Queue in design Security and robustness Separate nontransactional from transactional Data model ADO with cursors Schema Incorporate Audit in design instrumentation Active Directory Incorporate authentication and auditing Business logic Data access layer Data services System services Use as much of COM+ as possible SQL Server It is hard to summarize a whole course in one slide, but the preceding slide is an attempt to so The slide shows, for each layer in an Enterprise template, the most important point for the logical design of that layer and the most important point for the physical design of that layer For example, in data services, the important logical design activity is a data model, while the important physical design issue is whether to use a relational database for persistent storage or a hierarchical directory Some clarifications might be needed, such as why the use of a Queue design pattern is so important in the logical design of business logic The answer is that, as applications become more modularized and decentralized, it is going to be important to have a universal mechanism for collaboration between components 14 Module 12: Summary # Design Validation Topic Objective To provide an overview of the section topics and objectives Lead-in ! Logical Design ! Physical Design In this section, you will review how to perform logical and physical design validation for an enterprise application While the previous sections provided summaries of material that was already covered in the modules of this course, this section provides insight into a topic that has not been discussed before: design validation How we know that a design is correct and complete? Since application design is still an art rather than a science, we never really know There are, however, validation techniques that can provide some confidence that the design is actually meeting the needs of the use cases While a detailed discussion of this topic is beyond the scope of this course, some ideas about good validation practices for logical and physical designs will be presented Module 12: Summary 15 Logical Design Topic Objective To provide a summary of logical design validation Lead-in In this topic, you will see a summary of logical design validation for an enterprise solution ! Out-in Design % ! Use case validation Reviewing Pattern Usage User services Facades Business logic Data access layer Data services Logical design validation can use two techniques to ensure that the proposed design is an effective and efficient representation of the use cases Out-in Design Using out-in design, you begin with each use case and trace its implementation through all the objects that are part of different layers in the design This is a tedious task, and one that must be undertaken for each of the critical use cases, if not for all use cases For example, the Create Requisition use case should be traced starting with the user services object, through the Web facade object, through the connected business logic object, through the transactional DAL object, and culminating in the data services object Reviewing Pattern Usage Reviewing pattern usage ensures that an efficient logical design has been derived The idea behind using design patterns is to identify common features and create commonality in the design By identifying the degree to which design patterns have been used, it is possible to verify how good the proposed logical design is It is a common maxim that applications are 80 percent the same This should be reflected in the design 16 Module 12: Summary Physical Design Topic Objective To provide a summary of physical design validation Lead-in In this topic, you will see a summary of physical design validation for an enterprise solution ! In-out Physical Design % % ! COM+ applications COM+ components Reviewing Technology Usage User services Facades Business logic Data access layer Data services Physical design validation, like logical design validation, can use two techniques to ensure that the proposed design is an effective and efficient representation of the use cases In-out Physical Design Using in-out physical design, you begin with each component in the data services and trace its implementation through all components that are part of different layers in the design This is a tedious task, however, because as you trace outward from the data services, the number of callers will grow and you will trace a large part of the system It is not necessary to perform this task for every use case, but it should be performed for the critical use cases For example, the requisition table should be traced starting with the data services component, through the DAL components (both transactional and nontransactional), through the connected business logic component, through the Web facade component, and culminating in a Hypertext Markup Language (HTML) page (rich client) that uses it Reviewing Technology Usage Reviewing technology usage ensures that an efficient physical design has been derived The idea behind mapping the technology that has been used for each component is to ensure that the proper technological choices have been made and that the technologies that have been chosen can work together to provide the desired outcome Module 12: Summary 17 Future Enhancements to Market Purchasing Topic Objective To provide an overview of future enhancements Lead-in In this topic, you will see an overview of potential enhancements to the Market Purchasing application Request Return * * * * * * Requestor * RMI Processing Vendor * In Module 1, “Designing Distributed Applications for Windows 2000,” the presentation about the Microsoft Solutions Framework (MSF) delineated the difference between the vision of a solution (long term) and the scope (near-term deliverable) and discussed the importance of versioned releases to an efficient and effective delivery of a solution Market Purchasing is no exception Version 1.0 delivers functionality, which is rated as very high in importance to the customers and users of the application We can, however, speculate about what functionality and use cases might be of extreme importance and should be added in version 2.0 For example, the return of goods that not meet expectations might be such a feature This feature is depicted in two use cases presented in the preceding slide The first use case is from the requestor to the vendor It notifies the vendor of an intent to return specific goods and requests a Return Material Authorization (RMA) The second use case is from the vendor to the requestor and provides the requestor with an RMA This is by no means the only extension to Market Purchasing that could be contemplated Other extensions could include batch requisitions to vendors that create larger, more economic orders, the creation of requisitions that would have multi-period delivery, and so on 18 Module 12: Summary Review Topic Objective To reinforce module objectives by reviewing key points Lead-in The review questions cover some of the key concepts taught in the module ! Summarize the logical design considerations for each of the layers of the Enterprise template and in particular the use of design patterns ! Summarize the physical design considerations for each of the layers of the Enterprise template and in particular the use of technology ! Review the key technologies that impact multiple layers ! Summarize the best practices for each of the layers of the Enterprise template ! Discuss future enhancements for Market Purchasing What are the new behavioral design patterns and in which layers can they be used? Queue—business logic Authentication—system services What are the two physical design technologies that are pervasive? What they have in common? Security Error handling A plan is required What are the two techniques that you can use to validate logical design? Out-in design Reviewing pattern usage What are the two techniques that you can use to validate physical design? In-out physical design Reviewing technology usage ... this module Required Materials To teach this module, you need the following materials: ! Microsoft® PowerPoint® file 1910A_12.ppt ! Module 12: Summary Preparation Tasks To prepare for this module, ... you should: ! Read all of the materials for this module iii iv Module 12: Summary Module Strategy Use the following strategy to present this module: ! Design Patterns and Design Tools in Logical... application Module 12: Summary # Overview Topic Objective To provide an overview of the module topics and objectives ! ! Best Practices ! Design Validation ! In this module, you will review a summary