In article <[log in to unmask]>, James B. Byrne
<[log in to unmask]> writes
>I know that this reveals the profound depth of my ignorance
>but, assuming that we move our existing data from
>TurboImage to HP Eloquence, say sitting on a Linux Box,
>then I presume that we could set up a JBDC connection and
>serve the data to Java applications running on Win2Kpro or
>Linux desktops. Is this correct? If is is, then is there a 'better'
>way to go about such a change?
>
>
>Assuming a modest size operation with about 20 concurrently
>connected users processing about 200 discrete business
>transactions (invoices / shipments) a day I expect a very
>modest investment in server hardware would suffice, but I am
>wondering about the requirements for a java workstation.
>What are the list members' opinions on what would make a
>suitable sized server and workstation for this arrangement
>(Eloquence, JBDC, and Java)?
>
>
>Regards,
>
>Jim
>--- *** e-mail is not a secure channel ***
>James B. Byrne Harte & Lyne Limited
>vox: +1 905 561 1241 9 Brockley Drive
>fax: +1 905 561 0757 Hamilton, Ontario
>mailto:[log in to unmask] Canada L8E 3C3
Jim,
You should be thinking in terms of design strategies as well as
appropriate platforms.
Your Image databases can remain on the HPe3000 in the short term whilst
you re-engineer your applications (client presentation logic and
business processing logic) into Java classes and objects.
So for example any VPLUS code, forms files, etc., can be re-engineered
to Java classes and XML files using the ANSI-Studio IDE and V+Adapters
from Advanced Network Systems.
These new Java classes and XML files can then be used with re-engineered
database access code for access to the existing Image databases using
JDBC, but make sure its a type 3 server side driver. Type 1 and 2 JDBC
drivers are client side with high overheads.
Alternatively, in place of JDBC, use ADBC from Advanced Network Systems
which doesn't have the overhead of JDBC, runs on the server rather than
the client (so the clients can be lighter weight systems) and can be
implemented with connection pooling middleware on the server to improve
the access efficiency and to reduce the licence requirements for
connections to the database (Image). An example of an ADBC based
application running with Web/iX middleware connection pooling can be
seen at the following URL for Shawnee Court House.
http://www.shawneecourt.org/
->Case Info -> Public Access
which will give you some idea of the look, feel, and performance of a
migrated client.
Subsequently the databases can be migrated to HP-Eloquence employing the
ADBC-Eloquence api in place of the ADBC-Image api. Basically just a
matter of swapping two .JAR files
Typically your new client side Java will run in a web browser so you
will need to make sure that the hardware has adequate memory to run the
browser of choice (eg. Netscape, Internet Explorer, Opera, etc), and you
will need to install a more recent JDK on the client than is provided
with the browser distribution.
Alternatively you may prefer to create Java client applications using
JFC and Swing classes which would not have the browser overhead, obviate
the browser security issues, and allow "thinner" client systems.
This approach would involve more client side design work however.
Your business logic can run on the client side or one the server side
according to how you wish to partition the logic. The received wisdom
currently is that server side Java is to be preferred over client side,
at least for the business logic, transaction management, and database
access.
If you are intending to implement a completely Java based application
design then you will probably want to employ Servlets and JSPs running
within Tomcat on the server. You may also want to employ a design using
Enterprise Java Beans (EJB) for transaction and security management,
running within a J2EE compliant web application server which provides
EJB container services and JNDI services.
So in summary chose an appropriate platform for the databases - HP3000
for Image; Linux, HP-UX, NT, for HP-Eloquence; and one for the server
side Java - Linux, HP-UX, NT; and one for the clients - NT/2000, Linux
(some nice GUI's - Kde, Gnome, Motif), Mac, etc.
If you put your databases on and NT/2000 box then you'll probably not
want to run anything else there. Similarly for middleware serving on
NT/2000, keep it on a separate server.
If you use Linux on your server then it should be able to handle both
the database and the middleware servers, but you might want to separate
them for security and resilience. On one system you would need at least
512Mbytes memory, 1Gbyte would be better. Your client PC's would
probably only need 64Mbytes for Linux with KDE or Gnome although
128Mbytes would be better. NT/2000 would need at least 128Mbytes.
Hope this is helpful
Chris
Information and references -
J2EE Overview
http://www.the-internet-agency.com/adbcwebix/j2ee.htm
Evolution Strategies for MPE
http://www.the-internet-agency.com/adbcwebix/migration.htm
ANSI ADBC-Image and ADBC-Eloquence
http://www.the-internet-agency.com/adbcwebix/ansi-adbc.htm
ANSI Studio with VPLUS
http://www.the-internet-agency.com/adbcwebix/studio-vplus.htm
V+Adapters - white paper
http://www.the-internet-agency.com/adbcwebix/ANSI-V+Adapters.doc
ANSI-Web J2EE Application Server
http://www.the-internet-agency.com/adbcwebix/ansi-web.htm
--
Chris Thompson
The Internet Agency, UK
http://www.the-internet-agency.com
European Distributors for Advanced Networks Systems Inc.
Distributors of CCS TRAX and CCS C-iX 'C' compiler for MPE
MPE and RTE migration tools and services
IBM Development Partner
Voice: +44 7836 364575
Fax: +44 1202 418209
Email [log in to unmask]
ANSI -
Advanced Network Systems Inc., USA
Specialist in JAVA and J2EE
http://www.advnetsys.com
Voice: +1 908-638-3330
Fax: +1 908-638-3331
Email [log in to unmask]
-----------------------------------------
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
