Professional ASP.NET 3.5 in C# and Visual Basic Part 66 ppsx

Evjen c12.tex V2 - 01/28/2008 2:25pm Page 607 Chapter 12: Introduction to the Provider Model This single class for the personalization system inherits from the ProfileProvider base class. This is illustrated in Figure 12-11. Figure 12-11 As with the other providers covered so far, SqlProfileProvider connects to a Microsoft SQL Server Express Edition file by default. Although this is the default, you can change the connection to work with either SQL Server 7.0, 2000, 2005, or 2008. For instance, if you are connecting to a SQL Server 2005 database, you define your connection in the web.config and then associate your SqlProfileProvider declaration to this connection string. This scenario is presented in Listing 12-12. Listing 12-12: Connecting the SqlProfileProvider to SQL Server 2005 <configuration> <connectionStrings> <add name="LocalSql2005Server" connectionString="Data Source=127.0.0.1;Integrated Security=SSPI" /> </connectionStrings> <system.web> <profile> <providers> <clear /> <add name="AspNetSql2005ProfileProvider" connectionStringName="LocalSql2005Server" applicationName="/" type="System.Web.Profile.SqlProfileProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </providers> Continued 607 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 608 Chapter 12: Introduction to the Provider Model <properties> <add name="FirstName" /> <add name="LastName" /> <add name="LastVisited" /> <add name="Age" /> <add name="Member" /> </properties> </profile> </system.web> </configuration> Remember that to store profile information in your SQL Server database, you have to configure this database so the proper tables, stored procedures, and other items are created. This task was discussed earlier in the chapter. The SiteMap Provider Similar to the personalization provider just discussed, ASP.NET 3.5 provides a single provider to work with sitemaps. Sitemaps are what ASP.NET uses to provide you with a centralized way of maintaining site navigation. By default, the definition of a Web application’s navigation is located in a structured XML file. The sitemap provider lets you interact with this XML file, the .sitemap file, which you create for your application. The provider available for sitemaps is System.Web.XmlSiteMapProvider ,which provides you with the capability to use the ASP.NET navigation system to connect to an XML-based file. This single class for the sitemap system inherits from the StaticSiteMapProvider base class, which is a partial implementation of the SiteMapProvider base class. This is illustrated in Figure 12-12. This is the first provider introduced so far that does not connect to a SQL Server database by default. Instead, this provider is designed to work with a static XML file. This XML file uses a particular schema and is covered in considerable detail in Chapter 14. The code required to configure XmlSiteMapProvider is presented in Listing 12-13. Listing 12-13: Defining an XmlSiteMapProvider instance in the web.config <configuration> <system.web> <siteMap defaultProvider="MyXmlSiteMapProvider" enabled="true"> <providers> <add name="MyXmlSiteMapProvider" description="SiteMap provider that reads in .sitemap files." type="System.Web.XmlSiteMapProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" siteMapFile="AnotherWeb.sitemap" /> </providers> </siteMap> </system.web> </configuration> 608 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 609 Chapter 12: Introduction to the Provider Model Figure 12-12 The XmlSiteMapProvider allows only a single root element in the strictly designed web.sitemap file. The default file name of the XML file it is looking for is web.sitemap , although you can change this default setting (as you can see in Listing 12-13) by using the siteMapFile attribute within the provider declaration in the web.config file. SessionState Providers As mentioned in the beginning of the chapter, an original concept of a provider model existed when the idea of managing session state in different ways was first introduced with ASP.NET 1.x. The available modes of storing session state for your users include InProc , StateServer , SQLServer ,oreven Custom . 609 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 610 Chapter 12: Introduction to the Provider Model Each mode has definite pros and cons associated with it, and you should examine each option thoroughly when deciding which session state mode to use. You can find more information on these session state modes in Chapter 22. This provider model is a bit different from the others discussed so far in this chapter. The SessionState- Module class is a handler provided to load one of the available session state modes. Each of these modes is defined here: ❑ System.Web.SessionState.InProcSessionStateStore : Provides you with the capability to store sessions in the same process as the ASP.NET worker process. This is by far the best- performing method of session state management. ❑ System.Web.SessionState.OutOfProcSessionStateStore : Provides you with the capability to store sessions in a process separate from the ASP.NET worker process. This mode is a little more secure, but a little worse in performance than the InProc mode. ❑ System.Web.SessionState.SqlSessionStateStore : Provides you with the capability to store sessions in SQL Server. This is by far the most secure method of storing sessions, but it is the worst performing mode of the three available methods. These three modes for session state management are illustrated in Figure 12-13. Figure 12-13 Next, this chapter reviews each of the three modes that you can use out of the box in your ASP.NET 3.5 applications. 610 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 611 Chapter 12: Introduction to the Provider Model System.Web.SessionState.InProcSessionStateStore The InProcSessionStateStore mode is the default mode for ASP.NET 1.x as well as for ASP.NET 2.0 and 3.5. In this mode, the sessions generated are held in the same process as that being used by the ASP.NET worker process ( aspnet_wp.exe or w3wp.exe ). This mode is the best performing, but some problems exist with this mode as well. Because the sessions are stored in the same process, whenever the worker process is recycled, all the sessions are destroyed. Worker processes can be recycled for many reasons (such as a change to the web.config file, the Global.asax file, or a setting in IIS that requires the process to be recycled after a set time period). An example of the configuration in the web.config file for working in the InProc mode is presented in Listing 12-14. Listing 12-14: Defining the InProc mode for session state management in the web.config <configuration> <system.web> <sessionState mode="InProc"> </sessionState> </system.web> </configuration> As you can see, this mode is rather simple. The next method reviewed is the out-of-process mode — also referred to as the StateServer mode. System.Web.SessionState.OutOfProcSessionStateStore In addition to the InProc mode, the StateServer mode is an out-of-process method of storing session state. This method does not perform as well as one that stores the sessions in the same process as the ASP.NET worker process. This makes sense because the method must jump process boundaries to work with the sessions you are employing. Although the performance is poorer than in the InProc mode, the OutOfProcSessionStateStore method is more reliable than running the sessions using InProcSession- StateStore . If your application’s worker process recycles, the sessions that this application is working with are still maintained. This is a vital capability for those applications that are critically dependent upon sessions. An example of using OutOfProcSessionStateStore is detailed in Listing 12-15. Listing 12-15: Running sessions out of process using OutOfProcSessionStateStore <configuration> <system.web> <sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424"> </sessionState> </system.web> </configuration> 611 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 612 Chapter 12: Introduction to the Provider Model When using the StateServer mode, you also must define where the sessions are stored using the stateConnectionString attribute. In this case, the local server is used, meaning that the sessions are stored on the same machine, but in an entirely separate process. You could have just as easily stored the sessions on a different server by providing the appropriate IP address as a value for this attribute. In addition to the IP address, note that port 42424 is used. This port is required when using the StateServer mode for sessions. Changing the port for the StateServer is detailed in Chapter 22. System.Web.SessionState.SqlSessionStateStore The final provider for session state management available to you in ASP.NET is the SqlSessionState- Store . This method is definitely the most resilient of the three available modes. With that said, however, it is also the worst performing of the three modes. It is important that you set up your database appro- priately if you use this method of session state storage. Again, Chapter 22 shows you how to set up your database. To configure your application to work with SqlSessionStateStore , you must configure the web.config as detailed in Listing 12-16. Listing 12-16: Defining SqlSessionStateStore in the web.config file <configuration> <system.web> <sessionState mode="SQLServer" allowCustomSqlDatabase="true" sqlConnectionString="Data Source=127.0.0.1; database=MyCustomASPStateDatabase;Integrated Security=SSPI"> </sessionState> </system.web> </configuration> Next, you review the providers available for the Web events architecture. Web Event Providers Among all the available systems provided in ASP.NET 3.5, more providers are available for the health monitoring system than for any other system. The new health monitoring system enables ASP.NET application administrators to evaluate the health of a running ASP.NET application and to capture events (errors and other possible triggers) that can then be stored via one of the available providers. These events are referred to as Web events. A large list of events can be monitored via the health monitoring system, and this means that you can start recording items such as authentication failures/successes, all errors generated, ASP.NET worker process information, request data, response data, and more. Recording items means using one of the providers available to record to a data store of some kind. Health monitoring in ASP.NET 3.5 is covered in Chapter 33. 612 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 613 Chapter 12: Introduction to the Provider Model By default, ASP.NET 3.5 offers seven possible providers for the health monitoring system. This is more than for any of the other ASP.NET systems. These providers are defined in the following list: ❑ System.Web.Management.EventLogWebEventProvider : Provides you with the capability to use the ASP.NET health monitoring system to record security operation errors and all other errors into the Windows event log. ❑ System.Web.Management.SimpleMailWebEventProvider : Provides you with the capability to use the ASP.NET health monitoring system to send error information in an e-mail. ❑ System.Web.Management.TemplatedMailWebEventProvider : Similar to the SimpleMailWeb- EventProvider ,the TemplatedMailWebEventProvider class provides you with the capability to send error information in a templated e-mail. Templates are defined using a standard .aspx page. ❑ System.Web.Management.SqlWebEventProvider : Provides you with the capability to use the ASP.NET health monitoring system to store error information in SQL Server. As with the other SQL providers for the other systems in ASP.NET, the SqlWebEventProvider stores error infor- mation in SQL Server Express Edition by default. ❑ System.Web.Management.TraceWebEventProvider : Provides you with the capability to use the ASP.NET health monitoring system to send error information to the ASP.NET page tracing sys- tem. ❑ System.Web.Management.IisTraceWebEventProvider : Provides you with the capability to use the ASP.NET health monitoring system to send error information to the IIS tracing system. ❑ System.Web.Management.WmiWebEventProvider : Provides you with the capability to connect the new ASP.NET health monitoring system, the Windows Management Instrumentation (WMI) event provider. These seven providers for the ASP.NET health monitoring system inherit from either the WebEvent- Provider base class, or the BufferedWebEventProvider (which, in turn, inherits from WebEventProvid- er ). This is illustrated in Figure 12-14. What is the difference between the WebEventProvider class and the BufferedWebEventProvider ?The big difference is that the WebEventProvider writes events as they happen, whereas the BufferedWeb- EventProvider holds Web events until a collection of them is made. The collection is then written to the database or sent in an e-mail in a batch. If you use the SqlWebEventProvider class, you actually want this batch processing to occur rather than having the provider make a connection to the database and write to it for each Web event that occurs. Next, this chapter looks at each of the seven available providers for the health monitoring system. System.Web.Management.EventLogWebEventProvider Traditionally, administrators and developers are used to reviewing system and application errors in the built-in Windows event log. The items in the event log can be viewed via the Event Viewer. This 613 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 614 Chapter 12: Introduction to the Provider Model Figure 12-14 GUI-based tool for viewing events can be found by selecting Administration Tools in the Control Panel and then selecting Event Viewer. By default, the health monitoring system uses the Windows event log to record the items that are already specified in the server’s configuration files or items you have specified in the web.config file of your application. If you look in the web.config.comments file in the CONFIG folder of the Microsoft .NET Framework install on your server, you see that the EventLogWebEventProvider is detailed in this loca- tion. The code is presented in Listing 12-17. Listing 12-17: The EventLogWebEventProvider declared in the web.config.comments file <configuration> <system.web> <healthMonitoring heartbeatInterval="0" enabled="true"> <bufferModes> <! Removed for clarity > </bufferModes> <providers> <clear /> <add name="EventLogProvider" 614 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 615 Chapter 12: Introduction to the Provider Model type="System.Web.Management.EventLogWebEventProvider, System.Web,Version=2.0.0.0,Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> <! Removed for clarity > </providers> <profiles> <! Removed for clarity > </profiles> <rules> <add name="All Errors Default" eventName="All Errors" provider="EventLogProvider" profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:01:00" custom="" /> <add name="Failure Audits Default" eventName="Failure Audits" provider="EventLogProvider" profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:01:00" custom="" /> </rules> <eventMappings> <! Removed for clarity > </eventMappings> </healthMonitoring> </system.web> </configuration> As you can see from Listing 12-17, a lot of possible settings can be applied in the health monitoring system. Depending on the rules and event mappings you have defined, these items are logged into the event log of the server that is hosting the application. Looking closely at the < rules > section of the listing, you can see that specific error types are assigned to be monitored. In this section, two types of errors are trapped in the health monitoring system — All Errors Default and Failure Audits Default . When one of the errors defined in the < rules > section is triggered and captured by the health monitoring system, it is recorded. Where it is recorded depends upon the specified provider. The provider attribute used in the < add > element of the < rules > section determines this. In both cases in the example in Listing 12-17, you can see that the EventLogProvider is the assigned provider. This means that the Windows error log is used for recording the errors of both types. As you work through the rest of the providers, note that the health monitoring system behaves differently when working with providers than the other systems that have been introduced in this chapter. Using the new health monitoring system in ASP.NET 3.5, you are able to assign more than one provider at a time. This means that you are able to specify in the web.config file that errors are logged not only into the Windows event log, but also into any other data store using any other provider you designate. Even for the same Web event type, y ou can assign the Web event to be recorded to the Windows event log and SQL Server at the same time (for example). System.Web.Management.SimpleMailWebEventProvider Sometimes when errors occur in your applications, you as an administrator or a concerned developer want e-mail notification of the problem. In addition to recording events to disk using something such as the EventLogWebEventProvider , you can also have the error notification e-mailed to you using the SimpleMailWebEventProvider . As it states in the provider name, the e-mail is a simply constructed one. Listing 12-18 shows you how you would go about adding e-mail notification in addition to writing the errors to the Windows event log. 615 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 616 Chapter 12: Introduction to the Provider Model Listing 12-18: The SimpleMailWebEventProvider definition <configuration> <system.web> <healthMonitoring heartbeatInterval="0" enabled="true"> <bufferModes> <add name="Website Error Notification" maxBufferSize="100" maxFlushSize="20" urgentFlushThreshold="1" regularFlushInterval="Infinite" urgentFlushInterval="00:01:00" maxBufferThreads="1" /> </bufferModes> <providers> <clear /> <add name="EventLogProvider" type="System.Web.Management.EventLogWebEventProvider, System.Web,Version=2.0.0.0,Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> <add name="SimpleMailProvider" type="System.Web.Management.SimpleMailWebEventProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from="website@company.com" to="admin@company.com" cc="adminLevel2@company.com bcc="director@company.com" bodyHeader="Warning!" bodyFooter="Please investigate ASAP." subjectPrefix="Action required." buffer="true" bufferMode="Website Error Notification" maxEventLength="4096" maxMessagesPerNotification="1" /> </providers> <profiles> <! Removed for clarity > </profiles> <rules> <add name="All Errors Default" eventName="All Errors" provider="EventLogProvider" profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:01:00" custom="" /> <add name="Failure Audits Default" eventName="Failure Audits" provider="EventLogProvider" profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:01:00" custom="" /> <add name="All Errors Simple Mail" eventName="All Errors" provider="SimpleMailProvider" profile="Default" /> <add name="Failure Audits Default" eventName="Failure Audits" provider="SimpleMailProvider" profile="Default" /> </rules> <eventMappings> 616 . response data, and more. Recording items means using one of the providers available to record to a data store of some kind. Health monitoring in ASP. NET 3. 5 is covered in Chapter 33 . 612 Evjen. 12: Introduction to the Provider Model System.Web.SessionState.InProcSessionStateStore The InProcSessionStateStore mode is the default mode for ASP. NET 1.x as well as for ASP. NET 2.0 and 3. 5. In. provider just discussed, ASP. NET 3. 5 provides a single provider to work with sitemaps. Sitemaps are what ASP. NET uses to provide you with a centralized way of maintaining site navigation. By default,