Limits of Web
I have a question regarding the limits of web applications. I sent out an e-mail requesting help for a problem with submitting multiple forms and the responses I am getting say I am nuts for trying to do such complicated application on the Web. My problem is that I work for a government agency that wants to take very complicated client server data entry and reporting applications (there are master/details that go three levels deep) and rewrite them for use on the web. In order to save money they want them to be similar enough to the client-server applications so that they will not have to retrain users. I am currently finishing up the first (and easiest) of these applications and have had not a few headaches and frustrations. My question is using technologies such as Java, Tomcat, JSP, and Tag Libraries, how realistic is it to expect to be able to develop complicated data entry forms with the same ease of use, precision, and stability as client server applications using such tools as Java Swing, PowerBuilder, VB or Oracle Developer? Are there tools that I am missing that would make this easier or is the web just not able to handle such sophisticated apps? Am I setting myself up for disaster? Thanks In Advance Jeff Sulman
RE: Limits of Web
Jeff, My opinion is to reset the customer's expectation. I have been there and the best way is to inform them of the differences between web-enabled and VB/PB apps. You will not be able to provide all (if any) of the functionalities that VB, PowerBuilder, client-server apps can via the web. Even with all the JavaScripts out there it still is hard. Southin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, September 24, 2001 9:59 AM To: [EMAIL PROTECTED] Subject: Limits of Web I have a question regarding the limits of web applications. I sent out an e-mail requesting help for a problem with submitting multiple forms and the responses I am getting say I am nuts for trying to do such complicated application on the Web. My problem is that I work for a government agency that wants to take very complicated client server data entry and reporting applications (there are master/details that go three levels deep) and rewrite them for use on the web. In order to save money they want them to be similar enough to the client-server applications so that they will not have to retrain users. I am currently finishing up the first (and easiest) of these applications and have had not a few headaches and frustrations. My question is using technologies such as Java, Tomcat, JSP, and Tag Libraries, how realistic is it to expect to be able to develop complicated data entry forms with the same ease of use, precision, and stability as client server applications using such tools as Java Swing, PowerBuilder, VB or Oracle Developer? Are there tools that I am missing that would make this easier or is the web just not able to handle such sophisticated apps? Am I setting myself up for disaster? Thanks In Advance Jeff Sulman
Re: Limits of Web
At 04:59 PM 24/09/01, you wrote: >I have a question regarding the limits of web applications. > >I sent out an e-mail requesting help for a problem with submitting multiple >forms and the responses I am getting say I am nuts for trying to do such >complicated application on the Web. > >My problem is that I work for a government agency that wants to take very >complicated client server data entry and reporting applications (there are >master/details that go three levels deep) and rewrite them for use on the >web. > >In order to save money they want them to be similar enough to the >client-server applications so that they will not have to retrain users. I >am currently finishing up the first (and easiest) of these applications and >have had not a few headaches and frustrations. > >My question is using technologies such as Java, Tomcat, JSP, and Tag >Libraries, how realistic is it to expect to be able to develop complicated >data entry forms with the same ease of use, precision, and stability as >client server applications using such tools as Java Swing, PowerBuilder, VB >or Oracle Developer? Are there tools that I am missing that would make >this easier or is the web just not able to handle such sophisticated apps? >Am I setting myself up for disaster? Just out of interest, what's to stop you using a Swing applet? Jim -- * Jim Cheesman * Trabajo: [EMAIL PROTECTED] - (34)(91) 724 9200 x 2360 I have my doubts about disbelief.
RE: Limits of Web
Security -Original Message- From: Jim Cheesman [mailto:[EMAIL PROTECTED]] Sent: Monday, September 24, 2001 10:27 AM To: [EMAIL PROTECTED] Subject: Re: Limits of Web At 04:59 PM 24/09/01, you wrote: >I have a question regarding the limits of web applications. > >I sent out an e-mail requesting help for a problem with submitting multiple >forms and the responses I am getting say I am nuts for trying to do such >complicated application on the Web. > >My problem is that I work for a government agency that wants to take very >complicated client server data entry and reporting applications (there are >master/details that go three levels deep) and rewrite them for use on the >web. > >In order to save money they want them to be similar enough to the >client-server applications so that they will not have to retrain users. I >am currently finishing up the first (and easiest) of these applications and >have had not a few headaches and frustrations. > >My question is using technologies such as Java, Tomcat, JSP, and Tag >Libraries, how realistic is it to expect to be able to develop complicated >data entry forms with the same ease of use, precision, and stability as >client server applications using such tools as Java Swing, PowerBuilder, VB >or Oracle Developer? Are there tools that I am missing that would make >this easier or is the web just not able to handle such sophisticated apps? >Am I setting myself up for disaster? Just out of interest, what's to stop you using a Swing applet? Jim -- * Jim Cheesman * Trabajo: [EMAIL PROTECTED] - (34)(91) 724 9200 x 2360 I have my doubts about disbelief.
RE: Limits of Web
The web is not that complicated a paradigm and trying to shoehorn it into a rich GUI environment can be a real headache. (At least that's my experience) Furthermore people using a web app aren't necessarily used to having to navigate that rich GUI. IMO part of the web's success is that it has a simpler interface model. Make a web app look like a web app not a VB App and your users will be happier and your training costs lower. If you are just looking for the ease-of-deployment that comes with a web app but really need a rich client front end I'd recommend checking out java web start (look on the javasoft web site) as a way to automatically deploy changes in a SWING based app to clients. HTH > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 24, 2001 7:59 AM > To: [EMAIL PROTECTED] > Subject: Limits of Web > > > I have a question regarding the limits of web applications. > > I sent out an e-mail requesting help for a problem with > submitting multiple > forms and the responses I am getting say I am nuts for trying > to do such > complicated application on the Web. > > My problem is that I work for a government agency that wants > to take very > complicated client server data entry and reporting > applications (there are > master/details that go three levels deep) and rewrite them > for use on the > web. > > In order to save money they want them to be similar enough to the > client-server applications so that they will not have to > retrain users. I > am currently finishing up the first (and easiest) of these > applications and > have had not a few headaches and frustrations. > > My question is using technologies such as Java, Tomcat, JSP, and Tag > Libraries, how realistic is it to expect to be able to > develop complicated > data entry forms with the same ease of use, precision, and > stability as > client server applications using such tools as Java Swing, > PowerBuilder, VB > or Oracle Developer? Are there tools that I am missing that > would make > this easier or is the web just not able to handle such > sophisticated apps? > Am I setting myself up for disaster? > > Thanks In Advance > > > Jeff Sulman > >
Re: Limits of Web
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.
Re: Limits of Web
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. >
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 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. >
Re: Limits of Web
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 > 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. > > > > > >
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] 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 > 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 f
Re: Limits of Web
Hi, Jim, I am unclear about your question. The Web can easily take care of this sort of thing. Certain there is no trouble with a number of Java solutions to the job at hand. I am not sure why you would think that Java could not do this. It is a relatively easy task. It's just a matter of banging the solution out, really. You must have an underlying problem that you are not articulating? If you are an administrator that does not know the limits of the technology, then the simple answer is that this is easy. Micael -Original Message- From: Jim Cheesman <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Monday, September 24, 2001 8:22 AM Subject: Re: Limits of Web >At 04:59 PM 24/09/01, you wrote: >>I have a question regarding the limits of web applications. >> >>I sent out an e-mail requesting help for a problem with submitting multiple >>forms and the responses I am getting say I am nuts for trying to do such >>complicated application on the Web. >> >>My problem is that I work for a government agency that wants to take very >>complicated client server data entry and reporting applications (there are >>master/details that go three levels deep) and rewrite them for use on the >>web. >> >>In order to save money they want them to be similar enough to the >>client-server applications so that they will not have to retrain users. I >>am currently finishing up the first (and easiest) of these applications and >>have had not a few headaches and frustrations. >> >>My question is using technologies such as Java, Tomcat, JSP, and Tag >>Libraries, how realistic is it to expect to be able to develop complicated >>data entry forms with the same ease of use, precision, and stability as >>client server applications using such tools as Java Swing, PowerBuilder, VB >>or Oracle Developer? Are there tools that I am missing that would make >>this easier or is the web just not able to handle such sophisticated apps? >>Am I setting myself up for disaster? > > >Just out of interest, what's to stop you using a Swing applet? > > >Jim > > > > >-- > > * Jim Cheesman * > Trabajo: >[EMAIL PROTECTED] - (34)(91) 724 9200 x 2360 >I have my >doubts about disbelief. > > >
Re: Limits of Web
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] >
Re: Limits of Web
There is no need to use Swing, but it is not that slow. Chances are that your developers have learned how to write Swing but that they have no learned how to wrap the application up for speed. On the security issues, you can make things as secure as you want, so I don't get that problem. -Original Message- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Monday, September 24, 2001 8:51 AM Subject: Re: Limits of Web > >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. > >
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] 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 op
Re: Limits of Web
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] > 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
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] 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] > 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 > betw
Re: Limits of Web
At 08:41 PM 24/09/01, you wrote: >Hi, Jim, > >I am unclear about your question. The Web can easily take care of this sort >of thing. Certain there is no trouble with a number of Java solutions to >the job at hand. I am not sure why you would think that Java could not do >this. Eh? I never said java couldn't do the task!!! I was asking if *Jeff* had considered using an applet! >It is a relatively easy task. It's just a matter of banging the >solution out, really. You must have an underlying problem that you are not >articulating? > >If you are an administrator that does not know the limits of the technology, >then the simple answer is that this is easy. Really? A secure, fast loading applet that has (at last post) maybe 12-15 tabs of data to enter? (Which I really don't like the sound of - I'm not surprised that Jeff's management want to maximise the use they're getting from their trained users, though perhaps with a better designed form in the first place... there's *no* excuse for 12-15 tabs ;) I repeat: Secure, fast loading, reliable, easy to use (?) - this you call easy??? >Micael >-Original Message- >From: Jim Cheesman <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> >Date: Monday, September 24, 2001 8:22 AM >Subject: Re: Limits of Web > > > >At 04:59 PM 24/09/01, you wrote: > >>I have a question regarding the limits of web applications. > >> > >>I sent out an e-mail requesting help for a problem with submitting >multiple > >>forms and the responses I am getting say I am nuts for trying to do such > >>complicated application on the Web. > >> > >>My problem is that I work for a government agency that wants to take very > >>complicated client server data entry and reporting applications (there are > >>master/details that go three levels deep) and rewrite them for use on the > >>web. > >> > >>In order to save money they want them to be similar enough to the > >>client-server applications so that they will not have to retrain users. >I > >>am currently finishing up the first (and easiest) of these applications >and > >>have had not a few headaches and frustrations. > >> > >>My question is using technologies such as Java, Tomcat, JSP, and Tag > >>Libraries, how realistic is it to expect to be able to develop complicated > >>data entry forms with the same ease of use, precision, and stability as > >>client server applications using such tools as Java Swing, PowerBuilder, >VB > >>or Oracle Developer? Are there tools that I am missing that would make > >>this easier or is the web just not able to handle such sophisticated apps? > >>Am I setting myself up for disaster? > > > > > >Just out of interest, what's to stop you using a Swing applet? > > > > > >Jim > > > > > > > > > >-- > > > > * Jim Cheesman * > > Trabajo: > >[EMAIL PROTECTED] - (34)(91) 724 9200 x 2360 > >I have my > >doubts about disbelief. > > > > > > -- * Jim Cheesman * Trabajo: [EMAIL PROTECTED] - (34)(91) 724 9200 x 2360 A kind word turneth away wrath, but not as effectively as superior firepower.
Re: Limits of Web
In my hunch, they do not even have the proper Requirements so that they do not even have a Right Architecture as a subsequent result. That's why they are wondering and drifting unless their technical team is just exploring and trying to create the pilot or poc system without the baseline architecture. This is a common problem and has been practiced at many organizations in many years. Especially in the large-scale, enterprise-level solution development practice. More than likely, they will face the design problem during the course of the development process and face the architectural problem even they may luckily pass the acceptance test. Speaking of "Easy of Use", "Reliability", "Fast Loading or Performance", "Security", "ETC", they are related to the Customer Satisfaction, Modeling, Architecturing, Building Right System Right, etc. I will tell you ONE THING for sure. Those issues are never been easy unless you are building a lousy dog house and it's ok and allowed to get rid of the dog if s/he does not like the dog house. But I doubt that they can do it. Just take a moment to read the history of TC4 or Catalina why they have remodel the architecture. At least, the TC team learned after a period of time albeit they learned in a hard way. But some learn in the harder way. Pae > At 08:41 PM 24/09/01, you wrote: > >Hi, Jim, > > > >I am unclear about your question. The Web can easily take care of this sort > >of thing. Certain there is no trouble with a number of Java solutions to > >the job at hand. I am not sure why you would think that Java could not do > >this. > > > Eh? I never said java couldn't do the task!!! I was asking if *Jeff* had > considered using an applet! > > > > >It is a relatively easy task. It's just a matter of banging the > >solution out, really. You must have an underlying problem that you are not > >articulating? > > > >If you are an administrator that does not know the limits of the technology, > >then the simple answer is that this is easy. > > > Really? A secure, fast loading applet that has (at last post) maybe 12-15 > tabs of data to enter? (Which I really don't like the sound of - I'm not > surprised that Jeff's management want to maximise the use they're getting > from their trained users, though perhaps with a better designed form in the > first place... there's *no* excuse for 12-15 tabs ;) > > I repeat: Secure, fast loading, reliable, easy to use (?) - this you call > easy??? > > > > >Micael > >-Original Message- > >From: Jim Cheesman <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > >Date: Monday, September 24, 2001 8:22 AM > >Subject: Re: Limits of Web > > > > > > >At 04:59 PM 24/09/01, you wrote: > > >>I have a question regarding the limits of web applications. > > >> > > >>I sent out an e-mail requesting help for a problem with submitting > >multiple > > >>forms and the responses I am getting say I am nuts for trying to do such > > >>complicated application on the Web. > > >> > > >>My problem is that I work for a government agency that wants to take very > > >>complicated client server data entry and reporting applications (there are > > >>master/details that go three levels deep) and rewrite them for use on the > > >>web. > > >> > > >>In order to save money they want them to be similar enough to the > > >>client-server applications so that they will not have to retrain users. > >I > > >>am currently finishing up the first (and easiest) of these applications > >and > > >>have had not a few headaches and frustrations. > > >> > > >>My question is using technologies such as Java, Tomcat, JSP, and Tag > > >>Libraries, how realistic is it to expect to be able to develop complicated > > >>data entry forms with the same ease of use, precision, and stability as > > >>client server applications using such tools as Java Swing, PowerBuilder, > >VB > > >>or Oracle Developer? Are there tools that I am missing that would make > > >>this easier or is the web just not able to handle such sophisticated apps? > > >>Am I setting myself up for disaster? > > > > > > > > >Just out of interest, what's to stop you using a Swing applet? > > > > > > > > >Jim > > > > > > > > > > > > > > >-- > > > > > > * Jim Cheesman * > > > Trabajo: > > >[EMAIL PROTECTED] - (34)(91) 724 9200 x 2360 > > >I have my > > >doubts about disbelief. > > > > > > > > > > > > -- > >* Jim Cheesman * > Trabajo: > [EMAIL PROTECTED] - (34)(91) 724 9200 x 2360 > A kind word > turneth away wrath, but not >as effectively as superior > firepower. > >
Re: Limits of Web
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] > 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] > > > 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 ha
Re: Limits of Web
Pae, I agree completely except for one thing, we are not learning the hard way. We started with a small, none enterprise application using one archetecture and realize that it is barely capable of handling what we are doing. All I am doing now is seeing if there are other archetectures out there that we should be looking into before we get into larger enterprise scale applications. Is this learning the hard way? No, we've learned our lesson and are now trying to correct it. Secondly, not all companies have the resources to hire professional consultants to do their work. I wish we did be we do not. Therefore the only thing we can do is read books, use resources like the tomcat-users group and plod along increasing our technical knowledge - often by making mistakes and learning from them. Thanks Jeff
Re: Limits of Web
I think it depends on the requirements of the application. If all you need is data entry forms that contain elements such as text boxes, drop-down list, radio buttons, etc., then, you can do it no problem. In the end, you may find that it's actually a hell of a lot easier making them Web based. The way you write things is a bit different, but, once you get some of the basics down, it's not that hard. One of the main issues that you face when migrating from a client/server environment to a Web environment is the fact that HTTP is a stateless protocol. However, Java Servlets let you store session/state information on the server side which solves this problem. Jon - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 24, 2001 9:59 AM Subject: Limits of Web > I have a question regarding the limits of web applications. > > I sent out an e-mail requesting help for a problem with submitting multiple > forms and the responses I am getting say I am nuts for trying to do such > complicated application on the Web. > > My problem is that I work for a government agency that wants to take very > complicated client server data entry and reporting applications (there are > master/details that go three levels deep) and rewrite them for use on the > web. > > In order to save money they want them to be similar enough to the > client-server applications so that they will not have to retrain users. I > am currently finishing up the first (and easiest) of these applications and > have had not a few headaches and frustrations. > > My question is using technologies such as Java, Tomcat, JSP, and Tag > Libraries, how realistic is it to expect to be able to develop complicated > data entry forms with the same ease of use, precision, and stability as > client server applications using such tools as Java Swing, PowerBuilder, VB > or Oracle Developer? Are there tools that I am missing that would make > this easier or is the web just not able to handle such sophisticated apps? > Am I setting myself up for disaster? > > Thanks In Advance > > > Jeff Sulman >
Re: Limits of Web
Unless, Web forms are inadequate, I wouldn't use applets at all, I'd just make it completely server-side and use servlets. Jon - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 24, 2001 10:43 AM Subject: Re: Limits of Web > > 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. >
