Interoperability Scenarios and Technologies for SharePoint Server 2007

Summary: Learn about standards, technologies, and techniques for integrating Microsoft Office SharePoint Server 2007 with other applications in common interoperability scenarios. (15 printed pages)

Scot Hillier, Critical Path Training, LLC (Microsoft MVP)

July 2009

Applies to: Microsoft Office SharePoint Server 2007

Contents

• The Importance of Interoperability

• Strategic Changes to Expand Interoperability

• Common Interoperability Scenarios

• Standards and Technologies

• Content SharePoint Server Can Consume

• Content SharePoint Server Can Produce

• SharePoint Server Search

• Identity and Access

• Partner Solutions

• Conclusion

• About the Author

• Additional Resources

The Importance of Interoperability

When a software vendor introduces a new product or technology to the marketplace, the business focus tends to be on meeting customer demands for a certain type of functionality. As a result, vendors tend to create all-encompassing proprietary solutions with the intention of selling a complete suite. However, the data and documents created within these proprietary systems often have importance beyond the commercial lifespan of the application in which they were created. The usefulness of the data and documents also frequently extends beyond the scope of the parent application. For example, documents created in a proprietary document-management system may need to be accessible from a corporate intranet, or data in a customer relationship management (CRM) system might be used as an input to the creation of business documents.

Interoperability between line-of-business (LOB) systems and solutions built by using Microsoft Office SharePoint Server 2007 is especially important. Typically, Office SharePoint Server solutions provide aggregation points where documents and information from several sources come together. Documents may be stored directly in Office SharePoint Server solutions in document libraries or they may be surfaced from external repositories, sites, and file systems. Data in Office SharePoint Server solutions may come directly from lists or from interoperability with external LOB systems. Office SharePoint Server solutions are often implemented as intranet, extranet, or Internet sites where the business case calls for access to many different sources of data.

Along with consuming data from other systems, interoperability with Office SharePoint Server is important when other systems need data from Office SharePoint Server or need to take advantage of Office SharePoint Server capabilities. Other systems, for example, can store documents in Office SharePoint Server libraries so that they can use security, versioning, and approval functionality. Other systems may create companion sites within Office SharePoint Server to facilitate collaboration or reporting, just as Microsoft Office Project Server 2007 does today. All of these examples show that interoperability with Office SharePoint Server is a critical factor in creating complete enterprise solutions.

Strategic Changes to Expand Interoperability

On February 21, 2008, Microsoft announced a broad set of changes to its technology and business practices to increase the openness of its products and drive greater interoperability.

The announcement outlined four new interoperability principles that apply to high-volume products like Office SharePoint Server. These principles are:

• Ensuring open connections

• Promoting data portability

• Enhancing support for industry standards

• Fostering more open engagement with customers and the industry, including open source communities

Ensuring open connections means supporting the connectivity between third-party products and Office SharePoint Server. To this end, Microsoft has made available documentation for all the API and communication protocols for high-volume products, including Office SharePoint Server, without royalty or license fees. For more information, see Microsoft Open Protocols.

Promoting data portability means making it easier to move data from one system to another. In support of this principle, Microsoft is working to create new APIs for Microsoft Office Word 2007, Microsoft Office Excel 2007, and Microsoft Office PowerPoint 2007 to enable developers to create plug-ins that support additional document formats. Additionally, end users would still be able to save these new document formats in Office SharePoint Server libraries.

Enhancing support for industry standards means that when an industry standard is supported in a high-volume product such as Office SharePoint Server, it will work with other major vendors to achieve a consistent and interoperable implementation. This means that you can expect that Office SharePoint Server will support industry standards in a way that supports custom applications and third-party products.

Fostering more open engagement means that Microsoft will provide resources, facilities, and events for commercial developers and community-based developers:

• Microsoft is a founding member of the Web Services Interoperability Organization (WS-I), an open industry organization chartered to establish best practices for Web services interoperability, across platforms, operating systems, and programming languages.

