This is a long response, but there are many answers to your question. You can get more specific information in the separate forums here, but here's your overall picture of how to structure this:
1). Unless you can't avoid it, do not use
applets for web-based database interaction. This rule can be bent a little bit if you are building an
intra-net application and the client wants the look-and-feel of a traditional app but served up in web pages, but they should not be used in
inter-net applications, because you have no control over what the client machine is like. Since applets run on the client side, this is very important.
2). For small web-based applications, JSP/Servlet technology connecting directly to a Database should be sufficient. It is not as truly scaleable as EJBs, but there is less processing overhead involved. In this case, I use JSPs to display data to the user and Servlets to perform functions. The Servlet never displays any HTML; once it has perfomed its function it redirects the request to a JSP. (JSPs become Servlets when they are run, but it is much easier to edit a JSP for visual content then it is to edit a Servlet.)
3). Larger web-based applications should be run using EJBs. There is a certain overhead involved with EJBs that makes them not suitable for smaller apps, but they are highly scaleable. If you think that your application will need to grow rapidly, use EJBs. in this situation,
you should use JSPs/Servlets to talk to the EJBs. The EJBs perform functions (Session EJBs) or interact with the database (Entity EJBs). There are two methods to write an Entity EJB to a data base: Container Managed Persistence and Bean Managed Persistence. Using Container Manager Persistence you do not have to write any SQL, but there is a certain amount of setup work to do if you have to move your beans from one vendor's server to another (and not all servers support all databases). Bean Managed Persistence is portable from app server to app server, but not from Database to Database. Use what you need. (I use BMP, but wrote my own dynamic persistence engine, so that I am portable from app sever to app server and data source to data source (including Text and XML)).
4). Due to various technical difficulties, is inadvisable to connect AWT/Swing to an EJB. If you find you must use AWT/Swing, they should communicate with Servlets with communicate with the EJBs. This can be fairly clumsy, but it will work.
5). Java Script runs on the client side. In terms of enterprise applications, it is useful for manipulating data in forms beofre submitting the forms to the server (e.g., copying billing address data to the shipping address data). While not needed, it can be a useful tool to have.
Hope that this helps clear things up. For more information, visit the other, specific, forums and/or read various books on the topics. Also just go out and try building a small application just to
test and prove the technologies to yourself.
[ April 04, 2003: Message edited by: Joel McNary ]