RSS

Monthly Archives: 九月 2010

ASP.NET Security Vulnerability对SharePoint的影响

嗯,是的,最近闹得沸沸扬扬的ASP.NET Security Vulnerability同样会影响SharePoint Server。如果你手头有正在运行的SharePoint生产服务器(特别是服务器是用来提供Internet Web网站服务的情况),请确保阅读了这篇文章。Erucy已经写了一篇专门的文章讲述SharePoint 2007/2010的workaround

 

Posted by on 2010/09/27 in 未分类

1 Comment

为SharePoint网站创建自定义导航菜单

相信不少人都希望把SharePoint网站内置的那个顶部导航菜单,换成自己希望的样式。由于SharePoint 2007/2010的网站导航基本上基于标准的ASP.NET SiteMap模型,所以只要你对ASP.NET SiteMap有一些了解,就能创建一个自定义的导航菜单。

在开始之前,让我们先从网上随便找一个样子比较cool的菜单控件。在下面的示例中,我会选择使用Smooth Navigation Menu这个jQuery控件,来渲染出SharePoint网站的顶部导航菜单。将Smooth Navigation Menu控件相关的.js、.css、.gif文件统统下载下来,我们将把它们都放进SharePoint项目中。

打开Visual Studio 2010,创建一个SharePoint 2010项目(我最喜欢的项目模板是“空白SharePoint项目”),在项目中添加一个映射文件夹,来存放Smooth Navigation Menu控件所需的所有文件。我选择在Layouts文件夹中创建一个SmoothNavMenu子文件夹来存放这些文件,如下图所示:

image

接下来开始创建自定义导航菜单。实际上,我们有很多方法可以用来创建自定义导航菜单。例如,我们可以选择以自定义控件的方式,来创建一个自定义导航菜单。由于在这个示例中,我们使用的是一个jQuery插件来实现界面渲染,所以选择以用户控件(.ascx)的方式来创建自定义导航菜单,似乎是一个更好的选择。

在Visual Studio 2010中,向项目中添加一个用户控件,为其命名为SmoothNavMenu.ascx。

image

然后打开新建的这个SmoothNavMenu.ascx用户控件,为其填充内容。

image

SmoothNavMenu.ascx中大部分的内容,都是按照Smooth Navigation Menu控件的要求,添加所需的.css和.js引用。从第20行到第34行的JavaScript代码,作用是在页面载入之后,将Smooth Navigation Menu初始化。具体用法请参考Smooth Navigation Menu的网站

第16行到第18行,我们将一个Literal控件放到一个<div>元素中。在用户控件的后台代码中,会查询当前网站的顶部导航结构,并生成相应的html元素,然后通过这个Literal控件填充进用户控件。<div>元素的声明同样是Smooth Navigation Menu的要求。Smooth Navigation Menu会根据Literal控件所输出的html元素,渲染出导航菜单。

接着打开用户控件SmoothNavMenu.ascx的后台代码文件,SmoothNavMenu.ascx.cs。在用户控件的后台代码中,我们需要获得当前网站的顶部导航结构,并根据其结构生成html元素。获得网站顶部导航结构的代码是:

image

然后在Page_Load事件中,我们调用此方法来得到网站顶部导航结构,然后通过BuildMenuContent方法(此方法的具体实现代码略)生成Smooth Navigation Menu所需的html元素,然后将这些html元素通过Literal控件的Text属性填充到用户控件界面上。

image

好了,到这里,我们已经把自定义的导航菜单创建好了。但是,如果你想要在网站上使用它,还需要把它放到网站的母版页上面去,同时删除母版页上那个默认的导航菜单控件。要做到这些,你可以使用SharePoint Designer,打开网站,找到母版页,然后蛮干。或者使用更好的方法,在项目中创建一个新的母版页,让新母版页上使用我们创建的自定义导航菜单,然后使网站使用新的母版页。