• Microsoft created an online Interoperability Forum to support developers.

• A Document Interop Initiative has been launched to address data exchange between document formats.

• Microsoft created the Interop Vendor Alliance as a community of software and hardware vendors working together to enhance interoperability with Microsoft systems on behalf of our mutual customers.

For more information about the Microsoft focus on interoperability, see the Microsoft Interoperability home page.

Common Interoperability Scenarios

When creating solutions that provide interoperability with Office SharePoint Server, there are several common patterns that are used, depending upon the exact integration needs and requirements. These patterns include portal-to-portal interoperability, content repository-to-portal interoperability, LOB-to-portal interoperability, and data-to-portal interoperability. Although it is generally best to integrate at the data level or logic level, each of these patterns has strengths and weaknesses. Selecting the correct interoperability patterns helps ensure a successful solution.

Portal-to-Portal Interoperability

Many organizations have more than one type of portal product deployed, making it natural to want to use existing portal investments when creating a new portal. For example, an organization might be using an SAP portal to access business processes, but might want to introduce Office SharePoint Server to take advantage of its collaboration, document management, and search functionality. In this scenario, the organization wants to have interoperability between the portals to provide the best user experience.

It would be ideal to use entire modules of functionality between the portals (for example, using an SAP workflow within an Office SharePoint Server document library), but the reality is that portals are developed on completely different architectures that make this type of interoperability nearly impossible. Instead, portal-to-portal interoperability relies on the use of existing standards and technologies to use the functionality of one portal in another. These solutions range from the simple use of hyperlinks to access content in another portal all the way through custom solutions that surface data from one portal in another. Figure 1 shows a conceptual drawing of content from one portal being rendered in another.

Figure 1. Portal-to-portal interoperability with IFrames

Content Repository-to-Portal Interoperability

Because documents are a significant part of any organization, content repositories of many varieties are often part of the interoperability equation. In these scenarios, organizations wish to maintain their existing investment in content management while using the additional capabilities of Office SharePoint Server. For example, a law firm might have an existing Interwoven-brand document repository that they want to surface in an extranet so that clients can easily access these documents as a legal case progresses.

In these scenarios, content management vendors often supply a set of Web Parts for accessing the content repository from within Office SharePoint Server. These Web Parts typically provide a view into the repository and a limited subset of functionality such as check-in, check-out, edit, and view capabilities. Web Parts may provide a quick solution for content repository-to-portal interoperability, but they might be too restrictive in cases where end users require more robust functionality. In these cases, custom solutions based on existing standards can provide a better end-user experience. Figure 2 shows an architectural drawing of an external repository displayed in a portal.

Figure 2. Content repository-to-portal interoperability

LOB-to-Portal Interoperability

LOB systems are often mission-critical applications that contain a significant amount of data. This data can cover a wide range of areas from customer contact information to organizational performance data. For most organizations, no portal solution would be complete without some level of LOB-to-portal interoperability. For example, a manufacturing company might want to create product sites based on data contained within a manufacturing system.

In these scenarios, functionality and data may be surfaced in Office SharePoint Server. For example, end users might use the Office SharePoint Server enterprise search engine to search for a product. The results returned from the search could take users to an Office SharePoint Server site dedicated to the product, where they could view details. If they subsequently needed to update the product bill of materials, for example, they could select an action within the portal to launch the manufacturing system and display the appropriate product record. Figure 3 shows an architectural drawing of LOB data presented in a portal.

Figure 3. LOB-to-portal interoperability

Data-to-Portal Interoperability

While using the functionality of a LOB system can be important, the data created by these LOB systems can be even more important to an organization. Data from enterprise resource planning (ERP) systems, for example, may be combined with CRM data in a data warehouse to create a complete picture of organizational performance across geographies and industries. Such data is often used to create dashboards and reports that can be accessed from within Office SharePoint Server.

