Approaching Solutions with the Information Bridge Framework

  • Article

 

Charles Maxson
OfficeZealot.com

May 2004

Applies to:
    Microsoft® Office Information Bridge Framework 1.0
    Microsoft Office Outlook® 2003
    Microsoft Office Word 2003
    Microsoft Office Excel 2003

Summary: The Microsoft Office Information Bridge Framework offers developers a powerful new way to expose line-of-business (LOB) data and processes to Microsoft Office users. The article will serve as a brief introduction as to how to approach getting starting with solutions in Information Bridge Framework. (13 printed pages)

Note This article assumes some familiarity with the concepts of the Information Bridge Framework. See the Microsoft Office Information Bridge Framework product documentation for more details.

Contents

Introduction
Analysis: Exactly What Do You Want to Do?
Some Advice
About the Architecture
Notes Along the Way
Web Services
Metadata
User Interfaces
Entry Points
Conclusion

Introduction

The Microsoft Office Information Bridge Framework is a powerful framework for developing data-driven solutions that target the Microsoft Office System. Often, the challenge with a powerful technology is how a developer can just start using it. Because Information Bridge Framework provides an abundance of features coupled with a high level of abstraction, it can be a little daunting. In addition, Information Bridge Framework, unlike many Office-based solution technologies, requires end-to-end enterprise development skills. Although it targets Office, Information Bridge Framework draws upon a widely differing skill set than do, for example, applications created in Microsoft Visual Basic® for Applications (VBA). So if you are expecting—or expected—to implement a complete Information Bridge Framework solution yourself, be prepared to write Web services, craft XML-based metadata, produce XSL transformations, design .NET-based Microsoft Windows® Forms, wrangle with smart tags in Office, and attach XSD schemas to Office documents. Information Bridge Framework truly runs the gamut, but you should not be overwhelmed. Like any good technology, the Information Bridge Framework learning curve can be mastered.

Analysis: Exactly What Do You Want to Do?

You have taken the first step and determined that an Information Bridge Framework solution is right for you and your organization. Or perhaps someone else has determined that and turned to you to get it done. Either way, approaching an Information Bridge Framework solution is similar to kicking off any other application building process. The first thing you need to do is plan exactly what your solution is going to do. The Information Bridge Framework has a lot of moving pieces, and you need to get yours in order because, like any software project, changes are easiest before you start. You should start by performing a thorough analysis that begins with a number of questions. The following section contains examples of some questions that apply to Information Bridge Framework. Note that this is clearly not an all-inclusive list of topics to consider, just some points to get you thinking.

What are My Expectations for Information Bridge Framework?

You need to understand your main goals for building the solution in the first place. Information Bridge Framework's focus is on making Office users more productive. How is your solution going to build upon that? Understanding how your users currently work should help you see that more clearly; if you are unsure, watch your users, and try to interpret what is missing or inefficient in their current processes. Set the expectations of your Information Bridge Framework solution to conquer their current inefficiencies.

What Type of Information Bridge Framework solution?

Of course, Information Bridge Framework solutions range from quick and simple to extensive and complex. You need to ask yourself which type is your going to be with a good understanding that things may change down the road—of course you do not want to paint yourself in the proverbial corner. If you are simply trying to produce a read-only view into one or more of your (LOB) applications, you can take more liberties. For example, you may be able to forgo setting security policies in your metadata or only develop one Information Bridge Framework Region that you use to display all of your data. However, if you solution requires transactions, multiple levels of security access to data, and/or read-write capabilities with confirmation and state management, you would be better advised to have a solid plan before you put code to compiler.

How Important is Extensibility?

One of the great benefits of Information Bridge Framework solutions is that they are easy to build onto. As you are probably aware, users and managers often like to see a new feature or two added after they have had experience with the original version of a solution. Planning ahead for that in Information Bridge Framework is helpful, because it can help you make sure you can adapt to change and get the most of out reusing existing content. Questions like how to organize metadata, whether to put my schemas and transforms in-line, whether you are optimizing your user controls for easy adjustments or they will used in another context will help you get the most out of Information Bridge Framework's flexibility and reusability.

Will Your Solution be Combined with Other Information Bridge Framework Solutions?