在Visual Studio 2010中,向项目中添加一个“模块”,把VS2010自动创建的那个Sample.txt文件改名为v4_SmoothNavMenu.master,然后把内容替换为SharePoint 2010网站默认使用的v4.master母版页的内容(直接在SharePoint Designer中找到v4.master,打开它,全选所有html内容,复制,然后到VS2010中打开v4_SmoothNavMenu.master,粘贴)。

image

由于我们需要把v4_SmoothNavMenu.master文件放进网站的母版页样式库里面,所以打开Elements.xml,编辑其内容,修改<Module>标签的Url属性为“_catalogs/masterpage”,修改<File>标签的Type属性为“GhostableInLibrary”:

image

现在我们来修改v4_SmoothNavMenu.master这个母版页文件,从Visual Studio 2010中打开它,首先在头部区域,添加一个<%@ Register %>标签,将之前创建的那个用户控件注册到页面上:

image

然后搜索母版页中一个ID为“PlaceHolderHorizontalNav”的ContentPlaceHolder控件,将里面的那个AspMenu控件删除掉(它就是母版页上原本用来显示顶部导航菜单的控件),然后将我们创建的用户控件添加到这个地方:

image

母版页就成功改好了!我们希望网站的管理员可以通过激活或停用一个Feature,就相应的启用或停用这个新建的母版页。所以,在Visual Studio 2010中,打开Features文件夹,将VS2010自动创建的Feature1改名为SmoothNavMenuFeature,双击它,在Feature设计器界面上为这个Feature添加更友好的说明信息:

image

在SmoothNavMenuFeature上点击鼠标右键,选择“添加事件接收器”,然后在生成的代码文件中,取消FeatureActivated和FeatureDeactivating方法的注释,并添加如下代码。简单来说,这些代码的作用是在管理员激活这个功能时,自动为网站应用新的母版页,并在管理员停用功能时,恢复网站原有的母版页。

image

大功告成!编译,部署,激活“Smooth Navigation Menu 导航菜单”功能,回到网站首页,应该就能看到网站的顶部导航菜单已经被替换成了我们创建的这个自定义导航菜单。

通过“网站设置 – 顶部链接栏”管理页面,你可以为顶部导航添加新的节点。但是,如果这个SharePoint网站不是一个发布网站,通过内置的“网站设置 – 顶部链接栏”管理页面是没法直接创建二级菜单的。嗯,实际上,这里有一个小技巧,通过直接在地址栏输入“http://网站url/_layouts/AreaNavigationSettings.aspx”,就能打开原本只有发布网站才能使用的导航设置页面,其中的“全局导航”就是网站的顶部导航,在这里是可以直接向“全局导航”添加二级菜单的:

image 

然后,下面就是你可以看到的效果,这个菜单就是通过我们在上面所创建的自定义导航菜单所渲染出来的:

image

虽然这篇文章是以SharePoint 2010为基础进行演示,但其中绝大部分内容是可以工作在SharePoint 2007网站中的(当然肯定没有Visual Studio 2010如此之好的工具支持)。另外,对于导航中的权限、访问群组,并没有在这个示例中有所体现。

 

Posted by on 2010/09/27 in 未分类

3 Comments

SharePoint 2010 服务应用程序(Service Application)架构(3)

一个服务应用程序除了可以为服务器场内的网站提供服务之外,还能发布给其他服务器场,为其他服务器场中的SharePoint网站提供服务。比如,如果企业中存在着多个服务器场,它们都需要某个服务器场中的“企业全局元数据”服务应用程序中所存储的公用元数据,那么管理员可以将这个服务器场中的“企业全局元数据”服务应用程序,发布给企业中所有SharePoint 2010服务器场使用。下图显示了在SharePoint 2010管理中心发布一个服务应用程序时的界面。

image