In these scenarios, data is used to create reports that are stored in document libraries or dashboards that appear as content pages within Office SharePoint Server. Executives typically access reports and dashboards to get a high-level understanding of organizational performance. In more sophisticated solutions, reports and dashboards offer "drill-down" and "drill-through" capabilities that expose more detailed data to support a specific analysis. Figure 4 shows an architectural drawing of LOB data used to create a dashboard in a portal.

Figure 4. Data-to-portal interoperability through a dashboard

Standards and Technologies

Because applications use widely different architectures and technologies, Office SharePoint Server interoperability depends on existing standards and technologies to expose and consume data, documents, and functionality. There are several key specifications that directly support interoperability between various platforms, and several technologies that can be used to create custom interoperability solutions. Because of the support for standards, customers will always be able to use standards-based technology to produce or consume content with Office SharePoint Server. The following sections detail these specifications and technologies.

Really Simple Syndication

Really simple syndication (RSS) is a standard that defines a Web "feed," which contains content and metadata information for a site. Feeds are created as XML documents that provide a summary of content, along with metadata about the published content. These feeds are consumed by a feed reader that presents the feed information to the end user. Feed readers are available in many forms, from stand-alone readers to readers that are integrated into Internet Explorer, Microsoft Office Outlook, and SharePoint Server. For more information, see the RSS Specification.

Web Services

Web services provide the means for software applications to connect to other software applications by using standards such as HTTP, XML, and SOAP. Broad vendor agreement on these standards and proven interoperability have set Web services apart from other integration technologies.

Typically, Web services are designed to use remote procedure calls (RPC) or Representational State Transfer (REST). Web services that are based on RPC generally make use of the SOAP by using underlying XML messages to communicate between the client and the server. Web services that are based on REST (often called "RESTful" services) make use of Uniform Resource Identifiers (URI) to provide a unique address for a given resource.

Web services are a cornerstone of the Microsoft .NET Framework model and form the foundation of Microsoft interoperability efforts. By exposing key product features as Web services across its entire line of product offerings, Microsoft enables true cross-product and cross-platform interoperability. For more information, see W3C Web Services Activity and Web Services Interoperability Organization.

Web Services for Remote Portlets

The Web Services for Remote Portlets specification defines a Web service interface for accessing and interacting with presentation-oriented Web services. It was produced through the efforts of the Web Services for Remote Portlets (WSRP) OASIS Technical Committee. WSRP enables scenarios where a content consumer or aggregation engine consumes presentation-oriented Web services provided by portal or non-portal content producers.

Figure 5 shows an architectural drawing of a user interface element in one portal being exposed to another portal through WSRP.

Figure 5. Portal interoperability with WSRP

Portals acting as remote clients discover WSRP producers either directly through a Uniform Resource Locator (URI) or through a registry. Portals that call the exposed Web services of a WSRP producer are referred to as WSRP consumers. WSRP consumers receive markup from one or more WSRP producers. This markup is then aggregated and transformed to create content for an end user in the consuming portal. Office SharePoint Server includes a WSRP Web Part that can act as a WSRP consumer. Microsoft has also released a WSRP Toolkit for SharePoint, enabling customers to build custom solutions that act as WSRP producers. For more information, see OASIS Web Services for Remote Portlets (WSRP) TC.

Content Management Interoperability Services

Microsoft, EMC, IBM, and other leading software vendors have jointly developed the Content Management Interoperability Services (CMIS) specification. The CMIS specification was designed to simplify interoperability with enterprise content management (ECM) systems by leveraging existing open standards including SOAP, REST, and the Atom syndication format.

CMIS promises to dramatically reduce the IT burden around multivendor, multirepository content management environments. Repositories that implement the specification will expose a standard API that will make it simpler to publish and consume content. Developers can create solutions that surface content from any repository directly in an Office SharePoint Server portal. The specification is managed by the OASIS Content Management Interoperability Services (CMIS) Technical Committee. For more information, see OASIS Content Management Interoperability Services (CMIS) TC.

Office SharePoint Server Object Model