Quite conceivably the value of Information Bridge Framework will drive the adoption of multiple solutions. You will want your solution to be a "good citizen" in the Information Bridge Framework solution stack of your organization. You should really think out naming conventions for items including namespaces and entity names in addition to the other Information Bridge Framework metadata items. Optimal usage of metadata scopes is another aspect of your solution that might make it easier to interact with. You should decide whether to use one metadata scope for your entire solution or to use one for each set of data or functional component.

Where is My Data? Is it Information Bridge-Compliant Already?

A critical layer to any solution is the data layer. It may seem that Information Bridge Framework can even be more challenging than many solution types because it is expected to work with any and all back-end data applications and line of business systems. However, this is strength, not a weakness. Information Bridge Framework has established a prescriptive architecture for working with other systems. It involves exposing data and actions in the form of Information Bridge-compliant Web Services. If you can get your desired data sources to expose their data and operations in the form of Information Bridge-compliant Web Services, you can work with any or all of them in a predictable, repeatable way.

Note   Information Bridge-compliant Web Services are not a requirement for working with the Information Bridge Framework, but using them can reduce the complexity and quantity of Information Bridge Framework metadata that must be produced for a solution.

One of the most important things to consider is whether your data sources are exposed under the Information Bridge Framework guidelines for Information Bridge-compliant Web Services. If your data sources are not already exposing Web services, you will need to write Web services before you can continue. If your data sources are exposing Web services, they must be Information Bridge-compliant Web Services, or you will need to either wrap the existing Web services to be Information Bridge Framework-compliant or create new Web services from scratch. You will need to determine the best cause of action given your specific requirements and options.

What Are the Entry Points to My Solution?

There several different entry points available in an Information Bridge Framework solution including Information Bridge Framework search, Office smart tags, and attached-schema documents. You can use any combination of these, but which entry points you implement will have an effect on the ultimate design of your solution. For example, attached-schema documents require an XSD document with a namespace on its root element that matches a metadata scope name in your Information Bridge Framework metadata. If you have existing schemas that you want to apply to Word documents in your solution, you should name your Information Bridge Framework metadata scopes accordingly. This is not required, but good planning and an understanding of your final objectives before you start will enable you to avoid redundant and unnecessary extra work.

Some Advice

Developing Information Bridge Framework solutions can be satisfying, especially when you start seeing your LOB data appear in the task pane. However, you should take your time getting started and do your analytic homework first. Unless you have time to create a non-working prototype, which can be useful if you have the time, make sure you have planned accordingly. In addition, you should start off small—with Information Bridge Framework when you get the little things working the big things come easier. Debugging in Information Bridge Framework 1.0 can be complicated, so you should take steps gingerly to avoid getting lost along the way. Aim for getting simple pieces of functionality operational with a plan to build upon them as you master the Information Bridge Framework.

About the Architecture

At this point, it may be helpful to take a step back for a big picture look at the architecture of the Information Bridge Framework before approaching each of the individual details of an Information Bridge Framework solution. Figure 1 shows the architecture of the Information Bridge Framework.

Figure 1. Architecture of the Information Bridge Framework

You can see that Information Bridge Framework is essentially split into to major segments; the server side and the client side. Key components include Web services, the Metadata Service, the Context and Action Service Engine (CAS Engine), the Application and Integration Rendering layer (AIR), and Office.

Web Services

Web services function as the data access layer to your enterprise/LOB application. Although Information Bridge Framework works best with Information Bridge-compliant Web Services, that is not a restrictive requirement. Although Information Bridge Framework is about simplifying data connectivity through a Web services layer, you could conceivably forgo Web services altogether and use alternative approaches. For example, you could create an Information Bridge Framework solution that calls .NET assemblies to access data through ADO.NET. Although this is possible, it is not really the intended design of Information Bridge Framework. Simply put, Information Bridge Framework works best with Information Bridge-compliant Web Services.

Metadata Service

Information Bridge Framework is a highly declarative solution framework that leverages a metadata schema to define its solutions. The framework provides the Metadata Designer tool, which is a Microsoft Visual Studio® .NET add-in used to create, organize, and publish Information Bridge Framework metadata. Behind the scenes, the components that make up the Metadata Service are a Microsoft SQL Server™-based database and a pair of Web services used to read and write the metadata from the database. Security is managed through Authorization Manager running on a computer running Microsoft Windows Server™ 2003.

The Context and Action Service Engine

