This can go in a couple of directions.
I don't actually recommend connecting Tomcat directly to the Internet. In order to work with the standard HTTP and HTTPS ports (80 and 443), Tomcat must run as a privileged user, which is a security exposure. Better to use a safer proxy such as Apache httpd and have all the Tomcat stuff internal. So ideally, all of the code you need could then be in a single webapp internally, proxied via Apache or Squid or something.
That's probably not possible without major surgery on the apps. So the next best thing is to set up a communications channel between the webapps. The most flexible option would be to have the first app make web services calls to the second app. However, since you're on an internal network, where you can use certain mechanisms that are difficult-to-impossible to use on the open Internet. The 2 most likely candidates for me would be RMI or
EJB (and EJB is basically an extension of RMI).
Tomcat doesn't implement either EJB or RMI natively the way full-stack servers such as
JBoss do, but you can add such functionality to individual applications by incorporating the right libraries.
Another option is available if you haven't coded yourself specifically into a webapp architecture, and that's to replace the internal Tomcat's functions with a standard RMI server. If you don't actually need all the functionality of a web server, that can make things a little more lightweight. I used to work with a system that had the primary webapp offload long-running tasks to an RMI service.