The purpose of OLE is to allow an outside code base to interact with and control an OLE enabled (IDispatch derived) application.

The OLE interface has a client and a server. Your assumption is correct in that Perl code calling Win32::OLE and accessing an application does indeed create an instance of the application. The application can be on the local machine or remote, and it is the Server, while your code is the client, so it would be limited to opening IE and controlling it.

I have created OLE interfacing applications to automate many of the business processes I encounter. From autoformatting wordfiles, reading and aggregating data from from them based on a template, creating dynamic reports in excel from data mined from the web based on a template provided by the "customer" (all of my customers are internal). I've written apps to go through a series of public mail boxes and save off all the attachments, create slides in a PowerPoint presentation based on data I mined from the web (part of the excel application)...The list goes on and on.

I've also written COM components with this interface in mind so that others could transform XML documents through BizTalk and access MSMQ queues in an application specific manner using whatever programming language they preferred.

Really, anything that is done on a regular basis in any of these applications can be automated with the OLE interface. When you are writing in VBA for any of these applications, you are writing code directly against the OLE interface.

C-.