The Context and Action Service Engine (CAS Engine) is the service that runs on the framework's client computers, and its main purpose is to interpret Information Bridge Framework metadata, execute operations, and process results on behalf of the client. The CAS engine works with the metadata from the Metadata Service or the local client metadata cache when invoked through an Office application request.

The Application and Integration Rendering Layer

The Application and Integration Rendering Layer (AIR) is the user interface layer that integrates Information Bridge Framework within Microsoft Office. AIR covers elements that make the Information Bridge Framework UI possible, such as the task pane and menus, and it enables interoperability between Information Bridge Framework and Office.

Microsoft Office 2003 Professional

Office is the target host for Information Bridge Framework solutions. Information Bridge Framework leverages Office's smart tag and smart document functionality to bring your solutions to life.

Notes Along the Way

Although it may be helpful to categorize Information Bridge Framework solution focus areas in line with its physical architecture, it can also be helpful to approach Information Bridge Framework solutions in a different way by thinking of Information Bridge Framework as four functional areas that you need to address to deliver a solution. These are:

  • Web Services
  • Metadata
  • User Interfaces
  • Entry Points

The rest of this article contains some information that may assist you in making Information Bridge Framework solutions more approachable. Some of these ideas may be considered best practices, or at least "better practices", and others are suggestions based on experience. Note that this is not meant to be an exhaustive list of ideas about Information Bridge Framework development. If you are new to Information Bridge Framework, a good place to start is reading the product documentation and reviewing the sample solution that is included with Information Bridge Framework.

Web Services

The foundation of any Information Bridge Framework solution is the Web services. And as was mentioned earlier in this article, good planning and design are essential in Information Bridge Framework, and this starts with your Web services. One of the worst results of poor planning is having to go back and make changes to your solution's Web services. This will have a costly ripple effect throughout much of your entire solution that can become quite consuming. It is best to plan well and get your Web services right from the beginning.

If you do not understand what Information Bridge-compliant Web Services are, or how you use them, read the product documentation and review the sample solution. It should take you only a few moments to understand Information Bridge-compliant Web Services. Even if you are new to creating Web services, remember that it is just a different type of protocol for accessing data and performing functions.

One of the first rules of thumb in building your Web services is to separate the implementation of your data services from that of your Web services. There are several reasons for doing this—note this is not a requirement by any means but a strong recommendation—including simplifying the solution metadata so that you work directly with your data objects and not with the Web services. This also makes it easier to change and extend your solution. The sample solution is a good reference point for what that should look like in practice.

Use Naming Conventions

Another tip is to use a naming convention with your Information Bridge Framework Web services. Because Web services will ultimately be generated into Information Bridge Framework metadata artifacts, you should anticipate that you will be working with a lot of content as your solution is built. Good naming practices can help keep development and management of metadata from becoming too complicated. Consider using a naming convention that best identifies your data objects and Web service operations, and above all keep them succinct and consistent. For example, when describing a data object that will be an Information Bridge Framework entity, name it exactly what it is. If you are exposing data for a sales invoice for example, call it "Invoice"; if it is customer account data, "Customer" and "Account" are good names. As long as the name is unique and readily identifiable, you can choose whatever name you want. When describing Web service operations (Web Methods), you know that Information Bridge Framework categorizes them as three types:

  • Get
  • Put
  • Act

Although it is not required to name a Get operation "GetSomething" or an Act operation "ActExecuteOnThis", it can be helpful when quickly glancing over metadata or the Web services test page that Visual Studio .NET generates to use a Get, Put, or Act prefix. It makes for very consistent and clear identification of your service operations. "GetCustomer" quickly translates to a Web service method that will return customer data. "PutCustomerAddress" is easily identifiable as an operation that updates a customer's address.

You should also consider having a naming methodology for namespaces. The purpose of namespaces is to uniquely identify both your Web services and data objects. When you separate the implementation of your data services from your Web services, you should also be giving them unique names. It is a good practice to be consistent and to use a readily identifiable convention. For example, if you are creating an Information Bridge Framework solution that is dealing with customer data, your Web services could use a namespace such as http://WebServices/CRM, and your data could use urn:schemas:CRM. Such a convention enables you to quickly see the relationship—they are both referring to CRM data, but they are unique and automatically identifiable. Keep them consistent and short in actual length of characters because they will be used throughout your solution metadata.

