Easy fix here. Write servlet which does the communication with EJBs for you
and then
let the applet communicate with the servlet over HTTP. THis will get's you
around problems 
with firewalls as well. At least this is what we do for our applets 
Our architecture is:
client: HTML, DHTML, JavaScript, Applet
web server: servlets, JSP
app server: EJB
database

Miroslav Halas
Software Engineer
Compuware Corp.
15305 Dallas Parkway
Suite 900
Addison, TX 75001
phone 9720-960-0960 x 1333
fax 972-960-8489


-----Original Message-----
From: Conan C. Albrecht [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 12, 2000 10:17 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Thin Client ?


We used to have similar problems.  We solved it with EJB and Swing. 
Your clients do NOT need the entire j2ee.jar.  They only need a few
interface classes and remote stubs. Most of that jar can stay on the
server.  This should bring it down to about 20K (at least it does for
us).  For the rest, we use Swing for user interface, which already comes
in the Java plug-in.  Therefore, we don't need to download any special
user interface classes.  Our overall download is about 50-60K.

Unfortunately, there is no way to automatically jar up the interfaces
you need from j2ee.jar.  You'll have to do it manually.  A good way to
know is to unjar everything into the directory tree.  Then run the
applet the old way (i.e. without jar where it downloads class by class
as it needs them).  With Netscape and the plug-in, you can see each
class that downloads in the plug-in's console (IE doesn't show this for
some reason).  Just jar up those classes.

Our problem with thin client is that Java itself is not thin.  It
requires a pretty good machine to run well and requires the Java plug-in
for J2.  Our only solution to this is servlets, which are a dream, but
some of our work requires applets, which we are stuck with the large
plug-in download.

Good luck.

Guy Perron wrote:
> 
> Hi,
> 
> We've recently changed our architecture in order to reduce the applet
> client's size. For instance, before, in a two-tier architecture, we had a
> 2.3 MB client with all the database code, business logic and the db driver
> in it. Now we added a middle-tier using EJBs and our client jar is about
1.3
> MB large, the rest of the code being in the Beans. But, this client needs
> j2ee.jar (5MB) plus 350ks of other jar in order to run !
> 
> How do I reduce the size of the jar, do I have to manually isolate the
> packages I use in the jar and build a smaller version of it myself ?
> 
> Down the line, isn't the goal to have a smaller client or am I missing
> something ?
> 
> Any thought ?
> 
> ----
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "unsubscribe jonas-users".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".

-- 
Conan C. Albrecht
Director of Software Development
Center for the Management of Information
University of Arizona
McClelland Hall Room 114
Tucson, AZ  85721
http://www.cmi.arizona.edu/users/calbrecht/
[EMAIL PROTECTED]
 -- or --
[EMAIL PROTECTED]
(520) 621-2640 (voice)
(520) 991-0644 (cell)
(520) 621-2641 (fax)
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".

Reply via email to