SharePoint Server exposes both an object model and Web services. Together, they can be used to access nearly all content, security, and administration functionality in Office SharePoint Server. Microsoft provides the proprietary protocols for the SharePoint Server Object Model on MSDN and as a download.

Content SharePoint Server Can Consume

The very nature of a portal is to aggregate information from a variety of sources. To this end, SharePoint Server has the ability to consume information from external sources by using several different techniques. This section covers many of the approaches used by Office SharePoint Server to consume and display information.

Links

Links are perhaps the simplest form of integration. Office SharePoint Server allows for the simple addition of links that lead to additional content. A separate set of links may be created in a list or links can be placed directly into the site navigation.

IFrames

IFrames enable page-based content from a Web site or portal to be surfaced in SharePoint Server. IFrames are essentially a picture frame surrounding a Web page that is delivered directly from an external source. In Office SharePoint Server, an IFrame is typically created through the Page Viewer Web Part. This Web Part is configured with the address of the page to display. Figure 6 shows an IFrame that displays the Microsoft home page within a SharePoint portal.

Figure 6. An IFrame in a SharePoint portal

Really Simple Syndication

SharePoint Server can consume RSS content from Web sites by using a feed reader. In SharePoint Server, the feed reader takes the form of a Web Part that may be used to subscribe to a feed. Figure 7 shows the feed reader Web Part configured to subscribe to the Microsoft SharePoint Team Blog.

Figure 7. A Feed reader on a SharePoint site

The Business Data Catalog

The Business Data Catalog (BDC) is a feature found in the Enterprise Edition of Office SharePoint Server. The purpose of the Business Data Catalog is to allow SharePoint Server to use data from external LOB systems. These systems can include customer relationship management (CRM) solutions, enterprise resource planning (ERP) solutions, custom applications, and databases. To connect to an external system, the Business Data Catalog requires an "application definition" file that describes the target system and how to connect with it. After this application definition file is created and loaded into the Business Data Catalog metadata database, data can be consumed from the target system.

After establishing a data connection, SharePoint Server can use data from the external LOB system in several interesting ways. First, a set of Business Data Catalog Web Parts are included with Office SharePoint Server that allow users to perform wildcard lookups against the data source and then display detailed information about any single item. Second, the Business Data Catalog data may be used to create a pick list for a column in a SharePoint list. For example, a list of customers could be presented that was sourced from a CRM system. If the data in the CRM system changes, so do the values in the pick list. Third, the Business Data Catalog data can be used to supplement profile information in SharePoint Server. For example, if the organization maintains employee information in a separate system like PeopleSoft, this data may be used to enhance the profile information visible in SharePoint Server. Finally, Business Data Catalog data may be searched by using the enterprise search capability of Office SharePoint Server. This means that end users may use keywords to search for and locate data within external LOB systems. Figure 8 shows an architectural diagram of the Business Data Catalog and its integration points.

Figure 8. Business Data Catalog architecture

Web Services

SharePoint portals can consume information from any XML Web service. This includes Web services based on the SOAP or REST protocols. Typically, Web service consumption is done through the Data Form Web Part. The Data Form Web Part can use Web services as a data source and then present that information directly to the end user. The Data Form Web Part uses XSLT transformations to change the data received from the Web service into a suitable display. Often, the setup and configuration of a Data Form Web Part is done in Microsoft Office SharePoint Designer 2007, which is uniquely suited for the creation and management of Data Form Web Part sources and displays. Figure 9 shows a sample Data Form Web Part in SharePoint Designer prior to having an XSLT transform applied.

Figure 9. Data Form Web Part consuming a Web service

Web Services for Remote Portlets

SharePoint Server can consume content from external portlets that support the WSRP 1.0 standard. SharePoint Server consumes data from external portlets through the use of its WSRP Consumer Web Part. The WSRP consumer Web Part must be configured to reference the external portlet; it will then display the content. For more information, see Plan Business Data Web Parts.

BizTalk Adapters

