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,如需转载请自行联系原作者

目录
相关文章
|
18天前
|
监控 Go API
Go语言在微服务架构中的应用实践
在微服务架构的浪潮中,Go语言以其简洁、高效和并发处理能力脱颖而出,成为构建微服务的理想选择。本文将探讨Go语言在微服务架构中的应用实践,包括Go语言的特性如何适应微服务架构的需求,以及在实际开发中如何利用Go语言的特性来提高服务的性能和可维护性。我们将通过一个具体的案例分析,展示Go语言在微服务开发中的优势,并讨论在实际应用中可能遇到的挑战和解决方案。
|
18天前
|
网络协议 数据挖掘 5G
适用于金融和交易应用的低延迟网络:技术、架构与应用
适用于金融和交易应用的低延迟网络:技术、架构与应用
44 5
|
19天前
|
Go 数据处理 API
Go语言在微服务架构中的应用与优势
本文摘要采用问答形式,以期提供更直接的信息获取方式。 Q1: 为什么选择Go语言进行微服务开发? A1: Go语言的并发模型、简洁的语法和高效的编译速度使其成为微服务架构的理想选择。 Q2: Go语言在微服务架构中有哪些优势? A2: 主要优势包括高性能、高并发处理能力、简洁的代码和强大的标准库。 Q3: 文章将如何展示Go语言在微服务中的应用? A3: 通过对比其他语言和展示Go语言在实际项目中的应用案例,来说明其在微服务架构中的优势。
|
17天前
|
监控 持续交付 Docker
Docker 容器化部署在微服务架构中的应用有哪些?
Docker 容器化部署在微服务架构中的应用有哪些?
|
17天前
|
监控 持续交付 Docker
Docker容器化部署在微服务架构中的应用
Docker容器化部署在微服务架构中的应用
|
25天前
|
机器学习/深度学习 人工智能 自然语言处理
医疗行业的语音识别技术解析:AI多模态能力平台的应用与架构
AI多模态能力平台通过语音识别技术,实现实时转录医患对话,自动生成结构化数据,提高医疗效率。平台具备强大的环境降噪、语音分离及自然语言处理能力,支持与医院系统无缝集成,广泛应用于门诊记录、多学科会诊和急诊场景,显著提升工作效率和数据准确性。
|
6天前
|
监控 持续交付 API
深入理解微服务架构及其在现代软件开发中的应用
深入理解微服务架构及其在现代软件开发中的应用
13 0
|
17天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
15天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
16天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
35 1
服务架构的演进:从单体到微服务的探索之旅