1. Goals

As the Billing / Pricing / Accounting team, our goal was to efficiently handle the billing of users of the MIA system and maintain a reliable storage device for all transactions. We planned that this would involve keeping track of all connections that utilized MIA applications and basic functions, which includes two-party regular computer-to-computer calls, GSPOT service, phone-to-computer calls, and conference/group calls. To this end, we would also need to develop our own fair pricing schemes through which all billing would follow. In addition, reliability was to be taken into consideration.

In order to keep track of all connections, we required an observer to sit on the signal server and every application and relay to the billing server all relevant messages. Relevant messages would be defined as those signifying a call being initiated or a call concluding. The observer would be some application which the billing server could establish a socket connection to in order to communicate with it. When a call is initialized, the observer would communicate with the billing server and the billing server would record that a call began. When a call is concluded, the observer would again notify the billing server which would locate the record for the call, complete it with pertinent information (such as the length of the call and the cost), and then save the transaction in a reliable storage device.

For pricing, we realized that developing fair pricing schemes would be best supported by research into current schemes. We planned to search the internet for these and research papers on internet pricing. For simple connections involving two parties, we planned to use a scheme dependent upon the time of day in some manner to account for periods of high traffic / bandwidth demand. For conference / group calls, we planned to make the cost dependent upon the number of users in a group.

Reliability was also a major goal for our system. This we defined to mean the database would remain uncorrupted and data within would be accurate and trustworthy. It would also involve secure access to the database and secure transmissions between clients and the billing server to maintain trustworthy transactions.

 

 

 

 

 

 



 

 

 

 

2. Accomplishments

Our areas of accomplishments mirrored all of our goals and even went above them with the addition of a Graphical User Interface for facilitating management.

Communication between the billing server and its multiple clients went through many different versions before we were able to settle on using Message Centers. Message Centers are objects developed by the Signaling Team that handle all communication between signaling, directory, billing, management, and all applications by sending Java Serializable Objects called Messages through reliable socket connections. Message Centers are located on all major servers and observers from the different teams are created to listen in on messages that pass through. These observers are called Listeners and the Billing System has one on the signal server Message Center (called BillingClientSignal) and on every application (called BillingClientApp). On startup, the Billing Server uses its Message Center to send a Message to the BillingClientSignal giving it the location of the server (this is the address to use whenever a message is to be sent through the Message Center to the Message Center located on the Billing Server). With this information, new applications can start up with a BillingClientApp and contact the Signal Server to register themselves. Hidden in the communication, the BillingClientApp communicates the BillingClientSignal to get the address of the Billing Server. Then, the BillingClientApp contacts the server, registers the current user, and is ready for communication with other computers and phones.

Communication is handled using Messages specifically for the Billing System. These contain information extracted from Messages that pass through the corresponding Message Centers. To ensure trustworthy communication, an authentication algorithm is utilized on all messages. This is discussed below under Authentication.

Database access and usage was a major part of the Billing System, our goals, and our accomplishments. To access databases, we use JDBC, which neither of us was initially familiar with. All access to the database is handled by a direct connection to Microsoft Access and to the MIA Billing Database. This database maintains a list of all registered users and their IP Address which is known when an application starts up. There are also tables which contain all calls made by a specific user and the cost and service of each, as well as the time of the calls and with whom the user talked to. Separate tables are used to keep track of all calls involving two parties currently active. This is used by the Billing Server to keep track of calls that have started and to locate the information about them when they end. Another utility table is the group table which lists all groups that are currently active and contain at least one person. These expand to sub tables which contain lists of all users in the group and the billing scheme for them. This billing scheme records the times of every change in the size of the group and the size at any time. This is necessary to produce a fair pricing scheme for conference calls.

The database is secured with a password at initiation to prevent unauthorized external access and is robust in its SQL queries and updates. Every SQL command is treated as an atomic command, one that either is completely executed or not at all. This is handled by commits and rollbacks on database transactions to prevent corrupt data from ever being in the database.

We have implemented a PricingManager that encapsulates all the pricing policies and related details. PriceManager provides all the static variables and methods that are used/called in order to compute the price of various services.

The PriceManager implements the following basic pricing policy for two-party call:

For multi-parties call (conference call) , PriceManager implement a separate pricing policy as following:

