WebTaxi Design

from http://www.eventhelix.com/ThoughtProjects/WebTaxi/WebTaxiDesign.htm

WebTaxi is designed to use existing services to reduce the cost of development. The system uses a standard web server platform. Interfaces with all the services are implemented in terms of XML interactions. All the XML interactions take place over HTTP. This architecture greatly simplifies the deployment of the service.

The taxi software is implemented in an off-the-shelf PDA device that supports basic voice recognition. Support for voice recognition simplifies the taxi driver's interactions with the WebTaxi system. This is a lot safer too, as the driver is not required to press any buttons when operating the taxi. The Taxi PDA also interacts with Web services. No proprietary interfaces need to be supported as all the communication is using XML.

Why Web Services?

Perhaps the most radical feature of WebTaxi design is the extensive use of services. We will examine the advantages of using these services by examining the role played by two major services in our system:

  • Mapping Service

  • Mobile Messaging Service

Mapping Service is a standard service that allows us to compute the duration and time required for every taxi service. In addition to this basic functionality, the mapping service also takes into account current traffic conditions in finding the optimum route. It can also take care of road closures, road construction in advising about the routes. If we had used mapping software instead of a service, none of these real-time updates to traffic would have been available. In addition, loading the detailed city maps into every PDA would increase the memory requirements.

Mobile Messaging Service also simplified out design. We do not have to worry about different cellular standards when using the messaging service. The software just needs to specify the mobile number of the phone. The messaging service takes care of figuring out the exact interfaces with the service provider to the specified phone. The same thing applies on the Taxi PDA. Thus the WebTaxi system is insulated from cellular technology changes. If a new cellular, perhaps satellite technology becomes available, WebTaxi would be able to use this technology as soon as the Mobile Messaging Service supports it. This also simplifies the work for new cellular providers as they just have to provide an interface to the Mobile Messaging Service and all the service applications would directly work on the new cellular network.

WebTaxi Server Design

WebTaxi Server will consist of the following software modules:

  • Taxi Session Manager

  • Taxi Session

Taxi Session Manager

The Taxi Session Manager controls all the active taxi sessions. There is one Taxi Session Manager on the WebTaxi server. Whenever user requests a Taxi, the Session Manager creates a Taxi Session that independently handles all the operations related to finding and offering service. The session manager just needs to be notified when the taxi service is completed.

With this design in place, the system can easily handle sessions from thousands of taxis. The taxi manager just has to manage the instances of sessions. The Taxi Session object carries out all the session specific work. Another advantage of this design is in terms of scalability. The system can scale from a single machine handling the entire load to multiple machines handling the load. This distribution of load is possible because taxi sessions can be scheduled on different processors. The load distribution can be accomplished in several ways. We will be discussing the following two techniques in the section on scalability:

  • Symmetric Multiprocessor

  • Distributed Cluster

Taxi Session

  1. Taxi Session objects are created whenever the customer requests a Taxi service. A Taxi Session object just handles the operations of one taxi. This simplifies the design of this object.

  2. When the taxi session is created, it gets all the information about the taxi request from the taxi session manager. The taxi session then goes through the following steps to handle the session:

  3. The taxi session obtains a starting point to end point map from the mapping service.

  4. This information is then used to compute the total bill for the customer.

  5. This information is then sent to the customer as an HTTP post message.

  6. If the customer clicks ok, taxi session will start searching for the taxi.

  7. Taxi session will broadcast the taxi request. The maximum time to respond will be set to 5 minutes.

  8. If no taxi responds, the maximum time to respond is increased in five-minute increments.

  9. When taxis do respond, the taxi is selected by comparing their actual time to respond to the service.

  10. Once a taxi has been selected, the taxi driver is informed that he or she has been selected for the service.

  11. The taxi driver can accept or decline the service. If the service is accepted, the customer will be notified with an HTTP post that the taxi service will be available.

  12. When the taxi reaches the start of service point, it notifies the taxi session.

  13. Taxi session will e-mail/page the customer.

  14. The taxi session will also be informed about the actual start and end of service.

  15. When the service ends, taxi session will bill the customer and credit money into the taxi driver's account.

Taxi PDA Design

The Taxi PDA is a standard PDA device that supports wireless Internet access. The device communicates with the WebTaxi server using the Mobile Messaging Service. The device runs a service driver that allows the application to work transparently with different cellular technologies. The device also uses the mapping service to obtain mapping information.

But the most important aspect of the Taxi PDA is its GPS interface. GPS allows the Taxi location to be obtained with an accuracy of about 100-meter. The taxi location is obtained whenever a taxi request broadcast is received from the WebTaxi server. Using this information the taxi computes the time it will take to reach the service point. If the taxi is currently free, the time to reach the service point is computed by just mapping the current taxi location and the starting point. If the taxi is busy it has to add the remaining service time to the estimate. It may be noted that if the taxi is currently busy and it has already accepted the next taxi request, it will not respond to the broadcasts even if it can reach the starting point within the maximum stipulated time.

Scalability

When the traffic on the WebTaxi server increases we can upgrade to a symmetric multiprocessor. The multiprocessor could be connected to a database server that keeps track of the database about customers, taxi drivers. This configuration is shown in the figure below.

When the system traffic increases further, the website can be enhanced by using a frontend multiprocessor to run the session manager object discussed above. The taxi session manager will balance the traffic load between several middle tier processors. These processors will be running the taxi sessions. All the data context will be saved on a single multiprocessor database server. The database server will form the backend of the system. This three tier structure is shown in the figure below:
© Lynne Grewe