SharePoint 2010已经包含了一组内置的服务应用程序,它们为SharePoint 2010网站提供了诸多后端服务,是组成SharePoint 2010的重要组成部分。下面的表格列出了主要的SharePoint 2010内置服务应用程序,以及它们的简要说明。

服务应用程序

描述

是否存储数据

是否可发布

SharePoint Foundation 2010

SharePoint Server 2010 标准版

SharePoint Server 2010 企业版

Access Services

在浏览器中查看与编辑Microsoft Access 2010数据库。

仅缓存数据

不包含

不包含

包含

业务数据连接

访问和修改后端业务系统的数据。

使用数据库存储

包含

包含

包含

Excel Services

在浏览器中查看Excel文件。

仅缓存数据

不包含

不包含

包含

Managed Metadata Service

提供了对企业级托管元数据的存储和管理,同时可以在网站集之间共享内容类型。

使用数据库存储

不包含

包含

包含

PerformancePoint

提供了PerformancePoint Services所包含的BI报表功能。

仅缓存数据

不包含

不包含

包含

PowerPoint

在浏览器中查看、编辑和广播PowerPoint幻灯片。

仅缓存数据

不包含

不包含

包含

搜索

提供了SharePoint 2010的企业级搜索功能。

使用数据库存储

不包含

包含

包含

安全存储服务

用来存储访问其他应用系统的用户凭证信息,这些凭证信息可用于SSO单点登录场景。

使用数据库存储

不包含

包含

包含

状态服务

暂时存储用户的会话(Session)数据。

使用数据库存储

不包含

包含

包含

使用率和运行状况数据集

收集用户使用率和运行状况数据,提供相关的数据报表。

使用数据库存储

包含

包含

包含

User Profile

为“我的网站”、配置文件页面、社会化标签和其他社会化功能提供支持。

使用数据库存储

不包含

包含

包含

Visio Graphics Service

在浏览器中查看Microsoft Visio图形。

仅缓存数据

不包含

不包含

包含

Web分析

提供Web Service接口。

不存储

不包含

不包含

不包含

Word Automation Services

进行批量自动化文档转换操作。

仅缓存数据

不包含

不包含

包含

 

在上个版本的SharePoint中,只有Office SharePoint Server 2007才具有共享服务提供程序架构,而Windows SharePoint Services 3.0是没有使用共享服务提供程序架构的。但是对于SharePoint 2010,无论是SharePoint Foundation 2010,还是SharePoint Server 2010,都使用了统一的服务应用程序架构。但SharePoint Foundation 2010、SharePoint Server 2010标准版和SharePoint Server 2010企业版所内置的服务应用程序数量是不同的。

除了上面的表格所列出的服务应用程序之外,在为SharePoint 2010系统安装了额外的Office Web Applications和Project Server组件时,它们都会向服务器场中注册更多的服务应用程序。

从上面对SharePoint 2010服务应用程序架构的讨论中,我们可以了解到,服务应用程序架构比上个版本的共享服务提供程序提供了更好的灵活性,并构建起一个强大的后端服务架构。通过服务与服务应用程序,SharePoint 2010将前端的网站与后端的服务有效的进行了分离。

最后需要提醒的是,并非所有SharePoint 2010服务都是基于服务应用程序架构来构建。例如, “Microsoft SharePoint Foundation 沙盒代码服务”服务就并非基于服务应用程序架构,实际上,它使用了一个名为“SPUserCodeV4”的Windows服务来实现自己的功能。

 

Posted by on 2010/09/26 in 未分类

Leave a comment

SharePoint 2010 服务应用程序(Service Application)架构(2)

第(1)篇文章中,回顾了一下SharePoint 2007中的Shared Services Provider(SSP)架构。从这篇开始,将开始讲述SharePoint 2010中的服务应用程序架构。

