<FONT FACE="VERDANA, ARIAL, HELVETICA" COLOR="#0000FF" SIZE=5>How The Profile Page</FONT>
<HR>
<H2>Functional Overview</H2>
The user, having logged into the Frequent Flier application, goes to the Member Profile page: <STRONG>profile.asp</STRONG>. This page consists of a large form full of user information retrieved from the database when the page loads.
The user makes changes to the page by editing the form and clicks on the submit button when finished.
The form is validated via JavaScript. If the validation is successful, then the form is posted to the same page: <STRONG>profile.asp</STRONG>. Since a form value was passed to the page to indicate that this is a submission request, the page does not display any of its HTML, but rather takes the form values and sends them to the components that handle updating the database. If no errors are returned, then <STRONG>profile.asp</STRONG> redirects to <STRONG>FFHomepage.asp</STRONG>.
<H2>Data Model</H2>
Four tables from the Frequent Flyer database are involved: the diagram below is only a subset of the entire data model<p>
<TR><TD><I>Member</I></TD><TD>Includes information about the user including contact information and preferences such as seating, smoking, and eating. One record from this table is involved in the scenario.</TD></TR>
<TR><TD><I>Interests</I></TD><TD>A list of interests such as "Fishing", "Golfing", "Tropical Vacations." All of the records from this table are retrieved in order to create the check boxes for each of these interests.</TD></TR>
<TR><TD><I>MembersInterests</I></TD><TD>Consists of records which list an InterestID and a MemberID. When querying the database all the records which match the current AccountID are retrieved. When updating the database, all of these records are deleted and as many new records are written as the user has indicated as interests on the form.</TD></TR>
<TR><TD><I>InterestCategories</I></TD><TD>Is queried along with Interests to provide a category name that will appear with the interests.
</TABLE>
</CENTER>
<H2>Components Used</H2>
The <B>ExAir</B> component is written in Microsoft Visual Basic 5 and is called from profile.asp. It includes a class called <B>Member</B> which handles all changes to the Members and MembersInterests tables of the database.<P>
The methods involved in the process described above are:
<TR><TD><I>Member.GetForID</I></TD><TD>Retrieves account information about the user by querying the Member the AccountID (which was stored in a session variable when the user logged on).</TD></TR>
<TR><TD><I>Member.ListInterests</I></TD><TD>Retrieves all of the interests, along with the category name of the interests, and indicates whether this particular user has indicated each interest. All of this is achieved in one fell swoop with an absolutely brilliant SQL SELECT statement that performs a LEFT JOIN along with a nested INNER JOIN.</TD></TR>
<TR><TD><I>Member.Update</I></TD><TD>Writes all of the changes to the Member table.</TD></TR>
<TR><TD><I>Member.UpdateInterests</I></TD><TD>Writes all of the changes to the MembersInterests table.</TD></TR>
</TABLE>
</CENTER>
<TABLE>
<TR><TD>
<H2>Transaction Usage</H2>
The Member class is registered with Microsoft Transaction Server. The four methods listed above
all contain code that manages the transaction so that if connections to the database fail, or other
errors occur while the components are running, the transaction can be safely aborted. This code also
insures that as soon as the components are done performing their allotted tasks, they can be reused
by other clients, thus providing maximum scalability.
<P>
<H3>Process Isolation</H3>
The member component is registered with Microsoft Transaction Server. It is located in the Exploration Air <B>package</B>.
The package runs in a separate process from IIS, giving process isolation.
Separating the business components into another process will help protect the IIS process from corruption or failure
due to bad behavior of the business components. This protection should minimize the chances of the web server being interrupted.
<H3>Transactions</H3>
The member component's transactional property is set to <B>Required</B>.
By setting the transactional property of the component MTS will guarantee that the information that is either
read or updated will always be protected from corruption. The protection that is guaranteed is as follows:-
<DIR>
<LI><B>Atomic</B> - Member profile and interests are updated as one atomic piece of work
<LI><B>Consistent</B> - Interests will always match the current member profile
<LI><B>Isolated</B> - When updates are being made others are locked out of that data
<LI><B>Durable</B> - Updates are committed and made durable in SQL server.
</DIR>
In the case of a failure either programmatic or system MTS will automatically abort the current transaction.
<H3>Resource Management</H3>
Many resources that are used in an application can be shared among all of the components in the application.
Resources such as database connections are automatically being pooled. This allows for very quick access to data
as the connection does not need to be "rebuilt" each time it is requested but rather can be shared among many users
accessing the same data. Other resources such as threads etc are also shared.
<H3>State Management</H3>
The above services are provided automatically by registering the membership component with MTS.
In order for MTS to optimize state management on the server the membership component "tells" MTS at the
end of a method call that it has completed it's work and no longer needs the state to be held in this object.
MTS is then able to release the state of the object as soon as the method is complete. Although clients may maintain
references to the membership object the actual activations of the membership component will exist only when methods are executing
on the object. This behaviour allows for many more users to access the same server.</TD></TR></TABLE>
<!--END TABLES HOLDING GRAPHIC, NAVIGATIONAL LINK, AND MAIN CONTENT-->
