Distributed notification design

[VisionSet]

I have a simple set of model classes that are used on a client as part of
MVC and on a server for distributed access. When a client updates a model
object, this object is sent to the server, many clients maybe interested in
this change and want to have updated versions themselves.
As I see it I have two basic options with the RMI approach I will be taking.

1/ Stubs/Skeletons are compiled for both directions such that when the
server receives an update it should then transmit an event to all interested
clients, details of these clients can be tracked by the server. [if the
client has terminated this will throw remote exception and that clients
details can be removed from the server]
The small event object transmitted will be an identifier that gives an
attribute such that the client can determine if its copy has changed, if so
it can request the model object itself.

2/ The client will poll the server, say every 30secs. It will generate a
request object similar to the event in 1/ above and the server will check if
it has a newer version, if it has it will return it.

Does this make sense?
Am I being naive in anyway?
I realise that I have to make the decision between the two myself by
weighing up more than I've mentioned.
I'm guessing that 1 - 5 % of polls will be fruitful.

I have read that objects should not contain primary keys (ie when they are
derived from DBMS mapping)
I'm guessing that this is because an implementation of equals will serve
this purpose.
But are there any detrimental effects from doing this? My identifier
(event/request) object was going to contain this.

TIA

 

[daniel.w.gelder]

Why have the client poll? Just have the server loop for every client
and poll itself in a thread. If there's an update, send it.

 

[VisionSet]

Why have the client poll? Just have the server loop for every client
and poll itself in a thread. If there's an update, send it.

poll itself? I'm not understanding you.

Are you saying go with option 1 - and I'd need the remote connection both
ways ie client and server to have UnicastRemoteObject ?

Or are you saying that it is possible with just the client initiating
connection (option 2) and the server holding references to regular
(non-remote) client objects, for the server to call the client? I thought
non-remote objects were pass by value, so that surely would not work.

 

[Abhijat Vatsyayan]

JMS is a good option for distributed events. The event could contain
information about which object has changed (if it is possible to
identify objects this way!). Depending on how distributed the
application is, what kind of network are clients and servers running
on and other distributed programming issues, information in the events
could be very different.

Abhijat

 

[Patrick May]

I have a simple set of model classes that are used on a client as
part of MVC and on a server for distributed access. When a client
updates a model object, this object is sent to the server, many
clients maybe interested in this change and want to have updated
versions themselves.

What is the nature of the "model objects" that you're updating?
What volumes do you expect? How many clients will you have? What
kind of performance is required? Do you need guaranteed delivery?
Once-and-only-once? In-order?

As I see it I have two basic options with the RMI approach I will be
taking.

I recommend against recreating the wheel. From your brief
description, it sounds like you should consider either JavaSpaces or
JMS.

Regards,

Patrick

 

[VisionSet]

What is the nature of the "model objects" that you're updating?

Simple synchronous (turn based) game model. updates player and move data.

What volumes do you expect?

Tiny per client, 1 update at most every 3 minutes

How many clients will you have?

This won't become a comercial product, under 100 clients to the 1 server,
which won't be duplicated.
If I develop it further later I will consider a new communication
architecture.

What kind of performance is required?

I think you get the picture.

Do you need guaranteed delivery?

No, the client is not expecting delivery within their 'connection' session.

Once-and-only-once?

In-order?

Yes, but the server will guarantee that outside of the communication
protocol.

I recommend against recreating the wheel. From your brief
description, it sounds like you should consider either JavaSpaces or
JMS.

Well this is going to be simple enough for me not to have to learn JINI or
JMS at this stage

Mike W

 

[Abhijat Vatsyayan]

I would suggest not developing this from scratch.
JMS should not take you more than 15 minutes to figure out. Jini should
also be pretty straight forward.