|
Storing information - II After taking a look at memory-based storage, and RAM /temporary workspace-based, storage, as among the locations, apart from a database, where information could be stored, let's discuss some of the other locations:
IIS runtime objects
The Web server (Internet Information Server) provides a runtime environment for storing various parameters and states related to the user sessions and applications. Although this usage is similar to the application-based memory variables discussed earlier, there is a difference--here the server maintains these variables for the client applications.
The following objects are available:
Session object:
This is used to store information or parameters related to the user session. If there are 10 users connected to your Web server there will be 10 session objects running. This should be used to store information about the currently connected user. It could be things like the name, other personal details, the sites visited by the user within your site, some other user preferences, etc.
Application object:
This object stores global information that is accessible throughout the Web application. Any information stored here will be available to all the users connected to the Web server.
This object can be used to store application details like the connection string to the database server, number of users connected to the Web server or any other server connectivity information.
Shared property manager
The currently preferred method of creating Web applications is to make a separate set of components for managing the business logic and data access. For managing security, transactions and scalability, the components need to be deployed using the Microsoft Transaction Server (MTS). A typical Web application deployment can be represented as follows:
Now each component is to be written as a discreet piece of code without bothering about concurrency, transactions and security. All these are offered externally by MTS.
The scope of the current discussion does not permit me to go into details of MTS component development. However, there is one important design consideration while developing MTS components. You must write these as 'stateless' components.
Stateless means that no state should be stored on the server side in terms of values of variables, properties, etc. This is because, during the lifetime of a particular component invoked by you, it is possible that the MTS resource pooling engine may actually give you reference of any of the active instances of the object.
This means that you cannot guarantee that some state stored by you on the invoked object may remain static when you want to refer to it again after some time.
This is a problem if you require to store some state on the server. You typically want to store the server state if you want some values to be shared across multiple user sessions. A classic example of this functionality is shared information related to Web-based multi-user games.
The facility to share the state across instances of applications on the server side is available using the Shared Property Manager.
The Shared Property Manager enables multiple users to easily access shared global data without the need for complex programming. It is an MTS resource dispenser that provides synchronised access to application-defined, process-wide properties (variables). A multi-user application may require common access to shared information stored in memory. Components can be designed to create, use, and update global data within the MTS environment. Any component within a package can share information with other components in the same package.
The SharedProperty object is used to set or retrieve the value of a shared property. A shared property can contain any data type that can be represented by a variant. To use the SharedProperty object, you must set a reference to the Shared Property Manager Type Library (Mtxspm.dll).
You can create a SharedProperty object with the CreateProperty method or the CreatePropertyByPosition method.
A SharedProperty object can be created or accessed only from within a SharedPropertyGroup.
The Shared Property Manager eliminates name collisions by providing shared property groups, which establish unique name spaces for the shared properties they contain. The Shared Property Manager also implements locks and semaphores to protect shared properties from simultaneous access, which could result in lost updates and could leave the properties in an unpredictable state.
Shared properties can be shared only by objects running in the same process. If you want instances of different components to share properties, you have to install the components in the same MTS package. Because there is a risk that administrators will move components from one package to another, it's safest to limit the use of a shared property group to instances of components that are defined in the same DLL.
Property bags for ActiveX controls
ActiveX components are a method of writing reusable code with or without a visual interface.
Fox example, the date picker control is an ActiveX component. Components are used to provide generic functionality that is usable simply by embedding the control on your form or within your code and accessing its properties and methods.
In this example, if this control was not available, you would have to write a lot of complex code to create your own calendar and manage its visual layout.
Use of ActiveX controls for in-house development of applications is also important. When you write any reusable functionality as an ActiveX control, it becomes reusable from any language that supports ActiveX. Currently all major languages support ActiveX.
Most components have properties, and in most cases you'll want to establish default values for those properties in the Initialize event of the class. Those default values are frozen when you compile the component, so how do you allow a developer to change the default values to meet their own special conditions? Classes have a special property, Persistable, that allow you to store a component's values between instances.
Suppose you had an ActiveX DLL that calculates loans, with an InterestRate property used in the calculations. You could initialise the InterestRate to some arbitrary value, but since interest rates periodically go up or down, the InterestRate property would need to be modified each time the component is run. With class persistence, you can store the InterestRate value and modify it only when the interest rate changes. Each time your component is run it can retrieve the InterestRate from storage, so the component will always provide the latest rate.
While ActiveX controls have always been able to persist their data, persistence for ActiveX components is slightly different. A control stores property settings inside its .CLS file, but a component can't do that. Instead, it uses a PropertyBag object that can be saved just about anywhere--in a file, a database, a cell in a spreadsheet, or even in the registry.
Performance monitor counters
Performance monitoring is a utility available with Windows NT. This provides a very efficient method of monitoring, logging and analysing application performance. All the applications, including Windows NT, SQL Server, IIS, MTS, Exchange, etc, use the performance monitor to publish information about the application state dynamically.
It is possible to write your own performance monitor counters. This is another place where critical performance-sensitive data from your application could be stored. If the person views just the graph, the data is discarded after the viewing session is over.
However, if the logging or reporting option is used, the data can be stored persistently. The stored data can be later reviewed like an action replay or it can be dumped in a file for analysis in a database or a spreadsheet.
SQL server allows you to write custom stored procedures with specific naming conventions that return a number. These monitors can be directly viewed in the performance monitors.
Writing performance monitor counters for your own application is more complex. You require to write special code using Platform SDK (Win32 SDK) using the C language to provide custom performance monitor counters.
A performance object is an entity for which performance data is available. Performance counters define the type of data that is available for a counter object. An application can provide information for multiple performance objects, each with one or more counters.
An application can also define objects that have multiple instances. For example, a SCSI application could use a single set of counter definitions to define a drive object with two counters, such as 'Bytes Read' and 'Bytes Written'. The performance DLL for the application could report performance data for each drive controlled by the application.
|