在SharePoint 2010中,微软重新设计了共享服务提供程序架构,将其改进成了服务应用程序架构。相比共享服务提供程序架构,服务应用程序架构有更好的灵活性。如果一个SharePoint 2010服务实现了服务应用程序框架,那么管理员就可以根据需要,在服务器场中创建一个相应的服务应用程序,来提供此服务。当然,管理员也可以为一个SharePoint 2010服务,创建多个服务应用程序。每个服务应用程序可以有不同的设置,甚至可以有不同的数据库,用来存放服务应用程序单独的数据。这也就是一个服务应用程序也被称为服务的一个可配置服务器场实例(Configured Farm-Scoped Instantiation)的原因。

服务应用程序运行在服务器场中的应用服务器上,它们通常需要被运行在前端服务器上的组件,例如Web部件,来调用。前端服务器上的组件是透过一种叫做服务应用程序代理的中间组件,来调用服务应用程序的。所以,如果服务应用程序需要能够被调用,它就需要有一个配套的服务应用程序代理。在默认的设置中,所有服务应用程序代理都托管在一个名为“SharePoint Web Services”的IIS Web网站中。打开SharePoint 2010应用服务器上的IIS管理器,就能看到这个IIS Web网站。下图展示了“SharePoint Web Services”IIS Web网站,它的每一个虚拟目录,都代表了一个发布出来的服务应用程序代理。

image

管理员在SharePoint 2010管理中心网站,打开“管理服务应用程序”页面,就能看到当前服务器场中所有的服务应用程序。

image

我们用实际的例子来进一步解释服务应用程序架构的概念。SharePoint 2010中内置了一个名为“Managed Metadata Service”的服务,它可以存储和管理一组公用的元数据,在SharePoint网站中的列表项可以使用这些元数据,来对列表项进行标识。“Managed Metadata Service”服务实现了服务应用程序框架。管理员可以在服务器场中,新建一个类型为“Managed Metadata Service”的服务应用程序,并将其命名为“企业全局元数据”。下图展示了管理员新建这个服务应用程序的界面。

image

在下图中可以看到已经创建完成的“企业全局元数据”服务应用程序。在这个服务应用程序下方,同时还有一个同样名为“企业全局元数据”的条目,它就是在管理员创建“企业全局元数据”服务应用程序的同时,自动被创建出来的服务应用程序代理。前端服务器上的组件,就是通过这个代理,来调用到“企业全局元数据”服务应用程序所提供的功能的。

image

如果要让一个SharePoint网站能使用由服务应用程序提供的服务,需要将SharePoint网站所属的Web应用程序,与服务应用程序的代理进行关联。由于服务器场中可能存在许多的服务应用程序代理,为了方便管理,SharePoint 2010将服务应用程序代理按照分组的方式进行来管理。然后,一个Web应用程序可以选择关联到一个服务应用程序代理组,这样就一次性的同时关联到了这个组所包含的所有服务应用程序。

SharePoint 2010默认包含了一个名称为“默认”的服务应用程序代理组,服务器场中所有的服务应用程序代理,默认都位于这个代理组里面,同时所有Web应用程序都与“默认”代理组关联了起来。如果没有特殊的需求,这个默认配置已经可以满足企业的需求了。

下图显示了一个典型的服务应用程序逻辑架构。可以看到,服务器场中所有的服务应用程序代理(包括“企业全局元数据”),都包含在“默认”代理组中,服务器场中也只有这一个代理组。服务器场中的三个Web应用程序,都与“默认”代理组进行关联,所以,它们都能访问到“默认”代理组所对应的服务应用程序所提供的服务。如果“企业全局元数据”服务应用程序中存储了企业中的所有重要元数据,那么三个Web应用程序所包含的所有SharePoint网站,就都可以使用这些由“企业全局元数据”所存储的元数据了。

image

如果这个时候,企业中的财务部门提出了一个新的需求,要求对于一组特定的财务元数据,进行更严格的安全性保护,除了财务部门的SharePoint网站之外,其他网站都严禁访问到这些财务元数据。为了保证足够高的安全性,管理员可以选择再创建一个类型为“Managed Metadata Service”的服务应用程序,取名为“企业财务元数据”,然后使用这个单独的服务应用程序来存储和管理财务元数据。

