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





本文转自 kaneb0y 51CTO博客,原文链接:http://blog.51cto.com/kaneboy/391411,如需转载请自行联系原作者

目录
打赏
0
相关文章
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
云卓越架构:云上网络稳定性建设和应用稳定性治理最佳实践
本文介绍了云上网络稳定性体系建设的关键内容,包括面向失败的架构设计、可观测性与应急恢复、客户案例及阿里巴巴的核心电商架构演进。首先强调了网络稳定性的挑战及其应对策略,如责任共担模型和冗余设计。接着详细探讨了多可用区部署、弹性架构规划及跨地域容灾设计的最佳实践,特别是阿里云的产品和技术如何助力实现高可用性和快速故障恢复。最后通过具体案例展示了秒级故障转移的效果,以及同城多活架构下的实际应用。这些措施共同确保了业务在面对网络故障时的持续稳定运行。
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
68 11
深入理解微服务架构及其在现代软件开发中的应用
深入理解微服务架构及其在现代软件开发中的应用
95 32
深入理解微服务架构及其在现代应用开发中的应用
深入理解微服务架构及其在现代应用开发中的应用
40 4
深入理解容器化技术及其在微服务架构中的应用
深入理解容器化技术及其在微服务架构中的应用
81 1
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
67 3
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####

热门文章

最新文章