Home > Articles > Programming > Windows Programming

  • Print
  • + Share This
Like this article? We recommend

Like this article? We recommend

Architecting the System

Although there are many advances to the .NET environment—including the Common Language Runtime and strong typing—the main thrust of .NET is to enable the creation of loosely coupled, service-based applications that will become common as we move forward into the Internet age. This section provides a brief overview of this concept and how the gasTix architecture functions on top of that foundation.

The .NET Architectural Foundation

With the advent of Microsoft Transaction Server (MTS) and its successor, COM+, Microsoft created an environment in which components can interact when carrying out various transactions on behalf of one client or another. MTS provided the framework for many key application functions such as security and transaction management. This frees the developer to focus on business functionality. An environment was created in which applications can truly be implemented using a set of reusable, business-oriented components—a huge improvement over the previous structured approach for building applications.

Unfortunately, there was a problem with deciding how to take advantage of these components in rolling out enterprise-wide applications. In order t get components on remote MTS servers to work together, developers need to know where those components were located. Furthermore, to take advantage of those components, developers have to write to a COM-based interface, which introduces several middleware-related issues in communicating with legacy, CORBA, or EJB-based systems.

In the Internet age, the need for data exchange between applications will become more important than ever as the different components of an enterprise's supply chain become more strongly integrated. You cannot assume that these disparate systems will be located in the same country, let alone on the same network backbone. You also can't assume that these applications will be built using the same technologies. Because of this, the applications will require some type of middleware to glue it all together.

So, how does .NET position its applications for the Internet age? There are three basic components:

  • Establishment of the .NET platform and its suite of servers to provide a secure, stable, and scalable platform upon which to build sites

  • Introduction of Web services to provide an implementation-independent method for interaction between systems

  • Providing a framework via BizTalk for enabling messaging and workflow between these various sites and services

A much more thorough discussion of the .NET concept can be found in Chapter 1 of this book.

gasTix Conceptual Architecture

With the new .NET concepts in mind, gasTix decided to imagine the site as a set of as many interactive sites and services as possible to provide the greatest flexibility for implementing, and later extending, the site. Each major application is viewed as a site that provides a set of services for the other sites to consume.

Furthermore, this site and service concept ensures the most flexibility in adding new outlets and new functionality. For example, if another Web site expressed interest in linking to gasTix for ticket information, the presence of the service concept provides an existing and quick means for interfacing with this other site. This concept even spilled over into recasting traditional applications as services to provide greater flexibility in how certain functionality is provided. For example, by breaking the printing and shipping of tickets into a separate fulfillment service, greater flexibility was provided in determining when and where the tickets were developed. The possibility of obtaining a third party to provide the service became a possibility.

The rest of this section provides a description of the sites and related service categories required to support gasTix. Figure 2.1 provides a graphic depiction of these services and how they are related.

Figure 2.1 The gasTix architectural environment.

Purchasing Mechanisms

To maximize potential ticket sales, gasTix will allow purchases from a variety of sources. The sources that gasTix will support are as follows:

  • Internet users—Represents the set of users attempting to purchase the tickets using their Web browser through the gasTix Web site.

  • Kiosk—In some cases, gasTix will want to place stands in appropriate locations to allow people to purchase tickets on the spot. Examples of potential locales for the kiosks include venue sites, outside of box offices for after-hours purchases, or at various promotional events.

  • Box offices—These are traditional outlets for purchasing tickets. Examples of locations included in this category include box offices located at the various venues, retail stores that are partnering with the main ticket distribution company, and centers set up to handle telephone purchases.

  • Internet partners—In some cases, gasTix might partner with outside Web sites to provide a mechanism for allowing their site users to purchase tickets.

  • Wireless users—As soon as possible, gasTix wants to handle users interested in obtaining tickets from a mobile device of some kind.

Ticketing Interface

There are several mechanisms for allowing users to access the site. The service needed depends on the users' location and to what extent they will have to use the site. The following two mechanisms are available for providing that access:

  • Traditional Web server—Access to the system is provided through a traditional Web server. This technique provides enhanced performance and additional functionality.

  • Web services interface—Access to the system is also provided through a new set of services through which other Web sites or similar consumers can access the system. These interfaces will be limited in functionality compared to the internal interfaces.

Ticket Engine

