Expert One-on-One J2EE Design and Developmentfischli/courses/swa/swarch/ots/Requirements_J2EE_Sample_Application.pdfExpert One-on-One J2EE Design and Development Rod Johnson WROX

1

Expert One-on-One J2EE Design and Development Rod Johnson

WROX

Programmer to Programmer

Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 http://www.wiley.com

Copyright © 2003 Wiley Publishing, Inc., Indianapolis, Indiana

Requirements for the Sample Application We will specify an application realistic enough to provide the basis for worthwhile discussion of Java EE architectural decisions and a meaningful implementation exercise. This application has been designed from the business perspective (with generous input from a business analyst friend) rather than a Java EE technology perspective. Although it is simpler than a real application to avoid introducing irrelevant detail, it is more than an excuse to demonstrate a preconceived set of Java EE technologies.

1 Overview

The requirement is for an online seat reservation system for the X Center, an arts and entertainment complex that presents shows in a range of genres such as opera, concert, theater, and comedy. The X Center currently has three performance halls. Each has a default seating plan, used for most performances, but occasionally a particular show may vary this slightly. The seating plan for Mahler's Eighth Symphony might need to remove 20% of seats from sale to accommodate the choir. When Zanetti's circus performs, 6 seats from each row between the stage and the rear of the hall must be withdrawn from sale to make room for the caged walkway through which the lions move. This also affects which seats are considered adjacent.

The X Center is owned by the Z Group, an international entertainment company that owns many other theaters and entertainment venues. The Z Group views the online booking system for the X Center as a pilot, and hopes to use it as a basis for systems for its other venues. Hence from the initial release, this system must allow for rebranding. It must be possible to change the presentation of the site without changing the basic functionality, so that another theatre in the group could allow its customers to book tickets with presentation following that theatre's own branding.

Some of the X Group's other venues are in non-English speaking countries, so although there is no immediate requirement for internationalization, it will be necessary if the system is successful. Some venues are in multi-lingual countries such as Switzerland, so if the system is adopted in these venues it must allow users to choose their own language.

The X Center presently has no online ticketing system. Its 5 to 10 box office employees (more casual staff are employed during peak times) presently use a client-server system based around an Oracle database. No part of this system, except perhaps parts of the database schema, is likely to be reusable for the web interface.

http://www.wiley.com/

2

2 User Populations

The application must support three groups of users: public Internet users (customers); box office users (employees of the X Center who assist customers who have chosen not to purchase online); and administrators (employees of the X Center responsible for posting and updating data).

Public Internet Users

These users are customers, members of the public, accessing the service through a web browser. It is important that the system has acceptable response times. Customers wish: To find out what shows are on offer and access information about shows and performances To find out what performance dates still offer seating availability To book seats online, using a credit card

It is possible that premium services, such as the ability to book a larger number of seats in a single transaction, might be offered to a distinct "registered user" community in the future. However, in the initial system, registration is offered only as a convenience to save users re-entering their billing address. The priority is to ensure that the path to purchasing tickets is as straightforward as possible, hence users will not be forced to register, which may risk alienating them.

In order to fulfill these requirements, the system should offer a simple, usable, and fast web interface. It is important that this interface works on as many browsers as possible. Browser-specific functionality should be avoided, and the required browser level should be as low as possible without sacrificing functionality. Applets, Flash animations and the like are considered likely to deter users, and should not be used.

Box Office Users

These are employees of the X Center, who work within the X Center itself, and are on the local network. Some employees may work from home, in which case they will have access to an Internet connection. Box office users perform the following activities: Respond to phone and over-the-counter enquiries by members of the public, principally on the

availability of seating. To support this task, box office users must be given powerful query functionality unavailable to public Internet users, to enable them quickly to respond to questions such as, "What is the first date on which I can have 25 adjacent B Reserve seats to Carmen?"

Sell tickets to members of the public who wish to see a show. Supply tickets to customers who booked online but chose to collect the tickets from the box office

instead of having them delivered by post. This is also necessary for late bookings, when there isn't time to post out tickets.

Occasionally, cancel reservations on phone request.

