翻译一篇有关SHAREPOINT构建协同办公平台的文章

jilh

　　这两天完成了导师下给我的任务，翻译一篇英文文档，这篇文档是微软MSDN上的文章，关于使用SPS来构架协同办公平台的文章。。由于我的英文水平相当的有限，所以贴出来，让大家看看，希望可以帮我解决很多我翻译不了的地方。文章的原地址是：http://msdn.microsoft.com/msdnmag/issues/04/07/WindowsSharePointServices/
我的翻译如下:

使用Windows SharePoint服务构建协同办公应用平台

在过去几年中，Microsoft有一个很重要的可用的技术产品。Windows SharePoint Services(WSS)和SharePoint Portal Server(SPS)是两个旗舰产品。这篇文章从两个地方来写。在这个月中介绍ShaprePoint的基础体系结构和讨论使用Microsoft.NET Framework的SharePoint的开发。第二部分，将讨论用WSS和SPS模型对象和自定义的Web Parts对SharePoint站点进行编程。
Windows SharePoint Services 被认为是Windows Server 2003操作系统官方附加产品的一部。WSS提供一个框架用来建立协作的Web站点，使得公司内的多个团队，部门和大型组织很容易的共享信息和文档。任何一个用户能够使用Web浏览器或者通过Microsoft Office 2003产品如Word和Excel来进行协作。
Wss也提供一个基础框架通过包含在Web Part Pages和Web Parts中来产生UI。Web Part Pages和Web Parts是SharePoint非常有用的一个方面，因为每一个WSS站点都提供一个可以完全定制的、基于浏览器的UI。Web Parts 能够用来记录每个用户的个性化的信息。
SharePoint Portal Server 2003是Microsoft Office 2003系统的一部分，被用来建立企业级的门户站点。最重要的是注意SPS是建立在WSS之上的。SPS通过增加可管理的特性帮助用户在众多的信息和文档中很好的导航来弥补WSS的不足。并且SPS使用索引，搜索，audience targeting,single sign-on提高门户站点的性能。
图1显示了WSS和SPS的角色上的根本的不同。WSS是基于协作的主题和存储和共享的是基于列表的数据和文档。SPS在另外一个方面是基于集合的主题。SPS集合不同地方的信息和文档。

图1   WSS和SPS的角色

本质上，WSS给你的是你存放内容的位置而SPS是提供所需要的导航和搜索内容的方法。这两个角色相互之间补充。WSS允许一个企业级的公司创建和维护数千的协作网站，而一个或多个SPS门户站点允许用户在这些WSS站点中的内容寻找所需的数据。
SPS依靠WSS来提供许多本质上的服务。例如，WSS提供SPS能够记录成员和共享列表和文档。此外，由于门户站点的用户接口SPS不需要使用rendering引擎来生成HTML。SPS利用WSS Web Part Page和Web Part的体系结构来构造用户接口。

Windows SharePoint Services
对于购买Windows Server 2003操作系统的个人或者事公司来说，WSS是免费赠送的。WSS安装文件能够使用Windows Update service或者从Microsoft.com站点的Sharepoint站点上下载。
WSS framework是建立在Windows Server 2003操作系统，IIS6.0和ASP.NET上面的。图2显示了WSS framework的基本模块是如何组合在一起的。需要注意的是在此之前必须成功的在Windows Server 2003上面安装WSS，首先需要在主机上面通过IIS6.0和ASP.NET 1.1搭建一个Application Server。

图2  WSS体系结构

一旦知道了WSS的历史学习它将是一件很容易的事情，WSS是Sharepoint第二代产品和技术的一部分，第一代产品是建立在基于IIS框架上的被称为SharePoint Team Services(STS)之上的。STS框架和WSS提供一个协作的框架来共享基于list的数据和文档相似，不过和WSS不同的是，WSS是建立在.NET Framework或者ASP.NET上的，而STS是建立在使用ISAPI扩展属性之上的。
由于只有有限的工具，自定义和扩展STS页面站点总是很困难。在WSS和SharePoint第二代产品中站点的自定义是很容易的因为可以使用像FrontPage 2003这样的WSS-compatibe的页面设计工具。WSS有很好的扩展性，因为可以自己来为WSS站点和SPS门户站点用Visual Studio.NET的C#或Visual Basic.NET语言写自定的的应用软件和Web Parts。
STS和SharePoint第一代产品和技术同时也遭受了伸缩的问题。一个基础的体系结构运行在最大状态的前端页面服务器上必须是可靠的。这个缺点使得它不可能超出STS页面站点使用Web farm environment，当Microsoft的程师开始设计WSS和SharePoint第二代产品和技术，他们把修复STS的伸缩问题作为最主要的目标。因此，他们设计了一个体系结构来支持数万用户和数万页面站点的WSS和SPS的开发。

