Module 5: The Facade Layer

Contents Overview 1 Introduction to the Facade Layer 2 Technologies 6 Demonstration: Declarative Security 13 Logical Design of the Facade Layer 23 Physical Design of the Facade Laye

Contents

Overview 1

Introduction to the Facade Layer 2

Technologies 6

Demonstration: Declarative Security 13

Logical Design of the Facade Layer 23

Physical Design of the Facade Layer 26

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, 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 the facade layer The facade layer provides a unified interface to a set of interfaces in the business logic layer and the data access layer (DAL) This module presents the two types

of facade layers: the Web services facade layer and the business facade layer After completing this module, students will be able to:

! Describe the differences between the two types of facade layers: the Web services facade layer and the business facade layer

! Describe the role of the facade layers and how to apply design patterns

! Describe the techniques for securing a facade layer

! Describe the design of robust COM+ components

! Create the logical and physical designs for facade layers

! Describe the logical and physical designs for the Market Purchasing facade layer

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_05.ppt

! Module 5: The Facade Layer

! Lab 5: The Facade Layer

Preparation Tasks

To prepare for this module, you should:

! Read all of the materials for this module

! Complete the lab

Presentation:

75 Minutes

Lab:

60 Minutes

Module Strategy

Use the following strategy to present this module:

! Introduction to the Facade Layer The purpose of this section is to introduce students to the facade layer The facade layer provides a unified interface to a set of interfaces in the business logic layer and the DAL This module presents the two types of facade layers: the Web services facade layer and the business facade layer

In the topic “The Business Problem,” emphasize that the key functions of a facade layer are to act as a logical buffer between user services and the underlying application architecture (business logic and DAL), to act as a security buffer for the underlying application components, and to maintain the robustness of the application

Students might have questions about how the Web services facade relates to Web services It is important not to confuse the Web services facade with Web services The Web services facade simplifies an interface for accessing business logic in the system It does not, by itself, expose functionality and features over the Internet (which is what Web services does) For more information about Web services and NET, go to

http://www.microsoft.com/net/

! Technologies The purpose of this section is to introduce students to two issues that are important for the facade: security and robustness

This is primarily a review of security For further information about COM+ security, refer to Module 8, “Making Applications Secure,” in Course

1907A: Building Distributed Applications for Microsoft Windows 2000 with

Visual Basic

Robustness is discussed in detail The topics in this section describe techniques for handling errors in COM+ applications, features in COM+ that affect failure behavior, and suggestions for diagnosing COM+ errors The topic “Strategies for Handling Errors in COM+” lists and describes basic guidelines for handling errors in COM+, including when to use

HRESULTs and ErrorInfo objects

The topic “How COM+ Modifies Return Values” identifies the single condition under which COM+ converts a standard HRESULT to a COM+ error code before passing it back to the caller

The topic “Fault Isolation and Failfast Policy” presents how fault isolation and failfast policy affect COM+ behavior

The topic “Finding the Source of an Error” describes how you can diagnose the source of an application error and obtain a description of the error by using a combination of Microsoft Windows® 2000, COM+, and other tools The topic “Interpreting Error Codes” identifies the predominant error-handling mechanism for C++ and Microsoft Visual Basic®

! Logical Design of the Facade Layer The purpose of this section is to introduce students to the logical design considerations that apply to a Web services facade layer and to a business facade layer

! Physical Design of the Facade Layer The purpose of this section is to introduce students to the physical design considerations that apply to a Web services facade layer and to a business facade layer

Securing a distributed application is a primary function of the facade layer

It involves protecting the software and application content from unauthorized use yet making it available to authorized users

The most problematic part of writing components is incorporating robustness to handle possible errors Trying to determine what can go wrong and how to address these errors can be challenging under the best

conditions The facade layer is where error handling becomes an issue An error that originates in the database bubbles up through the DAL and business logic layer to the facade layer The facade layer is responsible for converting errors into a readable format that the user services can handle

