我个人的理解,SharePoint Web 应用程序(SharePoint Web Application)代表的是 SharePoint 网站(集)的物理容器。
SharePoint Web 应用程序需要指定内容数据库、宿主 IIS 应用程序池、应用程序池管理员账号等信息,这些都是 SharePoint 网站(集)的物理容器属性。从这以后(网站集,网站,列表。。。)都是在数据库里面操作,是为逻辑容器。(姑且让我这么区分吧)
所以,像下面这样解释 Web Application 和 Site Collection, Web Site 之间的关系就是比较准确的了:
和
上面第一张图,如果是将 Web Application 画进 Site Collection 那个方框中了,就有点问题了。
顺便说一句,上面图形中只是描述这些对象之间的逻辑关系,并不意味着必须按照这个关系路径来访问这个关系树中的枝叶。你可以直接访问某个列表(List)而无需列表所在站点的访问权限。所以,对于打破了继承关系的这些对象来说,其权限其实是扁平的,并无树状继承一说。
配置 SharePoint Web 应用程序,并不是一件简单的事情。
感谢 lxrc4561200 提供的网址 Web技术网 (SharePoint),大大简化了我整理索引链接的难度:) 这篇 SharePoint 2010管理中心创建Web应用程序 和这篇 SharePoint2010管理中心管理Web应用程序 可以作为创建、设置 SharePoint Web 应用程序的一个很好的开始。
2013-1-3 补充:上面这个网站链接已经打不开,我在博客园找了一篇类似的:SharePoint 2010 使用笔记(应用篇-管理中心-应用程序管理)。原来的 Web技术网内容不错,可惜不知道为什么打不开了。但那个网站也不是没有问题,最大的问题就是:罗列 SharePoint 功能,不讲应用。就好比教你所有 PhotoShop 的菜单命令,但是,你还是创作不出来绚丽的图片作品一样。
毫无疑问,创建新的 SharePoint Web 应用程序的时候,全部接受默认的选项也是可以的。
或者,你也可以面对这么多选项,做出很多“艰难”的决策来对 SharePoint 做更多的了解。
有“经典”和“基于声明”的两种。
“经典”的里面,又可以选身份验证提供程序:NTML 或者 Kerberos。
“基于声明”的就更多了。
有人用 IIS 对“经典”的身份验证做了测试 IIS的各种身份验证详细测试,不过,有点儿含糊的感觉,图少,另外有图解版的,可以对照着看 Windows安全认证是如何进行的?[NTLM篇]、Windows安全认证是如何进行的?[Kerberos篇]。
NTLM 无须额外的配置即可使用,所以,一般体验和个人研究都选择它。
“基于声明”的,原理和 Kerberos 的有点儿像,都引入了 Token Issuer 的角色(SharePoint 拿到验证 Token,还要用 Security Token Service 再转换一次才能使用)。不同的是,声明 Claims 引入了证书签名加密、基于 SAML 协议,适用于非 Windows 系统的互信授权,从而可以跨过企业间的异构界限,实现联合身份验证 Federation。Form Based 身份验证也划入了“基于声明”的行列。
有本书讲这个主题的,叫做 A Guide to Claims-Based Identity and Access Control,原理讲得很好。不过,实际操作指南少,还得靠自己再去找。
再顺便说一句,因为“基于声明”的验证方式出现较晚,Microsoft Office 2010 以前的版本在与其整合应用的时候,会有一个二次登录的问题。(似乎问题是卡在身份验证服务器提供的登录转向页面上,不过我尚未深入研究)
微软有个帮助你规划应用的图 Design Sample: Corporate Portal with Claims-based Authentication。
配置 Form Based 身份验证: Sharepoint 2010 Form 身份认证的实现(基于SQL) 和 Configuring Forms Based Authentication for SharePoint 2010 using IIS7。
配置 Federation 身份验证:端对端配置 SharePoint 2010 和 ADFS v2 版本。配置到最后,会用到配置“信任”:SharePoint 2010管理中心管理信任。
SharePoint 2010 无须扩展应用程序即可同时支持以上这些身份验证方式并存,麻烦的是,登录时会多出来一个选择验证方式的界面。当然,这很“讨厌”,于是有人看不下去了,Multiple Authentication Methods in SharePoint 2010、SharePoint 2010: transparent login with mixed authentication。
你想弄一个 http://www.adventureworks.com 这样的网站的话,就指定主机头值。但是,按照我的印象,还是在 SharePoint2010更改网站的URL(1)、SharePoint2010更改网站的URL(2) 里面设置更加方便。
端口,别和默认端口(21 什么的)冲突即可。HTTPS 协议默认 443 端口,如果已经占用了,就换别的。不想换?!那就申请通配符证书吧。
建议挑一个非域管理员、非本机管理员的账号试试,会很好玩的。用这个账号登录网站,就会显示“系统账户”或者“System Account”。
这个名称,其实无所谓,不重名即可。不过,我喜欢在 WSS_Content 后面加上 “_端口”,看上去好区分。
一个 Web Application 里面可以使用多个内容数据库,但是,一个网站集(site collection)只能存在于一个内容数据库中。你可以将不同内容的网站集放到不同的内容数据库,这样对于改进性能和提升管理水平很有帮助。SharePoint 2010 默认是把新创建的网站集放在最新创建的那个内容数据库中,这样显然是不方便的,在数据库之间移动网站集 提供了按照我们本来的意思安排网站集和内容数据库的方法。
即 SharePoint Service Application,姑且可以看做是 SharePoint 的 Web 版公共程序库,提供各种服务供各个 Web 应用调用。
没把握的话,全部选上,否则在学习、测试的时候会有各种各样的错误。
熟悉的话,你就麻烦了,这里又牵涉到一个服务应用程序规划的问题,取决于服务器场中每台 SharePoint Instance 的角色定位问题。
微软有个图可以帮助你决定(当然,你也可以被这个图扰乱),到底要怎么样分配 SharePoint Web 应用程序关联的服务应用程序 Cross-farm Services in SharePoint 2010 Products。单机环境玩不了这个 :(
上面这些决策,显然不是(纯)程序员或者网站管理员、网站用户应该(以及能够)考虑的,这些明显是给另外一拨人去思考的。所以呢,单枪匹马的搞 SharePoint 项目的时代,不说已经过去,大概从来就没有到来过吧。
这些问题,个人在单机上面搞研究是不会遇到的,所以,弄个拟真的环境很有必要(见本文第一篇里面关于 安装和配置 的部分)。不仅仅是 SharePoint,其它的技术平台都应该会有这个问题。
联系客服