SOA面向服务体系概述
- 格式：docx
- 大小：19.14 KB
- 文档页数：6
下载文档原格式
合集下载
面向服务体系架构
VS
概念
SOA采用分布式系统架构，将应用程序的 不同功能单元（即服务）定义为独立的、 可复用的软件组件，并通过标准的接口（ 如REST、SOAP等）与其他服务进行通信 。这种架构使得应用程序能够灵活地适应 业务需求的变化，提高系统的可维护性和 可扩展性。
面向服务体系架构的价值
提高业务灵活性
SOA使得业务功能能够以服务的形式进行封装和 重用，从而加快了业务开发和部署的速度，提高 了业务的灵活性和响应能力。
负载均衡
通过负载均衡技术，确保服务在高负载情 况下仍能正常运行，防止拒绝服务攻击。
面向服务体系架构的安全管理实践
制定安全策略
根据业务需求和安全风险，制定相 应的安全策略和规章制度。
安全培训
对开发人员和管理人员进行安全培 训，提高安全意识和技能。
安全测试
在服务开发过程中，进行安全测试 ，确保服务的安全性。
服务滥用
数据泄露
拒绝服务攻击
跨站脚本攻击
由于SOA的松散耦合和开放性， 服务可能被滥用，如未经授权地 访问或恶意攻击，导致数据泄露 或系统崩溃。
在SOA架构中，数据需要在多个 服务之间共享和传输，这增加了 数据泄露的风险。
攻击者可能通过发送大量无效请 求，使服务超负荷运行，从而导 致合法用户无法访问服务。
案例三
• 总结词：医疗卫生行业通过构建面向服务的体系架构，实现医疗资源的共享和业务协同。 • 详细描述 • 医疗卫生行业面临医疗资源紧张、信息孤岛等问题，需要实现医疗资源的共享和业务协同。 • 服务封装：将医疗资源封装为服务，如医疗资讯、病历管理、药品管理等。 • 服务注册与发现：通过服务注册中心和服务发现机制，实现服务的动态发现和调用。 • 医疗协作：通过构建医疗协作平台，实现跨科室、跨医院的医疗协作。 • 数据共享：构建数据共享平台，实现医疗数据的共享和分析，支持数据驱动的决策。
SOA_术语概述
SOA 术语概述第1 部分，服务、体系结构、治理和业务术语引言在任何领域中，语义都非常重要，而在面向服务的体系结构（Service-oriented architecture，SOA）中更是如此。
由于SOA 涉及多个团队和组织，因此就相关术语达成一致至关重要。
本系列将带着您开始SOA 之旅，为您定义基础术语和主要概念。
您将了解SOA 领域中所使用的各个词汇。
对于每个术语，将说明其为何对SOA 重要、其在这种情况下的含义、相关的标准有哪些以及与其他术语的区别如何。
关于组织方式的说明以下列出的术语并不是按照字母顺序排列的，也不是按照其重要性进行排列。
我们将按照构建块的方式对其进行排列。
首先讨论的是“服务”，因为这个术语可能是理解SOA 框架的最基本概念。
我们将以服务为基础形成“体系结构”、“治理”和“业务”概念的定义。
在很多情况下，我们都将较大的术语分解为较小的组成部分进行讨论。
服务服务显然是面向服务的体系结构的核心，术语服务的使用非常广泛。
不过，这个术语对于不同的人有不同的含义，“什么是服务？”这个问题经常会引发激烈的争论。
我听到过人们讨论业务任务、业务服务、应用程序功能、技术服务或基础设施服务。
我将基于IBM Rational® Method Composer Plug-in for SOA Governance 和IBM Rational® Unified Process for Service-Oriented Architecture 给出一个定义。
（有关更多信息，请参见参考资料部分。
）“服务是执行可重复任务的可发现资源，由外部化的服务规范进行描述。
”由于存在多种不同的定义，通过定义“服务”来开始本文的讨论比较困难。
例如，您可能会认为上述定义过于偏重于技术。
请记住，一定不要过于依赖于服务的正式定义，而要将重点放在服务背后的主要概念上，包括：∙业务一致性：服务并不基于IT 功能，而是基于业务的需求。
SOA
决策支持信息
贸易伙伴
信息集成平台的功能
多种预建的适配器 图形化数据格式转换 事务机制 基于订阅/发布的消息机制 可靠的消息传递 消息路由
动态部署
系统管理 安全性保证 B2Bi，PKI支持
Information Integration Platform
集成的四个技术层面
interface Self-contained with no visible dependencies to other services (almost) Always available but idle until requests come Easily accessible and usable readily, no “integration” required Coarse grain Independent of consumer context,
• 传统软件包是被编写为独立的（self-contained）软件，即在一个完整 的软件包中将许多应用程序功能整合在一起。实现整合应用程序功能 的代码通常与功能本身的代码混合在一起。我们将这种方式称作软件 设计“单一应用程序”。与此密切相关的是，更改一部分代码将对使 用该代码的代码具有重大影响，这会造成系统的复杂性，并增加维护 系统的成本。而且还使重新使用应用程序功能变得较困难，因为这些 功能不是为了重新使用而打的包 • SOA旨在将单个应用程序功能彼此分开，以便这些功能可以单独用 作单个的应用程序功能或“组件”。这些组件可以用于在企业内部创 建各种其他的应用程序，或者如有需要，对外向合作伙伴公开，以便 用于合作伙伴的应用程序。“服务”的概念是要使用与实施细节无关 的标准化接口来构建这些“组件” • 服务装配化使企业随需而变
SOA_简介
简单对象访问协议 (SOAP)
12/38
� SOAP 是用于在网络上交换基于 XML 的消息的协议。 通常，使用 HTTP 作为传输协议，但也可以使用其他 协议，如 SMTP 等。 � SOAP 消息包含以下元素： � Envelope：必需的元素，用于将文档标识为 SOAP 消 息 � Header：包含应用程序特定的信息 � Body：必需的元素，定义调用和响应信息 � Fault：包含有关出现的错误的信息 � SOAP 内容可由 WSDL 文件确定。
WSDL
9/38
� Web 服务描述语言（ Web Services Description Language，WSDL） 是一个 XML 实例文档，符合用于服务请求方和服务提供者之间的通信 的 W3C 标准 XML 语法。它描述 Web 服务如何工作。正是由于 WSDL 文件，Web 服务才被称为“自描述”，因为可以从 WSDL 文件生 成 SOAP 消息。事实上，很多工具都可以从 WSDL 文件创建客户机代 码。 � WSDL 文件包含以下元素： � Type：使用某种语法（如 XML 模式）的数据类型定义（ string、int） � Message：要传递的数据 � Part：消息参数 � Operation：服务支持的操作的抽象描述 � Port Type / Interface：一个或多个端点支持的操作的抽象集。此名称 已更改，因此可能会遇到两者中的任何一个。 � Binding：特定端口类型的具体协议和数据格式规范 � Port / Endpoint：绑定和网络地址的组合。此名称也已更改，因此可 能会遇到两者中的任何一个。 � Service：相关端点的集合，包括其关联的接口、操作、消息等。
服务
6/38
� 利用基于SOA的系统构建方 法，如图中所示的一样，一个 基于SOA架构的系统中的所有 的程序功能都被封装在一些功 能模块中，利用这些已经封装 好的功能模块组装构建所需要 的程序或者系统，而这些功能 模块就是SOA架构中的不同的 服务(services)。
面向服务的体系结构
面向服务的体系结构摘要：一、面向服务的体系结构概述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.模块化面向服务的体系结构将复杂的业务功能抽象为简单的服务单元，使得系统的设计和开发变得更加模块化。
这有助于提高系统的可重用性和可维护性。
面向服务的软件体系架构设计与实现
面向服务的软件体系架构设计与实现面向服务的软件体系架构（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 架构实际上是一个独立于平台（如操作系统和编程语言）的技术，可以让系统根据需要进行选择，因此可以将系统部署在不同的平台上。
SOA定义
面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。
这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。
松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。
而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。
我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。
虽然基于SOA的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。
由于它考虑到了系统内的对象，所以虽然SOA是基于对象的，但是作为一个整体，它却不是面向对象的。
不同之处在于接口本身。
SOA系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与SOA 相似。
然而，现在的SOA已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。
soa面向服务的体系结构
面向服务的体系结构（Service-Oriented Architecture，SOA）是一种分布式运算的软件设计方法。
这种架构方式中的软件组件（调用者），可以通过网络上的通用协议调用另一个应用软件组件进行运行和操作。
SOA的核心思想是将应用程序拆分成一组相互独立的服务，这些服务可以独立部署、升级和扩展，从而提高了应用程序的灵活性和可维护性。
在SOA中，服务是定义明确的、独立的功能单元，它们通过网络接口进行通信和交互。
这些服务可以使用公共接口标准和架构模式，因此可以快速整合到新应用中。
此外，SOA的关键技术包括UDDI （Universal Description,Discovery,and Integration）、WSDL（Web Services Description Language）、SOAP（Simple Object Access Protocol）和REST（Representational State Transfer）等。
值得一提的是，企业服务总线（Enterprise Service Bus，ESB）在SOA中扮演着重要的角色。
它是一个中央的、可重用的基础设施组件，被用于协调和组织分布式系统中的各个服务之间的通信和交互。
总的来说，SOA提供了一种更加灵活、可扩展和易于管理的软件架构方法，它已经成为许多企业和组织的首选架构模式。
面向服务体系结构(SOA)漫谈)
面向服务体系结构（SOA）漫谈摘要：本文简单的对于面向服务体系结构(SOA)进行了介绍，并且对SOA的特点进行了整理，以及对SOA的未来做了展望。
一SOA定义SOA是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。
从这个定义中我希望表达的前提有下面两点：1) 软件系统架构：SOA不是一种语言，也不是一种具体的技术而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它更像一种模式(Pattern)。
因此它与很多已有的软件技术比如面向对象技术，是互补的而非互斥的。
它们分别面向不同的应用场景，用来满足不同的特定需求。
2) SOA的使用范围：需求决定同时也限制功能。
SOA并不是包治百病的万灵丹，它最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。
在下面我们会详细讨论Internet的各种特点如何决定SOA的特点，这里我们只需要先简单回顾一下Internet环境区别于Intranet环境的几个特点：a) 大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语言也不同；b) 大量、频繁的数据传输仍然速度缓慢并且不稳定；c) 版本升级无法完成，我们根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。
前看来大多数软件的功能最终将作为服务来交付和使用。
当然，它们可以实现为紧密耦合的系统，但从门户、设备以及其它终端使用的观点看，它们将使用一种面向服务的接口。
我们已经注意到有人提出体系架构师和设计者应该谨慎避免将所有功能都作为服务。
我们认为这是不正确和不适当的。
如果有了成熟的Web服务协议和技术，再考查是否将所有功能实现为Web服务是否有效，这可能会更加有效，但这并不会减弱从服务的角度来设计所有功能的需求。
服务是发布的主要构造成分，应该在每一重要的接口中使用。
面向服务的体系结构可以让我们按照相关的服务来管理使用（发送、接收、使用，等等）服务。
SOA简介
另外，对于SCA标准是否可以完美实现SOA，也存在一些争议。David Chappell（Oracle公司副总裁及SOA首席技术专家）就提出SCA的一个特点是一个组合构件内的基本构件必须是由同一软件厂商的技术开发的（a single-vendor construct）。譬如一个组合构件不能由.Net C#开发的基本构件和Java开发的EJB基本构件组合而成。这个特点影响了SCA系统的交互性，具体到开发流程中，也就是单一的组合构件必须在同一软件厂商的平台上开发。不过个人认为这只是理论严谨性的问题，在实践开发中似乎不是个大问题，一个组合构件由同一平台开发也是有好处的，有助于提高它的开发效率和运行效率。毕竟一个组合构件对应一个基本业务服务，就好比一个团队工作里的一个成员。成员之间的合作可以讨论耦合度和合作方式，但是每个成员自己要做的事情还是要讲求效率优先。
SOA简介
SOA （Service Oriented Architecture 面向服务架构）最早由Gartner公司提出（Gartner是国际权威IT研究与顾问咨询公司，曾提出ERP、SOA等划时代的概念）。遵循SOA规范的银行软件系统，可以理解为是多个松散子系统协同工作的结合体。“松散” (松耦合) 意味着每个子系统（在SOA架构中被称为服务：Service）独立开发，独立运行，但通常需要和别的子系统进行数据交互。比如有一个核心系统实现帐务处理的功能，另外还有ATM子系统，信用卡子系统，中间业务子系统等，需要和核心系统发生数据交互。著名业界研究公司Celent对SOA的定义是：”一个为了实现业务上和IT上的需求和开发的松耦合服务的集合”（"a set of loosely coupled modularservices to support both business and IT requirements."）
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SOA（面向服务体系）知识概述SOA概览最近半年以来，在企业级应用开发领域，谈论最多的一个词，恐怕非SOA(Service-Oriented Architecture，面向服务架构)莫属。
那么SOA究竟拥有什么样的魔力，能够让众多的软件厂商对他趋之若骛，掀起新的一轮企业架构浪潮。
让我们在本文中一探SOA的究竟。
那么什么是SOA，让我们先从基本概念开始讲起。
什么是SOA?SOA是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。
服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
SOA的关键是“服务”的概念，W3C将服务定义为：“服务提供者完成一组工作，为服务使用者交付所需的最终结果。
最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。
将SOA定义为：“本质上是服务的集合。
服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。
服务间需要某些方法进行连接。
所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。
”将SOA定义为：“按需连接资源的系统。
在SOA中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。
与传统的系统结构相比，SOA规定了资源间更为灵活的松散耦合关系。
”Gartner则将SOA描述为：“客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成……SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。
”Gartner相信BPM和SOA的结合对所有类型的应用集成都大有助益??“SOA极大的得益于BPM技术和方法论，但是SOA面临的真正问题是确立正确的企业意识，即：强化战略化的SOA计划（针对供应和使用）并鼓励重用。
”虽然不同厂商或个人对SOA有着不同的理解，但是我们仍然可以从上述的定义中看到SOA的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。
需着重注意的是，SOA并不是新生事物。
大型IT组织成功构建和部署SOA应用已有多年的历史??这要比现有的XML和Web服务长很多。
IBM CICS和BEA TUXEDO就是过去被用于构建SOA应用的两种技术范例。
重点说明的是SOA并不是一种现成的技术，而是一种架构和组织IT基础结构及业务功能的方法。
SOA是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）的模型。
这一定义阐明了SOA的范围。
SOA要求开发人员将应用设计为服务的集合。
SOA要求开发人员跳出应用本身进行思考，考虑现有服务的重用，或思索他们的服务如何能够被其他项目重用。
“单独的”、“独立的”、“封装完善的”服务所具有的一个关键的好处是，可以采用多种不同方法将它们组合成较大型的服务，由此来实现重用。
但是，SOA并不仅仅是一种开发方法??它还具有管理上的优点。
例如，现在管理员可直接管理开发人员所构建的相同服务，这远胜于以往管理单个应用的方式。
通过分析服务间的交互，SOA可以帮助企业了解何时以及为什么业务逻辑被切实执行了，这使管理员或分析师能够有针对性的优化业务流程。
SOA的基本特征SOA的实施具有几个鲜明的基本特征。
实施SOA的关键目标是实现企业IT资产的最大化重用。
要实现这一目标，就要在实施SOA的过程中牢记以下特征：﹡可从企业外部访问﹡随时可用﹡粗粒度的服务接口﹡分级﹡松散耦合﹡可重用的服务﹡服务接口设计管理﹡标准化的服务接口﹡支持各种消息模式﹡精确定义的服务契约我们现在开始依次讨论以上概念。
1 可从企业外部访问通常被称为业务伙伴的外部用户也能像企业内部用户一样访问相同的服务。
业务伙伴采用先进的B2B协议（ebXML或RosettaNet）相互合作。
当业务伙伴基于业务目的交换业务信息时，他们就参与了一次会话。
会话是业务伙伴间一系列的一条或多条业务信息的交换。
会话类型（会话复杂或简单、长或短等）取决于业务目的。
除了B2B协议外，外部用户还可以访问以Web服务方式提供的企业服务。
2 随时可用当有服务使用者请求服务时，SOA要求必须有服务提供者能够响应。
大多数SOA都能够为门户应用之类的同步应用和B2B之类的异步应用提供服务。
同步应用对于其所使用的服务具有很强的依赖性。
许多同步应用通常部署在前台，其最终用户很容易受到服务提供者短缺的影响。
很多情况下，同步应用利用分布式服务提供者，这样可以响应更多的用户请求。
但是，随着提供特定服务功能的服务器数量的增长，出现短缺的可能性也呈指数级上升。
当相比之下，异步应用要更为稳健，因为其采用队列请求设计，因此可以容许出现服务提供者短缺或迟滞的情况。
异步应用大多数情况下部署在后台，用户通常不会觉察到短暂的短缺。
大部分情况下异步应用能够稳健应对短时间短缺，但是长时间短缺则会引发严重问题。
在服务短缺解决、队列引擎将罕见的大量工作推到共享的应用资源中时，可能会出现队列溢出甚至服务死锁。
服务使用者要求提供同步服务时，通常是基于其自身理解或使用习惯。
在多数情况下，采用异步模型可以达到同样的效果，但更能够体现SOA的最佳特性。
当然，并不是所有情况下都应当采用异步设计模式。
但大多数情况下，异步消息可以确保系统在不同负荷下的伸缩性，在接口响应时间不是很短时尤其如此。
3 粗粒度服务接口粗粒度服务提供一项特定的业务功能，而细粒度服务代表了技术组件方法。
举个例说明最为清楚??向计费系统中添加一个客户是典型的粗粒度服务，而你可以使用几个细粒度服务实现同一功能，如：将客户名加入到计费系统中，添加详细的客户联系方式、添加计费信息等等。
采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够。
Internet环境中有保障的TCP/IP会话已不再占据主导、建立连接的成本也过高，因此在该环境中进行应用开发时粗粒度服务接口的优点更为明显。
除去基本的往复效率，事务稳定性问题也很重要。
在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长、导致后台服务超时，从而中止。
与此相反，从事务的角度来看，向后台服务请求大块数据可能是获取反馈的唯一途径。
4 分级一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差，因为粗粒度服务倾向于解决专门的业务问题，因此通用性差、重用性设计困难。
解决该争论的方法之一就是允许采用不同的粗粒度等级来创建服务。
这种服务分级包含了粒度较细、重用性较高的服务，也包含粒度较粗、重用性较差的服务。
在服务分级方面，须注意服务层的公开服务通常由后台系统（BES's）或SOA平台中现有的本地服务组成。
因此允许在服务层创建私有服务是非常重要的。
正确的文档、配置管理和私有服务的重用对于IT部门在SOA服务层快速开发新的公开服务的能力具有重要影响。
5 松散耦合SOA具有“松散耦合”组件服务，这一点区别于大多数其他的组件架构。
该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。
服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。
这是服务实现能够在完全不影响服务使用者的情况下进行修改。
大多数松散耦合方法都依靠基于服务接口的消息。
基于消息的接口能够兼容多种传输方式（如HTTP、JMS、TCP/IP、MOM等）。
基于消息的接口可以采用同步和异步协议实现，Web 服务对于SOA服务接口来讲是一个重要的标准。
当使用者调用一个Web服务时，被调用的对象可以是CICS事务、DCOM或CORBA对象、J2EE EJB或TUXEDO服务等，但这与服务使用者无关。
底层实现并不重要。
消息类Web服务通常是松散耦合和文档驱动的，这要优于与服务特定接口的连接。
当客户调用消息类Web服务时，客户通常会发送的是一个完整的文档（如采购订单），而非一组离散的参数。
Web服务接收整个文档、进行处理、而后可能或者不会返回结果信息。
由于客户和Web服务间不存在紧密耦合请求响应，消息类Web服务在客户和服务器间提供了更为松散的耦合。
6 可重用的服务及服务接口设计管理如果完全按照可重用的原则设计服务，SOA将可以使应用变得更为灵活。
可重用服务采用通用格式提供重要的业务功能，为开发人员节约了大量时间。
设计可重用服务是与数据库设计或通用数据建模类似的最有价值的工作。
由于服务设计是成功的关键因此，因此SOA 实施者应当寻找一种适当的方法进行服务设计过程管理。
服务设计管理根本上讲是服务设计问题，服务设计需要在两点间折衷??走捷径的项目战术与企业构建可重用通用服务的长期目标。
超越项目短期目标进行服务接口的开发和评估是迈向精确定义服务接口的重要一步，同时还需要为接口文档、服务实现文档及所有重要的非功能性特征设立标准。
在大型组织中实现重用的一个先决条件是建立通用（设计阶段）服务库和开发流程，以保证重用的正确性和通用性。
此外，对记述服务设计和开发的服务文档进行评估也是成功利用服务库的关键。
简言之，不按规则编写服务将无法保证可提供重用性的SOA的成功实施。
在执行规则的过程中会产生财务费用，需要在制定SOA实施计划时加以考虑。
7 标准化的接口近年来出现的两个重要标准XML和Web服务增加了全新的重要功能，将SOA推向更高的层面，并大大提升了SOA的价值。
尽管以往的SOA产品都是专有的、并且要求IT部门在其特定环境中开发所有应用，但XML和Web服务标准化的开放性使企业能够在所部署的所有技术和应用中采用SOA。
这具有巨大的意义！Web服务使应用功能得以通过标准化接口（WSDL）提供，并可基于标准化传输方式（HTTP 和JMS）、采用标准化协议（SOAP）进行调用。
例如，开发人员可以采用最适于门户开发的工具轻松创建一个新的门户应用，并可以重用ERP系统和定制化J2EE应用中的现有服务，而完全无须了解这些应用的内部工作原理。
采用XML，门户开发人员无须了解特定的数据表示格式，便能够在这些应用间轻松地交换数据。
你也可以不采用Web服务或XML来创建SOA应用，但是这两种标准的重要性日益增加、应用日趋普遍。
尽管目前只有几种服务使用者支持该标准，但未来大多数的服务使用者都会将其作为企业的服务访问方法。
8 支持各种消息模式SOA中可能存在以下消息模式。
在一个SOA实现中，常会出现混合采用不同消息模式的服务。
﹡无状态的消息。
使用者向提供者发送的每条消息都必须包含提供者处理该消息所需的全部信息。
这一限定使服务提供者无须存储使用者的状态信息，从而更易扩展。
﹡有状态的消息。
使用者与提供者共享使用者的特定环境信息，此信息包含在提供者和使用者交换的消息中。