Steve,
While working on a project at ANR Pipeline, we did just this. The Web
Server and a Citrix Server were used to allow remote access to the
application. While a Unix and NT boxes uses Remote Method Invocation to
maintain data integrity and validity. A Sybase backend was used to house
the data.
To answer your question about overhead costs .. as I noted earlier we were
using a Web Server and a Citrix Server. If your implementation requires
more than one platform to access the data, RMI can be a very effective
solution. Even in the case where you're using all Java, RMI could be used
on all the clients, instead of the browser, freeing up needed resources, and
reducing local overhead, plus allowing you more flexibility in terms of
security and internet access.
As for my execution of ASP -> Java -> SQL .. I've created a 3 layer model in
the Java realm. Here I create three types of classes ... Store, Instance,
and Container. Store opens the connection to the SQL server, and maintains
the user information. Instance is the basic information about each row of
the Table or series of Tables. This object manages the appropriate values
and insures that everything stays within range. Container manages all the
instances of the Table or series of Tables. In that it gets and dispatches
the various instances out. It also has responsibility for ensuring that
inter instance relationships and rules are maintained .. i.e. no two
instances can be from the same company.
On top of these three layers, I then build a 4th, which becomes the API to
ASP. Instead of having several individual objects to mount onto NT and IIS,
I mount just this one. It contains two sets of functions ... One to
establish a connection to the database, and the 2nd to fetch the appropriate
containers. This makes it easier in ASP, since I only have to create one
object, and then initialize a variable to point to the containers class.
That's what I'm doing. Oh, and because I have to work with several
languages .. C, C++, Java, VB, ... I try to follow this pattern. I'm
presently working on an INI admin tool, which has many similarities to all
this. It simply reads in all the sections (which may repeat) into it's
appropriate objects, then the visual interface allows me to manipulate the
information, and then I can write it all back out. The only difference
here, is that I'm not maintaining a static link to the INI file, like I
would with a SQL Server.
Michael J. Fuhrman
Reliable Business Computers
http://www.creliable.com/
-----Original Message-----
From: Steve Houghton [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 07, 1999 9:01 AM
To: [EMAIL PROTECTED]
Subject: Comments on business logic separation
I realize the benefits of separating business logic from the presentation
between servlets and jsp. However I wondering if anyone actually takes it
one step further and actually goes to a remote object layer (RMI or CORBA).
There obvious advantages to that are that any other application based on any
technology (client server, host-based or web) can plug right in using these
common objects. BUT, what I'm curious about it the overhead of worrying
about such things given that there is an obvious trend of less development
toward client/server and MUCH more web. (The other overhead would be in
actual execution time as well). While I like the model, is it really worth
it?
Also, as far as separation goes, I'm currently using a process where i've
got:
JSP->servlet->SQL helper classses specific to the servlet->generic SQL
helper classes to do the grunt work.
I'm always looking for better ways and would like any comment as to what
others are doing.
I've been an ASP developer for 3 years and have jumped in to this JSP/Sevlet
stuff a month ago. I absolutely love this compared to ASP. Its 100 times
cleaner and you can easily get to much more powerful api's simpler and
faster. To any of the people designing the JSP/Servlet specs: keep up the
excellent work - i'd be surprised if anyone does web development using
anything else in a year or so.
Steve
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