图3  Web Farm Configuration

WSS体系结构是基于最小状态的前端页面服务器的。它建立在所有联系页面站点的基于list数据和文旦都被存储在SQL Server数据库这种集成存储策略上的，如图3所示。这种集成存储策略是允许WSS Web Servers的开发人员有效的在Web farm environment进行伸缩扩展。

DATABASES
WSS依靠两种不同的SQL Server数据库：配置数据库和内容数据库。配置数据库保存了每一个物理的页面服务器，IIS 虚拟服务器和WSS页面站点的所有配置信息。内容数据库保存了联系WSS页面服务器的数据。
每一个WSS Web server的配置WSS都需要一个额外的配置数据库。一个简单的开发包括一台运行WSS前端页面服务和配置数据库的SQL服务的主机和一个内容数据库。一个具有良好扩展的WSS开发包括用多个前端服务器构成的Web farm scenario。一个WSS开发还能包含多个后端数据库。例如，在可靠的开发中通过多台主机运行SQL服务部署多个内容数据库来提高系统的性能。但是，对于每个WSS开发都只有一个配置数据库。这个配置数据库提供一个中心信息仓库来协同前端和后端服务器。
每一个内容数据库存储了一个或多个WSS页面站点的数据。WSS数据被存在一个site-by-site，基本包括所有有关站点列表和文档的自定义和个性化的信息。这个集成存储策略提供了除数据库以外一个在STS上改进的在文件系统存储和注册的site-specific数据。事实上每一个和站点相关的事情都存储在一个单独的SQL服务数据库中，这样就可以很容易的在WSS下进行备份和恢复啊。
如果是刚开始接触WSS，应该在Windows Server 2003的计算机上安装所有的东西。如果已经安装另外Windows Server 2003，需要把IIS6.0和ASP.NET1.1配置为应用服务器。当配置IIS和ASP.NET时，确定没有安装FrontPage Server Extesion因为是和WSS相矛盾的。然后可以运行STSV2.EXE文件来安装WSS。
对于单台计算机配置，WSS不需要使用SQL Server完全版。WSS安装程序能够安装MSDE的一个名叫Windows MSDE的一个特别的版本(WMSDE)。WMSDE不像MSDE标准版因为它没有限制使用2GB的存储空间和10个数据库的连接。然而，WMSDE比MSDE有更多的限制，因为WMSDE只支持表计划。这意味着不能用WMSDE来创建个儿呢自定义的数据库和表。
如果在一台工作站上安装SPS，这个安装过程是复杂的。首先，这里有好几个SPS特性需要活动目录。因此，SPSP安装必须在活动目录域中的一部分。在Windows Server 2003上安装SPS之前，首先把机器添加到一个已经存在的活动目录中或配置它成为一个域控制器。运行Windows Server 2003的计算机已经在域中，把它用SPS配置IIS6.0和ASP.NET1.1为可用的应用服务。同时也推荐安装SQL服务来代替WMSDE来存放门户站点的数据。
一旦在Windows Server 2003计算机上安装好了IIS6.0，ASP.NET1.1，和SQL Server，病把它添加到一个活动目录域中了，久可以准百安装SharePoint Portal Server 2003。的一件事情是SPS安装程序需要安装WSS。然后，在WSS上面再安装SPS。最后，SPS安装显示一个向导来一步一步的创建配置数据库和初始化门户站点。
注意，SPS创建额外的数据库来存放服务器上的SPS服务，用户简档和安全信任信息的数据。
在SQL服务上安装WSS或者SPS，需要用SharePoint为IIS应用池来添加一个SQL登录Windows系统帐户的认证。在默认情况下，WSS和SPS配置IIS应用池在NET AUTHORITY\NETWORK SERVER帐户认证下。如果不想要默认设置，可以把IIS应用池配置为任意一个Windows帐户。无论决定使用哪一个Windows帐户，都需要一个SQL登录帐户来登录SQL Server。
一旦用SQL Server添加了合适的SQL 登录帐户，必须把这个登录帐户添加到安全管理和数据库创建的服务角色。如果不按照这些步骤来做，在安装或配置WSS或SPS时会产生许多的错误。这是因为在默认的情况下，IIS应用池时在NT AUTHORITY\NETWORK SERVICE帐户下运行的，而这样是没有权限去登录到SQL服务器的。必须配置SQL服务器赋予这个帐户可以创建和设置他们安全设置的权限。