Microsoft BizTalk Server is middleware designed to connect multiple business systems across domains. The core of BizTalk Server is a messaging and orchestration system that can communicate between systems by using XML messages and that can model business processes that involve multiple systems. BizTalk Server uses a series of adapters to connect with LOB systems.

One of the BizTalk Server adapters supports integration with SharePoint Server. Using this adapter, end users may create XML messages through Microsoft Office InfoPath forms that are maintained in SharePoint libraries. These XML messages may then be used in orchestrations that involve other systems. Essentially, this acts as a workflow engine for SharePoint Server with the entry point being an InfoPath form.

Prior to Office SharePoint Server 2007, there was no "built-in" workflow engine. So, workflow solutions would either use BizTalk Server or a third-party workflow engine. With the release of Office SharePoint Server 2007, you can now use Windows Workflow Foundation to create workflows. However, the BizTalk Server adapters can still play an important role where SharePoint Server needs to participate in an existing orchestration. For more information, see BizTalk Adapter Pack.

Content SharePoint Server Can Produce

In the same way that SharePoint Server can consume content from other portals, it can also produce content for these same portals. Not surprisingly, the technologies available for producing content run parallel to the technologies for consuming content. Just as SharePoint Server supports consuming data through several different technology standards, it also supports exposing data through these standards. This section takes a look at ways to make SharePoint content available to other portals.

Links

SharePoint portals consist of pages that can be accessed through hyperlinks. Therefore, other portals can use lists of hyperlinks to access various pages within the SharePoint portal. Some of these pages may also support QueryString arguments that can be used with the links. For example, a portal could link to the SharePoint search page and provide a keyword within the QueryString argument so that the link automatically executes a search.

IFrames

SharePoint page content can also be rendered within an IFrame. Other portals can use a variety of technologies, such as portlets, to render IFrames that reference SharePoint pages. End users still need permission to view the content, even when rendered in an IFrame. For more information, see Integrating SharePoint with Other Portals and Applications.

Really Simple Syndication

SharePoint search results and all lists in SharePoint Server support RSS. Users select to subscribe to lists by using the Action menu on the list toolbar. Users can also subscribe to search results by using an icon that appears on the search page. All of the SharePoint RSS feeds are authenticated, which means that users need a feed reader that supports authentication to view SharePoint content. For more information, see RSS: Really Simple Syndication.

Web Services

SharePoint Server exposes several Web services that may be consumed by other portals. These Web services provide methods for use with sites, lists, users, and search. While the existing Web services do provide a significant amount of functionality, custom Web services may also be written that wrap the SharePoint object model. Figure 10 shows a conceptual drawing of integration with Web services. For more information, see available Web Services.

Figure 10. Integration with Web services

Web Services for Remote Portlets

Because SharePoint Server does not provide an WSRP producer by default, Microsoft has developed the WSRP Toolkit for SharePoint 2007. This toolkit shows how to enable interoperability between SharePoint Server and portals based on technologies supporting WSRP (Web Services for Remote Portlets). This document details two methods for adding WSRP producer functionality to SharePoint Server, and briefly explores other interoperability options through data integration by using industry standards.

WebDAV

Web-Based Distributed Authoring and Versioning (WebDAV) is a protocol that allows for the editing of documents across HTTP. SharePoint Server has full support for WebDAV, which means that its content can be accessed by using the file explorer. Organizations can use this technology to map SharePoint libraries, for example, as drives on end user machines. Figure 11 shows the file explorer using WebDAV.

Figure 11. WebDAV and the file explorer

RPC Services

Remote Procedure Call (RPC) is a protocol layered on top of HTTP that allows a client application to communicate with SharePoint Server. RPC calls made from the client take the form of an HTTP POST request to send methods to SharePoint Server. These POST requests send XML messages formatted by using Collaborative Application Markup Language (CAML). CAML is an XML language that is specific to SharePoint Server. It forms the underlying message for RPC method calls to request documents, update lists, and perform other operations. For more information, see Introduction—What Is CAML?.

SharePoint Server Search

