Since I know zilch about salesforce platform, you'll have to evaluate my answer for feasibility from salesforce point of view. But some cursory googling says salesforce
can do HTTP requests.
So assuming that API is feasible for you and you are familiar with
servlets, one simplistic solution would be like this:
1. Deploy the conversion code as a servlet in
Tomcat on the EC2 instance. It could also be deployed as a servlet based or standalone RESTful web service, if you're more familiar with RESTful services.
2. You need a reliable URL (like "http://yourec2server.yourapp.yourcompany.com" or "http://your-EC2-elastic-IP-address") to address your EC2 instance.
The public DNS name assigned by Amazon is fairly reliable, but it may change everytime your EC2 instance is restarted.
A better option is to get an elastic IP which acts like a static unchanging IP.
3. The salesforce app sends a HTTP POST multipart request to that servlet/webservice URL (let's say "http://your-EC2-elastic-IP-address/convert)", with the Word file as a multipart upload.
4. The servlet/webservice uses OpenOffice API to convert received Word file to PDF, publishes that file in some directory which is served by Tomcat, and returns that published path as a URL (say "http://your-EC2-elastic-IP-address/published/convertedfile.pdf").
5. The salesforce app now sends another HTTP GET request to that published file URL to download the PDF to its environment.
6. Once the salesforce app is done with the PDF, it can send another request to the servlet/ web service to delete the file.
I don't know how many files you expect to convert per hour, but an elastic IP and servlet based solution certainly set you up to scale out to more instances if necessary. If this scaling out is foreseen, then prefer to publish that PDF to a common storage like an S3 bucket which is accessible from all instances, instead of publishing it in a local directory under Tomcat which won't be accessible from other instances.