IIS WEB SITES AND VIRTUAL SERVERS
WSS页面站点配置是在IIS页面站点的级别上。默认的IIS是创建一个名为“Default Web Site”的IIS页面站点来监听来自80端口的HTTP请求。可以使用IIS管理工具来创建一个额外的IIS页面站点来监听来自不同端口或不通主机头的HTTP请求。图4显示了在一个IIS Web 服务器上配置两个虚拟服务来让用户访问。

图4  用户可访问的两个虚拟服务器

注意WSS安装程序添加了他自己特定的IIS页面站点，名称是“SharePoint Central Administration”。WSS用这个IIS Web Site来运行SharePoint Central Administration HTML页面。SharePoint Central Administration Web 站点在安装时被配置为随机使用的一个端口。
在SharePoint术语中，一个IIS页面站点被认为是一个虚拟服务器。一个虚拟服务器为了在WSS站点上运行必须被WSS扩展。当用默认设置安装WSS，它自动把监听80端口扩展为一个虚拟服务器。也可以使用SharePoint Central Administration HTML页或者一个叫STSADM.EXE的WSS命令行管理工具来对另外的虚拟服务器进行扩展。
WSS不像ASP.NET那样因为不需要用IIS虚拟目录来配置每一个页面站点。WSS在配置数据库和内容数据库中存储所有的配置信息。这意味着一旦扩展了一个虚拟服务器，然后就可以创建WSS页面站点了，他们不需要出现在IIS的元数据当中。被代替的是一个入口在合适的内容数据库中配置数据库中被创建。本质上，IIS不知道一个扩展的WSS站点是否包含一个WSS页面站点还是10000个WSS页面站点。因为WSS不需要为每一个新的WSS页面站点配置成为一个IIS虚拟目录，可以得到更多的伸缩性和更好的维护性。
当WSS自身扩展为一个虚拟服务器的时候，会安装一个自定义的ISAPI过滤器来调用WSS过滤器(STSFLTR.DLL)来截取每一个请求虚拟服务器的路由信息，并决定这些请求是发到WSS还是发到IIS。为了做这个决定，WSS过滤器检查引入的URL和考虑配置数据库来决定是否处理。需要记住的是，在要运行WSS站点的时候和ASP、ASP.NET一样需要一个虚拟服务器。
当WSS自身扩展为一个虚拟服务器的时候，会添加一个web.config文件到主机的虚拟服务器的根目录下。这个web.config文件提供了在WSS和在虚拟服务器内部运行的所有的ASP.NET代码的初始化配置。默认情况下，这个web.config文件包含清晰的限制性的安全设置。当代码需要提高权限或当测试开发一个新的Web Part的时候就需要请求修改web.config文件的一个区域。
在SharePiont术语中，一个URL空间是在目标虚拟服务器上可用的所有URL的集合。WSS分离在管理路径中得一个扩展的虚拟服务的URL SPACE。WSS中被管理的路径被认为是包含路径，不被管理的路径被认为是排除路径。当WSS过滤器检查请求的URL是不是排除路径中的一部分，它知道对于标准的ASP或ASP.NET请求就交给IIS去处理。
当想把一个虚拟服务器上的标准的ASP.NET主机扩展成一个WSS服务器需要做什么？例如，想象一下，在http://AcmeServer/webapp1上的ASP.NET Web应用程序和一个可用的WSS站点在通一个虚拟目录下进行开发。在这种情况下，需要理解如何配置包含和排除路径。在实际中，对URL Space需要用ASP.NET Web Applicatoin来添加一个排除路径。图5显示了一部分用户接口来提供使用Sharepoint Central Administration HTML页面来定义管理路径。