Employ XSD

It is likely that when you are building a solution for the Information Bridge Framework, you will build many data objects. Minimally, every entity requires a definition schema of itself and a schema that represents its view locator. It if have multiple views, the list grows. That means you will have to create many classes to define all of your data objects. A tool that ships with Visual Studio .NET called the XML Schema Definition Tool (Xsd.exe) can automatically generate classes for you if you have an XSD representation of the data structure. Because XSDs are readily available when working with most data systems these days, using Xsd.exe can be a great time saving and error reducing way of generating data classes. Even if you do not have XSDs for your data objects, you probably will find that creating data structures in Microsoft Visual Studio .NET XSD designer is a lot easier than typing long classes by hand in code.

Consider, for example, a solution build with data from SQL stored procedures. You could automatically generate the XSD files for the data objects by dragging the stored procedure from the Visual Studio .NET Server Explorer to an open XSD file in design mode. Then you could save the XSD file, run the XML Schema Definition Tool referencing it, do a little bit of hand editing to clean them up, and your classes will be created.

For more information, see XML Schema Definition Tool (Xsd.exe) on MSDN.

Thick or Thin?

How you implement your Web services will have an impact on your solution, from both a performance standpoint and a manageability standpoint. You must consider how you will design your Web services—should you make them molecular to the smallest degree and then expect to have many of them, or should you opt for fewer chunky services that bring all the data you may need for a number of given uses and then rely on transformations to get the data to where you want it? Consider the following scenario: you want to have two Information Bridge Framework regions for your customer account entity, one that provides summary information and another that provides details. Should they be two different Web services or one that serves both views?

If you use thicker services, you may be pulling more data over the wire then you need, which may affect performance but will you require you to develop and manage fewer items. If performance is an issue, you can use thinner services but be prepared to use more code and more metadata. Either way, from a practical standpoint, make sure you try to limit the number of calls the Information Bridge Framework engine makes to your Web services; one call per request should be your goal

Metadata

Information Bridge Framework metadata can be overwhelming when building a solution. One reason is that because it is exclusive to Information Bridge Framework, it will be unfamiliar to you when you first create a solution. Information Bridge Framework's Metadata Designer (MD) tool helps you create and organize metadata, but you will still need to write some XML metadata on your own where the tool leaves off, for example when creating entities for example. Debugging Information Bridge Framework metadata is also difficult, and although there are some things you can do to simplify the process, it still will require some patience.

The suggestion to start small applies to the metadata more than anything else in Information Bridge Framework. For example, if you have an action on an entity that ultimately needs to show four unique regions, you should get the first one working, then add the second, and so on. You should limit the number of things that can go wrong so you can find them when they do. Do not confuse yourself by trying to do everything you need to get done at once—start small.

Learn the Information Bridge Framework Metadata XML

The Information Bridge Framework Metadata Designer makes generating and organizing metadata easier after you understand how to build Information Bridge Framework solutions, but learning the tool and the metadata concepts at the same time can be difficult. To really understand Information Bridge Framework's metadata, it can be very useful to spend some time reviewing and writing the raw XML by hand either in the Metadata Designer tool or in another editor, such as Notepad. This will help you to logically work out how the metadata is laid out and how they relate to each other.

Within the Metadata Designer tool, you can work directly with your solution metadata XML in a single XML file (MSIBFMetadata.xml). This enables you to leverage features like Microsoft IntelliSense® and AutoComplete as the MD tool validates your work against the Information Bridge Framework metadata schema. Working with the raw XML is a good way to help you to understand all the moving pieces behind the scenes of an Information Bridge Framework solution and more than likely enable you to come up to speed faster on Information Bridge Framework. It is also possible that you will find editing the raw XML faster after you have learned it, so this may be a very worthwhile exercise.

Apply Metadata Scopes

Metadata Scopes serve as partitions within Information Bridge Framework metadata, which enables you to separate different logical pieces of your overall metadata. They are helpful for grouping metadata to make it easier to work from a volume standpoint (allowing you to focus on smaller subsets), and they isolate metadata so that it can reside as separate sections that may have distinct purposes. How you implement metadata scopes depends on your environment and overall plan, and there are several ways that using metadata scopes makes sense. For example, if you are using four LOB systems with your overall Information Bridge Framework solution, you might divide up your metadata into a unique metadata scope for each system. If you are working with other Information Bridge Framework solution developers, each developer owning his or her own metadata may be a helpful alternative. Conversely, you could use one metadata scope for all of your metadata.

