面向服务的体系架构

合集下载

面向服务架构的微服务治理体系结构

面向服务架构的微服务治理体系结构

面向服务架构的微服务治理体系结构一、面向服务架构与微服务概述面向服务架构(Service-Oriented Architecture,SOA)是一种设计模式,它将应用程序的不同功能模块化成的服务,这些服务可以被不同的客户端通过定义良好的接口和协议进行调用。

微服务(Microservices)是一种将应用程序作为一套小服务的设计方法,每个服务运行在其的进程中,并通常围绕特定业务能力进行构建,可以地进行部署、扩展和更新。

1.1 面向服务架构的核心概念面向服务架构的核心概念包括服务的发现、组合、编排和治理。

服务发现允许客户端找到可用的服务;服务组合是将多个服务组合成新的服务;服务编排则是定义服务之间的调用顺序和逻辑;服务治理则是确保服务的质量和性能。

1.2 微服务架构的特点微服务架构具有以下特点:去中心化治理、分布式数据管理、业务能力驱动、技术多样性、部署和扩展、持续交付和自动化运维。

二、微服务治理体系结构的设计原则微服务治理体系结构的设计原则是确保微服务架构的可维护性、可扩展性和可靠性。

这些原则包括服务的标准化、服务的发现与注册、服务的配置管理、服务的监控与日志、服务的安全性、服务的容错与弹性设计。

2.1 服务的标准化服务的标准化是确保服务之间能够无缝交互的基础。

它涉及到定义统一的服务接口规范、数据格式和通信协议。

2.2 服务的发现与注册服务发现机制允许服务消费者在运行时发现服务提供者。

服务注册中心是服务发现的关键组件,它维护着服务实例的列表和状态。

2.3 服务的配置管理服务配置管理是集中管理服务配置信息的过程,包括环境配置、服务依赖和参数设置等。

2.4 服务的监控与日志服务监控提供了对服务运行状态的实时洞察,而日志记录则为问题诊断和性能分析提供了必要的信息。

2.5 服务的安全性服务的安全性涉及到认证、授权、数据加密和安全通信等方面,确保服务交互的安全性。

2.6 服务的容错与弹性设计服务的容错与弹性设计确保了服务在面对异常和故障时能够保持稳定运行,包括服务降级、熔断和自动恢复等机制。

面向服务体系架构

面向服务体系架构

VS
概念
SOA采用分布式系统架构,将应用程序的 不同功能单元(即服务)定义为独立的、 可复用的软件组件,并通过标准的接口( 如REST、SOAP等)与其他服务进行通信 。这种架构使得应用程序能够灵活地适应 业务需求的变化,提高系统的可维护性和 可扩展性。
面向服务体系架构的价值
提高业务灵活性
SOA使得业务功能能够以服务的形式进行封装和 重用,从而加快了业务开发和部署的速度,提高 了业务的灵活性和响应能力。
负载均衡
通过负载均衡技术,确保服务在高负载情 况下仍能正常运行,防止拒绝服务攻击。
面向服务体系架构的安全管理实践
制定安全策略
根据业务需求和安全风险,制定相 应的安全策略和规章制度。
安全培训
对开发人员和管理人员进行安全培 训,提高安全意识和技能。
安全测试
在服务开发过程中,进行安全测试 ,确保服务的安全性。
服务滥用
数据泄露
拒绝服务攻击
跨站脚本攻击
由于SOA的松散耦合和开放性, 服务可能被滥用,如未经授权地 访问或恶意攻击,导致数据泄露 或系统崩溃。
在SOA架构中,数据需要在多个 服务之间共享和传输,这增加了 数据泄露的风险。
攻击者可能通过发送大量无效请 求,使服务超负荷运行,从而导 致合法用户无法访问服务。
案例三
• 总结词:医疗卫生行业通过构建面向服务的体系架构,实现医疗资源的共享和业务协同。 • 详细描述 • 医疗卫生行业面临医疗资源紧张、信息孤岛等问题,需要实现医疗资源的共享和业务协同。 • 服务封装:将医疗资源封装为服务,如医疗资讯、病历管理、药品管理等。 • 服务注册与发现:通过服务注册中心和服务发现机制,实现服务的动态发现和调用。 • 医疗协作:通过构建医疗协作平台,实现跨科室、跨医院的医疗协作。 • 数据共享:构建数据共享平台,实现医疗数据的共享和分析,支持数据驱动的决策。

soa的架构层次

soa的架构层次

