This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
There's several options you can investigate. One would be to use Http requests (usually, though servlets can in theory be deployed on servers using other protocols) to communicate with the servlet engine just like a web browser would. This approach has the major advantage that your servlets don't need to change in any way, they don't even have to know it's not a browser that's connecting. Your application may need to be more complex than you want it to be though, especially if you need to maintain state between requests (and thus need cookie handling).
Another approach would create an extra service in each servlet, listening in on a standard TCP port. This system could alternatively use RMI as a protocol. Your application would place calls to this port and the servlet would then be triggered internally by that service. Of course this means major changes to your servlets.
Last but not least is a kinda hybrid solution which is to implement your servlets to provide SOAP services. This is now probably pretty much the standardised solution.