Alan,
Presumably these are the two scenarios
http://mysite.com/public/index.html (a completely static html site)
https://mysite.com/myapp/index.jsp (after uses have logged in from the public area)
So, some general nudges in the right direction
a) You don't have to buy 2 domain names, unless of course, you are infact using 2 domains e.g. mysite.com myappsite.com (the https doesn't make it a different domain). Even then you can probably just get away with one, ala
www.mysite.com, applications.mysite.com (which is still only 1 domain name - mysite.com)
b) You will need a SSL certificate (either self-signed which your users will have to accept, or you can buy one from someone like verisign).
If you want tomcat to service the https requests directly, then your URL will change to
https://mysite.com:8443/apps/myapp. In this instance, you have to setup tomcat with a keystore and the like, but for all intents and purposes they are separate processes, and apache won't need to talk to tomcat at all.
If you want your url to be
https://mysite.com/apps/myapps then use mod_jk (available from jakarta.apache.org - the docs are getting quite good now) to get Apache to be the front-man for tomcat. This means that you have to setup SSL with apache, and tomcat is configured to only talk to Apache, and doesn't service any user-requests directly.
I always try to setup applications to run with apache as the front man, my reasons :-
Naturalness of the URL - http://mysite.com/webapp is nicer, and less prone to user forgetfulness (They will forget the port number).Security - if you want to use the default http/https port, then you have to run as root in order to listen on ports less then 1024 (on unix/linux). Apache starts off as root, but requests are serviced by a non-privileged thread. Tomcat won't do that, requests will be serviced by a thread running as root, with all the possible problems that might bring.Running > 1 website on the same box (Tomcat can do this of course, but then you're restricted to having only JSP/static websites)Need to think about how things will work in production. Been a number of times when I goto deploy a webapp to be fronted by apache and it doesn't work because they've relied on some behaviour (I think an amusing one was setting up the web.xml welcome page to be html/index.html which just forwarded to ../index.jsp) that won't be tolerated by apache.