SOA的架构层次面向服务的架构(SOA)是一种灵活、松耦合的系统设计方法,它将应用程序的不同功能单元(称为“服务”)通过这些服务之间定义良好的接口和契约联系起来。

这种方法使得系统中的服务可以以一种统一和通用的方式进行交互,从而实现了系统的高内聚、低耦合。

本文将深入探讨SOA的架构层次,分析其各个组成部分及其在系统设计和实现中的作用。

一、服务层服务层是SOA架构的核心,它包含了一组可复用的、粗粒度的服务。

这些服务是业务逻辑的封装,具有明确的接口定义,可以独立部署和升级。

服务层的设计需要遵循一定的原则,如服务的无状态性、服务的自治性、服务的可发现性等。

这些原则保证了服务的可靠性、可维护性和可扩展性。

二、服务注册与发现层服务注册与发现层负责服务的注册、查找和管理。

当一个新的服务被创建并部署到系统中时,它需要在服务注册中心进行注册,将自己的接口定义、访问地址等信息发布到注册中心。

其他服务或客户端可以通过服务发现机制在注册中心查找所需的服务,并获取其访问信息。

这一层为系统提供了动态的服务绑定能力,使得服务之间的依赖关系更加灵活和可扩展。

三、传输层传输层负责数据的传输和通信。

在SOA架构中,服务之间的通信通常基于开放的标准协议,如HTTP、SOAP、REST等。

这些协议保证了服务之间的互操作性和跨平台性。

传输层还需要处理诸如消息格式转换、加密解密、压缩解压缩等底层细节,以确保数据的完整性和安全性。

四、业务流程层业务流程层负责将服务组合成业务流程。

一个业务流程可能涉及多个服务的协同工作,以完成某个具体的业务目标。

业务流程层通过编排和协调这些服务,实现了业务流程的自动化和智能化。

此外,业务流程层还可以根据业务需求对服务进行动态调整和优化,以提高系统的响应速度和资源利用率。

五、表示层表示层是系统的用户界面,负责与用户进行交互。

在SOA架构中,表示层可以通过调用服务层提供的服务来获取数据并进行展示。

由于服务层提供了统一的接口和数据格式,表示层可以更加灵活地设计和实现用户界面,以满足不同用户的需求和偏好。

面向服务的软件体系结构

面向服务的软件体系结构
6
面向服务的软件体系结构
SOA本身应该是“如何将软件组织在一起”的抽象概念。它 依赖于用 XML 和 Web 服务实现并以软件的形式存在的更加具体的 观念和技术。此外,它还需要安全性、策略管理、可靠消息传递以 及会计系统的支持,从而有效地工作。您还可以通过分布式事务处 理和分布式软件状态管理来进一步地改善它。
9
面向服务的软件体系结构
利用SOA的好处不仅仅在于它是一个软件开发流程,而 且还是一个业务开发流程。采用SOA有四个层次,您的实现可 以跨越从创建特定的软件服务到将您的业务模型全面转换到按 需系统的过程。
10
面向服务的软件体系结构
第一个层次是最简单的,因为它只需创建单独的服务。 在第二个层次中,您不仅可以创建服务,而且可以开始 将业务功能集成到SOA中。这涉及多个层次的集成,其中包括 应用程序集成、信息集成、流程集成和整个系统的集成。 第三个层次涉及将您的企业IT基础设施转换到 SOA模型, 而采用SOA的第四个层次集中于转换您的业务模型,以使之成 为随需应变的模型。
18
面向服务的软件体系结构
H T T P协议满足了S OA的三个基本特点 : ( 1 )独立的功能实体 作为服务器端的WEB服务器总是非常稳定地按照 自己的内在逻辑运行 ,响应外部
的请求 ,管理自己的资源和数据。 ( 2)大数据量低频率访问 对于一个HT T P请求来说 , 客户端与服务器端之间访问的边界就是一个请求,一
功地调用服务需要什么数据。
服务描述实际可供使用的服务。
业务流程是一个服务的集合,可以按照特定的顺序并使用一组特定的规则进行调用,
以满足业务要求。注意,可以将业务流程本身看作是服务,这样就产生了业务流程
可以由不同粒度的服务组成的观念。

SOA面向服务架构(PPT30页)

