I guess I am trying to determine if Java will do the Job before I invest all this time to learning it. Adthanksvance Tim.
Ok i'll break it a little. Cold Fusion is like ASP. It is also probably like servelets (If I am understanding servelets properly). It runs on the server and returns pure html to the browser. I really wanted to avoid this by using java. Each submission to the server takes a really long time and most validations end up taking several forms to complete.
Why applets. I wanted to use applets so that anybody can come to my web site and start working. I did not want to make people download and install a bunch of stuff (mainly because they are shall we say technologically challenged). Also as the application evolved the users to the application would allways be using the latest version. Same with bug fixes.
If you make your users download a copy of an applet to their hard disk and use that applet, they might not get the update when you provide one without having to hassle them. Suppose they downloaded an applet to their hard disk and used that. Your applet reference will no longer be to your service: www.eporkchop.com/myapplet.jar but something like c:\mystorage\myapplet.jar So you could try C:\mystorage\myapplet5.jar and the next version would be c:\mystorage\myapplet6.jar The user would get a message about how the applet was not found and they would need to download an update.
Seems kind of convoluted to do that. Is an applet the only way to make sure the client is using the latest version of code? Can I write a program (not an applet) that can load classes from my server?. Maybe just a tiny stub of of a program which then loads a series of classes to make sure that the latest version of the code is being used. Would that make any difference at all? I guess I need to understand the differences between a regular application and an applet first. Seems like I am getting ahead of myself.
An applet is a program that runs in a web browser. An application is a program that runs by itself (no browser). I suppose it would be possible to write a program that will always update itself. You could just open a socket to your server and say "hi! I'm version 2.11.2. Am I the latest?" And if the answer is no, the program can download a whole new copy of itself.
Very interesting. Isn't java able to dynamically load classes? What I was planning on doing was to have a stub applet or application that would download a JAR file from my server if the name was different. I.E if the locally saved Jar file is called myjar1.jar and the server is called mayjar2.jar then download the jar2 file. I am still confused about the whole applet application servelet thing somewhat though. Is it possible to do RMI or CORBA from inside a browser?
I want to clear up the application vs. applet thing using as few words as possible. Applet uses the JVM that is in the browser. It runs in the browser. An application uses the JVM that is installed on the machine. The code to run on a browser is a little different; start(), stop(), init(), destroy() are called by the browser when the browser thinks it is time to do so. In an application the public static void main() function of the called class is called.
[This message has been edited by Michael Finney (edited February 04, 1999).]
I think Tim Uckun understands when I say... I want a book. This book would be up to date with JDK1.2 It would explain the things you can only do (or can only do easy/well)in Java. I'm sure something in this book would discuss dynamic loading of Java classes and keeping aplications/applets current. This book would also discuss how to REALLY make network centric applications and why we would want to do such a thing in the first place. I want a book that says "this is why Java is best for the following things". I want the material that says this is what you require to make things work over the internet, it's easy, and people anywhere with a browser can access it. I want to see the bigger picture. I've seen java.lang and java.awt.* with swing. I require more. I want things which will stimulate my thinking and assist me in developing those things that people need and might not even know it. That's my thought process. I want a book.
I agree. A bigger picture is warranted. Not just java the whole thing. It seems to me that everybody is trying to do the same thing. Run code A in server Y return result to code B in machine X. Should be a simple thing really. Instead of some standard way of achieving this there are a dizzying number of technologies and solutions. DCOM, RMI, CORBA, ActiveX, EJB, Servelets and all kinds of transaction servers and assorted middleware products. Not to mention the front end where you can take your pick from pure HTML, ActiveXforms, Java app, Java applets, and just plain old VB/DELPHI/C++ applications. When I was a car salesman (a long long time ago) my sales manager used to be fond of saying "throw enough shit on the wall and some of it's bound the stick". It seems to me that's what SUN, M$, IBM, INPRISE et al are doing. M$ has at least 5 technologies that all compete with themselves. I have spent the last two weeks reading endless websites and white papers and talking to people. I have been quoted solutions that range from free to over 10K. I have downloaded at least a gigabyte of demos and I am still no closer to solving my problem.
Ah! However, I want my book to be just java oriented. (Maybe with intro to CORBA involved too, because java has support for interacting for CORBA). If I had more than java, it would be a huge or diluted book indeed.
You may want to consider the book "Database Programming with JDBC and JAVA" by George Reese from O'Reilly. It is somewhat of a mis named book. This book talks a LOT about writing distributed apps using RMI and some about JDBC. This book gave me a lot of the whys and some of the hows of doing something like this.
OK, this is where the lack of multi-threading begins to get hairy. I'm replying to Paul's questions about my "servlets on the client" proposal. Why servlets and not an application? Well, mainly for ease of use and to leverage the power of existing software. The thinking goes like this. My typical application consists of User Interface, Business Rules and Storage/Transfer Infrastructure. For a fast and effective deployment I want to buy in or re-use as many parts of the system as possible. So, consider the UI. I want a UI that is portable to as many platforms as possible, flexible, familiar and requires a minimum of download bandwidth. That rules out most custom UI libraries. The option we chose was to use the power of the Web browser which is fitted as standard to almost every system I've encountered. It's capable of complex formatted output, input via forms and links to remote pages if required, and is effectively free. A real bargain! So on to the transfer/storage architecture. If we're using a web-based UI, and want to minimise the processing on the client, then it makes sense to transmit as great a proportion of the data frmo the server to the client as pre-formatted HTML. So we need an architecture which is good at storing and delivering HTML-formatted data, but also capable of delivering other forms of content where required. Hmm, sounds like a web server. So in an ideal situation both the client UI (browser) and the central transfer/storage system (web server) can be bought in. But that's only really covered the transfer and storage of data, not business logic. Now as Paul mentions, one possibility is to download an application to the client which manages the connection with the server and updates itself if required. However, there are a few problems with this. It's going to be big, and a large part of it won't be directly business-related (code to manage updates etc.). Also, applications tend to grow into single-lump solutions where a small change may require the download of a lot of software. As we've already decided that the UI will use a standard browser it will have to talk HTTP and listen on a socket - but that's all a web server does, so why not standardise that component, and buy one in. So, we have a Web server on the central server, a browser and a simple web server on the client. What would be the best way to build the business login into these commercial components? Servlets, of course! Servlets are typically compact, easy to download, dynamically installable, good at generating and processing HTML User Interfaces and so on. A system like this is capable of using a HTML UI in a standard browser, either working on-line to the central server (local servlets just pass through/cache data) or off-line (browser only accesses local servlets and data). Software updates are completely transparent to the user and so on. I find this a very clean and powerful pattern for solving this kind of problem. Frank.
A reply in reference to Tim Uckun (posted 02-04-99 04:16 PM MT (US)) I suggest you consider buying "Not Just Java" (Java Series) by Peter Van Der Linden Paperback - 319 pages 2nd edition (January 1999) Go to Amazon and do a book search for Not Just Java. Be sure to click on the Published 1999 version. Read the reviews and decide. Tell us if you think that is a good idea. Thanks.
Is using the Java plugin a bad idea for internet clients? I know the documentation says that the plug-in is intended for intranets. I bet it is because internet connections are way to slow and LANs (5mb to download JDK1.2 plugin) take 3-10 minutes anyway. Please, tell me what you think.
Another question. If a person wants to support Macs and the latest they can run is JDK1.1.6 with a plugin, should all other development on other platforms for the product stay with JDK1.1.6? You would have to because you want your Byte codes to run on Macs as well as Windows and such. I'm thinking about Browsers in particular here.