tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Limits of Web
Date Mon, 24 Sep 2001 19:49:17 GMT

Again thanks for the reply.  One more question regarding XML.  When you
send the XML request info,  do you send the data as well?  For example if
the applet requests data from the server I,  would then process it, preform
the necessary SQLs on the database and then send the data back to the
applet as an XML document and have the applet parse it and desplay it?

                    "Brett M.                                                            
                    Bergquist"           To:          
                    <brettb@mail.        cc:                                          
                    com>                 Subject:     Re: Limits of Web               
                    01:46 PM                                                             
                    respond to                                                           

Okay for the internet.  That's what we support as well as intranet.  I
wanted to make sure that my application was easy to deploy in
an internet environment so I did not what to start using RMI or IIOP or
something else that would not flow over a firewall, so I
chose to use XML over HTTP.  Basically, our applets create an XML document
that describes the request data needed and then use an
HTTP POST to pass this data to the backend servlet.  The servlet processes
the HTTP POST data, transforms it back into a XML DOM
document.  It then analyzes and processes the request.  It then creates a
XML document as the response and passes this back to the
applet using the HTTP response.  We use an early version of Sun's XML
parser and I also modified the sample XML-RPC client and
servlet classes for my own use to support this.  It works pretty good and
performance of creating and parsing the XML is a
non-issue; the major processing time is taken by actually performing the
requested service.  If I had to do it over, I would
definitely look at using the quasi standard XML-RPC protocol or maybe even
SOAP, but I have a feeling that these are getting to
esoteric for my taste.  One other benefit of this approach was that the
front end is loosely coupled from the backend.  I could
change the front end side, maybe having a native application or something
similar, and the backend would be blissfully unaware.  The
XML is the binding protocol between the two.

Our applications currently have about 5 to 7 tab pages with about 10 to 15
items per page.  From the time the applet starts on the
browser to the time that it displays the data is about 1 to 2 seconds.
This is using just Tomcat as our web server and java servlet
engine.  We started to front the backend with Apache, but the connection
between Apache and Tomcat was flaky and we seem to get good
enough response time with just Tomcat.  It also simplifies the
configuration quite a bit.

We do one other thing that's a little interesting.  We needed to send
asynchronous updates to an alarm application.  As you know, a
web based application is primarily request/response driven.  Again, I did
not want a big configuration issue in dealing with opening
ports on the firewall, etc. so what I did was fake out the system by
issuing a HTTP request and I have the response never end.  That
is, the servlet side generates alarm information whenever it needs and
sends it down the response pipe back to the client.  Now this
tacks up a TCP connection from the server to the client so it puts a little
stress on the server resources, but with the number of
clients we were looking to support this was acceptable.

As for the jar package, we use a tool called "cannery".  You give it a
starting Java class file and it will find an package any
other classes that the starting class file depends on into a jar file.
This optimizes the jar file for the applet to be as small as
it can be.  It's pretty good but it may miss classes that are needed
through runtime reflection, in which case, you simply have to
tell "cannery" to include those class files manually.

Just another thought.  I worked on a previous system that tried to do some
other client side processing such as having a client side
hidden component that would open up a port and listen for updates, etc.
This involved getting into code signing using a certificate
such as from Verisign.  Each browser does this differently with different
code signing requirements.  This was a nightmare and I
don't think you want to go there.

With the solution that I came up with, the client has a one-time download
of the Java Plugin to install into their browser.  This is
not to small, about 5Mb, but not to large either.  Similar to the Flash
plugin.  We also host the Java Plugin on our own web site so
that the client can get it from our company as apposed to Sun's web site.
Sun has a habit of changing and removing links to the
Java Plugin when new versions come out.  We needed something a little more

Hope this helps.


----- Original Message -----
From: <>
To: <>
Sent: Monday, September 24, 2001 2:16 PM
Subject: Re: Limits of Web

> Brett,
> Thanks for your detailed reply.   The application will be deployed in an
> internet environment.   A few more questions. Some of our applets will
> 12 - 15 tab pages each w/its own set of data.  Is it feasible to get an
> quick enough response with this type of gui?  Also, what packing tool did
> you use to produce the Jar files?  And, if can in a sentence or to,
> how  you used XML for communication between the applets and the backend?
> Thanks again
> Jeff
>                     "Brett M.
>                     Bergquist"           To:
>                     <brettb@mail.        cc:
>                     com>                 Subject:     Re: Limits of Web
>                     09/24/01
>                     12:45 PM
>                     Please
>                     respond to
>                     tomcat-user
> Jeff, will your application be deployed in an intranet or internet
> environment?  This might make a difference in the solutions that
> are available.  Just for your information, I faced as similar situation
> the development of a Network Management System used to
> control and manage fiber optic communications equipment that we
> manufacture.
>  I needed a robust and complex gui with things such as greying out fields
> depending on the selections of other fields, validation on
> fields as they are entered, indicating to a user a field has been
> etc.  These needed to be done on the client side.  I
> looked at a few possibilities, namely JavaScript or Java applets.  At the
> time Sun's Jump Start was not available.  I chose to use
> Swing based Java applets.  To get around the differences in browsers, I
> chose to use the Java Plugin to provide this stable (fairly)
> environment.  In addition, in the back end we are using Tomcat with
> servlets, JSP pages, and XML as the communications between our
> Java applets and the backend.  I chose Java over JavaScript because of
> complexities involved in managing browser specific within
> JavaScript and also because of the better development and debugging
> environment I had in Java.
> Using a packaging tool that produces Jar files with the absolute minimum
> need for the applet, we are able to keep out applet size
> down to between 250k and 350k.  Once downloaded the applets are cached,
> this is pretty much a one time hit.  Our applications are
> quite responsive and have the gui needed.
> Just to let you know what we did.
> ----- Original Message -----
> From: <>
> To: <>
> Sent: Monday, September 24, 2001 12:54 PM
> Subject: Re: Limits of Web
> >
> > I asked for help w/technical issues not advice on how to manage
> > Please limit the answers to such.  Nobody's trying to get sympathy or
> pity;
> > just trying to do our jobs.
> >
> >
> >
> >                     Pae Choi
> >                     <paechoi@eart        To:
> >           >           cc:
> >                                          Subject:     Re: Limits of Web
> >                     09/24/01
> >                     11:12 AM
> >                     Please
> >                     respond to
> >                     tomcat-user
> >
> >
> >
> >
> >
> >
> > Then, they need to get help by getting professionals.
> >
> > One would be the architect who can help you folks at least
> > understand what is the difference between the thin and thick
> > clients.
> >
> > Second would be the security speciality who can help you
> > folks understand that the security is not a joke like anyone
> > suddenly realized and think they can grab and use it like
> > a plugable COTS.
> >
> > I've seen many folks use the terms like "client", "customer",
> > "boss", etc just to win the battle and get some sympathy or pity.
> > You need to know how to manage the customer expectaton
> > as well as teach your stakeholders learn that they will not
> > get over night whatever they want and demand just because
> > they think they can piss around you.
> >
> >
> > Pae
> >
> > >
> > > When we started with this app it we did not have the skills needed to
> > > develop Swing applets.  Now the problem appears to be the speed of
> these
> > > applets.  They are way to slow.  They also expect it to be as fast as
> > their
> > > Client Server Applications.  Plus the company I work for is paranoid
> > about
> > > security to the point of irrationality.  If they ever got wind of the
> > > security problems involved in applets they would shut development
> > >
> >
> >
> >
> >

View raw message