This is the heart of the site and provides the ticket sales and processing on behalf of any service through which a customer can purchase tickets. Through these interfaces, the engine provides a set of base functionality that these consumers can access. This functionality is divided as follows:

  • Login and security—Provides a means to validate the users and control their access to site features accordingly.

  • Site administration—Provides the mechanism for managing and configuring the users, sites, events, and performers of the system.

  • Event searching—Provides the capability to find an event of the user's choice through a variety of criteria.

  • Seat inventory—Provides the capability to find seats available for the given event and to reserve those seats for potential purchase.

  • Payment processing—Provides for obtaining and charging the user's credit card to handle actual purchasing of the seats.

  • Personalization—A certain amount of limited personalization of the site allows the users to specify their favorite categories.

  • Fulfillment—Provides the mechanism for having the tickets shipped to the purchaser as well as reporting information about the shipment status.

Back Office Support

Not all functionality is directly provided by the ticket engine. Where possible, gasTix looked for partners to provide functionality for the site. The following services are to be used by or interfaced with the gasTix system:

  • Accounting—Financial information is fed to the company's accounting system on a regular basis.

  • Address verification service—An outside service ensures that address information provided to the site is accurate.

  • Fulfillment system—An outside service actually prints and ships the tickets to the purchaser. In some cases, the printing portion of the system is located at the various box offices so they can be given to the purchaser directly. The fulfillment system also must be able to tell the ticket engine when the tickets have been printed and shipped.

  • Microsoft passport/wallet—Maintenance of user information is performed by an outside service that can make that information available to gasTix on an as-needed basis. An example of such a service is the Passport site from Microsoft, which allows Web users to centrally store personal data.

  • Credit card processor—Authorization and actual charging of credit card transactions are provided by an outside agency. The credit card information is first obtained from the user or from Passport and then run through the processor.

  • E-mail application—A service is required for sending e-mails to customers as necessary.

Future Considerations

There are several other requirements for gasTix that, although not implemented initially, are important to consider when architecting the site to allow for adding these options. Following is a list of several such enhancements for gasTix that can be made in the future.

  • Advanced personalization—Develop a whole suite of services that allow users to customize the functionality of the site as well as obtain specific data of interest on an as-needed basis.

  • Extended product line—Eventually the company might want to sell (or link to someone who sells) related merchandise such as posters and t-shirts.

  • Internationalization—The company is planning to branch out into selling overseas and will therefore need to handle multiple languages and currencies.

gasTix Use Cases

The following use case diagram, shown in Figure 2.2, and related descriptions provide an overview of the requirements for the gasTix Web site. The descriptions provided here are not intended as detailed task lists, but, rather, provide a general overview of the Web site functionality from a user point of view. This section first provides definitions of the various actors and then covers each use case in turn.

The use case descriptions are organized into the following headings:

  • Actor—Lists the user(s) and system(s) responsible for carrying out the functionality described by the use case.

  • Assumption—Specifies the conditions that should have occurred before the functions in the use case can be carried out.

  • Purpose—Defines the basic objective that the use case accomplishes.

  • Outputs—Presents the expected outcome of the use case function.

  • Description—Provides the detailed explanation of the tasks involved in the use case.

Figure 2.2 The gasTix Web site provides a variety of services.

Actors

The actors involved in the various use cases are described here. Several of the actors represent outside systems with which gasTix will operate. These are:

  • Customer—Includes a user attempting to purchase tickets through the site.

  • Microsoft Passport Service—Includes both the Passport and Wallet sections for providing information about registered customers and their credit information.

  • Accounting system—Provides general ledger processing on behalf of gasTix.

  • Address verification service—Provides a check of user-supplied address data to ensure there are no irregularities.

  • E-mail system—Provides forwarding of e-mail messages as required.

  • Credit card processor—Provides the services for authorizing and charging credit cards for purchases made on the site.

  • Fulfillment service—Includes the capability to print and deliver tickets to the customers. This can include mailing the tickets as necessary.

Display Main Page

Actor: Customer, MS Passport

Assumption: None

Purpose: To show the main page according to the customer's defined preferences.

Outputs: The main page is shown.

Description: Whenever customers visit the main page, the Web site checks to see whether the users have successfully logged into MS Passport. If they have, the site checks to see whether the associated username is stored in the database along with the customer's selected preferences. If the preferences have been set, the list of the user's preferred categories is retrieved from the database. The main page is then displayed with only the customer's preferred categories displayed. If no Passport account is found or no preferences have been set, the main page defaults to showing all categories.

Select Event by State

Actor: Customer

Assumption: The actor can cancel this use case at any time.

Purpose: To select an event based on the state in which the event is located.

Outputs: Detailed information about a specific event.

