Information Bridge Framework: Bringing SOA to the Desktop in Office Applications

  • Article

 

Ricard Roma i Dalfo
Microsoft Corporation

January 2005

Summary: Enterprises today are moving towards SOA as a way to expose their applications and data for consumption. Building solutions on top of these services is fairly easy today using existing development tools. Different vendors provide tools for both exposing and developing on top of those services by using standards like SOAP or WSDL. However, once enterprises start developing a few of these solutions problems start to arise. This article addresses some of the most common problems. (8 printed pages)

Contents

Introduction
The Metadata Approach
Information Bridge Framework
Information Bridge Architecture
Creating UI Components
Creating Solution Metadata
Deployment and Security
Conclusion
Resources

Introduction

Enterprises today are moving towards SOA as a way to expose their applications and data for consumption. By embracing SOA, enterprise assets like line of business applications or back-end systems can be used by a variety of solutions/applications built on top of the services exposed by those assets. In this world you can look at an enterprise as a set of services that expose sets of data or functionality and encapsulate the business logic behind them.

Building solutions on top of these services is fairly easy today using existing development tools. Different vendors provide tools for both exposing and developing on top of those services by using standards like SOAP or WSDL.

Once enterprises start developing a few of these solutions problems start to arise. Here are some of the most common problems:

  1. Solutions are one off. They only talk to one or a set of predefined services and the solution itself is hard to reuse. Changes on the services require a rebuild/redeployment of the solution.
  2. Knowledge about what the service exposes is in people's heads rather than in the definition of the service itself. Current standards only cover the how you get to those services.
  3. It is hard to bring different services together. There are no predefined aggregation mechanisms and there is no definition on how one service relates to another (services do not know about each other).
  4. Solutions UI is hard to do and usually poor (unless huge investments are made) by most common users standards. It is hard to emulate current off the shelf applications UIs in a one off solution.
  5. Most users are fairly familiar with applications like Office Suite (Word, Excel, Outlook, etc.) but they need to be trained if a new application/ solution is rolled out increasing the costs of such deployment.

Because all of the above a better mechanism for building solutions on top of existing services is required.

The Metadata Approach

Today, Web services expose quite a bit of information about how the service can be consumed but offer very little help in understanding what type of information or functionality is offered. Web services usually expose WSDL so tools can easily discover what methods and parameters the Web service exposes but offer little clues about what business entities are defined behind those methods or even if they affect the back-end systems at all (no way to say if a method will update the back-end system for example). It seems that WSDL is not enough for representing what today's services expose.

We propose a new set of Metadata that is associated with a service and explains the kind of things that a user of the service (a solution developer) will require to know. In this new Metadata we will expose concepts like:

  1. Entities—Abstract business or user definitions that will encapsulate a set of data or functionality. For example, we can have a Customer entity.
  2. Views—A schema associated with an entity that describes a subset of data about it. For example, for the Customer entity we may have several views like Customer Contact Information or Customer Financial Information. Each view complies to a particular schema and is a representation of the entity for a given context.
  3. Relationships—Entities/Views can be related to others and these relationships should be described in this Metadata. For example, Customer entity may be related to an Orders entity. Relationships allow for navigations between the entities by just executing the Metadata description. A relationship then will describe how to get from one entity into another.
  4. References—A reference is a common way to point to a set of information. It is a schema and represents the minimum set of information needed to retrieve a piece of data, e.g. Customer Id for retrieving a Customer. There can be multiple ways you can retrieve a piece of information, e.g. a customer could be retrieved by name, Id, SSN, etc.
  5. Operations—These are the methods that are available for a given entity/view to operate on. You could think of GetCustomer or UpdateCustomer or ReleaseOrder as examples of such operations.

Describing Metadata for existing Services only solves half of the equation. The other half (the solutions developed on top of these services) also requires a Metadata description. We think that you can build most solutions by thinking in terms of Actions that are executable by the end user. These Actions are constructed on top of the Services Entities/Views and provide actionability on top of them. A Customer action will certainly have an Action to display its data and maybe another action to update it. The action description should link the data retrieved from the service into the UI or solution functionality that will use it.

Information Bridge Framework

