|
|
Due
Sunday 11:59 PM, 2/18/2001
Only the
auto-connect capability for RMI chatting is due on Sunday!
In this lab, you will begin exploring and examining how to connect two
computers over the Internet, using Java RMI. (Remote Method Invocation)
Remote Method Invocation (RMI)
RMI is an OOP way for connecting computers across
the Internet. Essentially, a computer presents itself as an object to another computer. The remote system is
simply dealt with as an ordinary object, no different from
all of the other local objects (once the connection has
been established)
Click here to read more about RMI
We will be extending a demo chat program using
RMI. This program will connect to any other computer running
the same program and be able to send messages to/from the other
computer.
Tips and Traps:
- Once you get the basic RMIChat program
working, BACK UP YOUR CODE. We can't stress this
enough. If you foul up your code later on down the road,
you'll at least have something that works to go back to, instead
of having to start all over.
- Work in small steps and check to make
sure that your code works often. RMI programs are
notorious for failing in unexpected, baffling, and spectacular
ways. It's all too easy to break your code. Be wary,
and do not stray too far from working code!
- Map the shared "scratch"
directory from another machine as a drive and then run JBuilder
from both machines off of the same code. This is a
lot easier than copying code from one machine to the other
every two minutes.
- If your code is written correctly, you
should be able to chat with anyone else. Remember, your
programs are all using the same interface, so they should be
able to communicate without exceptions.
- Sometimes, the RMIRegistry thinks it
still knows what a class bound to it looks like, even after it
has been recompiled and changed significantly. It may be
necessary to stop the RMIRegistry and restart it. In the
case of an extremely recalcitrant RMIRegistry, it may be
necessary to kill it from the Task Manager.
- When usng anonymous inner classes which
are passed through RMI, they are rendered into stubs, so are
seen as an "interface" type, while to the local
machine, they are still concrete. This can cause class
casting errors, because the stub is not the same as the concrete
inner class, even though they are functionally equivalent.
- Oftentimes, it may be necessary to
perform what we like to call the "RMI Dance." If
you have set your .java.policy file corrcetly, and you think
you've done everything you need to have done, and you still get
permissions errors, then it's to do the "RMI
Dance." This dance is basically the same as getting
out of a car, running around it, and getting back in.
Quaint, but this is software, so it works. To do the RMI Dance, use the policytool to remove all entries from the
policy file, and then add the "CodeBase <ALL>" entry. Save the file, and
exit the tool. In JBuilder, stop all running copies of the
chat program, sto pthe RMIRegistry, and start it again. Now run the chat
program again. Thus endeth the little dance.
Features to add:
The meat of the lab is to add a few features to
the RMIChat program. The idea is to build onto existing code, not
tear apart what's there and write it again a different way.
- Add the ability to automatically connect to
another computer when they connect to you. This must be done
without modifying any of the interfaces. Dynamic Class Loading is
your friend. You have the RMIConnectionFactory to help you in this task.
Use it wisely. (Hint -- You have the two RMIChatTargets at that point.
Now what use could you make of them?)
- Add the ability to chat to at least 3 different
computers at all at once or one at a time (without losing the connections to
the others!). 5% bonus for making code that can talk to an
arbitrary number of computers. Again, this must be done without modifying
any of the interfaces.
|