Introduce SOA to office application Desktop

Ricard Roma I dalfo
Microsoft Corporation

Summary: Today's enterprises want to expose SOA as an application.ProgramAnd data to facilitate user use. Currently, it is very easy to build solutions on these services using existing development tools. By using standards such as soap or WSDL, different vendors can provide tools for public and development on these services. However, after the enterprise develops some solutions, the problem is exposed. This article focuses on some of the most common problems.

 

 

Content on this page

	Introduction
	Metadata Method
	Information bridge framework
	Information bridge Architecture
	Create a UI component
	Create solution metadata
	Deployment and security
	Summary
	Resources

Introduction

Today's enterprises want to use SOA as a way to expose their applications and data for users. By adopting SOA, enterprise assets (such as business process applications or backend systems) can be used by various solutions/applications built on the services exposed by these assets. Here, you can consider an enterprise as a set of public datasets or feature sets and encapsulate the business logic behind them.

Currently, it is very easy to build solutions on these services using existing development tools. By using standards such as soap or WSDL, different vendors can provide tools for public and development on these services.

After the enterprise develops some solutions, the problems are exposed. The following are some of the most common problems:

1.	The solution can only be used once. They can only communicate with one or more predefined services, and the solution itself is hard to reuse. After changing the service, you need to re-build/redeploy the solution.
2.	the understanding of the content published by the service depends on people's ideas, rather than the definition of the service. The current standard only covers how to obtain those services.
3.	it is difficult to integrate different services. There is neither a pre-defined aggregation mechanism nor a definition of how a service is associated with another service (services are not known to each other.
4.	according to most common user standards, the solution UI is hard to implement and is usually poor (unless a huge investment is made ). This is because it is difficult to simulate the current application UI in a one-time solution.
5.	most users are familiar with office suites (such as Word, Excel, and outlook) and other applications. However, when a new application/solution is designed, they need to be trained to increase the cost of such deployment.

For the above reasons, we need a better mechanism to build solutions on existing services.

Back to Top

Metadata Method

Currently, the Web Service exposes a lot of information about how to use the service, but it provides little help in explaining the type of information or functions provided. Web services usually expose WSDL, so tools can easily find out which methods and parameters are exposed by web services. However, there are few prompts (for example, does not tell a method to update the backend system ). It seems that WSDL does not fully represent the content published by the current service.

We recommend a set of new metadata that can be associated with a service and describe what users (solution developers) of the Service will need to know. In this new metadata, we will publish the following concepts:

1.	entity-the abstract business or user definition that encapsulates a set of data or functions. For example, we can have a customer entity.
2.	View-architecture associated with an object that describes the data subsets of the object. For example, for customer entities, we can have multiple views, such as customer contact information or customer financial information. Each view conforms to a specific architecture. It is an entity representation of a given context.
3.	the link-Object/view can be associated with other content. These relationships should be described in this metadata. For example, the customer entity may be associated with the order entity. Links allow navigation between entities. You only need to describe the metadata. Then, the link describes how to enter another entity from one entity.
4.	reference-reference is a common method to point to a group of information. It is an architecture that represents the minimum information set required to retrieve a piece of data, for example, to retrieve the customer ID. You can retrieve a piece of information in multiple ways, such as searching customers by name, ID, or SSN.
5.	operation-this is a method that can be operated on a given object/view. You can consider getcustomer, updatecustomer, or releaseorder as examples of such operations.

Describe the metadata of the existing service to solve only half of the problem. The other half (solutions developed on these services) also need metadata description. We believe that by considering the operations that end users can perform, you can build most solutions. These operations are built on service entities/views and provide operability on them. A customer operation will certainly have an operation to display its data, and an operation to update the data. The operation instructions should link the data retrieved from the Service to use its ui or solution features.

Back to Top

Information bridge framework

The information bridge framework (IBF) is Microsoft's answer to the aforementioned challenges and metadata methods. IBF allows you to connect lob and backend systems through office applications, and create solutions on web services through metadata. IBF can perform the following operations:

1.	Create metadata description for the service
2.	Create a metadata infrastructure for building solutions/applications on the service
3.	Highly reusable across Solutions
4.	Easy Maintenance and deployment of solutions
5.	Highly integrated with office applications
6.	Simple training for existing office users

Back to Top

Information bridge Architecture

The IBF architecture (1) includes the following components:

A) a web service that encapsulates lob or backend systems and is compatible with IBF. We will discuss compatibility issues in the next section (designing and developing IBF solutions.

B) a metadatabase (metadata service) that contains metadata of services and solutions ). This library can export itself as a Web service that provides access to metadata. There is also a central database describing all services and solutions. The client downloads a subset of the metadata based on their permissions to use it as the required execution basis.

C) IBF Client Engine. The last component contains two unique components:

A. the engine that downloads metadata from the metadata service and retains its local cache as needed. It can also understand metadata and execute metadata based on the current context. It executes all operations unrelated to the UI, such as soap calls and conversions. This component is unknown to the UI.

B. UI engine, which is a part of understanding where an application is hosted (Word, Excel, etc.) and displays the UI and provides services specific to the Host application. It can create an abstraction layer on the host application, so the solutions built with IBF do not need to understand the differences between the host applications.

D) The metadata designer is a visual Studio-based tool that allows you to edit metadata and import it to the metadata service.

 

Figure 1. IBF Architecture

 

Design and develop information bridge Solutions

When designing an IBF (information bridge framework) solution, you must divide it into three completely different blocks (2 ). On the one hand, you need to describe the IBF-compatible Web Service, which encapsulates the backend application functions that you want to provide to end users. On the other hand, you need to design the UI and experience that should be provided to the solution users. The last step is to link the service and UI solution that you build using IBF metadata. By separating these three phases, you can allocate different resources for each of these phases, and then operate them separately, simply on the interfaces they share (or the Public Architecture) to be consistent.