These users are primarily concerned with service reliability and usability. They receive a constant flow of enquiries from customers who expect to be serviced when they call. Thus it is essential that the public Internet interface should not reduce the reliability or performance of the box office interface.

As box office users can be given training on how to use the system, the priority should be functionality, rather than ease of use. Box office users must be given a powerful system that offers a quick way of performing common tasks. As the box office interface is for internal use only, there should be less emphasis on its branding and cosmetics.

The X Center management team wishes to maximize their IT investment and so believe that the same online ticket reservation system should service public Internet users and box office staff. Box office users, like customers, will use a web interface. This interface will be protected from Internet users via role-based security, and will have a separate entry point from the public Internet application. The system will automatically grant the appropriate privileges, based on username and password.

3

Administrators

These are employees of the X Center in which the ticketing system will be in operation. Admin users must be located within the X Center itself, accessing the local network. They fulfill a variety of clerical, marketing and management functions: Add new shows and performances Run management information and financial reports Configure settings of the ticketing system; such as the maximum number of tickets that can be

purchased in one transaction, and the period of time tickets can be reserved before payment is made

The X Center's management wish to use a consistent technology set within their system to minimize the number of skills their IT department requires, hence they would prefer that the same web technology was used for the Admin interface as for the customer and box office interfaces, rather than another technology such as Swing or VB. Management is also keen that the Admin interface should require no installation; authorized staff should be able to access it on any machine within the X Center building, and it should require no rollout process and ongoing updates.

The Admin interface will offer the additional security of running on a port accessible only within the X Center's firewall. This means that the Admin must run in a different web application (although possibly still on the same physical server). The Admin interface will be centered on the Oracle database, which will be its main means of communication with the other interfaces. As the X Center already has some Oracle skills in-house, the development of the Admin interface can be deferred until Phase 2.

3 Assumptions

Let's now consider the following assumptions: Internet users will not be required to accept cookies, although it is expected that most will. Seats for each show will be divided into one or more seat categories, such as Premium Reserve.

Seating plan and the division of seats into categories will be associated with shows, not individual performances.

All seats within the same category for the same performance will be the same price. However, different performances of the same show may have different price structures. For example, matinees may be cheaper than evening performances, to attract families.

Users will request a given number of seats of a chosen category for a specified performance, and will not be allowed to request specific seats. Users will not be allowed to provide "hints" for seat allocation such as "towards the front and on the right rather than the left".

Users requesting seats will be assumed to want adjacent seats, although they will be offered whatever is available if sufficient adjacent seats cannot be allocated. Seats are not considered to be adjacent if they are separated by an aisle.

Internet customers will not be able to cancel a booking once payment has been processed. They must call the box office, which will apply the X Center's policies regarding cancellation and refunds, and use the box office interface to cancel bookings when this is allowed.

4 Delivery Schedule

The X Center's management has determined that having a true online ticketing solution is a business priority. Thus they have determined a delivery schedule to ensure that the public system comes online as soon as possible. This schedule calls for the application to be delivered in three phases: Phase 1: Core Internet user interface, as described in the next section, and the box office

interface. Phase 2: Admin interface. In Phase 1, no GUI will be available to Admin users; they will need to

work with the database using Oracle tools. Development resources will be available to support Admin users in these tasks during Phase 2 development.

4

Phase 3: More sophisticated Internet interface. This will offer registered users premium services and add internationalization support.