! Market Purchasing The purpose of this section is to discuss the logical and physical designs of Market Purchasing and to explain the justification for the choices made The logical design of facade classes is based on the user services The physical design implements security and robustness

You can present the implementation of the Market Purchasing facade layer

by running Component Services and presenting the Market Purchasing Web Facade COM+ application and the Market Purchasing Business Facade COM+ application

To show how the facade separates user services from business logic, you

can present the source code for the CreateRequisition method in

mpfcdweb.Requisition When user services creates a requisition, it does not actually have all of the information from the user yet It first creates a default requisition and displays default values Then the user can change

those values and save or submit the requisition The CreateRequisition

method coordinates this by retrieving the default values by using the

nontransactional DAL and returning the values through out parameters

This is an example of functionality you would not want to place in business logic Also, you probably should not implement it in user services because this implementation would make user services more complicated

! Best Practices The main message in the best practices for a logical design is that a facade is needed The main message for the physical design is that an application requires security and error handling plans

Lab Strategy

! Lab 5: The Facade Layer The purpose of Lab 5 is for students to learn to design a facade layer Students probably will not derive answers that correspond exactly to the design of Market Purchasing This is acceptable as long as the student answers are justified and reflect the principles discussed in the module Discuss with students their answers to Lab 5

# Overview

! Introduction to the Facade Layer

! Technologies

! Logical Design of the Facade Layer

! Physical Design of the Facade Layer

! Market Purchasing

! Best Practices

This module will introduce the facade layer The facade layer provides a unified interface to a set of interfaces in the business logic layer and the data access layer (DAL) This module presents the two types of facade layers: the Web services facade layer and the business facade layer

After completing this module, you will be able to:

! Describe the differences between the two types of facade layers: the Web services facade layer and the business facade layer

! Describe the role of the facade layers and how to apply design patterns when designing facade layers

! Describe the techniques for securing a facade layer

! Describe the design of robust COM+ components

! Create the logical and physical designs for facade layers

! Describe the logical and physical designs for the Market Purchasing facade layer

In this module, you will learn

about the facade layer,

which consists of the Web

services facade and the

business facade, and about

how to create a logical

design and a physical

design for a facade layer

# Introduction to the Facade Layer

! The Business Problem

! Business Requirements

A facade layer provides a unified interface to a set of interfaces in the business logic layer In this section, the two types of facade layers are presented: the Web services facade layer and the business facade layer The distinction is made primarily because of the two different kinds of functionality that can be exposed

In this section, the facade layer will be placed in the proper context of the business problem After this discussion, you will learn about the business services interface, and specifically about the differences between a Web services facade and a business facade Finally, you will learn about the logical and physical designs of a facade layer The focus of this final topic will be on both design patterns and technology

In this section, you will learn

about the business problem

facing designers who need

to implement user services

and about the business

requirements for a facade

The Business Problem

DAL

Disconnected Business Logic Layer

Connected Business Logic Layer

Facade Layer Web Services Facade Business Facade

Transactional DAL Nontransactional DAL

User Services

Maintaining business rules and persisting data is a complex undertaking Many logical business objects and physical components are needed to facilitate these activities Without a facade layer, user services would need to interact with the business logic layer and the DAL The facade layer was introduced so that user services would not need to handle this complexity, and to provide a uniform layer for handling security and robustness issues

The key functions of a facade layer are to:

! Act as a logical buffer between user services and the underlying application architecture (business logic layer and DAL)

! Act as a security buffer for the underlying application components

! Maintain the robustness of an application

Topic Objective

To provide background

about the business problem

Lead-in

In this topic, you will learn

about the business problem

facing designers who need

to implement facade layers

Business Requirements

Facade Layer

Web Services Facade Business Facade

Public Web Pages

Internal Functionality

