db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: Shall we drop c/s mode?
Date Sun, 26 Jan 2003 23:10:02 GMT
I'm not a voter (in fact I am pretty much just learning OJB right now),
but I would very much prefer it not be dropped.

1) It is one of the points that sold my company on looking hard at OJB
(pretty much sold on it, actually, but this is part of the reason).

2) Integration into clustering in various application servers doesn't
always work for clustering a given application. For instance (this is
very much for real, though the project started as a learnign exercise) I
have used OJB as the persistence/integration layer for a simple
timetracker application for our part-timers. This application runs on
Tomcat right now. Happy fine. The next step is to write a simple command
line client to it instead of the web (a good third of our part-timers
prefer command line to web based ui's, is sorta nice). So... I A) go to
remote objects for the application (ick), B) turn off all caching and
use the database as the integration layer (ick ick), C) write an http
wrapper for calls that emulates a web browser (via HTTPClient or
somesuch) (ick^4), D) subclass the Struts ActionServlet to add startup
code to launch a thread to listen for simple TCP/IP traffic from the
command line client and have it use the same API to the business logic
in the same servlet container (messy messy), or.. a bunch of other
possibilities, but the one I LIKED was being able to use OJB in C/S mode
as an integration layer where OJB would keep the business objects
synchronized for me across JVM's without adding the overhead of remote
objects - I could bundle up the business logic in a jar, write a new
control layer (regular socket listener and parser) and a new front end
(the remote command line client), or whatever. The nice part of this is
it just takes telling the two applications running OJB about each other
and (presuming they are running on the same network) we get fairly
inexpensive, no-new-firewall-rules-on-the-client-side, added interfaces
and synchronization on completely seperate server apps. Pretty cool.
This application doesn't require C/S levels of scalability, but it is a
nice project for playing with the technology.

Not everyone runs in a fancy clustered Web or EJB container, or wants
to. The ability to deploy to a simple JVM (or four) is a big plus.

3) If no one wants to maintain it or sees value in it I will devote
higher priority to getting my butt up to speed and offer to do it.

I don't know how efficient C/S mode is right now (as I said, my next
step in learning OJB was to learn how to do it in the aforementioned
project) and pushing a remote-object integration layer may be more
efficient, but I really doubt it, and it requires a lot more from the
environment (RMI server and open ports on the client at a minimum unless
you really like polling for changed states).


View raw message