注意图5显示的虚拟服务器的包含路径和排除路径。一些包含路径比如站点的被定义为“wildcard inclusions”。wildcard inclusion的目的是使URL分解更有效果。WSS不允许包含路径在嵌套wildcard inclusion的URL space。一旦WSS过滤器检查进来的请求的URL的一部分匹配wildcard inclusion的一部分如http://AcmeServer/sites，它就知道把这个请求直接发送给WSS处理。



图5  WSS定义管理路径的UI界面　　
当WSS过滤器决定了请求的路径在包含路径中，则在配置数据库中定位到目标WSS站点。WSS利用站点的URL和唯一标识符GUID在配置数据库中存储每一个站点。这里在配置数据库中的补充信息将连接每个站点到目标内容数据库。
在WSS配置中，扩展多余一个的虚拟服务器将变得很有用。每一个虚拟服务器通过隔离的进程中使用IIS应用池运行WSS页面站点来进行配置。IIS也可以对每一个虚拟服务器做不同的安全认证需求。一个虚拟服务器被配置为需要Basic Authentication而第二个可以配置成需要Intergrated Windows Authentication。
在一些配置中，每一个WSS扩展的虚拟服务器将有它自己的内容数据库。它也可能扩展为一个虚拟服务器，因此，它与另外一个虚拟服务器都放在同一个内容数据库中。这就允许一对虚拟服务器提供两个不同的访问点来对WSS站点进行设置。这个非常有用因为对每个虚拟服务器可以对立的进行配置安全设置。例如，一个虚拟站点提供一个面向大众的页面站点是使用的典型的配置，请求的是SSL和基本的认证。而第二个虚拟服务器提供在防火墙后面访问的用户配置为需要请求windows集成认证。

Site Collections，Sites，and Workpaces
在虚拟服务器中，WSS站点被分割为站点集合——一个或多个站点能够组合为一个所有者的单元。创建一个新的站点集合需要提供所有者的一个WINDOWS登录帐户合一个e-mail地址。WSS保存了有关站点集合所有者的相关信息，所以它能够给他们授予管理的权限合给他们发送e-mail通知关于站点集合维护的事情。
一个站点集合总是包含一个top-level站点，这个站点拥有合站点集合一样的URL。当创建一个新的站点集合的时候，一个top-level站点就被自动创建了。除了top-level站点以后，一个站点集合可以随意包含其他的通过parent-child关系来联系top-level站点的二级站点。这个关系在图6中显示出来了。每一个站点必须在指定的站点集合中创建，并且所有的站点在相同的站点集合中都存储在相同的内容数据库中。

图6  虚拟服务器的站点集

站点集合作为一个整体的单元在WSS中备份合恢复。STSADM.EXE管理工具为备份和恢复一个站点集合提供了一个很容易使用的命令行。在备份站点集合后，稍后就可以在相同的Web 服务器或不同的服务器上来恢复它。将会发现WSS在站点集合中top-level站点中备份和恢复个人站点还是有些难度的。如果传剑一个站点来独立的备份和恢复，就应该在新的站点集合中创建一个top-level站点。
当在一个很大的具有成百上千的站点集合的WSS中进行日复一日的维护的工作，没有必要个别的备份站点集合。只需要对整个站点的内容数据库进行备份就可以了。备份内容数据库对需要公司来说是很容易的，因为可以使用相同的备份程序来备份不同的SQL数据库。
现在回到开始并问一个基本的问题：什么是WSS站点？首先，一个站点是存储内容的容器。站点的内容主要以列表的形式、文档库和子站点存储。第二，一个站点是一个用户可以配置得可以获得内容的一个实体。一个站点既能够定义自己的用户集合，也能够从父站点继承过来。每一个站点用户映射到已经再活动目录域或者本地windows安全帐号数据库中定义的windows帐户。一个站点也包含一个可以配置的组集合和许多用户在站点列表和文档库中定义为可以有访问权限的级别。
第三，一个站点也可以用自身的扩展性和自定义的用户接口发生在一个Web应用程序上。站点拥有者和页面设计者能自定义布局和站点页面的外观，并且可以用浏览器或者FrontPage 2003来修改站点的导航结构。
最后，一个站点是使用Web Part Page和Web Part技术的基础。站点所有者和页面设计者可以通过添加和配置共享的Web Part来自定义Web Part Pages。一个用户可以通过修改、添加、或者是删除Web Part来个性化。所有在Web Part Page上自定义的和私有的联系Web Part的数据都自动被存在内容数据库。
WSS在“工作平台”上支持多个不同的站点模板，一个工作平台就是一个标准的WSS站点。然而，一个工作平台的目的是比其他WSS类型站点的更严密的定义因为它通常更关注单个文档或会议。因此，工作平台站站点包含预先定义的列表来提供对Microsoft Office产品如Word,Excel,Access和Outlook的更好的集成。
每一个站点都从站点模板来初始化。一个站点模板是一个定义新站点中初始化列表集，文档库，Web Part Pages, 和Web Parts的蓝图。WSS有八个站点模板：Team Site, Blank Site, Document Workspace, Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace, 和Multipage Meeting Workspace。当一个站点在创建后第一次被访问，WSS在HTML页中显示如图7中的图提示用户选择可用的站点模板之一。