A facade layer represents a unified interface for the business logic components User services communicate with the business logic and DAL services by sending requests to the facade layer Although the business logic or DAL service objects perform the actual work, the facade layer might need to perform work of its own to translate its interface to the business services and DAL services interface The most important point is that clients (the user services) that use the facade do not have to access its subsystem objects (business services and DAL services) directly

The facade layer (Web services and business) runs on the middle-tier nodes that can be physically separate from the user services Consequently, the facade layer also acts as a security barrier for the business services and the DAL services The facade layer requires additional resources for managing and executing the facade layer components that create additional costs These additional costs are typically justified by the benefits of simplifying the interface for user services

A facade layer fulfills three important functions:

! The first function is to receive input from the user services and pass input values to the business logic

Because user services access the facade layer, user services do not need to understand the logical or physical structure of the business logic

Furthermore, whenever the business logic model changes, user services are not affected by these changes because they interact with the business facade layer

! The second function is to act as a conduit for requests from clients to the business logic layer to retrieve or update information regarding any of the business objects The facade layer also acts as a conduit for requests for retrieval of information directly from the DAL

! The third function is to maintain the robustness of an application

Topic Objective

To provide background

about the facade layer

Lead-in

In this topic, you will learn

the business requirements

of the two types of classes

that make up the facade

layer

A good strategy for designing the facade layer is to create one object for each use case identified in the conceptual design that is used directly by an actor The facade layer consists of two layers: the business facade layer and the Web services facade layer The distinction between these two reflects the type of functionality exposed The Web services facade layer exposes functionality to external users and applications over the Internet The business facade layer exposes functionality to internal users through an intranet to browsers or Win32® Distributed Component Object Model (DCOM) clients

The primary use of the Web services facade is to expose features and functionality to external users and applications For example, a banking Web site might expose functionality to enable Web users to view their account information This functionality would be exposed by the Web services facade called from Active Server Pages (ASP) Web pages

The Web services facade is not the same as NET Web Services But the Web services facade can be used in conjunction with Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), and the NET framework to create Web services

The business facade is primarily used to expose features and functionality to internal users For example, a banking Web site might expose functionality for tellers to update account information when customers make deposits or withdrawals This type of functionality would have different security requirements from the Web services facade It might also have different types

of clients Clients of the business facade might be Win32 clients or browsers over an intranet

# Technologies

! Authentication

! User Management

! Declarative and Programmatic Security

! Strategies for Handling Errors in COM+

! How COM+ Modifies Return Values

! Fault Isolation and Failfast Policy

! Finding the Source of an Error

! Interpreting Error Codes

This section covers technologies that can be used to help solve the issues of security and robustness In the first part of this section, the following security topics will be covered:

! Authentication Authentication confirms the identity of any user trying to log on to a domain

or to access network resources Microsoft® Windows® 2000 authentication enables single sign-on, in which credentials for the user are established and used for subsequent object access

! User management

In certain situations, you might not want to create a domain account for every user of a Web-based application In those cases it is still necessary to have a user management system User management allows you to register users and manage user data, protect and share user data, verify users’ identities, and control access to content on your site User management can also provide the basis for your application’s delivery of personalized content

to your users

! Declarative and programmatic security Securing content can either be performed declaratively, by using Windows 2000 or COM+, or programmatically by using COM+ If role-based security is being used in a COM+ application that contains your component, you have access to programmatic security functionality from within your component

In the second part of this section, COM+ error-handling topics will be covered The most problematic part of writing components is handling potential errors Trying to determine what can go wrong and how to address these errors can be challenging even in the best conditions

In this section, you will learn

about two important issues

for the physical design of a

facade layer: security and

robustness

The topics in this section describe techniques for handling errors in COM+ applications, features in COM+ that affect failure behavior, and suggestions for diagnosing COM+ errors:

! Strategies for handling errors in COM+

This topic lists and describes basic guidelines for handling errors in COM+,

including when to use HRESULTs and ErrorInfo objects

! How COM+ modifies return values This topic identifies the single condition under which COM+ converts a standard HRESULT to a COM+ error code before passing it back to the caller

