• Illustration: The Information Bridge Framework Architecture
• Sidebar: Microsoft CRM Bridged to Office

The Office Information Bridge Framework (IBF), due in July 2004, helps developers create "smart client" solutions for Office users to access data via Web services. Solutions created with the IBF could benefit employees who need to occasionally view and selectively update data from corporate applications such as customer relationship management (CRM) systems, but don't need all the capabilities of those applications. For developers, the IBF requires less coding than existing Office smart client technologies. However it isn't a total replacement for previous technologies, and the first version lacks some key capabilities, such as offline data access.

Quicker Data Access for Office Users

The IBF is a development platform for solutions that enable a Word, Excel, and Outlook client to access data in Web services, which would typically connect to systems such as enterprise resource planning (ERP), CRM, or line-of-business applications. The goal is similar to that of corporate portals: give occasional users quick access to data that they need without requiring them to use specialized client software. For example, a typical scenario for accessing a CRM system with an IBF solution might run as follows:

• A senior manager receives personal e-mail from an irate customer in Outlook 2003
• The solution recognizes the customer's e-mail address and retrieves the customer's data from the CRM system via a Web service
• The solution displays the data in a floating Outlook task pane; the manager can then view the data, edit it, or choose options from a menu of possible further actions provided by the Web service (such as logging the customer contact).

Microsoft believes that Office-based solutions can provide more productive data access for frequent Office users than a browser can: users can remain in the Office application they are currently using and can get data directly into and out of documents and messages they are working on without cutting-and-pasting or importing and exporting files. Of course, solutions built on the IBF require the latest versions of Office, so they also drive upgrades and further Microsoft's goal of getting Office embedded in IT solutions.

Microsoft's CRM group will use the IBF to expand access to MSCRM 1.2 data inside Office applications. (See the sidebar "Microsoft CRM Bridged to Office".) Microsoft is also likely to use the IBF to develop future versions of its Office Solution Accelerators, "smart client" solutions aimed at helping Office 2003 users solve common business problems, such as preparing sales proposals. In fact, the IBF was developed not by Microsoft's developer tools division but by the Information Worker New Markets Group, which develops the Office Solution Accelerators with partners.

Client-Side Engine Key to Solutions

The central component of IBF is a client-side engine installed on a user's PC that recognizes user interface events in Office documents and e-mail messages (such as clicking on a customer name), pulls up data from relevant Web services, and provides the user with a set of actions that can be taken. (See the illustration "The Information Bridge Framework Architecture".)

Developers program the engine by writing solution metadata—effectively a data file stored on a server and interpreted by the client-side engine. Solution metadata specify details of the solution user interface (such as how it displays data in the task pane) and what Web services it should call in response to a particular event. Developers can optionally code specific user interface elements (e.g., Smart Tags for recognizing names, Windows Forms for entering and viewing customer data changes in the application pane). However, developers can get some data viewing capabilities just with the solution metadata.

Not for All Smart Clients

For simple data retrieval and updating solutions, IBF offers some advantages over existing developer technologies such as the Office Web Services Toolkit, the Visual Studio Tools for Office 2003, or custom Smart Tags. The IBF offers simpler solution deployment because a single client-side engine can be used for multiple solutions—to connect to a CRM system as well as an order processing application, for example.

In addition, the IBF requires less custom code on the client, and less Office-specific code overall, because the developer does not have to write the code to handle events, manage communication with Web services, and display and update data in the IBF task pane. This in turn means that developers can build smart client solutions with less investment in Office-specific APIs. This capability is becoming increasingly important because the Office APIs could be in for radical changes in two to three years when Microsoft hopes to ship Office 12.

However, the IBF is more specialized than the existing technologies for Office-based smart clients such as the Visual Studio Tools for Office. The other technologies offer developers more choices for user interface design; for instance, developers can add new options to the Office menus, and code responses to events that the IBF doesn't detect (e.g., a user modifying a cell in Excel). The existing smart client technologies also support back-end data sources other than Web services, such as conventional relational databases. And the Visual Studio development environment does not yet have specific support for building IBF solutions Nevertheless, for simple solutions developers can get more done with less code on the IBF than they could with the other Office smart client technologies, and they can reuse their work across multiple solutions more easily.

The first version of IBF has some technical limitations. Solutions created with it only work online: they cannot cache data retrieved from a Web service, let users modify the data offline, and then synchronize the modified data when the user is back online. This means that IBF solutions will lack one of the main advantages of Office smart client solutions over corporate portals. Also, the IBF only supports Word, Excel, and Outlook as clients; it does not support InfoPath, an application specifically designed as a client for XML data and a front end to Web services. Microsoft says it will address both InfoPath support and offline use in future versions of the IBF.

Finally, an IBF solution, like a corporate portal, will never be a substitute for full clients for activities such as CRM. That means that IBF solutions might not be useful for workers who use such applications frequently, such as call center operators.

Requirements, Availability, and Resources

The IBF requires Word 2003 Professional, Excel 2003 Professional, or Outlook 2003 Professional on the client, as well as the .NET Framework 1.1. Administrators will also have to install the IBF engine on all clients. The Bridge Framework server for solution metadata requires SQL Server 2000 Service Pack 3 and Windows Server 2003. The graphical designer for solution metadata requires Visual Studio .NET 2003.

The IBF entered public beta testing in May 2004, with the initial production release planned for July 2004. A second release with support for InfoPath as a client is planned for fall 2004. The Bridge Framework is free, but it is not supported by Microsoft Product Support Services.

For further information on the Information Bridge Framework, see msdn.microsoft.com/office/ibframework.