Office SharePoint Server provides an enterprise-class search facility that can be used to index different types of stores that are both inside and outside of SharePoint Server. This capability means that the Office SharePoint Server search engine can consume content from across the enterprise. Additionally, the search engine may be used in conjunction with third-party engines through its support for the OpenSearch standard and Federated Search.

Search Architecture

Content sources are the stores where documents and information are kept within the enterprise. Office SharePoint Server has the ability to index content both within SharePoint sites and in external repositories. These external sources can include Web sites, Microsoft Exchange Server Public folders, file systems, and LOB systems.

The Office SharePoint Server indexing engine gains access to a content source through the use of a protocol handler. Protocol handlers allow the indexing engine to access the content source and to create a Security Descriptor that can be used to hide search results that an end user is not authorized to access. By default, Office SharePoint Server provides protocol handlers for common protocols such as files and HTTP. Protocol handlers exist for many common types of repositories, such as file systems. They can also be written to support any enterprise repository, such as Documentum and FileNet repositories. Additionally, Office SharePoint Server includes a protocol handler for the Business Data Catalog, which allows the indexing engine to crawl external LOB data stores such as CRM and ERP systems.

After access is gained to the content source, the indexing engine uses an IFilter to index each individual piece of content to support full-text queries. Without IFilters, searches cannot be performed on the content within objects. IFilters exist for common objects such as Microsoft Office documents, but can also be written to support any type of object.

As the indexing engine crawls the various content sources, it builds up a single index file. This index file can then be searched through an interface in Office SharePoint Server known as the Search Center. Search Center executes queries and then trims the results based on the Security Descriptor built by the protocol handler. For more information, see Enterprise Search: Search Connectors.

OpenSearch

In addition to searching through the Search Center, users may also perform queries by using OpenSearch. OpenSearch is a standard for ensuring that search engines and search results have interoperability between platforms. Office SharePoint Server supports federated searches with sources that support OpenSearch and return the result set as XML. A simple example of OpenSearch is the ability to provide a keyword query within a URL that links to the Office SharePoint Server results page. End users, for example, can use this technique to set up a custom search provider in Internet Explorer that runs Office SharePoint Server queries. For more information about OpenSearch formats, see OpenSearch.org.

Federated Search

Federated Search is the ability to display search results from various engines based on a single query. Federated Search differs from a standard search in that it involves multiple disparate search engines and external applications rather than a single search engine operating on a single index. The advantage of federated search is that Office SharePoint Server does not have to crawl all of the additional content to provide search results.

Federated Search was introduced with Microsoft Search Server 2008. After installing the Infrastructure Update for Microsoft Office Server, the same capabilities are made available in SharePoint Server. Federated Search works by using a "connector" to send a query to another engine and receive results. While some connectors are available, custom connectors may also be created. For more information about connectors, see Enterprise Search: Search Connectors.

Identity and Access

Office SharePoint Server has several technologies for authentication that support interoperability. These technologies include default capabilities and support for custom-developed solutions. Using these technologies allows both authentication within the SharePoint environment and with external systems.

Authentication

By default, SharePoint Server uses Windows authentication for access control. Within Windows authentication, SharePoint Server may use either NTLM or Kerberos authentication. NTLM authentication is the classic challenge-response authentication system and Kerberos is a more robust ticket-based authentication system. While NTLM does provide a secure environment for SharePoint operations, Kerberos authentication is considered the best practice because it is more flexible.

In addition to Windows authentication, SharePoint Server can also perform authentication against a variety of sources by using "pluggable providers". Pluggable providers are an extensible model that allow SharePoint Server to communicate with other user repositories, such as an LDAP server or a SQL database, to retrieve authentication information. Office SharePoint Server includes pluggable providers for both LDAP and SQL, and customers may also use this framework to integrate with many other authentication systems. Pluggable providers are useful when SharePoint Server is deployed in an environment that uses an LDAP server or in an extranet scenario where external users are maintained in a database.

Single Sign-On