! Fault isolation and failfast policy This topic shows how fault isolation and the failfast policy affect COM+ behavior

! Finding the source of an error This topic describes how you can diagnose the source and obtain a description of application errors by using a combination of Windows 2000, COM+, and other tools If you discover that an application error is caused

by COM+, you can interpret the error message by viewing the Winerror.h file or by using the Microsoft Visual C++® error utility

! Interpreting error codes This topic identifies the predominant error-handling mechanisms for C++ and Microsoft Visual Basic®

! The Web facade is accessed through public Web pages and might require some level of user authentication

! The business facade is accessed through protected Web pages or through DCOM Users are authenticated before being allowed to access protected Web pages or the business facade itself

The facade is almost always the entry point into a system, and therefore a good place to enforce security Authentication strategies set the level of protection against intruders trying to steal identities or impersonate users Authentication

is a fundamental aspect of system security It confirms the identity of any user trying to log on to a domain or access network resources For high-level security, you can use Windows 2000 authentication

Windows 2000 authentication enables single sign-on for all network resources With single sign-on, a user can log on to the domain once, by using a single password or smart card, and authenticate to any computer in the domain Successful user authentication in a Windows 2000 computing environment consists of two separate processes: the interactive logon process, which confirms the user’s identification to either a domain account or a local computer, and network authentication, which confirms the user’s identification

to any network service that the user attempts to access

Windows 2000 supports several types of authentication These types are industry standards When attempting to authenticate a user, Windows 2000 uses different types of authentication, depending on a variety of factors

Windows 2000 supports the following types of authentication:

! Kerberos v5 authentication Used with either a password or a smart card for the interactive logon process This is also the default method of network authentication for services

! Secure Sockets Layer/Transport Layer Security (SSL/TLS) authentication Used when a user attempts to access a secure Web server

! Windows NT LAN Manager (NTLM) authentication Used when either the client or server uses a previous version of Windows

User Management

! Active Directory

! Application

! Site Server Membership

User management is important if your application exposes user-specific features and functionality For example, a computer sales Web site might include a support section that users can go to if they have questions after they purchase a computer The Web site could prompt users to specify the type of computer they have the first time they access the support section If the Web site stores the information about which types of computers users own, users do not need to retype this information if they log on to the site in the future This type of functionality requires user management

Active Directory

In Windows 2000, you can use Active Directory™ to store your user information There are two advantages to using Active Directory as the user-information repository Active Directory is highly accessible because it is automatically replicated, and it is robust The repository can include user information as well as user-profile data You can also choose to store security credentials in the application database

Application

Your application can be the central repository of user data The application database stores both persistent user data, which is retained indefinitely, and dynamic data, which is never written to disk, but is maintained in random access memory (RAM) while it is current Dynamic data tracks users that are currently online

Topic Objective

To provide background

about user management

Lead-in

In this topic, you will learn

about user management in

Active Directory, the

application itself, and Site

Server

Site Server Membership

If you are reluctant to build your own application’s user management, Microsoft Site Server provides a membership service that can be used for Web sites Its membership features allow you to register users and manage user data, protect and share user data, verify users’ identities, and control access to content on your site

The Membership Directory is the central repository of user data for Site Server The Membership Directory stores both persistent data, which is retained

indefinitely, and dynamic data, which is never written to disk, but is maintained

in RAM while it is current

Declarative and Programmatic Security

If pContext.IsCallerInRole("teller") Then ' Do something …

COM+ Application

Object Interface

Declarative security is available only with Active Directory

Programmatic Security

In COM+ applications, you have access to programmatic security functionality from within your component You can check role membership to determine whether particular sections of code are executed You can access security information by using the security call context object, and you can determine whether security is enabled for the current call

For further information about COM+ security, see Module 8, “Making

Applications Secure,” in Course 1907A, Building Distributed Applications for

Microsoft Windows 2000 with Visual Basic

In this topic, you will learn

