1 / 17

SOA 介绍

SOA 介绍. 张 琦 SEG CS NJU. 目录. 概念 关键词 优势 挑战 遗憾. 概念. 面向服务的体系结构 （ Service-oriented architecture ）是构造分布式系统的应用程序的方法。它将应用程序功能作为服务发送给最终用户或者其他服务。 它采用开放标准、与软件资源进行交互并采用表示的标准方式 。 OASIS defines SOA as the following :

merrill-bryan
Download Presentation

SOA 介绍

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOA介绍 张 琦 SEG CS NJU

  2. 目录 • 概念 • 关键词 • 优势 • 挑战 • 遗憾

  3. 概念 • 面向服务的体系结构（Service-oriented architecture）是构造分布式系统的应用程序的方法。它将应用程序功能作为服务发送给最终用户或者其他服务。 • 它采用开放标准、与软件资源进行交互并采用表示的标准方式。 • OASIS defines SOA as the following: • A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

  4. SOA元素 Elements of SOA

  5. SOA原则 • 以下指导原则是开发，维护和使用SOA的基本原则： • 可重复使用, 粒度, 模块性可组合型, 构件化以及交互操作性 • 符合标准(通用的或行业的) • 服务的识别和分类，提供和发布，监控和跟踪。 • 下面是一些特定的体系架构原则 • 服务封装 • 服务松耦合(Loosely coupled)- 服务之间的关系最小化，只是互相知道。 • 服务契约- 服务按照服务描述文档所定义的服务契约行事。 • 服务抽象- 除了服务契约中所描述的内容，服务将对外部隐藏逻辑。 • 服务的重用性- 将逻辑分布在不同的服务中，以提高服务的重用性。 • 服务的可组合性- 一组服务可以协调工作并组合起来形成一个组合服务。 • 服务自治– 服务对所封装的逻辑具有控制权 • 服务无状态– 服务将一个活动所需保存的资讯最小化。 • 服务的可被发现性– 服务需要对外部提供描述资讯，这样可以通过现有的发现机制发现并访问这些服务。 • 除此以外，在定义一个SOA实现时，还需要考虑以下因素： • 生命周期管理 • 有效使用系统资源 • 服务成熟度和性能

  6. SOA使用协议 • XML - 一种标记语言，用于以文档格式描述消息中的数据。 • HTTP （或HTTPS） - 客户端和服务端之间用于传送信息而发送请求/回复的协议。 • SOAP(Simple Object Access Protocol) - 在计算机网络上交换基于XML的消息的协议，通常是用HTTP。 • WSDL(Web Services Description Language) （Web服务描述语言） - 基于XML的描述语言，用于描述与服务交互所需的服务的公共接口，协议绑定，消息格式。 • UDDI(Universal Description, Discovery, and Integration) （是统一描述、发现和集成） - 基于XML的注册协议，用于发布WSDL并允许第三方发现这些服务。

  7. SOA关键词 • 服务 • 松耦合 • 明确定义的接口 • 服务粒度

  8. 服务 • 服务（service）是封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。 • 通过定义的通信协议，可以调用服务来强调互操作性和位置透明性。一个服务表现为一个软件组件，然而实际上，服务的实现可能包括在一个企业内部的不同计算机上或者许多业务合作伙伴拥有的计算机上执行的很多步骤。就封装的软件而言，服务可能是一个组件，也可能不是一个组件。如同类对象，请求者应用程序能够将服务看作是一个整体。 • Web 服务是以使用 SOAP 消息（用 WSDL描述）的调用为基础的。使用 Web 服务的最佳实践就是与外部的业务伙伴通信。

  9. 松耦合 • 服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。服务请求者往往通过消息调用操作：请求消息和响应，而不是通过使用 API 和文件格式。 • 松耦合可以使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。在一个极端的情况下，服务提供者可以将以前基于遗留代码（例如，COBOL）的实现完全用基于 Java 语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真实的，只要新代码支持相同的消息模式。

  10. 明确定义的接口 • 服务交互必须是明确定义的。Web 服务描述语言（Web services Description Language，WSDL）是受到广泛支持的方法，用于描述服务请求者所要求的绑定到服务提供者的细节。服务描述的重点在于与下面几部分交互所用的操作： • ﹡服务﹡调用操作的消息﹡构造这种消息的细节﹡关于向何处发送用于构造这种消息的处理细节的消息的信息

  11. WSDL不包括服务实现的任何技术细节。服务请求者不知道也不关心服务的实现方式。它可以描述使用 HTTP 的 SOAP 调用。由于它的扩展机制，它也可以定义其他类型的交互，比如通过 JMS 提交的 XML 内容、直接方法调用、由管理遗留代码的适配器处理的调用（CICS），等等。 • WSDL的通用定义允许开发工具创建各种各样类型的交互的通过接口，同时隐藏它是如何由应用程序代码调用服务的细节。例如，如果服务是以多种交互类型公开的，Web 服务调用框架（Web Services Invocation Framework，WSIF）通过允许运行时决定调用高质量服务的最优方法来使用这种能力。

  12. 服务粒度 • 操作的粒度是一项重要的设计要点。对于外部的消耗推荐使用粗粒度的接口，而细粒度的接口可能用于企业内部。粗粒度接口可能是特定服务的完整处理。 例如 SubmitPurchaseOrder，在这里消息包括定义订购单所需的所有业务信息。细粒度接口可能具有用于以下方法的不同操作：CreateNewPurchaseOrder、SetShippingAddress、AddItem，等等。 • 虽然细粒度的接口为请求者应用程序提供了更多的灵活性，它同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。 • 粗粒度接口保证服务请求者将以一致的方式使用服务。面向服务的体系结构（SOA）不要求使用粗粒度接口，但是推荐使用它们作为外部集成的最佳实践。服务编排可以用来创建运行由细粒度操作组成的业务流程的粗粒度接口。

  13. 优势 • 企业系统的架构师认为SOA能够帮助业务迅速和高效地响应变化的市场条件 . 服务导向的架构在宏观（服务）上，而不是在微观上（对象）提高了重复使用性。同时，服务导向的架构可以简化与传统系统的互连和使用。 • 1. 简单化系统的开发： 由于SOA具有组合性，可以利用现有的SOA资源，根据同样的开放标准，在不受平台限制的基础上，可以直接利用现有的资源进行组合，让后在按照自己的客户需求，进行进一步的开放。 • 2. 面向企业商业流程： SOA是基于服务的构造，所以开放的出发点，就是如何解决企业流程中出现的问题。 3. 更好的适应性和扩展性:由于SOA的组件性，和优良的扩展性以及其组件性等待特征，SOA可以更具不同的需求，进行重新的组合和构造。 • 4. 互用性 对系统的升级，分布，和维护有个更多的优化 简化了提供，寻找和使用服务的过程 通过共同资源的利用，减少了开支

  14. 挑战 • 1. 大量的服务元数据。SOA环境利用服务间信息交互去完成指定任务。根据服务的设计，一个简单应用可能产生成千上万的信息，特别当来自不同的组织和公司提供的服务需要组合时，信息交互变得异常复杂。 • 2. 缺乏测试。目前没有一个优秀的工具可以针对一个特定架构对所有的服务（包括网络服务中的信息和数据库服务）提供测试。 • 3. 合适的安全级别。一个应用的的安全模型在它作为服务而被其他应用使用时可能不再有效。因此应用管理的安全不是最好的安全服务模型，很多新的技术和标准正试图为SOA服务提供更合适的安全模型。

  15. 遗憾 • 1.可靠性（Reliability） • SOA还没有完全为事务的最高可靠性——不可否认性(nonrepudiation)、消息一定会被传送且仅传送一次（once-and-only-once delivery）以及事务撤回（rollback）——做好准备。 • 2. 安全性（Security） • 　　在过去，访问控制只需要登录和验证；而在SOA环境中，由于一个应用软件的组件很容易去跟属于不同域的其他组件进行对话，所以确保迥然不同又相互连接的系统之间的安全性就复杂得多了。 • 3. 编排 （Orchestration） • 　　统一协调分布式软件组件以便构建有意义的业务流程是最复杂的，但它同时也最适合面向服务类型的集成，事实上，最大的难题不是建立模块化的应用软件，而是改变这些系统表示所处理数据的方法。

  16. 4. 语义 Semantics 定义事务和数据的业务含义。语义关系是设计良好SOA架构的核心要素。 就目前而言，没有哪一项技术或软件产品能够真正解决语义问题。学会如何以服务来表示基本的业务流程是一个重要的部分。 • 5. 性能（performance）： • 批评SOA的人士经常会提到性能是阻碍其采用的一个障碍，但技术的标准化总需要在速度方面有一些牺牲。这种怀疑观点通常针对两个方面：SOA的分布性质和Web服务协议的开销。 • 目前SOA可以使用如JBI技术去避免离开RPC或者通过XML进行传输。很多的XML技术大大提高了SOA的性能 • 6. 松耦合和敏捷性要求之间的权衡难题：服务松耦合设计其实是一把双刃剑，在带来应变敏捷性的同时，也给业务建模和服务划分带来难题。这就是为什么在SOA讨论中，业务建模的争论总是最多。 • 7. 跨系统集成难题：面向服务的体系结构（SOA）设计将跨越计算机系统，并且还可能跨越企业边界。我们不得不考虑在使用 Internet 时安全性功能和需求以及如何链接伙伴的安全域。Internet 协议并不是为可靠性（有保证的提交和提交的顺序）而设计，但是我们需要确保消息被提交并被处理一次。当这不可能时，请求者必须知道请求并没有被处理。

  17. 谢谢观看 张琦 2010年3月23日

More Related