No....
...and maybe.
An EJB Container give the developer "for free" the following "aspects" (to lend
terminology from AOP, aspect oriented programming): transactions, persistence,
security, scaleability. Typically these aspects countercross classes and breaks down
isolation etc. etc. I.e. gives error-prone, hard-to-read and hard-to-maintaine code.
This mainly holds true for larger projects.
The complexity that EJB _adds_ is that there is an additional layer with its
specialized application-server-software and so on. So looking at system-lifetime (ie.
post-delivery and on) an EJB-application is harder to maintain. For larger system the
lesser bugs and ease of expansion justifies the added complexity, for smaller systems
I don't think so.
Look at the system you want to build. If its transactional and you want to use
oo-techniques (or components, or what ever buzzword holds this week) you should
probably use EJB. If you're not transactional, there's no pay-off using EJB.
Looking at your project, your current architecture seems sound to me. Using EJB for
that is like killing of a bug with an atomic missile. EJB is powerful, but power also
adds complexity. For your project (if there is no expansions in the near future etc.
etc.) I should myself almost settle for a traditional 2-layered client/server
architecture, but that may be a bit too weak considering firewalls and other things.
Maybe http-tunneled IIOP using CORBA-style object-activation...? hmm...
-----Original Message-----
From: Booth, Peter [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, March 24, 1999 3:34 PM
To: [EMAIL PROTECTED]
Subject: Is this a suitable pilot EJB project?
Hello,
I welcome any opinions on whether the following small project
sounds like a suitable pilot EJB project:
I have an applet that currently uses cgi to connect to a legacy
graphing application on a web server. The graphing application
queries a database and produces line graphs as pdf files.
My project is to replace the legacy graphing app with an N tiered
graphing app. I had initially planned to use servlets to read data via
JDBC and return the time series data to the applet, which would build
the graph objects using a third party tool. The app is not really
transactional
in nature, I am interested in evaluating EJB technology with a project
where there is some pay-off.
Is there any gain in using entity EJBs to read data from a database?
The database stores a historical set of data points and is written to on
a daily basis. A typical graph would involve reading say eight curves
each with 2000 points. There will be perhaps 30 concurrent users.
Would EJB make it any easier to cache commonly used data?
Any opinions welcome.
Peter Booth
[EMAIL PROTECTED]
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
�������������������������o unsubscribe, send email to [EMAIL PROTECTED] and
include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