下图显示了管理员创建了“企业财务元数据”服务应用程序之后,在SharePoint 2010管理中心的“管理服务应用程序”页面中,可以看到这两个用来提供托管元数据服务的服务应用程序,以及它们各自的服务应用程序代理。

image

下图显示了更新后的服务器场服务应用程序逻辑架构图。从图上可以看出,服务器中新增了一个名为“企业财务元数据”的服务应用程序,而且它运行在一个单独的应用程序池中,以实现更高的安全性。除了原本的“默认”服务应用程序代理组之外,服务器场中还添加了一个“财务”代理组,这两个代理组所包含的服务应用程序实际上大部分都是重合的,不同的仅仅是一个包含了“企业全局元数据”服务应用程序,而另一个则包含了“企业财务元数据”服务应用程序。服务器场中包含了三个Web应用程序,其中前两个与“默认”代理组进行了关联,而第三个Web应用程序则是和“财务”代理组进行了关联。这样,只有包含在第三个Web应用程序中的SharePoint网站,才可能访问和使用由“企业财务元数据”服务应用程序所存储的财务元数据,而其他SharePoint网站则只能使用由“企业全局元数据”服务应用程序所存储的元数据。

image

(待续)

 

Posted by on 2010/09/14 in 未分类

Leave a comment

SharePoint 2010 服务应用程序(Service Application)架构(1)

SharePoint 2010认证考试出来之后,去把几个考试都考了一遍:70-57370-57670-66770-668。如果你正有计划也去参加这几门认证考试,我可以提供的建议是:不要在11:30开始考70-668,否则到12:00吃饭的时候,你很可能还没有答完题目。70-668包含不少场景题,也就是给一个场景,包含各种Business Requirements、Technical Requirements、Recovery Requirements之类,然后基于此场景选出最佳方案。阅读并理解场景会花费不少时间。

嗯,言归正传。如果你曾经使用过SharePoint 2007,一定知道在SharePoint 2007中有一个叫做“共享服务提供程序”(Shared Services Provider,简称SSP)的东东。SharePoint 2010对SSP架构进行了优化,设计了一个更灵活、更有扩展性的架构:服务应用程序(Service Application)架构。这几篇博文将围绕Service Application,仔细讲讲这个东东。由于服务应用程序是SharePoint 2010一个非常基础的架构,无论你是Developer,或是IT Pro,都需要对它有足够的了解。

“服务”这个词是一个比较通用的词汇,它可以用在很多场合,在每个场合中,它的含义可能都不会相同。简单来说,当我们使用 服务这个词汇的时候,通常是用来描述某个在后台运行的,可以进行某种运算,或是提供某些数据,能够让它的使用者调用的一组代码。服务的概念与应用程序是相对的,我们通常使用应用程序这个词汇,来描述一个拥有用户界面,用户能在这个界面上进行诸如点击、浏览等操作,大部分情况下可能是运行在客户端计算机里面的一组代码。一个服务的使用者可能是另一个服务或一个应用程序。

上面是对服务这个通用词汇的解释,这个解释在大部分场景中都是适用的。接下来,让我们来了解SharePoint 2010系统中的服务。

SharePoint 2010将其所包含的用来提供某种功能的后端组件,也称为服务。例如,SharePoint 2010包含了Excel Services服务,这是一个能将Excel文档的内容渲染成HTML页面的后台组件。SharePoint 2010的服务运行在SharePoint服务器场中的服务器上。每台服务器,都可能运行了一个或多个SharePoint服务。大部分SharePoint服务,也都可以运行在一个或多个服务器上。

