What is the Difference between ‘Word Automation’ and ‘Word Automation Services’?

http://blogs.msdn.com/b/ericwhite/archive/2010/12/07/what-is-the-difference-between-word-automation-and-word-automation-services.aspx

‘Word Automation’ and ‘Word Automation Services’ are two developer building blocks that have similar names, and have overlapping functionality, but are very different pieces of technology.  I received some email about the post Understanding the Three Approaches to Office Development using VSTO where readers were confused about this, so here is the scoop.

This post is one in a series on Microsoft Office 2010 application development. These posts will be published in the future as part of an MSDN article. As usual, after the MSDN article is published, I’ll place pointers in the blog posts to the article on MSDN.

1. Office/SharePoint Building Blocks and Developer Stories
2. Overview of Office 2010 Application Development
3. Office Application Scenarios
4. Understanding the Three Approaches to Office Development using VSTO
5. What is the Difference between ‘Word Automation’ and ‘Word Automation Services’?
6. Understanding the Architecture of Office 2010 Managed Add-Ins and Customizations
7. Understanding the Difference between Custom Task Panes and Action Panes
8. Microsoft Word 2010 Developer Building Blocks
9. Comparing Excel Automation to Excel Services

Word Automation

Word Automation is a technology where you can write a .NET application that uses the Word client executable to accomplish some task such as creating a document, querying a document for content, or modifying the content of a document.  Its roots are COM – in addition to using .NET to link to the Primary Interop Assemblies, you can use C++ or VB6 (or any other technology that can consume COM) to automate the Word client application.  In other words, you write a program that runs Word.  There is a rich object model that you can use to manipulate paragraphs, ranges, comments, etc.  This technology has been around for years.  If you are an experienced Office developer who needed to generate a large number of documents (prior to the introduction of the Open XML SDK), then you have probably used Word Automation at one time or another.

The user operates a .NET managed application that in turn runs the Word 2007 or Word 2010 client.

To make this completely clear, the following small console application starts Word, adds a paragraph, saves it, and then causes the Word application to quit.  You need to add a reference to the Word 2010 PIA.  You find this on the COM tab.

Note that the following sample uses the feature C# 4.0 that allows you to omit arguments that have default values.

using Word = Microsoft.Office.Interop.Word;
 
class Program
{
    static void Main(string[] args)
    {
        Word.Application app = new Word.Application();
        app.Visible = true;
        Word.Document doc = app.Documents.Add();
        Word.Range range = doc.Content;
        Word.Paragraph paragraph = range.Paragraphs.Add();
        paragraph.Range.Text = "Hello World!";
        object saveChanges = true;
        doc.SaveAs2(@"E:\Temp\Test.docx");
        ((Microsoft.Office.Interop.Word._Application)app).Quit();
    }
}
 

This scenario, where you are programmatically generating word-processing documents, is where you should be using the Open XML SDK instead of Word automation.

Word Automation Services

Word Automation Services is a service that runs under SharePoint Server 2010 (both Standard and Enterprise) that can convert documents to and from various formats, and can update content inside Word documents, such as calculated fields (like the table-of-contents).  Word Automation Services is specifically designed to complement the Open XML SDK for server-side scenarios.  Some tasks, such as repagination, updating fields, and importing altChunk elements are difficult to accomplish when using the Open XML SDK, so if your scenario requires those areas of functionality, it’s great to use the Open XML SDK together with Word Automation Services.  Both the Open XML SDK and Word Automation Services are ‘server hardened’.  You can build systems that generate and process hundreds or thousands of documents per day.

To use Word Automation Services, you must write code that runs on the SharePoint server; you cannot directly access Word Automation Services from a client computer.  The Managed Client Object Model does not include a programming interface to Word Automation Services.  See Developing with SharePoint 2010 Word Automation Services for more information.

However, there is an easy way to work around the server-side limitation of Word Automation Services:

• Write a WCF service that runs on the SharePoint server computer that exposes the functionality that you need in your client application.
• Write your client application to consume that WCF service, integrating Word Automation Services functionality into the client application.

You might have a scenario where you want to generate a PDF or XPS document based on user input in the client application.  To implement this, you need to expose functions in the WCF service that can take a Word document as input, and returns a PDF or XPS document.  You can then use the Open XML SDK to generate an Open XML word-processing document, and then use your WCF service to do the conversion.

Excel Automation vs Excel Services

Excel has the same possibilities.  You can write a program that automates the Excel client application to accomplish certain scenarios.  Alternatively, you can use Excel Services (part of SharePoint Server 2010 Enterprise) to implement functionality.

In contrast to Word, there are scenarios where using Excel automation is the only way to accomplish specific tasks.  If you need to modify a spreadsheet, such as inserting or deleting a row or column, then the appropriate technology may be to automate the Excel client application.  Inserting a row or column using the Open XML SDK would involve parsing formulas and modifying the parsed formulas, a fairly involved operation.