how you can implement

programmatic security

Note

Demonstration: Declarative Security

This demonstration includes a Visual Basic server named Security, which

obtains the account name and impersonation level used for all callers in the

chain, from original to direct It consists of a Role class that has a Caller

method that displays a message box containing the information it obtains The code for the method is as follows:

Public Sub Caller() Dim objSecCallCtx As COMSVCSLib.SecurityCallContext Dim objSecCallers As COMSVCSLib.SecurityCallers Dim lngCallers As Long

' Obtain a reference to the security call context object Set objSecCallCtx = GetSecurityCallContext

' Get the SecurityCallers collection object Set objSecCallers = objSecCallCtx.Item("Callers")

For lngCallers = 0 To objSecCallers.Count - 1 MsgBox "Name: " & _

objSecCallers(lngCallers).Item("AccountName") & _ " ImpLvl: " & _

objSecCallers(lngCallers).Item("ImpersonationLevel") Next

In this demonstration, you

will learn how to set up the

security for a COM+

component

To run this demonstration, perform the following steps:

! Make and register the Security.dll

1 Click the Start menu, point to Programs, then to Microsoft Visual Studio

6.0, and then click Microsoft Visual Basic 6.0

2 Locate the Security.vbp Visual Basic project in the <Install

Folder>/msdntrain/1910/DemoCode/Mod05/Security folder, and open

this project

3 On the File menu, click Make Security.dll

1 Click the Start menu, and point to Programs, and then to Administrative

Tools, and then click Component Services

2 In the left pane, expand Component Services, Computers, My Computer, and COM+ Applications

3 Right-click COM+ Applications, and click New and Application

4 On the Welcome to the COM Application Install Wizard page, click

Next

5 Click Create an empty application

6 In the Enter a name for the new application box, type Security, and then click Next

7 On the Set Application Identity page, click Next

8 Finally, click Finish

! Install a component

1 In the left pane, expand Security and Components

2 Right-click Components, and select New and Component

3 On the Welcome to the COM Component Install Wizard page, click

Next

4 Click Install new component(s)

5 In the Select files to install dialog box, click the Security.dll file in the

<Install Folder>/msdntrain/1910/DemoCode/Mod05/Security, and then

click Open

6 Click Next on the next wizard page

7 Click Finish

! Create a role

1 Under the Security COM+ application, click the Roles folder

2 On the Action menu, point to New, and then click Role

3 Type Admin, which is the name of the new role, and then click OK

! Assign roles to a component

1 Under the Security COM+ application, expand the Components folder and

click the Security.Role component

2 Right-click the Security.Role component, for which role-based authorization is to be performed, and select Properties

3 In the Properties dialog box, click the Security tab to display the Security page The Security page presents a list of all roles defined for the

application

4 Select the Admin role, and click OK

! Assign roles to a method

1 In the Component Services tool, expand Security.Role, Interfaces, Role, Methods, and right-click the Caller method, for which role-based authorization is to be performed, and select Properties

2 In the Properties dialog box, click the Security tab to display a dialog box

that shows the roles that the method has inherited from higher-level role assignment and all of the available roles defined for the application

3 Click Admin to specifically assign the Admin role to the Caller method Now even if the Admin role is removed at the component level, the Admin role will still be allowed to access the Caller method

4 Click OK

1 Expand the Roles folder and Admin, which is the specific role to which you

want to assign Windows 2000 users

2 Under the specific role, right-click the Users folder, point to New, and click

User to display the Select Users of Groups dialog box

3 In the Select Users or Groups dialog box, add the Administrator user to the role, and click OK

! Enable authorization checking for applications

1 In the Component Services tool, right-click the Security application, and select Properties

2 In the Properties dialog box, click the Security tab to display the Security

page

3 Click Enforce access checks for this application to enable security for the

Security application

4 Click OK

! Enable authorization checking for components

1 In the Component Services tool, right-click Security.Role, which is the

component for which the authorization setting is to be amended, and select