Description: A list of states along with a graphical US state map is displayed to the customer. The customer selects a state, and a list of artist or team names with events in the state is displayed, ordered by category. The customer selects an artist or team name and the system displays a list of events for the selected name. The customer then selects a specific event and the system displays detailed information about that event.

Select Event by Venue

Actor: Customer

Assumption: The actor can cancel this use case at any time.

Purpose: Select an event based on the venue in which an event is being held.

Outputs: Detailed information about a specific event.

Description: The customer decides whether to search for the venue by name or by state/city and proceeds according to one of the following two paths:

  1. Venue search

  2. The customer inputs the name of a venue and issues the search for a venue command. The system determines that the number of characters input is greater than or equal to one character in length. If not, the customer is prompted to enter a venue name and must restart the process.

    Upon successful venue name entry, the system searches for the venue input by the customer. A list of venues is displayed to the customer if matches are found. A "no venues found" message is displayed if no matches are found.

    The customer picks a venue from the list of matches and a list of events at that venue with summary information is displayed. The actor then selects a specific event and the system displays detailed information about that event.

  3. Select venue by state/city

  4. A list of states along with a graphical US state map is displayed to the customer, who then picks a state. A list of cities with a covered venue is displayed. If no covered venue cities are found for the selected state, a "no venues found" message is displayed.

    Next, the customer selects a city and a list of venues is displayed. The customer picks a venue and a list of events at that venue with summary information is displayed. The customer then selects a specific event and the system displays detailed information about that event.

Select Event by Category

Actor: Customer

Assumption: The actor can cancel this use case at any time.

Purpose: Select an event based on the category of the artist/team.

Outputs: Detailed information about a specific event.

Description: The customer picks a category and a list of subcategories for that category are displayed. The customer then picks a subcategory and a list of artist or team names with events fitting the category is displayed. The customer then picks a specific artist or team name, and a list of events for that artist or team with summary information is displayed. The customer next selects a specific event and the system displays detailed information about that event.

Select Event by Artist/Team Name

Actor: Customer

Assumption: The actor can cancel this use case at any time.

Purpose: Select an event based on the name of the artist/team.

Outputs: Detailed information about a specific event.

Description: The customer inputs the name of an artist or team name and issues the search for artist/team name command. The system determines that the number of characters input is greater than or equal to one character in length. If not, the customer is prompted to enter an artist or team name and must restart the process.

Upon successful artist/team name entry, the system searches for the name. A list of names is displayed if matches are found. A "no artists/teams found" message is displayed if no matches are found.

The customer picks an artist/team name from the list, and a list of events for that name with summary information is displayed. The customer then selects a specific event and the system displays detailed information about that event.

View Seating Chart

Actor: Customer

Assumption: The actor can cancel this use case at any time. A venue must be selected in order to proceed with this use case.

Purpose: To provide the actor with a graphical view of the seating chart for a specific venue.

Outputs: A graphical display for the selected venue.

Description: The customer picks the view seating chart option for a specific venue. If a seating chart is available for the venue, it is displayed. If no chart is available, a "no seating chart available" message is displayed. The customer can view the different seating configurations for the venue, if available.

Check Pricing and Availability

Actor: Customer

Assumptions: The actor can cancel this use case at any time. A specific event has been selected in order to run this use case.

Purpose: Determine which seats are still available for a specific event and the price for those seats.

Outputs: A list of available seats and prices for a specific event. The Purchase Tickets Use Case begins immediately.

Description: The customer selects the section in which they want to sit along with the number of seats desired. The system then looks for the best available seats meeting the criteria. If the system does not find seats available, it will return a message indicating no seats found. If the system does find seats, it returns a message showing the seats and section numbers found. At this point the seats are marked as reserved by the system. A button is shown giving the customer the option to purchase the tickets at this time.

Purchase Tickets

Actor: Customer, MS Passport Service, Address Verification Service, E-Mail System

Assumptions: The actor cannot cancel this use case after the final purchase has been submitted. However, the actor can cancel at any time prior to final purchase. A specific event has been selected, and a pricing/availability check has been run for this event.

Purpose: Enable the actor to purchase a specific number of tickets at a specific price for a specific event.

Outputs: A confirmation of purchase for the selected event, pricing, and seating.

Description: The seats are collectively reserved for no more than five minutes to allow the customer the opportunity to provide the necessary purchase information. The reservation is lifted if the five minutes expire, if the customer conducts a new search, or if the customer closes his/her browser.

