RMI calls

[Experiments,General] (12.31.08, 11:45 pm)

For my eventual monster programming project that will eventually (I hope) be the fruit of my labors as a PhD student (in addition to a big stack of paper that will make up the dissertation), I have been doing a bit of preliminary research. Mainly, I want to plan an architecture that is as clean and clear as possible. A challenge with academic projects is that they often stumble or run into problems after exposure to the outside world. My project is a system for simulating (and interacting with) characters in fictional worlds. This sort of thing requires many architectural layers, and in my experience, lots of trouble can come from letting the layers mingle too much.

So one natural question is: how to keep layers separate, and also have the project be extensible so that it can flourish after emerging from the comforting coccoon of academia? The problems I have run into the most frequently in extending my projects tend to fall under the categories of 1) organization, 2) persistence, and 3) networking. These questions are easily ignored when building experiments and prototypes, but when those are transformed into full fledged development, not having considered them can wreak havoc on a project. So, I’m doing these experiments in trying to figure out good architectures that could be used. I was thinking about networking and discovered the Java RMI framework. I looked at their tutorial which is deliciously short and extremely comprehensible. You would think that this sort of networking would be more cumbersome, but it’s really not.

I think I am going to plan on using RMI and design the character simulation system as a service. This will force me to think of interactions at a client-server level, and also make liberal use of Java interfaces. The RMI framework also relies on serialized objects for communication, so that means that messy and complex objects can’t just be handed from the client to the server. This is the sort of problem that occured with developing persistence in the InTEL project, and the sooner pinned down, the better.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

You must be logged in to post a comment.