SOA面向服务架构(PPT30页)
SOA面向服务架构(PPT30页)
SOA面向服务架构(PPT30页)
为什么要使用SOA
传统的架构,软件包是被编写为独立的(self-contained) 软件,即在一个完整的软件包中将许多应用程序功能整合在 一起。实现整合应用程序功能的代码通常与功能本身的代码 混合在一起。我们将这种方式称作软件设计“单一应用程序 “。与此密切相关的是,更改一部分代码将对使用该代码的代 码具有重大影响,这会造成系统的复杂性,并增加维护系统 的成本。而且还使重新使用应用程序功能变得较困难,因为 这些功能不是为了重新使用而打的包。
缺点:代码冗余 不能重用 紧耦合 成本高
SOA面向服务架构(PPT30页)
SOA面向服务架构(PPT30页)
为什么要使用SOA
SOA旨在将单个应用程序功能彼此分开,以便这些 功能可以单独用作单个的应用程序功能或“组件”。这 些组件可以用于在企业内部创建各种其他的应用程序, 或者如有需要,对外向合作伙伴公开,以便用于合作伙 伴的应用程序。
SOA优点:代码重用 松耦合 平台独立 语言无关
SOA面向服务架构(PPT30页)
SOA面向服务架构(PPT30页)
商品消费——软件服务
SOA面向服务架构(PPT30页)
SOA面向服务架构(PPT30页)
SOA工作流程
SOA面向服务架构(PPT30页)
SOA面向服务架构(PPT30页)
SOA角色
假设股票行业存在以下6个服务:
• Country() 输入参数:国家编码。输出项:国家名称和其他信息。 • YellowPages() 输入参数:公司名称;输出项:企业代码,所在国家等其他信息。 • NewYorkStock() 输入参数:公司代码,时间;输出项:该公司在纽约的股票价格 (美元)。 • LondonStock() 输入参数:公司代码,时间;输出项:该公司在伦敦的股票价格。 • USToRMB() 输入参数:美元价格,时间;输出项:对应的人民币价格。 • UKToRMB() 输入参数:英镑价格,时间;输出项:对应的人民币价格。

信息服务中技术结构类型

信息服务中技术结构类型

信息服务中技术结构类型信息服务中的技术结构类型信息服务是指通过信息技术手段,提供各种形式的信息传递、处理、存储、分析等服务。

在信息服务中,技术结构类型是指不同的技术架构和体系结构,用于支持和实现信息服务的各个环节。

本文将介绍几种常见的信息服务技术结构类型。

1. 客户端-服务器结构(Client-Server Architecture)客户端-服务器结构是一种常见的分布式计算结构,它将系统分为客户端和服务器两个部分。

客户端负责与用户交互,并向服务器发送请求,服务器负责接收请求并提供相应的服务。

这种结构可以实现分布式的信息服务,提高系统的可扩展性和性能。

2. 面向服务的体系结构(Service-Oriented Architecture,SOA)面向服务的体系结构是一种基于服务的架构模式,将应用程序划分为不同的服务单元,这些服务单元通过网络进行通信。

每个服务单元都提供特定的功能,可以通过组合不同的服务单元来实现复杂的信息服务。

SOA可以提高系统的灵活性和可重用性,使得不同的系统可以集成和共享信息服务。

3. 分布式体系结构(Distributed Architecture)分布式体系结构是指将系统的各个组件分布在不同的计算节点上,通过网络进行通信和协作。

这种结构可以提高系统的可靠性和可伸缩性,使得系统能够处理大量的信息请求。

分布式体系结构常用于大规模的信息服务系统,如云计算平台和大数据处理系统。

4. 多层体系结构(Multitier Architecture)多层体系结构是一种将系统划分为不同层次的结构,每一层都负责特定的功能。

常见的多层体系结构包括三层结构和N层结构。

三层结构一般包括表示层、业务逻辑层和数据层,每一层都有特定的职责。

N层结构是对三层结构的扩展,可以根据具体需求定义更多的层次。

多层体系结构可以提高系统的可维护性和可扩展性,使得不同层次的功能可以独立开发和部署。

5. 消息队列体系结构(Message Queue Architecture)消息队列体系结构是一种将系统的各个组件通过消息队列进行通信的结构。

面向服务的体系结构

面向服务的体系结构面向服务的体系结构(S ervice-O riented A rchitecture,SOA,也叫面向服务架构)是指为了解决在Internet环境下业务集成的需要,通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。

SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。

接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。

这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

传统的Web(HTML/HTTP)技术有效的解决了人与信息系统的交互和沟通问题,极大的促进了B2C模式的发展。

