I think there is an issue that has to be mentioned here. The search for universal protocol adoption is aimed at allowing automatic parameterized transactions between computers without human intervention. So if your business applications support (the monster) SOAP protocol, say, between you and your suppliers to run a business transaction, the computers can make business interactions and perform the transaction. At this point there is no graphic interface involved. If after the transaction the log is not enough and there is need for a report, then comes Swing, HTML, Servlets, JSPs, etc for the Browser, server, and the performance/security issues.
Luis. ----- Original Message ----- From: "Christopher K. St. John" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 07, 2002 1:17 PM Subject: Re: Servlets + Swing > "Grace S. Aguilar" wrote: > > > > I'm wondering, if I'd be using Servlets that would require the browser to be > > downloaded followed by the loading of the applet. On the other hand, if I > > opt to use RMI, I could be able to run the application with (using Java Web > > Start) or w/out the browser. However, I read in one article that it takes > > long time to perform remote method calls. > > > > I think you may be mixing some different issues: > > 1) Which RPC mechanism you use to get your client talking > to your server: raw HTTP, SOAP over HTTP, RMI, plain old > sockets, etc. > > 2) Which user interface mechanism you use: pure Swing (a > regular Java application), pure HTML (just a browser), > or a Swing applet running inside an HTML browser. > > 3) How you implement your server logic: putting the logic > right in the servlets, putting the logic inside the > RMI method implementations, or putting the logic in > beans (of one sort or another) that can be called > from an RMI or servlet container. > > 4) Your deployment mechanism: Java Web Start, download an > applet into a browser, etc. > > Many people choose the raw HTTP/pure HTML/code-right > inside-the-servlets approach, but you are pretty much > free to mix and match as you want. Another popular option > is raw HTTP/pure HTML/servlets+EJB. Or you could do a > SOAP/pure Swing/servlets implementation. > > You need to address each of the above three categories > on their own merits. For instance, RMI over an unreliable > transport like the public internet is risky, but RMI over > a LAN is perfectly fine (and if anything is considerably > faster than a bloated monster like SOAP) > > > -- > Christopher St. John [EMAIL PROTECTED] > DistribuTopia http://www.distributopia.com > > > ___________________________________________________________________________ > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff SERVLET-INTEREST". > > Archives: http://archives.java.sun.com/archives/servlet-interest.html > Resources: http://java.sun.com/products/servlet/external-resources.html > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > > ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