The sample application will extend only to Phase 1. The whole of the core Internet user interface will be implemented, and part of the box office interface (which won't be fully defined here). However, the sample application must define an architecture that will provide a basis for the later phases, so their requirements must be considered in the meantime.

5 Internet User Interface

Let's look in detail at the public Internet user interface. This illustrates many common issues in building Java EE web applications.

Basic Workflow

Although I've used UML state diagram graphics, each box represents a screen presented to a user successfully choosing a performance and purchasing a number of tickets, rather than a state. The following diagram shows an Internet user successfully booking seats:

Users are initially presented with the welcome screen, a list of all genres (such as Opera) and shows (such as Wagner's Tristan und Isolde) playing at the X Center (see Application Screens below for screenshots). Users can then proceed to the display show screen, which shows all performance dates for a given show, along with the categories and prices of seat on sale and the availability of each category of seat. This screen should indicate only whether each category of seat is available or sold out, not the number of seats remaining. This meets the needs of most users while avoiding disclosure of sensitive business information – for example, those tickets to a particular show might be selling poorly. Users can request a number of seats of a given category for a particular performance, in which case these seats are reserved to allow time for online credit card payment.

The system distinguishes between the concepts of reservation and confirmation/purchase in the booking process. The user can reserve seats for a performance for a period of time (typically 5 minutes), which will be held in system configuration. Reservation protects these seats from being shown as available to other users. Confirmation occurs when the user provides a valid credit card number, at which point a reservation becomes an actual purchase. Reservations are held in the database and in the user's session state. Reservations must either: Progress to bookings as a result of confirmation. Expire, if the user fails to proceed to purchase in the given time. These seats will then be

available to other users. However, the user who made the reservation may still purchase the seats without seeing an error message if they are still free when (s)he submits the payment form.

Be cleared, as the result of user activity other than continuing on to purchase. For example, if a user makes a reservation but then navigates back to the display show screen, it is assumed that (s)he does not want to proceed to purchase these seats, and that they should be returned to fully available status.

5

Error Handling

In the event of a system error (such as the Java EE server failing to connect to the database), the user should be shown an internal error screen consistent with the current branding. This should advise the user to try again later. Support staff should be notified by e-mail and through the log file record in the event of serious problems. The user must never see a screen containing a stack trace, "500 Internal Error" or other technology or server-specific error message. A user requesting an invalid URL should see a screen consistent with the current branding advising that the requested page was not found and containing a link to the welcome page.

Application Screens

Let's now take a closer look at the workflow in the public Internet interface. The following diagram is a more detailed version of the previous diagram, and shows all screens available to the Internet user, and the transitions between them:

The additional detail concerns failures to complete a booking and the optional user registration process. The user can fail to proceed to reservation or confirmation under the following circumstances: The user requested the display show screen and left a long delay before following one of the links

to the book seats screen. By the time they proceeded to this screen many more seats had been sold and requested category of seat was no longer available.

The only seats that can be offered to the user are not adjacent. The user does not wish to accept this, and follows the try another date link back to the display show screen. The unwanted reservation should be cleared and the user must begin the booking process again.

The user made a reservation, but failed to submit a credit card number in the lifetime of the reservation. This is not a problem unless the seats have been reserved or purchased by another user. In this case, the problem is explained to the user, who is reassured that their credit card was not debited and offered a link to the display show screen.

The user enters a credit card number in a valid format, but the transaction is declined by the credit card processing system. In this case, the user will be informed that the credit card payment was declined and that the reservation has been lost. The reservation is cleared, and the user must begin the reservation progress from scratch.

The registration process is optional. It allows users to enter a password to create an account that will save them entering their billing address and e-mail with each purchase (other premium services may

6

also be offered to registered users in the future). Users should not be forced to register to purchase tickets, as the management feels that this may reduce sales.

Registration will be offered after a user who is not logged in, and who has provided an e-mail address not already associated with a registered user, has made a booking. The user's username will be their e-mail address, which is entered in the course of the booking process. When a user registers and the application detects that the user's browser is configured to accept cookies, their username will be stored in a persistent cookie enabling the application to recognize their registration status on subsequent visits and prompt for a password automatically. This prompt will be introduced into the registration process through a distinct screen between the reservation and payment details screens. The following rules will apply: If the user is logged in, billing address and e-mail address (but not credit card details, which are

never retained) will be pre-populated on the payment details form. If a persistent cookie containing the user's e-mail address is found but the user is not logged in,

the user will be prompted to enter a password, before proceeding to the payment details form. The user can choose to skip password entry, in which case the persistent cookie will be deleted and the user will see an empty payment details screen.

If the user isn't logged in and doesn't have a persistent cookie, there should be a link on the show reservation page to allow the user to try to log in by entering both username and password before seeing the payment details screen. In the event of successful login, a persistent cookie will not be created.

The screenshots that follow the table present all the controls and information required on each page. However, they do not fully define the presentation of the application: for example, these screens might be used as the content well, with a custom header and side columns being added. There may be more than one such branding: it is a business requirement that the technical architecture allows this cost-effectively.

The discussion of each screen concludes with a summary of the required handling of some common issues with web interfaces, in the following format:

Screen name The name of the screen as discussed and shown in the diagrams above. The table describes the outcome of a request that will lead to this screen if successful.

Purpose What the page does (for example, "display user profile").

Alternative screens Alternative pages that may result from a request that would normally produce this page (for example, the behavior resulting from invalid form input).

URL URL of the page within the web application, such as /welcome.html. Note that although the chosen extension is html, all pages are dynamic.

Data displayed The data displayed on this page, and where it comes from (database, user session etc).

Requires existing session state

Yes/No.

Effect on existing session state

What happens to existing session state (such as a seat reservation) following a request to this page?

Effect of refresh/resubmission

What happens if the user refreshes this page?

Effect of the back button What happens if the user hits the back button?

Parameters required Lists the names, categories, and purpose of the parameters required.

Effect of invalid parameters

What happens if the expected request parameters are missing or invalid?

7

Welcome Screen

This page provides an index of all shows and performances currently available. It may also include static information and links about the X Center. The aim is to minimize the number of pages the user has to work through to perform common tasks, so this page allows direct progress to information about each show, without making the user browse intervening pages:

The page must be dynamic: genres and shows must not be hard-coded in HTML. The number of genres will not be so great in the immediate future that having a separate drop-down for each genre is likely to become unworkable. However, the system architecture must support other interfaces, such as splitting this page by having a separate page for each genre, if the number of genres and shows increases significantly. The user's first impression of the system is vital, so this page must load quickly:

Screen name Welcome

Purpose Display all genres and shows. If there are no current shows in a genre, that genre should not be displayed.

Alternative screens None.

URL /welcome.html. This should be the default page if the user does not specify a URL within the application.

Data displayed Dynamic genre and show listing from database; static information determined by HTML presentation (such as a photograph of the X Center).


No.


None.


Page should be marked as cacheable by the browser for 1 minute. Requests received by the web server should result in the generation of a page.

Effect of the back button Irrelevant. The user has no session state for the application.

Parameters required None.


Parameters to this page will be ignored.

8

Display Show Screen

This screen will allow the user to choose a performance date for a show in which they are interested, and proceed to make a booking. It will also provide information about the show in question such as the history of the work being performed and cast information. It is expected that some users, reluctant to use their credit cards online, will only use the Internet interface to this point, before calling the box office to purchase tickets on a given date; this is an additional reason for providing comprehensive information on this page:

No support is required for pagination in Phase 1 (although this is a potential refinement later); the user may need to scroll down to see all performances. For each performance, there is normally a hyperlink from each category of seat to the booking page. A superscript is used in place of a hyperlink to indicate that the given category of the given performance is sold out:

Screen name Display Show

Purpose Display information about the show. Display a list of all performances of the show, with availability (available/sold out) of each seating category. Include a legend explaining the cost of each category of seat.

Alternative screens None.

URL /show.html.

Data displayed Dynamic performance and seat availability information, from database. HTML-format information about the show the user is interested in. This

must be legal HTML within the content well, and may contain internal and external hyperlinks. This will be maintained by non-programmers with HTML skills. The URL of this document within the web application should be associated with the show in the database. If no URL is specified in the database, the seating plan for the performance should be displayed in place of show information.


No.


Any existing reservation will be cleared without notifying the user. However any existing user session will not be destroyed.


Page should be regenerated by the server.

Effect of the back button

Irrelevant. The user has no session state for the application.

Parameters required id (integer): the unique id of the show.

9


Parameters other than the show id should be ignored. If no show id is supplied or if the show id is non-numeric or out of range, a generic invalid request page will be displayed, with a link back to the welcome page. This cannot happen in normal operation, as the user should only arrive at this page as a result of hitting one of the Go buttons on the welcome page.

Book Seats Screen

To arrive at this screen, the user selects a performance date and ticket category by following a seat category link – in the screenshot above, one of the AA, A, B, or C links in the table on the right:

Screen name Book Seats

Purpose Provides a form that enabling the user to request a number of seats of a given category for their selected performance.

Alternative screens If no tickets are available for this performance, a simple screen should say that that category of ticket is sold out and provide a link back to the display show screen.

URL /bookseats.html

Data displayed The name of the show and the date of the performance. The name of the ticket category (such as Premium Reserve) and its unit

price. A dropdown with a default number of tickets selected. The default value

can be set by the Administrator, and should be configured to 6 seats in the application's factory settings. The value initially displayed in the dropdown should be the lower of the default value and the number of tickets of the requested category left (for example, if the default has been set to 8 and only 7 seats are left, the selected value will be 7). The range of the values in the dropdown should be from 1 to the lower of the number of tickets left and a default maximum set by the administrator. A typical value of the default maximum for seats purchased in the same transaction might be 12, to discourage scalpers.

Requires existing session state.

No.

Effect on existing session state.

Any reservation will be cleared. However the session will not be destroyed.

Effect of Page should be regenerated by the server. It is important that this page

10

refresh/resubmission always provides up-to-date information on seat availability (implicit in this screen appearing at all, and shown in the values in the dropdown), so no caching is permissible.

Effect of the back button.

Irrelevant. The user has no session state for the application.

Parameters required. id (integer): the unique id of the show. category (integer): the unique id of the seat category.

Effect of invalid parameters.

Parameters other than the show id and seat category should be ignored. If either parameter is missing, is non-numeric, or is out of range, a generic invalid request page will be displayed, with a link back to the welcome page.

Show Reservation Screen

This screen results from the successful reservation of the number of seats requested. This is the first operation resulting in the creation of session state:

Screen name Show Reservation

Purpose Informs the user that (s)he has successfully reserved a number of seats.

Alternative screens If no seats are available (because the user delayed in submitting the form, and the performance filled up), display a screen explaining the problem and prompting the user to try another date. In this case, no reservation will have been created, and the user will not have session state.

URL /reservation.html

Data displayed The name of the show and date of the performance selected. The number and names of the tickets requested.

The total cost of the tickets.

Whether or not the seats are adjacent. If the seats are not adjacent, this should be explained to the user and a link should be provided to allow the user to try another performance date. The seating plan will enable the user to work out how close these seats are (for example, B25 to B28 may be an acceptable gap; A13 to Y40 may not).

11

Seating plan (including all seat categories) to enable the user to work out the position of the seats. This seating plan will not be dynamic in Phase 1: there is no need to highlight the position of the reserved seats.

Login link if the user doesn't have a persistent cookie and isn't logged in. This will enable the user to log in before proceeding to the payment screen.


No. The generation of this page will create session state if none exists.


If the user has an existing reservation, it is cleared before processing the new seat request. It should be impossible for a user to have more than one simultaneous reservation in his/her session state or in the database.


On resubmission, the application should notice that the reservation held in the user's session matches the request. An identical screen (except that the expiry time of the reservation should be shown rather than the length of the reservation period) should be returned without any updates in the database. The lifetime of the reservation will not be prolonged.


Parameters required id (integer): the unique id of the show. category (integer): category we wish to reserve seats for.

count (integer): number of seats requested.


Parameters other than these should be ignored. A generic invalid request page will be displayed, with a link back to the welcome page if any of the required parameters are missing or invalid, as this should not happen in normal operation.

Payment Details Screen

Note that the password prompt or login page may appear before this page, and may result in pre-population of address and e-mail fields for logged in users. Credit card details will always be blank, as they are not retained under any circumstances:

12

Screen name Payment Details

Purpose Allows a user who has successfully reserved seats to pay for tickets and provide an address to which they can be posted.

Alternative screens A user who isn't logged in but has a persistent cookie will be directed to the password prompt page before arriving here.

A user who isn't logged in but selected the login link from the show reservation page will be directed to the login page before arriving here.

URL /payment.html

Data displayed Name of show and performance. Number of seats reserved.

Price of seats.

User profile data if the user is logged in. Otherwise all fields will be empty.


Yes. This page should only be shown if the user has a reservation in her session. Requesting this page without a session or without a reservation should result in a generic invalid request page.


None.


Page should be regenerated by the server. If the reservation held in the user's session has expired, the user should be shown a page indicating this and providing a link back to the "display show" page.


Parameters required None. This page depends on session state, not request parameters.


All parameters will be ignored.

On an invalid submission, this page will be redisplayed, with the missing or invalid field values highlighted and an error message for each field explaining the problem. The exact means of highlighting errors is a detail to be decided later. However, the system should support different styles of highlighting.

All fields are mandatory except line 2 of the address. The following validation rules are to be applied on submission of the form on this page: Credit card number is 16 digits. Credit card expiration date is 4 digits. Postal code is a valid UK postcode format (for example SE10 9AH). However, no attempt will be

made to check that this is a real postcode (Submissions that look like UK postcodes may be syntactically correct but semantically meaningless). It is the user's responsibility to enter their address correctly. In subsequent releases, other countries must also be supported, and postal code validation must be implemented based on the country selected from a dropdown. Only a fixed subset of countries will be supported, as the cost and reliability of posting tickets to some countries is considered unacceptable.

E-mail address must pass simple validation checks (that it looks like an e-mail address, with an @ symbol and dots in the right place). However, the transaction can still succeed even if the e-mail address does not prove to work; ticket purchase should not block while a test e-mail is sent.

No attempt will be made to validate the credit card number's checksum. This is a matter for the external credit card processing system.

13

Confirm Reservation Screen

This screen confirms the user's ticket purchase and provides an electronic receipt:

Screen name Confirm Reservation

Purpose Confirm the user's credit card payment. Provide a reference number. Allow the user to register if the user isn't logged in (a logged in user will not see the content under the ruled line).

Alternative screens If the credit card number is in an invalid format or if mandatory fields are missing or invalid, the payment screen is shown again, populated with the rejected values.

If the credit card is in a valid format but payment is rejected by the credit card processing system, the user should be sent to the payment rejected screen and the reservation cleared. This is treated as the end of the reservation process. The attempt to use a questionable credit card number should be prominently logged for the system administrator to see.

If the user's reservation has expired but the tickets are still available, payment will be processed as normal. If tickets have been sold to another user, the user will be directed to the seats gone page, and the expired registration cleared from the user session. The user's credit card will not be debited.

URL /confirmation.html

Data displayed Seats reserved; booking reference; price paid; user's e-mail address (the e-mail address will not allow modification if the user is logged in). Only the last 4 digits of the credit card number should be displayed. For security reasons, the credit card number should never be held in the users session or in the database.


Yes. A seat reservation must be found in the session, and the price must match the payment offered.


The reservation will be removed from the session object, as it will have been converted to a confirmed booking in the database. The user profile object will be retained in the session, which must not be destroyed. A logged in user will remain logged in.

14

If a logged in user changed their profile (either of the addresses) the database should be updated automatically with the new information.


Resubmission must be prevented, to avoid any risk of debiting a user's credit card twice.


Resubmission of this form will be impossible, so the back button should cause no problem.

Parameters required Parameters described under discussion of payment screen.


See discussion of payment screen.

6 Box Office User Interface

The box office interface should enable queries and operations such as the following: For a given show, display the total number of seats of each category available for a given date, as

well as the 5 longest runs of adjacent seats (for example, this would enable a box office user to tell a caller that they couldn't have 18 adjacent seats, but could have groups of 16 and 2 or 10 and 8).

For a given show, show the first date on which a given number of seats (adjacent or non-adjacent) of a given category are available.

Cancel a booking, given the booking reference (the box office user will first be enabled to view the booking data).

The box office interface's welcome page (after mandatory login) should offer immediate access to all common queries.

Each screen in the box office interface should prominently display the time at which it was rendered, and the box office interface must not implement caching of seating availability: box office staff must always have access to up to date information. Each screen in the box office interface relating to a show or performance must display the relevant seating plan. Only those features of the box office interface described above need be implemented for the sample application.

7 Non-Functional Requirements

Normal activity is fairly modest. However, at peak times (such as when a new performance by a major star is listed), the site may experience sharp peaks of user activity. Such activity will often center on a single show, meaning that the performance requirements for the show page are almost the same as the welcome page. The following table shows the minimum performance requirements for the most performance-critical pages of the public Internet interface:

Page Hits per second

Response Time (secs)

Welcome 2 3

Display Show 2 5

Book Seats 2 5

Show Reservation 1 5

Payment Details 1 5

Process payment details 1 30

(The performance of the payment processing will partly depend on the speed of the external credit card processing system.)

15

These are the minimum targets that will meet the immediate business requirements. The aim should be to far exceed them with a single Intel-based server running the application server, demonstrating the potential of the system for wider use within the Z Group (the database will be running on a separate machine).

Special attention must be paid to performance characteristics under concurrent access, and especially to the following scenarios: Heavy activity for one show or even one performance. This is a realistic possibility – for example,

if a movie star makes a guest appearance on a single night during the run of a play. Supporting concurrent requests for seats when a performance is almost full. This may result in

multiple users trying to reserve the same small group of seats. It is vital that this does not seriously impair overall performance, and that the reservation database cannot be corrupted.

Effect on the box office interface of heavy load on the public Internet interface. It is vital that box office staff is able to do their job without being hampered by slow response times.

If necessary to achieve adequate performance, the following trade-offs are acceptable: A new show or performance added by an Administrator may take up to 1 minute to show up on

the web interface. However, the system must not require a restart. The availability or lack of availability, of seating for a particular category (as shown to public

Internet users on the display show page) may be up to 1 minute out of date, although any time lag should be avoided if possible.

As cancellations are fairly rare, the remote possibility of a user failing to book a seat because the desired category was marked as sold out, when in fact availability reappeared within 1 minute of the user requesting the display show page, is deemed to be acceptable in the interests of performance. The slightly greater possibility that the performance may have sold out after the data was cached is not considered a serious problem: after all, the user could have answered the telephone or discussed the performance dates with friends and family prior to following the link for a given performance date and seat category. Such delays will often be much longer than 1 minute.

8 Hardware and Software Environment

The target application server will be JBoss 5.1.0, integrated with the Tomcat web container. Management is keen to minimize licensing costs, especially as the application may be deployed on a number of sites. The application may need to be ported to another application server in the future, so the design must not be dependent on JBoss. Should such porting be required, a small budget will be allocated for any code changes required and for testing on the new platform. If possible, the application should be verifiable as Java EE-compliant to reassure management that portability is achievable.

The X Center does not presently have its own web-facing hardware. Appropriate hardware will need to be purchased based on performance analysis; management is keen to minimize cost by maximizing performance per cost of hardware.

The application should support clustering if this becomes necessary as demand increases, but management expects that the performance figures described can be exceeded on a single server. All machines in any server cluster would be within the same local network.

The database will be Oracle 11g, as the X Center already has an Oracle license and Oracle expertise in-house. There is no likelihood of migrating to another database in the foreseeable future. The Oracle database already runs on a Sun server, and this will not change, regardless of the chosen hardware for the web server. The database server and application server(s) will run on the same local network, so rapid connectivity can be assumed.

There are no other constraints regarding technology to be used. Management have made a strategic decision to adopt Java EE because they believe it offers the best chance of successful integration with the legacy booking systems at the other venues with the X Group, but have no preconceptions on how Java EE should be used. Whether to use technologies such as EJB, JSF, and XSLT is a technical

16

decision. As the project will involve building a team, no constraints regarding existing Java EE expertise (such as "strong JSF experience, no EJB experience") need be considered.

A number of the X Center's staff has HTML skills, but are non-programmers. Therefore it is important that HTML content and site presentation can be controlled, as far as possible, without the need for more than a superficial understanding of Java EE technologies.

Documents

Expert One-on-One J2EE Design and Developmentfischli/courses/swa/swarch/ots/Requirements_J2EE_Sample_Application.pdfExpert One-on-One J2EE Design and Development Rod Johnson WROX