WEB服务(XML/SOAP/WSDL)技术则是要有效的解决信息系统之间的交互和沟通问题,促进B2B/EAI/CB2C的发展。

SOA 则是采用面向服务的商业建模技术和WEB服务技术,实现系统之间的松耦合,实现系统之间的整合与协同。

WEB服务和SOA的本质思路在于使得信息系统个体在能够沟通的基础上形成协同工作。

对于面向同步和异步应用的,基于请求/响应模式的分布式计算来说,SOA是一场革命。

一个应用程序的业务逻辑(Business Logic)或某些单独的功能被模块化并作为服务呈现给消费者或客户端。

这些服务的关键是他们的松耦合特性。

例如,服务的接口和实现相独立。

应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用,而无须理解服务的底层实现。

举例来说,一个服务可以用.NET或J2EE来实现,而使用该服务的应用程序可以在不同的平台之上,使用的语言也可以不同。

SOA的生命周期建模建模是面向服务的体系结构项目的第一步,几乎和技术没有任何关系,所有事项都和具体的业务相关。

请记住,面向服务的方法将业务所执行的活动视为服务,因此第一步是要确定这些业务活动或流程实际是什么。

对您的业务体系结构进行记录,这些记录不仅可以用于规划SOA,还可以用于对实际业务流程进行优化。

面向服务的体系结构

面向服务的体系结构摘要:一、面向服务的体系结构概述1.概念介绍2.发展历程3.主要特点二、面向服务的体系结构的优势1.松耦合2.模块化3.更易于扩展和维护三、面向服务的体系结构的实施1.服务识别与设计2.服务实现与部署3.服务管理四、面向服务的体系结构在各领域的应用1.企业信息系统2.物联网3.云计算正文:面向服务的体系结构(Service-Oriented Architecture,简称SOA)是一种软件设计模式,它将应用程序的不同功能单元(服务)进行抽象、封装和集成,从而实现软件系统的模块化、松耦合和可重用。

面向服务的体系结构已经成为现代软件系统设计的重要理念,并在全球范围内得到了广泛的应用。

一、面向服务的体系结构概述面向服务的体系结构起源于20世纪90年代,随着互联网的普及和电子商务的发展,企业逐渐意识到传统的客户端/服务器(C/S)和浏览器/服务器(B/S)架构已无法满足日益复杂的业务需求。

面向服务的体系结构应运而生,通过将业务功能抽象为可复用的服务单元,提高了软件系统的灵活性、可扩展性和可维护性。

1.概念介绍面向服务的体系结构是一种软件设计模式,它将应用程序的不同功能单元(服务)进行抽象、封装和集成,从而实现软件系统的模块化、松耦合和可重用。

2.发展历程面向服务的体系结构起源于20世纪90年代,经历了从传统的客户端/服务器(C/S)和浏览器/服务器(B/S)架构到面向服务的体系结构(SOA)的演变。

3.主要特点面向服务的体系结构的主要特点包括:松耦合、模块化和更易于扩展和维护。

二、面向服务的体系结构的优势1.松耦合面向服务的体系结构通过定义清晰的服务接口,实现了服务之间的解耦,使得服务之间的依赖关系变得更加灵活。

这有助于降低系统间的耦合度,提高系统的可维护性和可扩展性。

2.模块化面向服务的体系结构将复杂的业务功能抽象为简单的服务单元,使得系统的设计和开发变得更加模块化。

这有助于提高系统的可重用性和可维护性。

面向服务的架构(SOA)设计与实现


发展趋势
• 融入人工智能和机器学习技术,实现 智能服务 • 支持****跨平台、跨语言、跨组织的 协同开发 • 优化****服务治理和性能监控,实现 可持续发展
CREATE TOGETHER
DOCS
谢谢观看
THANK YOU FOR WATCHING
• 规划、设计、开发、测试、部署和维护 等环节 • 遵循****最佳实践和质量标准 • 持续改进和优化服务
03
SOA架构的部署与实现技术
云计算与SOA的融合
云计算
• 提供****按需分配、弹性扩展的计算资 源 • 支持****分布式计算和大数据处理 • 实现****服务化和资源化
SOA与云计算的融合
• 使用诊断工具进行故障定位和问题解决 • 分析****日志和性能数据,找出问题根 源 • 采取****相应措施,优化服务性能
SOA测试与验证最佳实践
测试与验证方法
• 使用测试框架和测试工具进行测试用例设计和执行 • 实现****测试报告和缺陷管理 • 遵循****最佳实践和质量标准
测试与验证策略
CREATE TOGETHER
DOCS
DOCS SMART CREATE
面向服务的架构(SOA)设计与实 现
01
面向服务的架构(SOA)基本概念及重要性
什么是面向服务的架构(SOA)
01
SOA是一种软件架构风格
• 强调松耦合和可重用性 • 通过服务进行组件间的通信与协 作
02
SOA是一种设计理念
• 采用****服务总线实现服务调度和消息 传递 • 实现****服务治理和性能监控 • 提高****系统可靠性和可扩展性
容器化与微服务架构在SOA中的应用
容器化

