Like this article? We recommend
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.
){kind=link}
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.
){kind=link}
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:
Venue search
Select venue by state/city
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.
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.