Project 1c: Timed and Background Activities

This is the third step of the Project. In this step you will implement timed background activity required to learn about new events and to determine the outcome of events after their scheduled time.

In addition, you will design odds-setting logic and interactions with the “Bank”.

You won't (yet) use WSDL-described Web Services™ or UDDI. That is deferred to the next (and final) part.

Due: 28 April 2005.

Simulating the Web Services

For debugging, you will simulate external Web Services using a few temporary tables in your database. These tables will represent state of yet-to-be-implemented Web Services. You can use Enterprise Manager or Query Analyzer to initialize and examine the tables to verify that your application is working correctly.

Providers

There will be a number of event provider services that supply you with initial definitions of events, and later with their outcomes. You can represent them by a providers table with schema:

• The prid column is a unique number identifying the provider.
• The evid column is a globally-unique event identifier (which should match the primary key of your Event EJBs).
• The opentime and schedtime, of type DATE, represent the time at which betting is opened (no wagers may be accepted before this) and the time the event is scheduled to happen.
• The description is a STRING containing a user-readable description of the event. This string is displayed to the user.
• The outcome is an integer value between 0 and 2 representing the outcome of the event: 0 = not happened yet, 1 = first participant wins, 2 = second participant wins.

Each provider Web Service manages information about a subset of the events. It has methods that will

• return information about the next event (known to the provider) whose opentime is after a specified time.

  This can be used to learn about new events. We assume events are made public in opentime order. Note your application will need to keep track of the most recent opentime it has learned about from each provider. The provider will not keep track of this for you.

• return the information about an event given its evid.

  This can be used to learn the outcome of an event in order to decide whether to bill or pay your customers. It is your responsibility to contact the event provider after the event has taken place; the provider will not contact your site in any way.

Each of these methods has a simple implementation as a SQL query on the Providers table.

The Bank

We assume all customers use the same bank. We can represent it by the bankaccounts table. The schema is

• The account number column matches the customer EJB account number field.
• The balance column.

The bank Web Service has methods to

• return the balance of an account identified by its account number.

  (This is an offshore bank in a country with no privacy laws.)

• deposit or withdraw a specified amount from an account identified by its account number.

  (I agree, I wouldn't put my money in this bank either …).

Again, each of these methods has a simple implementation as a SQL query on the BankAccounts table.

Timed Activities

Your site will need at least two time-driven activities.

1. Periodically, your site must check for new events to be made available to your customers.
2. After the scheduled time of each event (on which any wagers have been made) your site must contact the provider to determine the outcome of the event, and then pay or bill your customers as appropriate. You might even notify the customers by email.

You should use the EJB 2.1 services:

javax.ejb.TimedObject
javax.ejb.TimerService
javax.ejb.Timer

to implement these features.

For now, your ejbTimeout methods will simulate any necessary Web Services invocations using the database tables described above. But keep in mind that the next part of the project will connect to real Web Services.

Note: You should think about what happens if a customer tries to place a wager on an event just before the event is scheduled to happen. There is a potential race condition here. Be careful!

Setting the Odds

Your business wants to avoid bankruptcy. Thus, you need a sensible algorithm for setting the odds at which you are willing to accept wagers.

This is an amusing problem to think about. How does a casino maximize its expected profit? A little use of Google™ can be helpful here, or you can simply invent your own algorithm. Describe it, and argue that your rules bound the house's loss (whatever the outcome of the event) and tend to maximize your business' profit. Put the description into a file oddsalgo.{txt,pdf,doc} in your submission. Note I'm not demanding a deep game-theoretic analysis here!

General Appearance

At this point your site can almost start to look “real”. Once a user has identified herself, you can display a list of open future events, with the description and current odds for each event, and a “make a wager” button for each event. You can also display a list of the customer's outstanding bets, the bets she has recently won or her remaining credit limit, and so forth.

What to Submit

Create a .zip archive called proj1c.zip containing the following:

• your new database schema
• the source files of your EJBs and deployment descriptors
• your oddsalgo.{txt,pdf,doc} file
• a screen shot of your website showing a customer's page with multiple events available for wagering and multiple outstanding wagers.

Submit the zip file to CMS by the due date.