Properties

2 In the Properties dialog box, click the Security tab to display the Security

page

3 To enable authorization checking at the component, interface, and method

levels, select the Enforce component level access checks check box, and click OK

! XTest the Security component

1 Click the Start menu, and point to Programs, then to Microsoft Visual

Studio 6.0, and then click Microsoft Visual Basic 6.0

2 Locate the SecurityTest.vbp Visual Basic project in the <Install

Folder>/msdntrain/1910/DemoCode/Mod05/Security Test folder, and

open this project

3 Run the SecurityTest application

4 Read the messages that are displayed in the message box

Strategies for Handling Errors in COM+

! Return an HRESULT value for all methods in all component interfaces.

! Initiate the ErrorInfo object by whatever means your development tool provides.

! Use transactions to manage shared resource failures.

! Raise errors explicitly.

! Use the FACILITY_ITF range of errors to report interface-specific errors.

The preceding slide lists several error-handling strategies to use when you develop components for COM+

Return an HRESULT Value for All Methods in All Component Interfaces

COM+ uses HRESULT values to report any errors that occur during function calls or interface method calls An HRESULT is a 32-bit number that indicates whether a method has succeeded An HRESULT also identifies the facility associated with the error, such as RPC, Win32, or FACILITY_ITF for interface-specific errors Finally, system application programming interfaces (APIs) provide a lookup from an HRESULT to a string that describes the error condition

Using methods that return HRESULT values is fundamental to well-written components and is essential to the debugging process Visual Basic

automatically defines each method with an HRESULT as a return In C++, you must explicitly return an HRESULT

Initiate the ErrorInfo Object by Whatever Means Your Development Tool Provides

ErrorInfo objects are often called Component Object Model (COM)

exceptions because they allow an object to pass (or throw) rich error information to its caller, even across apartment boundaries The value of this generic error object is that it supplements an HRESULT, extending the type of

error information that you can return to a caller Each ErrorInfo object returns

a contextual description, the source of the error, and the interface identifier of the method that originated the error You can also include pointers to an entry

In this topic, you will learn

how to handle errors in

COM+

Automation provides three interfaces to manage the error object Your

component must implement the ISupportErrorInfo interface to advertise its support for the ErrorInfo object When an error occurs, the component uses the

ICreateErrorInfo interface to initialize an error object After the caller checks

the HRESULT and determines that the method call failed, it queries the object

to see if it supports the ErrorInfo object If it does, the caller uses the

IErrorInfo interface to retrieve the error information

Visual Basic programmers have easy access to the ErrorInfo object, which is exposed through the Err object You can raise errors with the Err.Raise function and catch errors with the OnError statement The Visual Basic run-

time layer handles the mapping for you If you are using the Visual C++ COM

compiler support, you can use the _com_raise_error class to report an error and the _com_error class to retrieve error information COM+ will not propagate traditional C++ exceptions as extended IErrorInfo information

Use Transactions to Manage Shared Resource Failures

Transactions can significantly reduce the amount of error-handling code that you need to write when using state-managed resource managers However, transactions do not eliminate the need for error handling altogether You still need to return error codes from your interface methods and check those error codes within the caller to avoid doing unnecessary work on behalf of a failed transaction

Raise Errors Explicitly

Avoid allowing error information to leave an object unless the object explicitly raises the error Catch all tool-generated errors and handle them in your component code At the very least, include a standard handler to report unexpected errors in a consistent manner

Use the FACILITY_ITF Range of Errors to Report Interface-specific Errors

Interface-specific-errors should be in the FACILITY_ITF range of errors, between 0x0200 and 0xFFFF You can define a custom error code in Visual

Basic as an offset from vbObjectError Use the MAKE_HRESULT macro in

C++ to introduce an interface-specific error code, as shown in the following example:

const HRESULT ERROR_NUMBER = MAKE_HRESULT (SEVERITY_ERROR, FACILITY_ITF, 10);