News
A bridge for Microsoft-land
- By Mike Gunderloy
- June 1, 2004
Microsoft recently announced the release of the beta version of the somewhat
grandiosely-named Microsoft
Office Information Bridge Framework. Microsoft has been creating extensible
and programmable products for years now, but lately I detect a new interest on
the part of the Redmondites in actually hooking all this stuff together. IBF is
designed to help developers quickly and easily hook together Microsoft Office,
parts of the Windows Server System, and .NET code to form solutions for the
knowledge worker.
There is a great deal of information already available in the Office
Developer Center, and I'm still coming to grips with it all. But the basic
idea here is that Office 2003 has enough power and XML hooks to tie into
corporate data sources with just a few glue components, which are supplied by
the IBF. You'll need to be running Windows 2003 Server and SQL Server 2000 to
provide the infrastructure, Office 2003 for the client, and Web Services
(presumably developed with Visual Studio .NET) to tie everything together. To
the extent that they can get anyone to buy into this stuff, this is obviously a
marketing dream for Microsoft. An organization that wants to be using the IBF
pretty much has to be on the latest and greatest versions of everything.
The basic idea is pretty simple. IBF is a way for information workers who
currently waste time looking things up and cutting and pasting to remain within
an Office document and have information brought to them. From the worker's point
of view, it's all done with Smart Tags and task panes. For example, you might be
reading a memo about inventory levels for various parts in your Chicago
warehouse, and discover that the inventory of widgets is very low. "Widget"
would get a Smart Tag with choices like "show order history", "visit
manufacturer Web site", and whatever else seems pertinent. Asking for the order
history would fill a task pane, perhaps with a grid of inventory changes. From
there, you could proceed to place the order for more inventory - all without
ever leaving Word where you were working in the first place.
For the developer, all this involves defining the entities in the business,
figuring out where the data is stored, building a metadata store that Office can
draw on, and providing Web services to get data, store updates, and perform
actions. IBF glues it all together so that it works flexibly even in situations
that you didn't anticipate. The whole ends up being very
information-centric.
Overall, the IBF looks to me like it's the Office analog of some of the
things that the Patterns & Practices Group has been doing for the purely
developer space. In the last few versions there's been a bit of an imbalance
between the developers within Microsoft who build Office, and those outside of
Microsoft who use it. They've been putting in new functionality and interfaces
faster than we consume them. By going beyond the traditional demo applications
to provide actual, usable code and prescriptive guidance, Microsoft is making a
sound investment in continuing to make Office a premier tool.
About the Author
Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.