大部分的SharePoint 2010服务,都是运行在服务器场中的应用服务器上,但有些服务也是可以运行在前端Web服务器上的。实际上,SharePoint 2010系统中有一个名为“Microsoft SharePoint Foundation Web 应用程序”的服务,专门用来描述处理用户HTTP请求的前端Web服务,凡是启用了这个服务的物理服务器,就被SharePoint 2010系统识别为前端Web服务器。另外,还有一个名为“Microsoft SharePoint Foundation 数据库”的服务,是专门用来标识SQL Server数据库服务的,它并不代表任何实质上的SharePoint 2010服务,仅仅用来标识在哪些服务器上运行着SQL Server数据库。

在SharePoint 2010管理中心的“服务器上的服务”页面中,管理员可以查看服务器场中的每台服务器上,运行了哪些服务。管理员可以通过这个页面,在每台服务器上启动或停止某个服务。如下图所示。

image

有一部分SharePoint 2010服务,使用了SharePoint 2010的服务应用程序框架(Service Application Framework)来构建。如果一个服务基于服务应用程序框架,那么这个服务可以包含多个可配置服务器场实例(Configured Farm-Scoped Instantiation,简称CFSI)。每一个CFSI被称为一个服务应用程序(Service Application)。服务应用程序运行在服务器场中的应用服务器上,一个服务应用程序可以被服务器场中的多个网站所使用,有一些服务应用程序甚至可以被跨服务器场调用。

为什么在SharePoint 2010中要设计出服务应用程序这套架构呢?其主要原因就在于,在一个大型的企业级系统中,系统中的各种后端服务,必须从网站中解耦了出来。有一些功能,是每个网站都必须要使用,例如,每个网站都需要具有搜索功能,让网站的用户能够搜索内容和数据。如果搜索功能与网站直接耦合在一起,那么每个网站就都会有自己的搜索服务。这不仅增加了整个系统的设计难度,还会造成不必要的系统资源浪费。所以,必然设计出要有某种架构,能将一组所有网站都需要用到的公用服务,从网站中解耦出来。系统中所有的公用服务,都由一个集中的“资源池”来进行提供,而网站只需要存储其自己的数据和内容。当网站需要为网站用户提供某项功能时,网站可以直接调用由集中的服务“资源池”所提供的相应服务。有了这样的架构,不但减少了整体的资源消耗,而且可以让开发人员更容易的向整个系统中添加新的服务。

在Office SharePoint Server 2007中,这个架构被设计成共享服务提供程序(Shared Services Provider,简称为SSP)。Office SharePoint Server 2007中的共享服务,包括企业级搜索、业务数据目录(Business Data Catalog)、Excel Services、用户配置文件(User Profile)等等,都由共享服务提供程序,提供给各个SharePoint网站。值得一提的是,虽然在大部分Office SharePoint Server 2007系统中,只需要为整个系统创建一个共享服务提供程序,但如果有需要,管理员是可以在系统中创建多个共享服务提供程序的。每个共享服务提供程序可以分别提供不同的服务,或是为不同的网站提供服务。

下图是取自微软公司《Office SharePoint Server 2007 的规划和体系结构》在线文档中的一个共享服务提供程序架构示意图。从图中可以看到,整个服务器场中包含了两个共享服务提供程序,其中第一个为“Web应用程序1”和“Web应用程序2”所包含的SharePoint网站提供服务,另外一个为“Web应用程序3”所包含的SharePoint网站提供服务。

image

只所以在一个服务器场中创建两个(或更多)共享服务提供程序,可能是出于性能的考虑,也可能是出于功能分割的考虑。比如,在上图所示的服务器场中,有可能“Web应用程序3”所包含的SharePoint网站并不需要所有的共享服务,它们可能仅仅需要Excel Services服务,而不需要其他的诸如搜索、用户配置文件等服务。所以,在服务器场中新建一个单独的共享服务提供程序,配置此共享服务

 

Posted by on 2010/09/07 in 未分类

Leave a comment