The pricing policy seeks to price discriminate conference call of larger group and also the users who want conference service at all (e.g having the flexibility for others to join the conference later, a two-party conference costs 50% more to each user than a plain two-party call service). As the conference group changes its size over time, the users will be charged accordingly for each time segment based on the membership of the group and the basic rate at each time segment.

For PowerPoint presentation with audio (GSPOT), PriceManager implement the following pricing policy:

The pricing policy seeks to price discriminate users who really need the service ( GSPOT service is 200% more expensive than regular call service) and it charges the receiver instead of the sender. The idea is that information can be bought through a series of PowerPoint slides where the slides can be delivered across the network on receiver’s demand and at receiver’s expense.

The PriceManager handles calls of different service types that span across different basic price rates. Calls that lasted for less than a minute will not be charged.

We have implemented a Graphical User Interface (GUI) using JavaSwing for retrieving a specific user billing information from the Access 97 billing database. The requested information is then shown on the screen. The information can then be printed or sent by email to the user as a Word97 file attachment.

The administrator gets to view the bill for a specific client, for a specific month and for a specific year. The administrator gets to choose a user from a dynamically generated user list in a combo box. New user can now register with billing with the administrative tool available on BillingGUIManage. Every time a new user registers with BillingGUIManage, his or her name will appear in the combo box after the refresh command is selected from the menu.

Although the screen displays only one page at a time, BillingGUIManager does provide convenient navigational buttons for viewing multi-paged bills.

BillingGUIManager also provide access to read and modified the pricing rates for different services. However, pricing rates modification can only be occur when there are no active connections. Administrator will be warned and stopped if tries to modify price rate while there are users with active connections.

BillingGUIManager shows in a table, in real time, which users are making calls and how much is the cost for each user as well as what type of services is the user using. The most updated list of active user can be obtained by executing refresh command from the menu.

Each important visual component of the BillingGUIManager has its own tooltips with helpful hints on how to use the component. Positioning the mouse cursor over a component, say a button, will trigger a small floating text that explains the function of the component. This feature seeks to make BillingGUIManager user-friendlier.

For the most part, we managed to accomplish what we set out to do. We are able to handle different type of services and charge the users accordingly. However, we did implement a Graphical User Interface for our billing administrator that was not planned for at the beginning of this project.

To ensure that messages between the Billing Clients and the Billing Server are not tampered with, a encryption/decryption security method is applied to Billing Messages traveling between MessageCenters. All Billing Messages are a subclass of a BS_EncryptedMsg. This Message contains the pertinent information in a Java String along with a timestamp. When Billing Messages are created, all information is packed into a String and sent to the encryption algorithm located on each Billing Listener. There, a time is stamped onto the object and used as a key to lookup a number in a hashtable that ranges from 1 to 15. This number is used to rearrange the bits in a Java char primitive object which is composed of 16 bits. The encryption is simply to move a specified number of bits from the left of the char to the right. This effectively masks all information in the String object which can now be sent with the BS_EncryptedMsg over the network to the appropriate Message Center destination. Upon arrival, the message is decrypted by using the same lookup timestamp into a similar hashtable to obtain the bits to rearrange. The String is then parsed to obtain the information in the child Message. The hashtable located at every Billing Listener is randomly generated upon startup by using the same seed for the random number generator (this seed being the time when the Billing Server starts). This seed is sent to all clients who are then able to recreate the hashtable for their own use. The seed is then discarded. Using this encryption method, the algorithm for encryption is made unavailable to snoops on the network and is useless without the hashtable. This hashtable is always generated at runtime, not hardcoded in, and thus insuring a little more security.

We believe our greatest challenge was learning and researching the use of JDBC and Java GUI’s and more specifically Java Swing. These were specifically Java features with which we were unfamiliar with but now feel confident in our ability to implement and utilize them efficiently. The Internet was an invaluable resource from which we were able to research examples and capabilities of Java in these areas.

Java Swing that we needed for our GUI development was not installed on any of the machines in the CSUGLAB. And we do not have the privilege to install the latest version of JDK (version 1.2) that includes Java Swing on the NT machines. We got around that problem by installing JDK 1.2 on our own machine at home and then copy the executables and class files to the NT machines in the lab. Then we had to set the environment variable "path" to point to the JBK 1.2 executables.