图7  选择站点模板

WSS支持创建和使用自定义站点模板。可以用FrontPage2003自定义一个拥有中心内容的站点，然后保存为站点模板。也可以在浏览器中把站点保存为站点模板。一旦自定义的站点模板被创建了，在相同的站点集中就可以创建新的可用的站点了。一个自定义的站点模板能够被导入到另一个站点集合中，也能够被用于创建top-level站点。

SPS Arhiteture
SPS建立在由WSS建立的体系的最高层。当创建一个新的SPS门户站点，实际上是创建一个物理上的WSS站点集合。然而，这里有一些显著的限制在SPS使用WSS时。每个虚拟服务器只能有一个门户站点。因此，站点集合包含的门户站点总是在虚拟服务器的根URL上被创建。
一旦在虚拟服务器的根上创建了一个门户站点，必须在相同的虚拟服务器上创建一个额外的标准的WSS站点集合。事实上，确切来说是从门户站点执行创建站点命令。SPS在一个新的站点集合上创建一个top-level站点。当一个门户站点用户点击"My Site"链接创建一个个人的站点，SPS也在一个新的站点集合中创建一个个人站点作为top-level站点。这个策略使得在SPS配置中很容易就备份和恢复共享的和个人的站点。
SPS通过对areas和listings来扩展WSS存储的内容。记住SPS是围绕集合的主题的设计的产品。Areas和listings常用来对门户站点内容的管理和对来自不同地方的内容进行集合。一个area是一个listings和一组子区域的容器。有时，一个listing会包含基于HTML的文本。更多的是，一个listing包含一个链接非门户的内容如文档，Web Page或来自网络的WSS列表。最关键的一点是listings允许SPS来链接用户到非门户站点内容如共享文件，Microsoft Exchange公共文件，WSS站点，公共Web站点和Lotus Notes，如图8。

图8  SPS列表

一个门户站点的area可以构造一个父子等级的关系。图9显示了基于HTML接口使得SPS提供可以在area工作的方法。这个用户接口可以很简单的实现添加和删除来自门户站点的等级的area和listings这样的对门户站点内容管理的工作。SPS也可以完成简单的对任何一个使用浏览器来重建一个area和listings。

图9  SPS区域

Area和listings的集合很简单，因为在门户站点内部和外部中通过内容很容意的导航。Area和listing也被SPS search service所集成。当在一个area范围内运行SPS search，SPS search通过内容和链接在子区域的内容和列表的内容完成。
SPS search service是通过SPS indexing service来完成的。这个indexing service被用来设计为建立通过内容链接和areas和listings建立起来的索引。这个index service能够知道如何通过特别的关键字在WORD文档和EXEL spreadsheets找出所需要的信息。一旦这个索引集建立了，SPS search service能够很快速的找到用户所需要的信息。

Conclusion
       这篇文章从深度上介绍了SharePoint产品和技术的体系结构。WSS和SPS是两个不同的产品，都是使得如何更好的进行协作。WSS提供了创建自定义和私有的合作站点。SPS通过集合各处的内容来充当补充WSS不足的角色。SPS是完全依赖底层的WSS结构体系。事实上，如果对WSS了解的也多，学习SPS也就越容易。
       In one sense, SharePoint products and technologies reduce the need for custom software development because WSS and SPS provide so much functionality right out of the box.WSS和SPS也提供可用的方法来写自己定义的应用程序和Web Part。此文是给开始学习SharePoint技术人员的一个指导。