Although this is an old question, there is not a lot of WebLogic specific insight into the answer. Here is my experience from 7 or so years of dealing with WebLogic (with and without a Netscaler as backend).
1) Why are you exposing your application on port 7001 or 7002? Typically, 7001 and 7002 would house the AdminServer, and you certainly DO NOT want people to be able to get to http://...:7001/console (or https://....:7002/console). Port 7001 and 7002 should only be able to be accessed from trusted (administrative) parts of your network.
1a) Typically, if you are using Oracle Fusion Middleware, the application would be run inside a separate managed server, which gets its own ports. As an example, Oracle WebCentre Content runs in a managed server called UCM_server1, which has its primary service ports as 16200 (http) and 16201 (https)
2) You should really put WebLogic behind a reverse proxy to surface any sort of site. We've generally used either OHS (Oracle's version of httpd) or Apache httpd. Then typically you would use the weblogic_module within httpd to reverse proxy to your WebLogic managed server. (and in its advanced settings you would set 'Enable WebLogic module' (or named similarly, I can't recall it off the top of my head).
2a) The weblogic_module is particularly important (or rather, it enables particularly important features when used behind a reverse proxy). Features like knowing:
Did the traffic come in on http or https (important if the application wants to craft links / redirects and you want to avoid things like redirect loops).
What IP did the traffic come from (particularly important if using SSO, depending on how sane your security settings are)
2b) Most of what the weblogic_module does is set particular HTTP request headers. Enabling the 'Use weblogic module' in the settings of the managed server simply tells WebLogic "trust some particular headers that come into the requests and use those to learn more about where the traffic came from and how it entered the system".
Actually, I would suggest its better to avoid using the weblogic_module, particularly if you want to make a better "oops, the site is unavailable" experience (ie. 503 handler) without redirecting the user (changing their context so they can't just reload the page). Just do the same things that weblogic_module is doing -- its not terribly difficult.
3) Stick a cache in front of that (varnish, nginx, etc.). In my experience, you do really want to only be serving the dynamic stuff from WebLogic, and make sure you serve static content from something optimized for that purpose. Don't tie up your worker threads needlessly; they can be scarce resources at times. Depending on your application, you may prefer to have something that allows you to have easy control over things like cache headers (cause some products --- Oracle WebCentre Content, I'm looking at you --- are just useless when it comes to making the site cache-friendly without rewriting Cache-Control headers).
4) You very likely want to have one URL... having different internal and external URLs is... just really awful. Consider using techniques such as 'split-horizon' DNS, whereby internal clients will get one IP (eg. 10.x.x.x), and external clients get another (eg. 123.x.x.x), or just serve all from the one public IP. You should have the same SSL certificate on each; HSTS may very well give you issues otherwise.
5) Speaking SSL, I would suggest that you also use self-signed certificates (or locally issued certificates if you have a local CA) for the internals (eg. WebLogic Servers such as AdminServer, as well as Nodemanager), and just have CA certificates on the actual web-heads.
6) If using httpd, I would highly recommend that you deploy it with the likes of mod_remoteip, with the idea being that you have a good source of logging.
The A-Team (they are from Oracle -- and very knowledgeable about various Oracle products) have a good blog post on the topic of weblogic_module: SSL offloading and WebLogic server
F5 have a useful deployment guide that shows how you configure a reverse proxy (F5 BigIP in their case, but still relevant for Netscaler or just httpd) and not have to use weblogic_module.
7) You're probably going to hate me for giving you so much to think about... but I tell you, its all driven by experience ... some of which is quite painful.
8) Oh, and in case you're running your Java workloads on a VMWare environment (that doesn't expose a hardware random number generator), you're going to want to do something to ensure that your application only ever uses /dev/urandom, and never /dev/random --- find all jre/lib/security/java.security files and set securerandom.source=file:/dev/./urandom to work around very long-standing (possibly resolved finally somewhere in Java 8) bug whereby it would be 'clever' and end up using /dev/random, making things like startup abominably slow.
