Armed with your knowledge of RMI you set up your own consulting practice, Armidextrous Consulting, and get your first job with an auto insurance company. Your first meeting with the company representatives goes something like this:
Mr. Clueless Leader (CEO): We need to save more money. Can you help us do that? I know you guys are up for a challenge. Our company does billions of dollars in business each year, as my exhorbitant salary and reserved parking spot will attest to. We need a powerfull system to help us save more money.
Mr. M. T. Suit (VP): Yes, we must leverage our existing competencies to align oursleves with the prevailing market forces.
Ms. Lisa P Hacker (Software Engineer): You see, we currently process all of our insurance claims using an ad-hoc mixture of paper and semi-automated processes. What we need is fully computerized systems. The insurance claim process starts with the creation of a claim by one of our claim agents. The claim agent gives our Debacle Teramax database server the SSN of the person and it outputs the person's personal information (name, ssn, make of car, etc.). The claim agent then fills out some other parts of the form by talking to the person. This paper form is then passed around, in no particular order, to
- The Claim agent which is the only one who can create a new claim. It queries the user for some questions which the user can choose to answer, or not. The user (claimee) must at least give his SSN and his reason for filing a claim.
- The Law Experts Examination of Customer Habits dept. (formerly the offices of Dewey, Cheetham, & Howe) in which some lawyers decide if the claim could be safely ignored, or if it could provoke a lawsuit against the company. The form is marked accordingly.
- The Award departemt who, if there is enough information on the form, determines how much of an award should be given for this claim.
You (CEO and RMI Master): I see. Initially I would have suggested you turn your paper claims into XML and send that XML claim around your network. However, that would lead to synchronization problems if the claim is duplicated and two people make incompatible changes to their copies of the XML claim. I think what we need to do develop remote Claim object which will reside in the Teramax server but whose reference can be passed around to the various department. Each department can then call methods on this object which will change its state. This way we can make sure that there is only one instance of the claim and that all departments change that instance. Of course I will need a copy of this claim form as well as a description of what exactly each department does.
Lisa: No problem. I will attach that information to the end of this problem set. Also, I will need an interface, running on the server, which will allow me to see the current state of all outstanding claims.
You: (Wonders why she calls the meeting notes a problem set.) No problem. I will also create a Monitoring client on the server which will let the user see all the current Claims, as well as all their data member values. Also, you said that these claims are sent around in no particular order, how should I simulate that?
Lisa: A random number generator, of course.
You: Of course. For testing purposes I will create clients that simulate the work of each of your departments. These clients will add information to every form they receive and then send it out to another randomly chosen department. Only when a Claim is finally approved or rejected by the Award department will it be deleted by the system. Hmmm...this does raise the question of how I will get any two clients to send Claims to each other. (Thinks for two seconds). Oh yeah, of course, that won't be a problem.
Lisa: Great! So, your deliverables include a Claim server, three department clients, and a Monitoring client which will show the state of all outstanding claims. For your final demonstration will show 10 different applications submitted and processed by the systems.
You: No problem
Mr. Clueless: (waking up from his nap) Great! I am glad we are all on board with this. I expect only the best from you guys! Go team! I'll be at the golf club in case anyone needs some more motivating.
M.T.: I like the way we are exploting the synergies of our centers of expertise. This will be a high-availability cross-platform five-nines enterprise-wide solution system.
|Field Name||Contents||Content Type|
|name||The person's name||String|
|sex||M or F||char|
|birth||date of birth||Date|
|makeCar||Make of car (Honda, Ford, ...)||String|
|typeCar||Type of car (sedan, coupe, wagon, SUV, compact, luxury, sports, truck)||TypeClass (which implements an enum)|
|accidentDescription||A short desciption of what happened.||String|
|fault||What the person at fault?||Boolean|
|amountClaim||Amount of claim||double|
|amountPayment||This person's monthly payments||double|
|previousClaims||Number of previous claims in the last 5 year.||int|
|previousAwards||Number of awards in the last 5 years.||int|
For testing purposes, your "database" should start out with these values. You do not need to use an actual SQL database. The data in this database should be updated as changes are made on a claim.
|von Rossum, Guido||987234910||M||4-9-70||GM||compact||200||1||1|
|Rowling, J. K||342981434||F||9-10-65||Volkswagen||SUV||350||0||0|
The claim agent's application will have a simple GUI which lets the person type in the information on the claim form. The way it should work is that the user fills in some of the blanks (only the SSN must be filled), then hits a create button and the claim is created. Once it is created any empty fields on the GUI for which there is data in the database should be updated. At any time the user should be able to change the data in the claim an hit the submit button to update that information and send it to a randomly chosen agent. Also, at any time the user should be able to create a new claim.
The LEECH agent does not need a GUI. Whenever it receives a claim it runs a simple algorithm which results in changes in the claim. It then sends the claim to a randomly chosen agent. The algorithm is:
The award department makes the final decision on whether to make the award or not. However, it will not do so until all the fields are filled in and there is a recommendation from the LEECH department. It always follows their recommendations. Once it makes the final decision it updates the claim to show this, makes sure that person's entry in the database is updated (how you do this will depend on your implementation), and deletes the claim.
After this agent deletes a claim, no other agent should be able to make any updates to that claim.
This agent runs on the same machine (JVM) as the Claim server. It should display a list of all the outstanding claims and their current status. It is fine to do this using a text-based interface (i.e. println).
As will all the problem sets, you will hand them in using our department's dropbox, at this link. You will hand in all your javadoc-commented java files. You will be graded on your (lack of) documentation. You will also include a README file that gives step-by-step instructions on how to run your program. Remember that the harder you make it for us to run your program, the more annoyed we will be when grading it. You must use the sample README.txt as your template. Failure to follow any of these rules will result in a 50% penalty.
Q:Do we have to use the database with attributes mentioned in
the PS2 description(specs)?
A: You are not required to use a real database, but you do need to store those attributes in some way so that you can use and change them later. Of course, you can use a real database (i.e., an SQL database) if you want to, simply remember to explain clearly in your README the steps we need to follow in order to run your program.
Q:Can we use a database to add new customers?
A: No. All new customer additions will be done via the claim agent. That is, if someone submits a claim who is not on the database then that person should be added to the "database". You can identify a new user because he will have a SSN that is not on the database.
Q:Should clients (Agents) run all the time?
Q:Is the Claim Agent the only one which interact with a user?
A: Yes. The monitor agent also has a display, but takes no input from the user.
Q:What is 'outstanding claims' in terms of the Monitor Agent?
A: Claims that have not been either approved or rejected by the award agent.
Q:In terms of the comunication between clients, I
think there are several ways of implementing it.
A: Yes, there are. I don't think there is any one "best" approach, altough there are some that waste more resources than others. You should explain your approach in your code comments (class comments).
Q:Is the randomness a requirement?
A: Yes. It is meant to simulate a real corporation :-) The agent should pass the claim on (randomly) in all cases.
Q:Can the other agents send a claim back to the claim agent?
A:Yes. This happens to me all the time. I fill out a form and get it back in the mail because the person who received it did not think it was meant for them.
Q:Do we have to implement multiple claims by a person at the same time?