Information Bridge Framework (IBF) is the Microsoft response to the above challenges and Metadata approach. IBF allows connecting LOBs and backend systems with Office applications and creating solutions on top of Web services via a Metadata approach. IBF accomplishes several things:

  1. Create Metadata description for services
  2. Create Metadata infrastructure for building solutions/applications on top of services
  3. High level of reusability across solutions
  4. Easy maintenance and deployment of solutions
  5. High level of integration with Office applications
  6. Very low learning curve for existing Office users

Information Bridge Architecture

IBF architecture (as seen in Figure 1) includes the following components:

a) An IBF-compliant Web service that encapsulates the LOB or back-end system. We discuss the compliance issue in the next section (Designing and developing an IBF solution).

b) A Metadata repository (Metadata Service) that includes both the Service and the Solution Metadata. The repository is exposed itself as a Web service that provides access to the Metadata. There is one central repository where all Services and Solutions are described. Clients will download subsets of this Metadata on as-needed basis for execution based on their permissions.

c) IBF Client Engine. This last piece has two distinct components:

a. The Engine which downloads the Metadata from the Metadata Service when needed and keeps a local cache of it. It also understands Metadata and executes it based on the current context. It performs all the non-UI related operations like SOAP calls, transformations, etc. This component is UI agnostic.

b. The UI Engine which is the part that understands about the application where it's being hosted (Word, Excel, etc.) and will render the UI and provide services specific to the host application. It creates an abstraction layer on top of the hosting application so Solutions built with IBF don't need to know about differences between hosting apps.

d) Metadata Designer is a Visual Studio–based tool that allows for editing/importing of Metadata to the Metadata Service.

Aa480044.infobridge-1(en-us,MSDN.10).gif

Figure 1.   IBF Architecture

Designing and Developing an Information Bridge Solution

When designing an IBF (Information Bridge Framework) solution you must separate it into three distinct blocks (see Figure 2). On one end, you need to describe an IBF-compliant Web service that encapsulates the functionality of your back-end application that you want to offer your end users. On the other end you need to design the UI and experience that you want to offer to the users of your solution. The final step is to link both your Service and the UI solution you have built by using IBF metadata. By separating these three stages you can allocate different resources to each one of them and then can operate in an independent manner and only agreeing on the interfaces (or common schemas) that they will share.

Creating an IBF-Compliant Service

IBF requires Services that will provide the data and interaction with the data needed for your solution. IBF currently supports two kinds of Services: Web Services and CLR Components. Web Services are the most common way to expose back-end data, and most of the IBF examples use them for the Service description. If you require offlining of data or caching (for performance reasons) a CLR implementation is also possible.

When designing a Service for IBF you should keep in mind that you are building a Service for user consumption, so you want to expose data and methods that are meaningful to the user.

Aa480044.infobridge-2(en-us,MSDN.10).gif

Figure 2.   The three distinct blocks of an IBF solution

There are also a few concepts you need to be aware of when building these Services:

  • Entities—You can think of an entity as a business object that has a particular meaning to the user and that the user will be able to act upon. An example of an entity can be Customer, Order or Opportunity. All of those have some data associated with them and are actionable from the user point of view. For example, the customer entity might have data associated with a particular customer (name, address, location, etc.) as well as methods that allow the user to act on the entity, such as UpdateCustomerInformation or SendEmailToCustomer. It might also be a starting point to other entities via relationships like CustomerOrders or CustomerOpportunities.
  • Views—IBF partitions entities in different views. A view is a subset of information related to the entity. For a customer you might have a Customer Contact Information view and a Customer Financial view.
  • References—A reference in IBF world is a piece of information that uniquely identifies an instance of an entity/view. For the previous example a reference could be Customer Id or Customer Name if that allows you to uniquely identify the customer.
  • Relationships—Some of the entity/views will have relationships between them and the Metadata we build should describe those. An example would be Customer and Orders since you can relate a Customer with its orders and an Order with its Customer.

Based on the previous concepts when you build a Service you will identify three different kinds of methods:

  • Get—A get method is one that allows you to retrieve the data for an entity/view by passing a Reference. An example would be a method called GetCustomerContactInformation that would accept a Customer Id Reference parameter.
  • Put—This is a method that allows you to modify the content of an entity/view by updating the back-end system. It accepts two inputs, the Reference to the entity/view to update and the data to be updated.
  • Act—This kind of method allows for doing things that are not related to getting/updating an entity/view or across multiple entities.

