How Would You Design This Application?

[John]

I'm looking for some ideas on which combinations of Java language
features, third party tools and design patterns would apply to the
design of the following type of system subject to certain constraints as
described below.

This is to be a distributed client-server system.

J2EE is NOT an option.



SERVER
This task manages a database on behalf of multiple clients. All requests
and responses must be synchronous. The database is relational but the
server must work with an object-oriented representation of the data therein.

The server must be a singleton.

If it crashes then something must restart it.


CLIENT
Must be Swing based.

Retrieves lists of database objects managed by the server with which to
populate its GUI.

User selects an object via the GUI, enters additional data via that same
GUI, and issues a synchronous add/update/delete transaction to the
server upon clicking the appropriate button. Client app must wait for a
response from the server before continuing.

All clients must display a "live" view of the internal state of the
objects that the server is maintaining on their behalf. In other words,
if client 'A' updates an object then the GUI of client 'B' should
reflect that change automatically.


OPTIONS CONSIDERED SO FAR

Hibernate - for the ORM. I'm okay with this part.

RMI - While this seems a natural fit to the system's design, in
prototyping it I find a number of problems. For instance:

An "activatable" server can be successfully launched on demand but
if/when the server exits normally or crashes I can't get RMID to
relaunch it. Perhaps I am doing something wrong?

The RMIRegistry and RMID are additional tasks that must be launched
prior to the server. This requires non-Java, OS-specific scripting to
achieve. I'd prefer an all-Java, OS-independent approach.

It's not clear to me how I would effectively apply the notion of an
Observable object in an RMI environment. This seems particularly murky
to me since the objects are also being managed by Hibernate. This is
probably the design aspect where I could use the most assistance.


SWING - I have concluded that plain Swing, without some sort of higher
level framework to streamline the process, is not worth coding. I have
looked at JGoodies and SWIXML, and each has its benefits, but they don't
cooperate with one another. So their potential value is lost to me.

I am also totally PO'd at having to write a custom model for every
blasted JTable and JList in the GUI as there are many lists of objects
to be managed by the server on behalf of the clients. Grrr.



Thanks for listening.

 

[Roedy Green]

This task manages a database on behalf of multiple clients. All requests
and responses must be synchronous. The database is relational but the
server must work with an object-oriented representation of the data therein.

see http://mindprod.com/jgloss/sqlvendors.html
http://mindprod.com/jgloss/pod.html
http://mindprod.com/jgloss/hibernate.html

 

[Roedy Green]

The server must be a singleton.

If it crashes then something must restart it.

To pull that off you will need some PC that keeps monitoring its
heath. It would unwise to expect the server to that itself. It maybe
too sick to notice.

The PC either reboots or powers off and powers on the server. The
server has a login script of services (start with out intervention)
that get things going again.

Google for UPS vendors. They may bundle such software with their
products.

 

[tom fredriksen]

This is to be a distributed client-server system.

What do you mean by this, it can only be one or the other i.e.
distributed or client/server system.

CLIENT
Must be Swing based.

You should perhaps have a look at XUI (an addition to swing)

OPTIONS CONSIDERED SO FAR

Hibernate - for the ORM. I'm okay with this part.

RMI - While this seems a natural fit to the system's design, in
prototyping it I find a number of problems. For instance:

Have a look at SOAP for this part, its the modern RPC which is w3c
standardised. It doesnt have the object features that RMI has.

You could also have a look at javaspaces(blitz) as a distributed storage
and communication mechanism, which support listeners on objects and changes.


/tom

 

[James McGill]

What do you mean by this, it can only be one or the other i.e.
distributed or client/server system.

I'm wondering why not.

Why couldn't a distributed system of server nodes be accessed by
clients? I use a system that fits that description, although I wouldn't
call it a "distributed client-server system" exactly.

 

[tom fredriksen]

I'm wondering why not.

Why couldn't a distributed system of server nodes be accessed by
clients? I use a system that fits that description, although I wouldn't
call it a "distributed client-server system" exactly.

My point is confusion of definition. A distributed system is both a
server and a client. Ie. a node in such a system can be both or either,
depending on the architecture of the system. So, it was merely my
intention to point out the confusion. Calling it both is a "butter on
lard" statement.

/tom