Visual Studio 2005 Tools for Office (VSTO 2005) supports a multitier architecture for document processing solutions. As shown here, a user (such as a builder seeking a permit) works with documents using a client component based on Office 2003, while a server component synchronizes data between documents and corporate applications (such as a permit management system). The components are structured as follows:

User. The user works with Word and Excel documents that contain application data in specially tagged XML "data islands." For example, a Word-based building permit application might include an XML data island that holds all applicant data such as company name, legal description of the building site, class of the proposed property, and so on. This information would be displayed to the user as form fields in the Word document.

Client. The client portion consists of two components: an application-specific .NET code package (called an assembly) authored by the developer and the VSTO 2005 engine. When the document is opened, the VSTO 2005 client engine automatically loads and runs the developer's code, which then defines how the user interface is presented (such as providing a menu of standard project codes for building projects), validates input (verifies that the company name field has been filled, for example), and manages communication with the server component. The VSTO 2005 client engine requires an Office 2003 host application (currently Word or Excel), and the .NET Framework run-time system.

Server. A data synchronization component on a server generates documents to send to the user and processes completed documents returned by the user. For example, a data synchronization component for building permits would generate Word form letters from data in the permitting system and extract the data from returned building permit applications for entry into the permitting system. Typically, this component would be a custom ASP.NET Web application that uses the VSTO 2005 server engine to fill and extract XML data islands in documents. This server engine does not require Office 2003, but does require the .NET Framework.

Data. Data in documents can come from diverse applications and databases, including enterprise resource planning systems, customer relationship management systems, and business-specific applications like the permit management system in this example. The data synchronization component would typically use application-specific APIs or protocols to communicate with each data source and reconcile its data with the data in documents being processed.

Back to associated article: Office Document Processing Platform Emerging