I'm not usually one to get terribly excited about Microsoft Office (and that's an understatement), however the next update to this suite of applications is perhaps the most significant one ever. I think it may have the potential to affect developers who may not have expected Office to provide any functional benefits to the application development process. While there are many new features, far too many to list and I am sure there are more than I realize, there is one change that has the potential to have a significant impact to developers. Specifically, the Office applications are no longer just client applications. As I understand it, the Office applications are now capable of providing services, much like a web server or other back end application where there is no visible user interface and instead provides support services for other applications that build upon the functionality. Of course, the applications continue to provide all the features you expect from a client standpoint when used in that manner - you can still edit documents, spreadsheets and so forth just like you always have. However, with the new services features, it now becomes possible for developers to programmatically take advantage of all the abilities of the Office applications in the context of a UI-free server application. This is a fundamental change in the way office applications can be used; by separating the user interface of the client from the logic of the underlying application services, the office applications can now provide their functionality as an API to any managed code application.
By providing the functionality of the office applications to a server application, Microsoft has effectively added new APIs to the managed code space that allows programs to programmatically do whatever the office applications are able to do when operated by a user. It may not be immediately obvious why this is a useful thing to be able to do, so let me fabricate an example to demonstrate my point. For instance, a web server that needs to produce a form letter, receipt, or some other procedurally generated document that is professionally formatted by a graphic designer could in theory use a Microsoft word service to load a template document, modify it, and render it into the desired output format (probably HTML, but possibly something else for that matter). The new features allows the author of the template to update the template document by at any time using Word, and the document created by the service application would automatically reflect any changes in the template since it would simply load the template and modify it procedurally. The person responsible for maintaining the server would not have to do anything beyond simply updating the template file when the designer changes it. In the past, one way a person might have solved this problem would have been to have the document builder perform a search and replace with an an HTML document, replacing data with the appropriate information. This however is error prone; changes in the template or changes in the data that needed to be shown on the document would have to be manually tested for errors. There is a possibility that somebody may overlook a change on either side of the equation resulting in a receipt that is incorrect. For instance, the template may have a new field that needs to be populated with something, but the web service may simply be unaware of this new requirement. By using a word service to manipulate a template, the application that builds the document can easily verify that all fields in the template have been populated correctly and throw exceptions if there are any unset template fields.
While old ways of doing procedural document generation (i.e. search and replace) can and do work, and the potential errors can be tested for when templates change, it is the elimination of the potential for human error and the need for human oversight that enables systems to become robust and dependable. And that’s a good thing. Any time we build a system that has verifiable behavior we can then rely on that behavior when we build other systems, which of course is the basis for creating reliable and robust applications of any significant size or complexity. This was just one example, but when you consider all the things that the Office applications are capable of, it is clear that the Office 2007 suite has the potential to be a useful, time saving API for people who would have otherwise mimicked some small portion of the functionality provided within the Office applications within their services.