Create a service compatible with IBF

IBF requires services that can provide data and interact with the data required for your solution. IBF currently supports two types of services: Web Services and CLR components. Web services are the most common method to expose backend data. Most IBF examples use them for service description. If you want to make data offline or cache (for performance reasons) CLR implementation, it is also possible.

When designing services for IBF, you should remember that you are building services for users, so you want to publish data and methods that are meaningful to users.

 

Figure 2.three different blocks of the IBF Solution

 

When building these services, you also need to know several concepts:

•	Entity-you can regard an entity as a business object that has special meaning to the user and can be operated by the user. Examples of entities can be customers, orders, or opportunities. They all have data associated with it, and from the user's perspective, they can be operated. For example, a customer entity may contain data associated with a specific customer (name, address, location, etc.) and methods that allow the user to operate on the entity, such as updatecustomerinformation or sendemailtocustomer. It may also be a starting point from a passed Link (for example, customerorders or customeropportunities) to another object.
•	View-IBF can use different views to separate objects. A view is a subset of Object-related information. For a customer, you may have the customer contact information view and customer financial view.
•	The reference in reference-IBF is a piece of information that uniquely identifies an object/view instance. For the preceding example, the reference can be the customer ID or customer name (if it allows you to uniquely identify the customer ).
•	Link-some objects/views have relationships. The metadata we build should describe these relationships. One example is the customer and the order, because you can associate the customer with the single-phase, and associate the order with the customer.

Based on the previous concepts, you should identify three different methods when building services:

•	The get-get method allows you to pass a reference to retrieve data for an object or view. An example is the getcustomercontactinformation method, which accepts the Client ID reference parameter.
•	Put-this is a method that allows you to modify the object/View content by updating the backend system. It accepts two inputs: the reference to the object/view to be updated and the data to be updated.
•	Act-This method allows you to perform operations unrelated to obtaining/updating objects/views, or to perform operations across multiple objects.

If you understand these concepts, you can build services around them. The service exposes a set of methods of the get/Put/Act type. Therefore, it defines the architecture for reference and view (data returned by the get operation.

To complete the service, you must also publicly describe the IBF metadata of the concepts described above. IBF provides tools to automatically generate metadata from web services, so that you can add metadata and map them to correct references by tagging methods exposed around objects/views.

Back to Top

Create a UI component

IBF allows your documents to contain activity links pointing to backend data. These documents include information about the backend data to be obtained through smart tagging or additional architecture of the document. The Smart tag or element node in the architecture stores information about the backend information to be directed. Refer to the previous discussions on how to create an IBF service. For example, a smart tag contains references to backend information. Your solution must define how it wants these smart tags to insert documents, which provides/recommends several methods for this IBF. You can automatically generate documents embedded with Smart Tags (this is useful if emails/documents are dynamically generated by some processes ); you can use the Smart Tag reader to detect text based on regular expressions, or search for and dynamically insert smart tags. You can also use the built-in search function in IBF, allows users to search for information instances they are interested in and allows users to paste them into the document.

The remaining UI part is the part to be displayed to the user. IBF provides a pane method that can host a region that is fully defined by the solution provider. IBF supports. Net CLR controls and HTML areas (and the menus of these areas ). Creating a UI is actually creating a control and implementing an interface for inserting data into the control. The widget does not need to know how to obtain data and where the data comes from. Control only needs to know the provided data type. IBF will dynamically instantiate the control at runtime and pass the correct data to the control. This allows you to separate data display from data retrieval. Based on the preceding example, you can create a control that understands the customer's architecture and contains its name and address ).

Back to Top

Create solution metadata

The last step to create an IBF solution is to create metadata that links the service description with the UI elements defined for it. To enable you to easily create these metadata-based solutions, IBF provides the following concepts:

•	Operations-from the user's point of view, these are executable units and can contain services and UI methods/operations. In the previous example, you should have a displayinformation operation that uses the service entity/View on customercontactinformation and links it to the user control we created for displaying customer information.
•	Conversion-because the data from the service and the data required by the UI elements may be different, IBF allows you to convert the data. XSL conversion, regular expressions, or calling CLR components are supported data conversion methods.
•	Link-your solution can have a link in addition to the relationship provided by the Service, and you can understand the relationship across services. For example, I can associate a customer in an old application with a customer in a CRM system.

Back to Top

Deployment and security

You can regard IBF as the central repository of metadata, and use it as a service description and UI element for dynamic deployment of solutions. Except for the IBF client, you do not need to install anyCode/Metadata. The IBF client component can be connected to the corresponding metadata service to obtain all metadata and UI elements required for a given context. After obtaining the metadata description and UI elements, the IBF client component executes them together with the service method call and constructs the UI and user experience as needed.

Because IBF uses the CLR component for UI rendering, it is built in. net Security, all components are dynamically downloaded and cached locally, and executed in the sandbox environment, so it does not harm the client machine. If you want controls to have higher levels of control, you can use standard. Net security policies to sign these controls and increase their permissions.

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

Back to Top

Summary

By separating the service layer from the UI Layer and linking them together through metadata, IBF allows high abstraction and reuse of your services and UI components. It provides a very powerful platform for specifying backend assets in an enterprise and creating solutions that can be linked or combined without coding based on these assets. In a metadata-driven method, the metadata method adds a lot of flexibility and allows you to further improve the solution based on your situation. IBF provides a powerful UI structure to help build a complete UI experience and integrate with office applications. Built on. NET technology, it also provides a secure and non-deployment environment for new solutions.

Back to Top