If the customer presses the purchase button, he or she is taken to the purchase screen. At this point, the customer enters the shipping option, billing address, and credit card information. Optionally, if this customer is logged in through MS Passport, the billing information is read from the personal account profile contained in Wallet and the fields are populated automatically. The customer will have the option to log into Passport at any time during this process. The customer will have the ability to edit the populated data.

NOTE

The seats are reserved in the Check Pricing and Availability use case rather than when the user selects the purchase button so that the seats aren't sold to another customer during the few seconds it takes to send the message to the Web site. This requirement is critical for events with extremely high interest in which tickets sell out in a matter of hours. Naturally, the five-minute time limit is then imposed to prevent the customers from reserving seats indefinitely.

When the customer selects the purchase button, the information is verified. The system verifies that a shipping option is picked, that required billing address fields are completed, and that credit card information is complete. If any of these items fail, the system displays an error message to the customers and provides them with an opportunity to fill in the required fields.

The customer's address data is also validated with the outside address verification service. If a success indicator or no response is received from the service, the address is considered acceptable. If an error is returned, a message is displayed stating that there might be an issue with the address data. The customer will have the opportunity to correct the data or to accept it as is.

The customer is then taken to a confirmation page detailing the purchase information. The customer can now accept or cancel the order at this time.

Once the system determines that all the information is entered correctly, the system calls the purchase ticket function. The credit card information is processed and the appropriate data is sent to the financial system. The system removes the seats purchased from the available list for the event. The system displays a confirmation and generates an e-mail with the same information to the customer. If any errors are encountered during the purchasing process, the purchase is rolled back and aborted. Any error messages are displayed to the customer, who is given the opportunity to resubmit the purchase if appropriate.

Request Ticket Delivery

Actor: Fulfillment Service

Assumption: A ticket purchase has been successfully processed by the system.

Purpose: Generates the request to deliver the tickets to the customer.

Outputs: A message to the fulfillment service.

Description: Upon completion of a successful sale, a request is generated to the fulfillment service to print and deliver them to the customer. The request must be confirmed by the fulfillment service as having been received. Otherwise, the request will need to be resent until it's successfully delivered.

Update Shipment Status

Actor: Fulfillment Service

Assumption: A ticket purchase has been successfully made and the ticket delivery request message has been sent to the fulfillment service.

Purpose: To update the system with the status of a ticket delivery request.

Outputs: An updated status in the system.

Description: The fulfillment service is required to inform gasTix of the status of a ticket purchase. The status is sent on two occasions:

  • A message is sent when the ticket is shipped to the customer.

  • Alternatively, if the ticket has not been shipped within a preset number of days, a status is sent providing an expected ship date. This message is resent according to an agreed-upon schedule until the tickets are successfully shipped. The purpose of this message is to ensure that the ticket delivery request has not been lost.

Delivery of this message must be guaranteed. Therefore, gasTix must acknowledge receipt of the message to the fulfillment system.

Set up Personal Account

Actor: Customer, Microsoft Passport

Assumption: The actor can cancel this use case at any time.

Purpose: Enable the actor to create a personal account for holding billing and contact information.

Outputs: A confirmation of the personal account creation.

Description: The customer picks the Create New Personal Account function. The customer is then taken to the MS Passport area where he or she will be prompted to either log in or modify their account information as appropriate.

Once the customer exits the Passport site and returns to gasTix, the actor's Passport username is returned. At this point, if the actor's username is not already stored, it is added into the system and a "personal account created" message is displayed.

Set Personal Options

Actor: Customer

Assumption: The customer selects the set personal preferences option. The customer can cancel this use case at any time. The user has successfully logged into the Microsoft Passport site.

Purpose: Allow the customers to set up their personal preferences for how the site behaves.

Outputs: A confirmation of the personal account update.

Description: The customer selects the set preferences option. A screen then shows all the categories available. The customer can then select those categories in which they are primarily interested. Once the selections are made, the customer commits the selection. The system then saves the personal account information and a "personal account updated" message appears.

Check Shipment Status

Actor: Customer

Assumption: None

Purpose: Allow the actor to see the status of a shipment.

Outputs: Shipment status

Description: The actor selects the check shipment status option. A screen prompts the customers for an order number. If the order is found, the status of the shipment is then provided. Otherwise, an error message is returned indicating that the order number is invalid.

Report Financial Transactions

Actor: Accounting System

Assumption: None

Purpose: To provide information about financial transactions for accounting purposes.

Outputs: An export of financial data for general ledger processing.

Description: At regular intervals, gasTix will compile data about all purchases since the last extract to the accounting system.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020