Tomcat and RMI design principles...

[Ric Searle <ri...@dialogue.co.uk>]

Hi,  I'm hoping to cause I little discussion about design principles...

We manage a very large database, which is used by a number of different 
applications written in different languages.  We have decided to write a 
common interface to this database, which all of these applications would 
use.  We've also decided that all future application development will be 
in Java.

Originally we thought we'd write the database interface as a Remote 
Object, which our client applications could instantiate using RMI, and 
call business-logic methods without worrying about the underlying SQL 
implementation.  In order to support our legacy applications (PERL & C) 
we were going to write a servlet that provided a SOAP interface to the 
methods of our business objects.

We've come to realise that by implementing our business objects within 
Tomcat, we get things like database connection pooling, which we need.  
Is it possible to make these objects available to Java clients by RMI, 
and still take advantage of these features of Tomcat?  Obviously our 
SOAP servlet would need to use the same objects locally.

Can that be done?  Are there any flaws with the design?  Can anyone 
suggest a more suitable approach?

TIA,

   Ric Searle
   Web Application Developer
   --
   Dialogue Communications Ltd

   http://www.dialogue.co.uk


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Tomcat and RMI design principles...

["Craig R. McClanahan" <cr...@apache.org>]

On Thu, 9 May 2002, Ric Searle wrote:

> Date: Thu, 9 May 2002 11:45:33 +0100
> From: Ric Searle <ri...@dialogue.co.uk>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: Tomcat and RMI design principles...
>
> Hi,  I'm hoping to cause I little discussion about design principles...
>
> We manage a very large database, which is used by a number of different
> applications written in different languages.  We have decided to write a
> common interface to this database, which all of these applications would
> use.  We've also decided that all future application development will be
> in Java.
>
> Originally we thought we'd write the database interface as a Remote
> Object, which our client applications could instantiate using RMI, and
> call business-logic methods without worrying about the underlying SQL
> implementation.  In order to support our legacy applications (PERL & C)
> we were going to write a servlet that provided a SOAP interface to the
> methods of our business objects.
>
> We've come to realise that by implementing our business objects within
> Tomcat, we get things like database connection pooling, which we need.
> Is it possible to make these objects available to Java clients by RMI,
> and still take advantage of these features of Tomcat?  Obviously our
> SOAP servlet would need to use the same objects locally.
>

What you are describing is exactly the use case that EJBs (in particular
entity beans) are designed to solve.  Internally, the servers they run on
support connection pooling and things like that, and they do so for both
web and non-web applications.  So do alternative design patterns for the
persistence layer.

> Can that be done?  Are there any flaws with the design?  Can anyone
> suggest a more suitable approach?
>

Off the top of my head, I would be very concerned about at least the
following issues with your suggested approach:

* Fragility - you can't access the business objects, even from
  a non-web application, unless Tomcat is running.

* Scalability - you can't independently increase the performance
  of database access or HTTP serving (depending on which becomes
  your bottleneck) without increasing the size of your single
  big server.

* Lock-In - You run the risk of designing yourself into a Tomcat
  dependency, rather than being portable to other servlet containers.

I would suggest reviewing the strategies outlined in the J2EE BluePrints
documents from Sun (http://java.sun.com/blueprints), particularly in the
"Enterprise" category.  Even if you choose a non-J2EE technology,
maintaining the separation of the persistence layer from the web layer
will be very much to your benefit.

Also, the book "Core J2EE Patterns" by Alur, Crupi, and Malks is one of
the most-opened books on my bookshelf ... highly recommended.

> TIA,
>
>    Ric Searle
>    Web Application Developer
>    --
>    Dialogue Communications Ltd
>
>    http://www.dialogue.co.uk
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>