面向服务的软件体系架构设计与实现

面向服务的软件体系架构设计与实现面向服务的软件体系架构(Service-Oriented Architecture, SOA)是一种基于服务的软件开发和构建方式,就像Web Services一样,SOA将应用系统划分为一个个松散耦合的服务,这些服务能够相互调用,形成一个可扩展的应用系统。

随着云计算、物联网、大数据等相关技术的普及,SOA也成为了一个相当流行的软件架构设计方式。

本文将从以下几个方面介绍面向服务的软件体系架构设计与实现:SOA核心概念、SOA的优势和劣势、SOA的设计原则、SOA的实现技术、SOA的开发工具以及SOA的应用案例。

一、SOA核心概念面向服务的软件体系架构(SOA)是一种基于服务的软件开发和构建方式,其核心概念包括以下三点:1.服务:SOA中的服务是一个独立的逻辑单元,它封装了某种特定的功能,并可以通过网络进行访问和调用。

SOA中的服务通常包括Web Services、RESTful Services、消息队列等。

2.业务流程:SOA中的业务流程是一系列的服务的有序调用,应用在需要对多个服务进行协调、合作的场景中。

3.服务注册与发现:为了方便调用和管理服务,SOA中引入了服务注册与发现机制。

服务提供者将服务信息注册到服务仓库中,服务调用方可以根据服务描述信息在服务仓库中找到需要的服务。

二、SOA的优势和劣势SOA有以下几个优势:1.松散耦合:面向服务的软件体系架构的服务是松耦合的,即每个服务最好只与其依赖的服务或资源相关。

这种松散耦合的优点在于当某个服务需要更新或替换时,对其他服务的影响相对要小,这样大幅度减少了整体系统部分维护和升级所需的时间和成本。

2.可扩展性:SOA的另一个优点是可扩展性,这意味着可以在系统中动态添加或替换单独的服务,而不会影响整个系统。

这也使得系统更加灵活和可适应变化。

3.平台无关性:SOA 架构实际上是一个独立于平台(如操作系统和编程语言)的技术,可以让系统根据需要进行选择,因此可以将系统部署在不同的平台上。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
面向服务的体系架构
SO vs OO
• SO 是对 OO的补充 • SO是为服务的整合而生 • SO 把互联作为首要的目标
– 提供平台无关互操作能力 – 提供更多的互联:同步,异步,one-way, two-way, request-response, queued, streamed communication
– – 服务之间的通信方式灵活,而不是固定某种方式 服务之间交互不需要了解彼此的运行环境 Services scale well in all directions. For example, a service can be scaled out by fronting it with a router service that distributes traffic among a farm of services If services make use of queue-based communication, they don't have to be online at the same time to interact. If services employ a discovery mechanism, they can locate each other without any prior notion about where they reside Restricting, relocating, or outsourcing a service requires changes only in policy, not to the service itself.
平台无关、实现无关

• • •
Services are scale invariant
– – – –
Services can be time independent Services can be address agnostic. Behavior is separated from constraints
• SO是松耦合而OO是紧耦合
– 基于OO的系统往往通过类库之间的依赖耦合 – 基于SO的系统通过Message互相关联
SO的四个原则
• 边界清晰
– 每次服务的交互都是需要跨越边界的 – 跨越边界需要付出较高的代价 – 服务的交互需要清晰考虑

