Basically what is done is to use an URL to identify the servlet, get an
HttpURLConnection, from the URL, setup the connection to do
output and input, set the request header for the content type to be "text/xml", get an
output stream for the connection, and write
the XML document to the stream. Then, get an input stream from the connection, read
the stream, and reconstruct the response XML
document from the data read. The various XML parsing packages have the ability to
write the XML document given a stream and to read
a stream and construct an XML document.
I'm sure that the same could be done without using applets, by constructing a document
and posting it using one of the scripting
languages such as JavaScript. It appears to me, however, that it would be cumbersome,
and I have not attempted to do so.
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 24, 2001 4:38 PM
Subject: Re: Limits of Web
>
>
> Brett,
>
> I 've a question regarding the communication between the Applet and
> Servelt (server). How can I send the XML file to the Sevlet from the
> Applet(Client) And also how can I get back the XML file with results from
> the Servlet to Applet, so that I can parse the results into fields..
>
> And also, is there any way to get same above XML communication between
> client and WebServer with out using Applets. For Ex:-> submitting a XML
> file instead of submitting a FORM.
>
> Thanks in advance.
>
> -Chinni.
>
>
>-----------------------------------------------------------------------------------------------------------
>
> V R Chinni (DPRA).
> Contractor for EPA.
> 214-665-6783
>
>-----------------------------------------------------------------------------------------------------------
>
>
>
>
>
> "Brett M.
> Bergquist" To: [EMAIL PROTECTED]
> <brettb@mail. cc:
> com> Subject: Re: Limits of Web
>
> 09/24/01
> 03:08 PM
> Please
> respond to
> tomcat-user
>
>
>
>
>
>
> Exactly. In my case, instead of performing SQL on a database, I perform
> SNMP on a network device. The same logic applies, however.
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, September 24, 2001 3:49 PM
> Subject: Re: Limits of Web
>
>
> >
> > Brett,
> > 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:
> [EMAIL PROTECTED]
> > <brettb@mail. cc:
> > com> Subject: Re: Limits of Web
> >
> > 09/24/01
> > 01:46 PM
> > Please
> > respond to
> > tomcat-user
> >
> >
> >
> >
> >
> >
> > 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
> > stable.
> >
> > Hope this helps.
> >
> > Brett
> >
> > ----- Original Message -----
> > From: <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > 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
> > have
> > > 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,
> > explain
> > > how you used XML for communication between the applets and the
> backend?
> > >
> > > Thanks again
> > >
> > > Jeff
> > >
> > >
> > >
> > > "Brett M.
> > > Bergquist" To:
> > [EMAIL PROTECTED]
> > > <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
> > in
> > > 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
> > changed,
> > > 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
> > the
> > > 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,
> > so
> > > 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: <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > 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
> > clients.
> > > > 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:
> > > [EMAIL PROTECTED]
> > > > hlink.net> 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
> > down.
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