It can be useful to have a metadata scope for each set of Web services or logical set of data. It is not a requirement, but it helps you to stay better organized and more productive because you can focus on one data set for each metadata scope. Combining metadata scopes helps avoid redundancies, and it may be advantageous if reuse is critical. Remember that solutions can work across metadata scopes so you are not completely isolating solutions; with metadata scopes you separate them. Using metadata scopes effectively will enable you to get the most out of your Information Bridge Framework metadata design.

Implement a Naming Convention for Metadata

When you create Information Bridge Framework metadata, using a well-thought out, consistent naming convention will help you to rapidly navigate and identify the many metadata artifacts that will make up your solution. If you expect to be one of many or more co-authors of an Information Bridge Framework solution, setting some standards as to how to go about naming objects in up front will help keep the team efficient and on the same page.

One example of how to use naming in metadata is, for example, when adding a metadata item that requires the use of a Port, you give the item and the Port the same name. This way you can search the metadata XML quickly and find the item and its Port with a single search. It is also helpful to use declarative names. For example, if you have a Transformation item that takes data that describes an Account object and is used to transform it to a smaller, summary subset of account data; you could give it a name such as "AccountSummaryTransform". Using a naming convention makes it easier to manage Information Bridge Framework metadata.

User Interfaces

Because Information Bridge Framework utilizes .NET Windows Forms-based User Controls for developing its regions, UI development is probably the area of Information Bridge Framework solutions that most developers will already be very familiar and most comfortable with. To enable a User Control to work with Information Bridge Framework takes little more than implementing Information Bridge Framework's IRegion interface with your form. Most developers will find Information Bridge Framework region design relatively easy—and it is often the most rewarding part, too.

Reuse Those Regions

Although Information Bridge Framework regions are easy to create and seamless to deploy, you should not need to create hundreds of them. In many scenarios, if designed right, you will not need to create more than a couple of regions for an entire Information Bridge Framework solution. Because it is good practice to produce as little code and content as possible (less to debug, maintain, load, etc.), your regions should be as flexible as you can make them so they are easier to reuse. If your solution calls for many different regions but they only display different lists of data, you could design a single user control that satisfies all instances. The Information Bridge Framework task pane shown in Figure 2 is an example of how five regions are drawn from only two user controls. The three expanded regions in Figure 2, which contain a docked data grid control, are displayed repeatedly each time with the appropriate data and formatting properties. This is achieved with just a small amount of code behind the region coupled with a series of unique transformations that deliver the data and the layout information to the region at run time. For more information about how this is implemented, see the Information Bridge Framework sample solution.

Figure 2. The Document Actions Pane

My Regions or Yours?

If you are looking for one less piece of code to write, one less object to debug, or one less component to deploy, think about using either of the two regions that are built into the Information Bridge Framework. Specifically, Information Bridge Framework provides an HTML region and a Reference list region as a part the Information Bridge Framework client installation. The HTML region is good for scenarios in which you only need to push content into a region and that do not require automation or business logic. The Information Bridge Framework Reference List region is ideal for returning a list of results when more than one entity reference is found. Showing both of these built-in Information Bridge Framework regions is done entirely from metadata through the use of custom Operations. In many cases these useful regions can enable you to forgo writing your own custom regions.

Odd and Ends

This section contains some ideas for designing regions for Information Bridge Framework. The first idea is to put as little logic as possible inside your regions. Not only does that mean they will initially require less effort to code, but more importantly, fewer things can go wrong, and less needs to be maintained if your solution changes. You can avoid coding in many cases by offloading the business logic into your Information Bridge Framework solution metadata. For example, instead of returning a big block of data to your region that you have to parse with code behind your user control, use a Transformation in your Information Bridge Framework metadata that results in the region getting only data that it needs, requiring little to no processing.

Another idea is to use custom region menus for actions as opposed to something like command buttons on the region. Not only does this enable you to push business logic from region code to metadata, it enables you to offer a more consistent user interface. In addition, consider using ShowDialog instead of ShowRegion when your user controls display an abundance of data or require that the user has to complete a task before advancing within your Information Bridge Framework solution.

