Advice on use of various RMI based technologies

Hello All,

Some several years ago I spent some energy trying to figure out the
suitability of using RMI as the base technology for an application server.
At that time, the technology was fairly immature as compared with where it
is today. We would have had to write our own SSL interfaces, etc, and
unfortunately, we couldn't put the resources into the effort. ... I
understand that things have come a very long way since then and I'd like
to get the benefits of your insights into which RMI based technologies to
use where and whatever other observations or insights you care to share.

I was thinking I'd start by summarizing some of the architectural details
of where we are already, then share what our thoughs are on what we need
from an RMI based application-server solution.

We've already got a host of code - many tens of thousands of lines - in
Java, and I'd love to be able to use as much of it as possible.  It was
written with the idea in mind that someday it would use RMI but it it's
anyone's guess how successful that part of the effort will prove to have
been. (The rest of it works _great!_) However, importantly, it connects to
a relational database - ANY relational database. (It actually has the
smarts to do SQL dialect translation and presently supports Oracle,
Sybase, Informix, DB2, Postgres, and ANTS - if anybody needs this
technology, contact me off-list, please.)

A LOT of trouble was taken in the present architecture to ensure the
security of the client to help ensure the right things happen in the
database. One of the aspects we wish to strengthen with an RMI-based
application server is to relieve some of the security requirements of the
client and move the lion's share of the security burden to the server
side. In fact, for performance reasons, we may well end up with a
two-tier-server architecture and that's OK with us. We may keep the same
database server "back end", and have trusted clients which themselves are
or have application servers that receive untrusted - or trusted - client
connections. This way the total workload is spread out and the db engine
can just scream. (This code is in support of super computing environments
and has to be both fast and reliable.)

One concern I have has to do with relational database "result sets". I
think that it's probably a bad idea to send a result set through an RMI
based connection because there's an implied ability of a result set to
update a database and my hunch is that it'll cause performance problems.
I'd love to hear thoughs on this - anyone actually do this? So... I'm
anticipating that the application server code will have to re-package
result sets into descrete objects and then pass those. (This is actually
also a good idea from the security aspect, but will cause an obvious
performance burden that a straight application to database solution
doesn't have.)

I think that one of the areas where there has been the most improvement,
and an area I am most hopeful of great commentary on, has to do with the
standpoint of an RMI server accepting and managing client connections. For
example, encryption through SSL is imperative. Right now, we do it through
our own tunneling solutions. I understand that some of the RMI based
packages (JENI/JERI?) have features that let one easily manage inbound
encrypted connections. What I'd like to do is link in such a solution with
our database: We already have all the metadata you could ever want on the
subject in our database and we shouldn't have to manage two authentication
repositories.  Similarly, we have questions and concerns about using
connection pooling; How does one keep the connection distinctive? Presume
that each inbound connection is a distinct user with their own privileges;
All database access, etc, for that connection has to be kept separate. Our
methods can keep this all straight by using a simple internal user-id
paradigm and then call methods that access the database with the
appropriate smarts. However, the hand-off from the SSL/connection stand
point is vital. Is this easy today? Which tools?

One area of RMI we don't need has to do with dynamic class loading. Not
only don't we need this, it would probably be a pretty bad thing for us.
The only reason I could see we might want to use it might be for dynamic
updating of the remotest remote client's code, but even then, it's not
something we care about. Surely a client should never be trying to send a
class to a/the server. (Or, maybe I misunderstand what this feature is all
about? -shrug- )

There might well be other areas of concern I've overlooked, so, please,
feel free to chime in so I'm not blind-sided later.

I want to thank you in advance for your thoughtful replies. I sure am
hopeful that RMI-based technologies are ready for these uses and don't
require too much left as an exercise for the reader. (I'll have enough
trouble on my hands just encapsulating and disecting all those Result
Sets!)

Thanks again,
Richard

--
Richard Troy
[email protected], 510-567-9957

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html