1.4 SharePoint 2010基础概念
本节将介绍SharePoint 2010中的一些主要概念,以作为后续开发的基础,理解这些关键的概念将对以后的开发有很大帮助。
1.4.1 服务器场
简单的理解,服务器场就是一系列服务器的集合。在简单的应用里,SharePoint 2010的所有功能可以部署在单一的服务器里;在生产环境里,SharePoint 2010的运行环境可以由多台服务器组成一个服务器场,包括Web前端服务器、应用程序服务器(包括爬网服务器、查询服务器等)、数据库服务器。
如图1-1所示是一个大规模的服务器场应用,每个服务器角色都分成了若干个服务器组,比如Web服务器就包括处理所有请求的服务器和存储索引的Web服务器,其中处理请求的服务器可以通过负载平衡器进行统一访问定位,负载平衡器有硬件和软件两种解决方案,这里不做赘述。
图1-1 服务器场架构
应用程序服务器角色主要包括了爬网服务器组、查询服务器组、其他应用程序服务器组(如托管元数据服务、Excel计算服务等),以及专属的沙盒解决方案应用程序服务器。SharePoint 2010可以搜索多至1亿条数据,配置Fast Search Server For SharePoint 2010的情况下更可以多至10亿条数据。但是每个查询服务器只能提供最多1000万条数据的服务。如果部署了SharePoint Foundation的服务器,则如前文所述只支持300000条数据的搜索服务。
数据库服务器角色主要包括了存储爬网后供搜索用的搜索服务器,存储站点集内容的内容数据库服务器,存储其他内容比如管理站点配置数据的其他数据库服务器。在企业级的应用里,每组数据库服务器都可以通过群集来提供更加可靠的服务。
1.4.2 Web应用程序
SharePoint 2010建立于IIS 7.0之上,所有默认的IIS网站里IIS会监听来自相关管理端口的请求,Web应用程序扩展了IIS网站,并因而也具有IIS网站一样独立的运行端口、独立的身份认证体系、独立的应用程序池、单独的web.config文件等。
一个Web应用程序通常由若干个网站集组成,SharePoint 2010使用内容数据库来存储网站集,一个内容数据库可以包含若干个网站集,但一个网站集只能存储在一个内容数据库里,一个内容数据库的大小要限制在100GB以内,但根据企业的具体服务器架构,通常要比这个推荐值小一些,如笔者所供职的某大型外企里的Share Point环境管理策略就要求限制在50GB以内。
警告:不要试图通过自定义代码访问内容数据库数据,任何这样的行为将会导致该内容数据库不被微软支持,在笔者了解的某个case中,某大公司的知识管理系统由于修改了SharePoint内容数据库的表结构导致了服务器当机。SharePoint的所有数据都建议通过SharePoint对象模型API来访问(有意思的是SharePoint也提供了访问内容数据库并执行SQL数据查询和修改的API)。
SharePoint 2010通过在IIS网站里配置SharePoint专属部件,定制的HttpModule和HttpHandle,通过ASP.NET 3.5来扩展IIS服务器的标准行为,通过和ASP.NET的这种集成让SharePoint 2010可以控制到达Web应用程序的每一个请求,如图1-2所示。
图1-2 IIS管理器
对从ASP.NET转到SharePoint的开发者来说,可以将SharePoint Web应用程序理解成一个大规模的ASP.NET应用程序,如前文所述,每个SharePoint Web应用程序都有自己的如同典型的ASP.NET应用程序一样的web.config文件。与ASP.NET网站不同的是,每一个网站集并不拥有独立的配置文件,SharePoint Web应用程序下唯一的一个web.config为所有该Web应用程序下的网站集提供配置信息,即便该Web应用程序下面可能有数百个网站集存在。
一个典型的SharePoint 2010服务器场至少有两个Web应用程序,一个是中央管理站点,另外一个开放给普通用户使用。图1-3是某公司的Web应用程序图,该公司将生产环境服务器分成三个Web应用程序,分别提供给员工、合作伙伴及客户使用。
图1-3 Web应用程序规划示例
如前所述,SharePoint 2010扩展IIS网站重要的一点是具有独立的权限认证体系,在图1-3所示的公司里,内联网所在的Web应用程序通过Windows集成认证来控制访问并禁止匿名访问。外联网通过定制的ASP.NET认证提供服务来认证用户(实际使用的是表单认证),外部网则配置为允许匿名访问来让互联网用户访问公司主页。
此外,随着在SharePoint 2010里基于声明的认证模型的引入,使得将认证委托给第三方的应用程序成为可能,例如在上述的例子中,该公司可以在开放匿名访问给外部网访问用户的同时,也允许用户通过Windows Live ID来访问,以提供更多定制的服务,后续将提供相应的例子予以详细说明。
更多信息:一个服务器场允许很多个Web应用程序存在,但是Web应用程序的数量在SharePoint产品设计中有相关限制,在实际生产环境部署中应该按照微软官方推荐来选择最佳实践。
1.4.3 服务应用程序
对应于SharePoint2007的共享服务,SharePoint 2010引入了服务应用程序的概念,在SharePoint 2010里,服务应用程序可以在运行于不同的Web应用程序下,甚至不同的服务器场的不同站点间共享数据。新的服务应用程序架构也使得SharePoint 2010性能得到进一步扩展,因为服务应用程序可以安装在独立于Web前端服务器的专属应用服务器之上。
服务应用程序的一个很重要的特点是它在架构上的解耦,在简单的服务器场配置里,服务应用程序可以安装在Web前端服务器上。在大型的服务器场配置里(如图1-4所示)服务应用程序可以安装在单独的应用程序服务器或者应用程序服务器组里。
图1-4 应用程序服务器组
按照一定的规范可以开发服务应用程序,此处不做赘述,图1-5显示了在企业级SharePoint 2010里常见的服务应用程序。
下面是几个常见的服务应用程序:
商业连接服务(Business Connectivity Service,以下简称BCS):早在SharePoint2007里就引入了商业数据目录(Business Data Catalog,以下简称BDC),BDC常见的一种应用是在SharePoint门户网站里显示外部系统的数据(通过SharePoint Designer 2007可以做到对表数据的映射修改等),开发人员可以通过XML文件定义外部系统和SharePoint的匹配关系,然后通过Web部件在画面里予以显示,外部系统数据也可以通过在列表里配置为一个新添加字段,进一步在搜索里被爬网到。但是BDC没有专门的开发工具,开发起来非常麻烦,而且要通过SharePoint修改外部系统数据也非常麻烦。BCS的推出解决了这一系列问题,开发人员甚至IT人员可以通过SharePoint创建外部内容类型,可以在浏览器里创建外部列表,可以通过Visual Studio做深入开发。
图1-5 常见服务应用程序
- 用户档案服务(User Profile Service):用来管理用户档案、组织档案(SharePoint 2010新功能)、我的站点、社交标签等。
- 搜索服务(Search Service):SharePoint2007里搜索服务和用户档案服务都绑定在共享服务里,但在SharePoint 2010里作为单独的服务来提供。
- 托管元数据服务(Managed Metadata Service):SharePoint 2010里全新推出的服务,此服务配置的元数据可以在所有绑定了此服务的Web应用程序下的所有网站集里访问元数据;此外,还可以通过此服务配置共享内容类型,通过制定某个站点集为集线器站点,在此站点集下创建的内容类型可以通过Timer Job推到所有绑定了此服务的Web应用程序下的所有网站集里。
1.4.4 网站集和网站
网站集是一个数据存储和权限分配的独立单位,网站集可以包含若干个网站,每一个网站集都必须建立在某个Web应用程序下面,但是网站不可以单独建立在Web应用程序下面,必须建立在网站集的下面。
网站集的存在有很多种原因,一个是因为其独立的权限控制体系,每个网站集之间的权限都是独立的,站点集(不要为这个词迷惑,站点集和网站集是同一个概念)管理员拥有网站集的最高权限,他可以在该网站集内创建不同的权限组,创建站点集的时候SharePoint会默认配置三个组,如图1-6所示。
- 网站所有者:拥有略低于站点集管理员的权限。
- 内容贡献者:可以在网站里创建文档库、列表等内容并具有创建和修改文档等权限。
- 访问者:拥有在站点集内只读的用户权限。
图1-6 权限设置
另外一个原因是可以提供站点集别的数据备份和还原,在SharePoint2007里通过stsadm命令,在SharePoint 2010里通过stsadm命令或者Windows PowerShell都可以进行站点集数据的数据备份和还原。顺带提一下,通过前面说到的这些方式可以在创建站点集的时候指定存储的内容数据库,通过浏览器创建站点集的时候SharePoint通过一个叫做roundtrip的算法,也就是从某个Web应用程序下存在的所有内容数据库里一个接着一个地创建,比如创建站点集A的时候存储在第一个内容数据库,站点集B在第二个内容数据库,站点集C在第三个内容数据库……当所有内容数据库都存储有站点集后再新创建的站点集会存储在第一个内容数据库,以此类推。
如图1-7所示的是某公司的站点结构图,实际的情况可能会更复杂。
图1-7 站点结构图
1.4.5 字段类型、网站栏和内容类型
字段类型包括单行文本、多行文本、数字、货币等各种类型,可以将其理解成数据库表的各种字段类型,字段类型可以被添加到列表、文档库等数据存储结构中。字段类型可以扩展,后续章节中会有详细介绍。
通过字段类型可以创建栏,栏可以理解为字段类型的实例,在列表里创建的栏只能供对应的列表使用,在网站集级别创建的栏可以供网站集内所有列表、文档库等使用。
内容类型是网站栏的集合,内容类型可以理解成一个一个的模板,比如员工内容类型就包括员工姓名、生日、邮件地址等网站栏的模板,网站栏在网站集级别创建,并可以单独添加到每一个列表或者文档库。在SharePoint 2010里引入了外部内容类型的概念,在SharePoint Designer里可以创建外部内容类型,将外部系统的数据映射到SharePoint里面来。
SharePoint 2010对字段做了功能上的改进,最突出的两点是增加了对字段值唯一性的设置,以及对字段值进行校验设置的功能。通过唯一性设置可以指定在本列内的值必须唯一,如果添加重复值时浏览器会提示内容重复;通过校验功能可以指定在客户端配置字段值的检验规则,比如要求是小写字母等。
1.SharePont 2010新功能:字段值唯一性设置
在SharePoint2007的版本里有一个缺憾就是——栏值没有唯一性设置,除了系统提供的内部ID字段外所有的栏值都不能唯一,如果要达到唯一控制的目的,必须开发额外的代码,比如通过事件处理器(后续章节会有专门介绍)在用户提交、编辑该栏值的时候予以控制,如图1-8所示。
图1-8 字段唯一性设置
但在SharePoint 2010里,我们可以直接在创建栏的时候指定该栏值的唯一性,这带来了很大的方便。如图1-9所示,我们在任务列表里创建一个单行文本的“UniqueNO”字段,并在创建的时候指定其为“强制唯一值”。单击“确认”按钮,会提示如果选择“强制唯一值”需要在该字段上加索引。
更多信息:图1-8最后一个托管元数据字段类型(Managed Metadata)仅适用于SharePoint Server 2010标准版和企业版,该字段类型可以从和所在Web应用程序的托管元数据服务应用程序里的配置进行交互,获取相关数据予以显示。
添加新栏之后如果我们输入多条数据,后创建的数据UniqueNO值与之前创建的有重复,在保存的时候会提示值重复(如图1-9所示)。但需要注意的是,与数据库表不同,设置为唯一性值的栏并不一定要求值非空,如果没有设置为非空,两条数据UniqueNO值都为空是允许的。
图1-9 值重复错误提示
2.SharePoint 2010新功能:字段值校验
SharePoint 2010在列表级别做的另外一个改善是加入了对字段值的校验功能,而且不仅仅是在字段级别可以对字段的值进行校验,在列表级别也能够对字段值进行校验(关于列表随后就会提到,这里可以将列表理解为数据库里的表,将列表级别校验理解为数据库表的触发器),与SharePoint提供的公式结合起来,前者可以用在对值的内容、长度等的校验,后者可以用在两个字段值的比较等方面。
看一个字段级别校验设置的实例。首先我们创建一个新列,单击“Column Validation”展开设置页,在公式里输入“=LEN(Region)<8”,在错误消息里输入“Please Make sure length is less than 8.”,当输入的Region字段值不符合规则的时候,错误消息将显示在添加或编辑新记录画面里。单击“确定”按钮保存,如图1-10所示。
图1-10 设置字段级别校验
保存成功后,当试图输入一个长度超过8的字符串时,我们设置的错误消息将会在字段下面予以提示,如图1-11所示。
图1-11 字段级别校验错误消息
再来看列表级别设置的例子。单击列表设置进入列表设置页面后,单击“校验设置”链接,如图1-12所示。
图1-12 校验设置链接
在打开的设置画面里我们针对新建的两个日期类型字段Date1和Date2,要求Date1的日期值必须在Date2之后,如果校验出错,提示“Date1 must be after Date2”,单击“确认”按钮保存,如图1-13所示。
图1-13 列表级别校验设置
保存成功后,当我们输入的Date1日期在Date2日期之前会提示如图1-14、图1-15所示的错误信息。有意思的是,这个错误信息不会像之前的字段级别错误信息在字段旁边予以显示,而是在新加或者编辑记录的画面的上部分。
图1-14 Date1日期在Date2日期之前
图1-15 列表级别校验错误提示
更多信息:如果想了解更多关于字段值校验的信息,欢迎通过RSS订阅笔者的博文:http://www.cnblogs.com/johnsonwong/archive/2011/05/27/2059405.html
1.4.6 列表和文档库
列表是SharePoint里用来存储数据的基本结构,列表可以理解为数据库的表,用户可以在列表里面任意添加栏,就如同数据库表的一个列,也可以将已经包含了若干个网站栏的内容类型直接添加到列表里,列表可以同时支持多个内容类型。图1-16就是一个典型的列表,列表里面包括标题(Title)、制造商(Manufacturer)、销售价格(SellingPrice)、审批状态(Approval Status)四个栏,其中标题是创建列表时默认添加的栏(默认栏还包括:创建时间、创建者、修改时间、修改者等),制造商、销售价格、审批状态是创建好列表后添加进去的栏。
建好列表后可以往列表里插入记录,即如同数据库表里一条一条的数据,每条记录都会有之前在列表里添加的所有栏的信息(如果基于内容类型创建的列表记录将只具有对应内容类型的相关栏),每个栏将根据建立栏时的设置,有属性(单行文本、多行文本、数字、货币等)的要求,有内容的要求(非空、唯一性以及其他用户自行定义的校验规则),在很大程度上都非常类似于数据库的表。
在SharePoint里通常可以看到很多种类的列表,比如通知、任务、日历、讨论版、联系人、链接、调查等都是列表的一种。
图1-16 列表
文档库是一种特殊的列表,与列表的主要不同在于文档库的每条记录有且仅有一个文件存在,而列表里可以没有文件或者有若干个文件作为附件存在。文档库或列表都支持版本控制。图1-17就是一个典型的文档库,下面列出的四个栏——类型(Type)、文件名(Name)、修改时间(Modified)、修改者(Modified By)都是默认添加的栏。
图1-17 共享文档库
文档库也有各种呈现形式,比如表单库、图片库、幻灯片库、维基页面库等都是文档库的一种。
更多信息:上图第一列类型里的图标显示以及新图标添加可以通过定制C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\XML下的DOCICON.xml配置文件来实现。
1.SharePoint 2010新功能:文档集(只在标准版及以上)
在SharePoint2007里所有的文档都是直接存在文档库里或者存在于文档库里的某个文件或者子文件夹里,每个文档都具有自己单独的属性。在SharePoint 2010里引入了文档集的概念,文档集指的是一组属性相同的文档,比如销售类、技术类等文档集具有相同的属性特征,只需要维护一套属性即可。
文档集在SharePoint Server 2010标准版及企业版里以功能(feature)的形式提供,需要使用的用户可以在站点设置->站点集功能页面激活“文档集”功能,如图1-18所示。
图1-18 文档集功能
激活以后还需要将文档集作为内容类型添加到相应的文档库里才能使用,如图1-19所示,在“SharePoint 1”这个文档集下面有两个文件且还可以添加更多的文件,而在“SharePoint 1”下面有两个链接“查看所有属性”和“编辑属性”,可以为整个文档集编辑并查看属性。
图1-19 文档集
2.SharePoint 2010新功能:唯一文档ID(只在标准版及以上)
唯一文档ID允许在站点集范围内按照一定的规则给文档编号,并且此编号在站点集范围内唯一,进一步可以通过独立于文件存储位置的统一方式来获取文件。很多企业都按照一定的编码规则来管理文档,而文档又通常分布在不同的文档库里,这个功能的引进会给文档的管理带来方便,不过在笔者接触过的一个案例中,400GB以上的数据要在SharePoint里进行管理,而且文档号要求唯一。由于数据量的限制,必须分成若干个站点集进行存储,如果在下一个版本中,微软能推出在Web应用程序级别统一管理文档号的功能,将更加方便。
言归正传,使用此功能也需要到站点集设置->站点集功能画面激活“文档ID服务”,如图1-20所示。
图1-20 文档ID服务
激活此服务后在站点集设置画面会多出一个连接“文档ID设置”,单击进入,如图1-21所示。
图1-21 文档ID设置
在设置画面里指定文档ID的编码规则,例如图1-22中制定文档ID以“3HVABCD”开头,单击“OK”按钮保存。
图1-22 设置文档ID
配置好后,当上传文档到文档库后会出现新的一列“文档ID”,里面的内容按照我们指定的规则进行顺序取号。
如果鼠标放到相应的ID上,我们会发现这是一个超链接(http://localhost/_layouts/ DocIdRedir.aspx?ID=3HVABCD-1-2),根据SharePoint配置和IE浏览器设置的不同,单击该链接会提示保存或者在IE里打开该文件。通过这种方式我们可以独立于文件真实存储的文档库,直接通过文档ID定位该文档,如图1-23所示。
图1-23 唯一文档ID
更多信息:在实际启用唯一文档ID服务时会遇到一些小的问题,具体的配置可以参考笔者的博客:http://www.cnblogs.com/johnsonwong/archive/2011/05/25/ 2057193.html。
此外,SharePoint Foundation在列表的Lookup字段,跨列表查询以及处于性能考虑的列表Throttling等方面都做了很大改善,在第3章将做详细介绍。