Finally, look for the Information Bridge Framework Region test tool (IWBUITest.exe) to test your regions without needing to have them as a part of a working solution. It will make debugging and design a lot easier for your user interfaces.

Entry Points

The different ways that a user can invoke Information Bridge Framework from Office are referred to here as entry points. These include smart tags, attached-schema documents, and the Information Bridge Framework Search functionality. These are important because without them users could not instantiate an Information Bridge Framework session. More sophisticated Information Bridge Framework solutions might contain variations of all three methods, but your needs may vary on your requirements and solution design.

The first rule for Information Bridge Framework entry points is to always implement Information Bridge Framework Search functionality no matter how simple it is. This removes the dependency on needing to have an Information Bridge Framework smart tag within a document to use Information Bridge Framework. Information Bridge Framework Search is pure metadata and it is not complex. In fact, if you copy the search metadata scope in the sample solution that Information Bridge Framework provides, with some very minor edits you could add it to your own solution metadata and have Information Bridge Framework Search running in no time. Note if you do not offer search, the Information Bridge Framework menu item is still added to the Office applications, but it will not offer any functionality and it may confuse your users. Refer back to rule number one—always offer search in Information Bridge Framework.

Implement an Information Bridge Framework Smart Tag

Although you could create an Information Bridge Framework solution without including your own custom smart tag recognizer, having one could be as important as having Search. Recognizers add one more degree of efficiency by enabling users to navigate directly to an Information Bridge Framework reference with little effort. Smart tag action handlers are more optional than recognizers, so if you have a straightforward solution you might want to not include one. However, you will not be able to offer any additional actions for recognized smart tags nor will you be able to build more meaningful smart tag menus. Without a custom Information Bridge Framework smart tag action handler you are limited to one action and the default Information Bridge Framework Show Details menu only. Therefore, you should add an Information Bridge Framework smart tag action handler if you want a more polished solution.

One Attached Schema Solution Means One Metadata Scope

An attached-schema document is a very powerful type of solution in which user interaction with the document can trigger Information Bridge Framework commands automatically. As an Information Bridge Framework developer, you can provide attached-schema documents with very little additional effort after your Information Bridge Framework solution is in place. Essentially all you need to do to create an attached-schema solution is to mark up a Word document with XML that is based off of an XSD schema. That attached XSD schema needs to coincide with certain aspects of your Information Bridge Framework metadata. These include the XSD namespace, which must match a Metadata Scope name in your solution metadata, and underlying XML nodes of the schema, which must match entity names within that Metadata Scope.

Note See the Information Bridge Framework product information for a more thorough explanation of attached-schema documents.

The requirements of an attached-schema document may mean that you need to produce your metadata in a certain way that may not be the optimal or desired way you would want to create your Information Bridge Framework solution metadata. For example, if you want to have three entities recognized from your attached-schema document but they are in three different metadata scopes, you would have to combine them in one metadata scope to make it work with an attached schema solution. This would either require you to design all your metadata solutions in advance around your attached-schema document or change existing metadata, which may not be possible and is definitely not preferable.

Therefore, the best approach in creating attached-schema document is to go about and design your Information Bridge Framework solution and metadata as you normally would. Then, after you identify opportunities in which an attached-schema document is desired, create a new Metadata Scope in your Information Bridge Framework solution metadata with the sole purpose of supporting your Information Bridge Framework attached-schema document. This way you never have to alter existing metadata or do any extensive pre-design planning. The new Metadata Scope for your attached-schema document solution would share the same name as your XSD's namespace. Inside this Metadata Scope, you then aggregate entities and other content residing in other metadata scopes. You can see this practice in action in the metadata scope named http://InformationBridge/SampleSolution in the Information Bridge Framework sample solution.

Conclusion

The Microsoft Office Information Bridge Framework offers enterprise-level developers a very robust platform for exposing line-of-business data inside of Microsoft Office. After you have worked your way through the available documentation and solution samples that are available with the product, thorough analysis and planning are the key ingredients for implementing your first Information Bridge Framework solution. Start off small and grow your Information Bridge Framework skills, and as you master each step, you will be able to repeatedly produce very exciting results with Information Bridge Framework in hardly any time at all.

About the Author

Charles Maxson specializes in designing and developing smart client solutions featuring Microsoft Office. He is also one of the resident zealots at OfficeZealot.com.