When you understand these concepts, you can build a Service around them. The service will expose a collection of methods of type Get/Put/Act and by doing so will define the schemas for the references and the views (data return by Get operations).
For the Service to be complete it has to expose IBF Metadata that describes the previously explained concepts. IBF provides tools that automatically generate Metadata from a Web service and you can then increment the Metadata by annotating the methods exposed in there around Entities/Views and map them to the right References.

Creating UI Components

IBF allows your documents to contain live links to back-end data. The way these documents contain information about what back-end data to obtain is via SmartTags or by having an attached schema to the document. The SmartTag or element node in the schema will store information about what back-end piece of information is pointing to. As discussed in the previous topic on how to create an IBF Service, these are References. SmartTags, for example, will contain a Reference to the back-end piece of information. Your solution will have to define how it wants these SmartTags to get into the document and IBF provides/recommends several ways for doing so. You can automatically generate a document with the SmartTags embedded (this would be useful if the e-mails/documents are dynamically generated by some process); you can use a SmartTag recognizer to detect pieces of text based on a regular expression or by doing a look up and dynamically insert a SmartTag in them; and you can also use the built-in Search capability in IBF for the user to find the instance of information they are interested in and allowing them to paste it into the document.

The remaining UI pieces are what will get displayed to the user. IBF provides a Window Pane approach that hosts regions that are fully definable by the solution provider. IBF supports .NET CLR controls and HTML regions (and menus for those regions). Creating a piece of UI is just a matter of creating a control and implementing one interface that will get the data into the control. The control itself does not need to know how or where the data is coming from. The control only needs to know the type of data that will be provided. IBF will dynamically instantiate the control at run time and will pass the right data to the control. This allows for a separation of displaying of data from how you get to that data. Following the previous example you could create a control that knows how to render Customer information (it knows about the schema of a Customer and that it contains its name, address and so on).

Creating Solution Metadata

The final step for creating an IBF solution is to create the Metadata that will link the Service description with the UI elements that have been defined for it. IBF provides a few concepts that allow for easy creation of these Metadata-based solutions:

  • Actions—These are the executable units from a user point of view and can contain both Service and UI methods/operations. In the previous example you would have a DisplayInformation action that would use the Service entity/view on CustomerContactInformation and would link it to the user control we created for displaying customer information.
  • Transformations—Because data from the Service and the data required by the UI elements might not be the same, IBF allows you to transform the data. XSL transformations, regular expressions or calling CLR components are all supported ways to transform data.
  • Relationships—Your solution may have relationships beyond those provided by the Service. It may also know about relationships across Services. As an example I may be able to relate a Customer in one of my legacy apps with my Customer in my CRM system.

Deployment and Security

You can think of IBF as a central repository of Metadata, Service description and UI elements that will be deployed dynamically as solutions are used by the IBF client components. No code/Metadata other than the IBF client needs to be installed on client machines. The IBF client component connects to the appropriate Metadata Service to obtain all Metadata and UI elements needed for a given context. After it has the Metadata description and UI elements, it will execute them along with the Service method calls, and it will construct the UI and user experience as needed.

Because IBF uses CLR components for UI rendering it builds on top of .NET security, all components are dynamically downloaded and cached locally, and are executed in a sandboxed environment so they cannot harm the client machine. If you need your controls to have a higher level of control, you can sign those controls and increase their privileges by using standard .NET Security Policies.

This provides for a robust and deployment free environment for your enterprise solutions.

Conclusion

IBF, by separating the Service layer from the UI layer and linking them via Metadata, allows for a high level of abstraction and reusability of both your Services and your UI components. This provides a very powerful platform for specifying the back-end assets in an enterprise and creating solutions around them that can be linked or combined without coding. This Metadata approach adds a lot of flexibility and allows for further refinement of solutions around customer scenarios in a Metadata driven approach. IBF provides powerful UI constructs to help build a complete UI experience and integration with Office applications. It also provides for a secure and deployment free environment of new solutions by building on top of .NET technologies.

Resources

For more information about IBF, go to the following site:
Information Bridge Framework Developer Portal

 

About the author

Ricard Roma i Dalfo
Microsoft Corporation
ricardrd@microsoft.com
Ricard Roma i Dalfo is the development lead for the Information Bridge Framework project. He is working on next versions of IBF and solving connectivity problems with Line of Business applications. He had been previously in the Office team and helped release Office 2000, XP, and 2003 in various development roles. He holds a M.S. in Computer Science from Polytechnic University of Catalunya.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal website.

© Microsoft Corporation. All rights reserved.