A major hurdle in the code that we faced was the inaccessibility of Microsoft Access Database through Microsoft’s Visual J++. We had a little difficulty in figuring out how to deal with this problem effectively, all the while thinking in long term about what other things would be affected if we could not use Visual J++. Our ultimate solution was to switch to Sun’s JDK which gave us no problems with using JDBC. We were fortunate that our research info JDBC was very thorough so we were able to locate this problem before actual coding began.

The most important thing we learned is still about working in large groups with multiple teams and coordinating how to implement communication and parts of the code that are dependent on other groups. This also means that how fast we are able to notify each other of significant changes is extremely important so as not to push other groups behind schedule and to allow enough time for discussion of new ideas. After our second report, management was much more responsive and able to bring our group together with Signaling and Directory to set straight the groundwork for our interfaces, where we are at, and where we want to be.

On a more technical level, we learned much about JDBC and Java GUI’s using the Java AWT Toolkit and Java Swing resources. We learned the difference between AWT components and Swing components (heavy weight component vs. light weight component) and why we should not mix two kinds of components together in one window (heavy weight component will always obscure the light weight component). The database access was not a simple task because of the Windows NT drivers and environment variables that had to be set. Since these were not things strictly handled in Java, we were largely uncertain about our results during testing.

As our project comes to a conclusion, we realize that there were many mistakes that we made. Mostly from inexperience and lack of communication, we had a slow start and were not focused on what we needed to do and how to go about accomplishing our goals. Though we had numerous meetings with the various groups we interacted with, we were still unable to agree upon an interface until we drew very near to our demo date.

We were unable to satisfactorily complete the recovery system for our billing server. With more time, we believe it is possible to improve the recovery algorithm we designed for groups and for client/server communication in the event of the billing server crashing.

Given more time, we would also have liked to test our Billing System more thoroughly to insure robustness and maintain the integrity of the database.

The Billing System should also have been more robust. It should maintain a recovery logging system. Using the reliable storage of the database, a time stamp should be recorded every minute. This would allow the server to restart and be able to correct incomplete transactions / calls / groups based upon the time of crash. Incomplete calls between two parties are completed by assuming the end of call as the crashtime and then calculating the appropriate charge. Calls that have been suspended are cleaned up from the database, as well. The Billing Server should be robust in its handling of unexpected messages, usually those associated with the Billing Server crashing and restarting, but not before some Messages were passed by. These include users joining groups not yet established, or leaving groups that they were not a part of. Also, handling of new users that bypass registration and connect to the MIA system.

6. Interface

Since we will be using Listeners and MessageCenters as discussed above, we will have no real interfaces to use to connect to signaling. In addition, the message objects will contain the information from directory about usernames and e-mail addresses, so billing will not need an interface to directory either.

For the Listeners, signaling will call our Listener object constructor:

where the MessageCenter m is the object to which our QueuedMessageListener will be registered with to receive messages, int i is the client ID number, String hostname is the host where the Billing server will be listening, and int portNumber is the port to connect to the Billing server.

MessageCenters will then send our Listener a message by using:

where Message m is the message object with relevant information (such as the source and destination of the connection), MiaAddress maSource is who the message is coming from, and long UniqID is an ID number to recognize messages that are part of connections using three-way handshakes as being related.

The project web page was slow in updating the project information and references to find different information for different teams especially for teams with higher numbers (team 6,7,8,9,10). It would have made our research for material much more effective if pointers were given to every one at the beginning of the semester.

There were a lot of typographical errors on the web page, especially the puzzles pages. Confusion over the material on the web could have been avoided if more care were taken into writing up the web pages.

All the sub-teams should get equal amount of help from the course staff, For example, teams with lower numbers (team 1,2,3,4)got a lot more information and help from the web page than sub-teams with higher numbers (team 6,7,8,9,10).

.

The Information Economy by Hal R. Varian <http://www.sims.berkeley.edu/resources/infoecon/>

JDBC - Connecting Java and Databases <http://zulu.cs.rmit.edu.au:2000/jdk/guide/jdbc/>

The Java Tutorial <http://www.javasoft.com/docs/books/tutorial/index.html>

Creating a GUI with JFC/Swing < http://www.javasoft.com/docs/books/tutorial/ui/index.html>

Flanagan, David. Java in a Nutshell. O’Reilly & Associates, Inc.: Sebastopol, CA, 1997.

Zukowski, John. Java AWT Reference. O’Reilly & Associates, Inc.: Sebastopol, CA, 1997.