External LOB systems are a common player in interoperability scenarios. The Business Data Catalog is useful for reading data from these systems, but it cannot be used for writing back. In cases where more interoperability is required, custom solutions may be written. However, these custom solutions need a way to authenticate against the external LOB system, which often uses a custom security database separate from Windows authentication. In these scenarios, the Single Sign-On (SSO) system within Office SharePoint Server can provide an answer.

The Office SharePoint Server SSO system is a credential repository that can be used to map Windows credentials to credentials in an external LOB system. Office SharePoint Server SSO is almost always used as part of a custom SharePoint solution where the solution accesses the Office SharePoint Server SSO system through code and retrieves credentials for the external LOB system. The solution then uses those credentials to log into the external system and perform functions.

Identity Life Cycle Management

Identity life cycle management (ILM) allows for the management of a users' identity across the entire enterprise. Although ILM is not specifically a part of SharePoint Server, it can be an important part of the overall interoperability story within the enterprise. Microsoft Identity Lifecycle Manager provides a flexible and comprehensive way to manage the life cycle of user identities and credentials across systems in the enterprise. The solution is designed to put users in control of their identities and relieve IT of the burden of identity management.

Partner Solutions

When thinking about an overall strategy for SharePoint Server interoperability, it is important to consider the products, technologies, and expertise that exist today. Before initiating any large or complex custom development projects for SharePoint Server integration, Microsoft recommends that you:

• Examine existing independent software vendor (ISV) solutions for SharePoint Server. Microsoft actively supports the growing number of ISV partners creating solutions for SharePoint Server.

• Engage a Certified Partner with demonstrated expertise meeting similar requirements to yours. Integrating multiple platforms can increase solution complexity

In addition to searching for partners solutions at the SolutionFinder Marketplace, consult your Microsoft Account team for assistance in locating proven Partner expertise and solutions for your requirements. For more information, see SolutionFinder Marketplace.

Conclusion

The investment that organizations have made in non-SharePoint platforms and applications often means that they must coexist with the Office SharePoint Server 2007 because they cannot easily be replaced. These existing platforms and applications often contain information and functionality that can be used in Office SharePoint Server 2007. Additionally, the information and functionality available in SharePoint Server is potentially useful to other platforms and applications. While multiple systems are in use, organizations can take advantage of the interoperability technologies and techniques presented in this article. These techniques can help ensure that all platforms and applications provide maximum value.

About the Author

Scot Hillier is an independent consultant and Microsoft Most Valuable Professional (MVP) whose focus is creating solutions for information workers with SharePoint, Office, and related .NET Framework technologies. He is the author of 10 books on Microsoft technologies including Microsoft SharePoint: Building Office 2007 Solutions in C# 2005 (Expert's Voice in SharePoint). Scot divides his time between consulting on SharePoint projects and training for the Critical Path Training, LLC. Scot is a former U.S. Navy submarine officer and graduate of the Virginia Military Institute. Scot can be reached at scot@shillier.com.

Additional Resources

For more information, see the following resources:

• Interoperability for SharePoint Server 2007 and Lotus Notes or Lotus Domino

• SharePoint Server 2007 Developer Center

• Microsoft Open Protocols

• Web Services Interoperability Organization

• Interoperability Forum

• Document Interop Initiative

• Interop Vendor Alliance

• Microsoft Interoperability

• RSS Specification

• W3C Web Services Activity

• OASIS Web Services for Remote Portlets (WSRP) TC

• OASIS Content Management Interoperability Services (CMIS) TC

• SharePoint Products and Technologies Protocol Documents

• Microsoft SharePoint Team Blog

• Plan Business Data Web Parts

• BizTalk Adapter Pack

• Micrsoft SharePoint Team Blog: Integrating SharePoint with Other Portals and Applications

• RSS: Really Simple Syndication

• Web Services

• WSRP Toolkit for SharePoint 2007

• Introduction—What Is CAML?

• Enterprise Search: Search Connectors

• OpenSearch.org

• SolutionFinder Marketplace