服务自治
– – – – – 服务完成的功能具有较强的内聚性 服务不会因为依赖的服务不可用而失败 服务的部署,管理,升级是彼此无关的 整个基于服务的系统在拓普布局会随着时间演化,而不影响系统 整个基于服务的系统没有控制权威
Service剖析(Ext)
• 从外部看Service暴露了一个service description和 一组Endpoint • Service描述
– WSDL:描述Service可以做什么,如何访问,Service位 置 – XSD:用来描述Service中消息的结构 – WS-Policy:描述Service的约束,如需要满足的安全要 求,QOS等 – WS-MEX:客户用来获取服务描述自己的元信息 (WSDL, WS-Policy)访问协议
SO对平台的要求
• • • 统一的编程模型
– – – – – – – 能够整合多种服务实现技术和交互技术 多种传输方式(Transport),消息格式(MF),消息交互模式(MEP)可供选择 平台无关 基于SOAP的能力 遵循WebService的架构 使用已有的通信标准WS-*协议 服务采用WSDL,XSD,WS-Policy和WS-MetaExchange进行描述 Security, Transactions, Reliable messaging MTOM 可以选择不同的传输机制如TCP,HTTP,SMTP等传输机制 可以自由的扩展,提供更多的传输机制支持 提供多种扩展技术支持,对服务开发透明 Scale up: 提供更好的服务器资源,Scale down: 切换对其它服务的使用,Scale out: Farms技术和负载均很技 术, Scale in: 采用更高效的通信技术(如本地优化)
Channel
• Channel为服务之间消息通信的通道 • Channel按照MEP可换分为simplex, duplex, request/response几种类型
Channel Stack
• 多种类型的Channel组和成一个管道,从而 组合了多个Channel的能力 • Channel Stack的组合受MEP的约束,利润 duplex就不能含有reliable session channel
更丰富的通信模式 广泛的互操作能力
• • •
提供企业应用需要的能力
– – – – – –
Transport, Protocol, and Format Neutrality Scale Invariance
体系架构
Application
Contracts
Service Runtime
Messaging

服务之间通过schema和contract关联,而非class和type
– Services interact solely on schemas for data and contracts for behaviors – Services do not combine data and behavior – Contracts and schemas remain stable over time
• One-way (simplex) • 异步two-way (duplex或者叫 solicit/response) • 同步two-way (request/response) • Notification • WSDL1.1对Notification和solicit/response 没有很好的描述
• Data Contract:数据结构信息,相当于OO中的 数据类型(VO) • Message Contract:定义了服务操作之间互相传递 的消息格式,控制了服务之间传递的消息的格式, 如Header,Body
Service剖析:Binding
• Binding描述了服务如何与外部通信 • 它指定了transport,encoding format, reliability requirements 和 security requirements, session requirements, transaction requirements信息 • 一个Service Contract必须至少有一个 Binding • 服务运行环境根据Binding信息创建 Channel Stack
Implementding
Service Contract
Implementation
Service Description
WSDL
WS-Policy
Service剖析:Contracts
• Service Contract
– – – – 有一个名称 由一个或多个Service operations构成 一个服务可以有多个Service Contract Service Contract相当于OO中的接口,Service operation相当于OO中的接口方法
Service vs WebService
• 共同点
– 都利用SOAP,XML,XSD,WSDL等标准协议 – 都具有自治、平台实现无关等特性
• 差异
– Service是WebService在SOA领域的后继标准 – WebService只提供了基于Http的传输通道和 request/response的消息交互模式,而Service是传输 中立,协议中立和格式中立的,能够提供多种消息交 互模式 – Service比WebService更成熟,更能够满足企业需要, 能够提共企业运算的安全、事务、可靠性以及性能满 足
– Transport:Channel用来通信的方法,如HTTP, TCP, SMTP, Queue – Encodings: 包括text, MTOM等编码方式编码消息在连接上传递 – Security:包括Transport的安全,如HTTPS,TCPS和消息安全, 例如SOAP Message Security – Reliable Session: 提供了两个关键能力,reliable message和 session, reliable message提供了消息的可靠传递和消息顺序等特 性,session保持了客户一系列交互的状态,它是建立在message 级别的,并不要求底层的通道是可靠或者支持session – MEP: 采用什么样的MEP决定于Channel是如何构建的,三个重要 的MEP为simplex, duplex, request/response – Interoperability: WS-Basic, WS-*
Reliable TCP Binary Request Security Sessions Transport Message Response Channel Channel Channel Encoder Channel
Channel Stack
• 可以组合形成Channel Stack的一些关键特征
Service剖析: Endpoint
• Endpoint描述了Service在何处的问题 • Endpoint用一个Address来关联Service Contract和Binding (ABC) • 服务的Endpoint通过Address告诉外界, Address的格式受多种因素影响,其中就包 括采用的transport
• Endpoint:Service的Access point
Service剖析(Int)
Address Endpoint
Service
Binding Binding Binding Service Contract
相关文档
最新文档