资源描述
An approach to solution architecture for SharePoint Products and Technologies
Date published:
September 2008
Summary:
When you work with Windows® SharePoint® Services 3.0 and Microsoft® Office SharePoint Server 2007 deployments, you must ensure that the architecture of the deployment is intuitive to your users, will scale and grow with your business over time, and importantly, that it performs well. The first stage of architecting a scalable solution is to design and deploy a server farm. However, you must also design appropriate information architecture for the solutions and information deployed on that server farm. By architecting the information structure and solution deployment, you can improve the efficiency of your Windows SharePoint Services 3.0 or Office SharePoint Server 2007 deployments.
This paper describes one way to design your information architecture by using metadata, site columns, content types, and managed properties. It also explains the feature and solution architectures, site definitions, and site templates.
You can view a video of a presentation that covers this material at
For alternative guidance for designing SharePoint Products and Technologies solutions, see Site and solution planning ( in the Office SharePoint Server technical library.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2008 Microsoft Corporation. All rights reserved.
Microsoft, SharePoint, and Windows are trademarks of the Microsoft group of companies.
All other trademarks are property of their respective owners.
Table of Contents
INFORMATION ARCHITECTURE 1
Site Columns 1
Best Practices for Site Columns 1
Content Types 2
Best Practices for Content Types 2
Managed Properties 4
Best Practices for Managed Properties 4
Content Databases 5
Content Database Architecture 5
Hardware Considerations 6
Configuring Content Databases for DBAs 6
SOLUTION ARCHITECTURE 7
Web Applications, Site Collections, and Sites 7
Server Farms 7
Web Applications 8
Content Databases 8
Site Collections 8
Sites 9
Variation Labels 9
Feature Architecture 10
What Is a Feature? 10
What Are Feature Scopes? 10
What Are Feature Dependencies 11
Hidden Features 11
Feature-site Template Associations 12
Installing and Uninstalling Features 12
How to Install Features 12
Scripted Feature Installs 12
How to Uninstall a Feature Completely 12
Activating and Deactivating Features 13
Activating and Deactivating Features by Using the User Interface 13
Activating and Deactivating Features by Using the Command Prompt 14
Solutions and Deployment 14
What Is a Solution? 14
Where to Deploy a Solution 15
How to Synchronize Solutions in a Farm 16
Site Definitions 16
What Is a Site Definition? 16
What Do Site Definitions Consist of? 16
Installing a Site Definition 17
Site Templates 18
What Is a Site Template? 18
What Do Site Templates Consist of? 18
Installing a Site Template 18
Information Architecture
You must ensure that you design your information architecture before you deploy your environment; this will save you subsequent time and effort. The key to developing robust and appropriate information architectures is to research and understand the business data and business intelligence requirements of your users.
When you plan your information architecture, you will find it useful to perform usage analysis to establish which sites and subsites receive the most traffic. You can analyze usage in your organization's existing deployments by examining the log files generated by Internet Information Services (IIS). There are numerous third-party tools available that generate usage reports based on these logs. If your users are currently working in a Windows SharePoint Services 2.0 environment, by using the Central Administration Web Application, you can activate Usage Analysis Processing. This gathers information from the IIS logs and generates a usage report for a specified site. You can use this information in conjunction with user surveys to establish what content is accessed most frequently; this will enable you to determine which content needs to be most easily accessible. You can also use user surveys to develop a clear plan for developing metadata that best describes content.
Site Columns
To develop accurate and pertinent metadata, you must first analyze user requirements. The key aim of taxonomy and metadata development is to provide targeted information to your users. SharePoint Products and Technologies provide site columns that provide a reusable template for controlling metadata. By using site columns, you can manage the structure and availability of content for your users. You can use site columns to gather metadata for content and to maintain a consistent use of metadata across the sites in your site collection. When you define a site column, you can associate it with any content type or list. For example, you can specify that any document that a user uploads to a specific list must have an author. To do this, create a custom site column that describes the type of data required, such as author, and then associate that site column with the list of your choice. Note that this is done through the configuration options for the list or library in question rather than from the site column. The site columns you specify for your content types are used as part of the index process and can help you to provide relevant search results.
Best Practices for Site Columns
When you develop metadata for your sites, you must determine the exact requirements of your users. You should work with your users to determine what data they use on a regular basis and how they describe this data, this will enable you to make the data more discoverable for your users. Custom site columns provide the administrator with a reusable solution that can be applied to lists or libraries in a site collection. To determine accurate site column specifications, you must examine the data that your users work with and perform interviews to gain a better understanding of what descriptive information is important to them. When you develop site columns, you must remember that they each represent an attribute that a user will manage for a particular content type. By defining site columns that can be applied across multiple lists, you can ensure that a particular type of metadata can be enforced across your deployment.
For example, after examining user requirements, you may determine that all documents are generated for specific customers. From your user interviews, you may also determine that your users want to be able to locate all files associated with a particular customer. Finally, you may determine that your organization has a limited number of customers; the organization produces data for Litware Inc., AdventureWorks, and Fourth Coffee.
In this situation, you can develop a site column called Customer. By using the gathered information, you can determine that the Customer site column must be a multiple-choice column that enables users to select one of the three clients. You can also specify that the column is a required field when users add their content. By prescribing the options available to your users, you can ensure that content added to a site that has been produced for Litware Inc will have the same Customer property value. If you specify the site column type as a Single line of text rather than a Choice, users can enter incorrect values. For example, a document added with a Customer property of LitwareIncorporated is not assigned the same Customer value as one added with a Customer property of Litware Inc.
The advantage of producing site columns is that you can apply them across the lists in your site or site collection. Additionally, you can subsequently modify site columns, and the changes that you make can be passed down to the lists that inherit that particular site column. In the example of the Customer site column, if your organization acquires a new customer, such as Contoso, you can modify the site column so that the new customer name is displayed in the list of choices. However, note that although the options change for new content when you modify an existing option, you must change the content your users have already stored on an individual basis.
Note: When you create a site column, you are given the option of adding the column to an existing group or creating your own groups. We recommend that you create your own groupings. By defining groups of site columns that have been identifiably defined for a specific group, such as a department or product type, you provide an easily understood structure for your metadata assignment.
The following list details the factors that you must consider when you develop site columns:
· Who is the information aimed at?
· What type of data do users work with?
· Can users already find the information they require?
· How do users work with content?
· What functionality do users require?
· What information requirements does your organization have?
Content Types
You use content types to store multiple types of documents in a single list, each with its own specific associated metadata. For example, you can create a different content type for each different type of presentation document, such as technical, sales, or training presentations. Each content type has site columns associated with it that determine the metadata stored for that particular content type. The use of content types enables you to maintain a consistent use of metadata for particular types of documents across your sites and lists.
Best Practices for Content Types
Many organizations require multiple types of content. Windows SharePoint Services 3.0 and Office SharePoint Server 2007 provide content types that enable administrators to architect a flexible solution for defining metadata, and default templates, specific to a type of content. It is also possible to associate workflows and policies with content types. By linking your workflows to a content type, your organization can track and ensure that users are following the appropriate business-driven content processes.
Content types are independent of document type; you use specific metadata to define and organize your content types. The following table illustrates how you can define different content types for your organization.
Document Type
Content Type
Metadata
Office Word Document
Proposal
Title
Created by
Customer
Product
Design Specification
Title
Created by
Customer
Product
Version
Microsoft Office PowerPoint® Presentation
Sales Presentation
Title
Created by
Customer
Delivery date
Technical Presentation
Title
Created by
Customer
Delivery date
Department
Delivered by
When you examine the existing information architecture in your organization, you must evaluate the types of document that your users use on a regular basis. You can create content types that reflect the type of information with which users work; this helps users to understand and locate information. By defining distinct content types with distinct compulsory or required metadata fields, you can enforce a strict structure on the properties exposed by certain documents. You must also observe and model the stages of common business processes; this will enable you to develop workflows that represent the real-life processes your organization follows. Planning for workflows enables you to automate processes that previously had to be done by hand; this increases business efficiency.
Note: For more information on workflow development, see Configuring Forms Services and Excel Services (
You must design content types carefully before you deploy them into your environment. Ensure that your content types fit with your overall information architecture; this includes the site or site collection they are designed for and the way in which your users will navigate to them. Creating inappropriate content types will result in user confusion, inability to locate relevant information, and a lack of pertinent structure throughout your sites and lists. A poorly designed content type may be too generalized to provide any relevant content information. For example, if you create a content type of Acceptance Letter that is a Microsoft Office Word document and has only Title and Created by properties, you reduce the chances of users locating that item through a property value search. However, if you create a content type of Acceptance Letter that is an OfficeWord document and has Interviewee, Interviewer, Created by, Date created, and Department properties, you produce a far more locatable content type.
When you develop content types, you must consider the following issues:
· What document types do your users deal with?
· What site columns have you defined for user content?
· How will your users locate content?
· Where does this content reside in the overall site structure in terms of business, organizational, or process information?
· What business requirements can you address by defining content types?
Managed Properties
You use managed properties to manage the organization of content metadata. Managed properties are only made available through Office SharePoint Server 2007; organizations that plan to deploy a Windows SharePoint Services 3.0 environment will not be able to take advantage of them.
A managed property is essentially a property that you map to one or many crawled properties. Crawled properties are discovered by th
展开阅读全文