Ⅰ 什么是soa架构
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言（与平台无关，与语言无关，与操作系统无关）。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
Ⅱ SOA架构体系下流水号设计思路探讨（1）
在企业级应用架构的语境下，流水号具有穿针引线的作用。这里说的企业级有两层含义，一是多应用，多数企业都有一组职能定位各不相同的应用系统提供IT支撑；二是这些应用系统是一个有机整体，而不是相互隔离的。服务的调用和数据的简单传递并不是企业级的充分表达，通过多个职责不同的应用系统配合、协作而完成一系列相关服务场景，这些应用系统才能成为企业级。
银行应用系统是企业级的一种典型应用，其每一个服务场景都需要通过交易渠道、客户信息管理系统、渠道整合、流程审批、业务处理、记账处理、核算处理、客户通知……等一系列应用系统协同，当用户在页面上的一个操作涉及到后台的一系列系统服务集成的时候，就需要一种流水号的设计体系对这些服务进行串接，记录在整个交易场景下各个应用的服务调用状态，以便于时候的查询、统计、分析、补录、基于原服务的二次交易等后续场景的使用。
我们简单梳理流水号的应用场景，以作为流水号设计方案的靶向标的：
SOA架构体系是应用系统专业化、复杂化发展的必然结果。 早期银行只有一个综合业务系统，所有的业务都在一个系统里实现，随着业务发展越来越复杂、越来越精细化各类专业业务系统由此诞生，原来一站式服务调用不适用了，要完成一个应用场景需要穿透三四个、乃至七八个应用系统。对于每一个后端应用系统来说，都只提供单一的、独立的、原子的服务，而对于渠道和客户来说提供的是一个场景，这时候就需要使用流水号将对服务的调用和场景关联起来。这有点类似于浏览器的无状态请求通过sessionid进行关联类似，当然不完全相同。
我们看一个典型的SOA服务调用场景。
渠道应用是面向客户服务的，所以其服务的颗粒度是场景级的，比如说：渠道对客户提供的是一个开户服务（图中的系统A），而不会关注客户在哪里建立、卡在哪里建立、账户在哪里建立等。而原子服务层应用便是后台的专业应用系统，就是我们上文说的客户、卡、账户管理的系统（图中的系统C、D），但是这些系统随着专业化、服务化、原子化，其上业务场景的属性逐渐削弱（理想状态下是没有场景）；这时候，当当当当……服务整合层强势登场，它提供了一个从原子化的服务到面向客户场景的桥梁，对同类场景进行整合发布，即是面向个性化业务需求的专项业务系统。在联创智融，我们叫他业务整合平台，它提供了可视化的开发平台、完善的高并发、高可用与异常处理机制、成熟的监控运营平台，通过提供完整的服务整合框架让应用开发从技术细节中脱离出来，专注于应用场景的开发，充分利用现有应用系统服务能力实现差异化的业务需求……（不好意思，没忍住，插播一段广告）
之所以要铺垫这么多，是因为流水号的设计基本思路是对SOA架构体系的落地。分析上图流程，客户直接使用的是渠道类系统A，我们假设S001，代表此次请求；应用系统之间还有多次服务调用，假如A->B是A001，B->C是B001，B->D是B002。很明显，客户的一次服务请求是通过后台的三次服务交互完成的，客户的请求S001和后台的请求A001、B001、B002性质完全不同。客户的请求是基于应用场景的，是一个开户请求、转账请求；后台的服务调用是基于应用服务的，是一个客户核验、记账请求、人行转出请求。为了让整个应用链路都保持S001的服务请求状态，需要将S001向下游每一次服务调用传递，并和A001、B001、B002建立映射关系。
我们将对客户展现的、面向交易场景的流水号S001，叫做 全局流水号 ；将面向服务请求、代表一次服务调用的流水号A001叫做 请求流水号 。全局流水号有在一个请求链条中保持不变的含义。其中请注意全局流水号和交易场景以及客户服务的区别，详见下图。一次客户服务指的是客户一次业务办理的整个生命周期，可以称为一个会话或者一个session，在这个会话周期内，客户可以办理多个业务（活转定、理财、取现……）而不用重复验证身份，新一代银行可以做到一次支付、一次验密、一次打印等。一个交易场景就是客户具体办理一个业务（存款），其中又可能涉及对后台的多次服务请求，比如客户身份核验就是在正式办理业务之前的一个预处理的步骤，但是也需要柜面和后台交互，这样在一个交易场景内，至少有两次到后台的用户请求。 客户会话级和交易场景级的流水号本次话题并不涉及，因为这两个状态主要在渠道类应用保持和使用，对于整体的应用架构体系并没有要求。
场景化的内容是否适合放到后端业务系统？
作为引申话题我们稍微展开一下：“场景化的业务内容是否适合放到后端业务系统？”。所谓场景化的业务指的是面向客户服务，而不是面向业务处理的业务逻辑，比如说客户校验、代理人信息、授权流程等。在很多银行的业务系统中，这些内容都在核心，这是历史遗留包袱，从上面的简单分析来看，这些内容都应该在场景层（也就是业务整合层）去实现。如果放到后端系统，会有几个问题：1、面向场景的业务处理要重复实现，没有必要且浪费效率；2、在专业化趋势下后端业务系统（主要是金融产品系统）并不需要此类业务信息，和本身的业务处理逻辑无关；3、从技术角度，场景化的内容如果放在后端，与之对应的将是全局流水号，但是后台系统的服务调用都是基于请求流水号，这个矛盾对于该笔流水的后续使用会产生很多不利影响，比如修改、数据整合等等。
本章从服务调用类型分析流水号的使用和关注的问题。根据个人经验对服务调用类型总结如下：
正向调用没什么特别需要说明的，就是一个正常的服务场景的调用。但是会涉及服务调用失败的情况下的重试情况，这时候要求下游系统能够辨别出重试交易，所以对于重试类服务，要求上游系统不能生成新的请求流水号，继续使用原请求流水号，如果下游系统上次服务调用时没有成功，则重新完成本次服务；如果已经成功完成，但是由于返回超时等原因，则不重复执行，直接返回交易已成功。
一些基本的规范说明：
这里的反向调用指的是原服务已经成功处理（也可能没有成功处理）的情况下，根据业务规定或者用户发起对原始服务进行逆操作，一般叫这类服务为冲正，对应的账务处理是抹账。在SOA架构体系下，需要遵循原路来、原路冲的处理原则，否则会因为找不到原始服务调用请求而冲正失败。
从数据完整性上也应该将交易链路中所有节点都做冲正操作，还原业务状态、回写账户、恢复额度等处理。所以从原则上，支持客户冲正的场景，在所有服务请求链路上，都应该提供相应服务的冲正服务，以便基于场景冲正时进行调用。
冲正是一个业务概念，可以是客户发起的，也可能是系统在交易失败后自动发起的。对于客户发起的冲正，其面向的是一个完整的交易请求，也就是全局流水号；对于系统间自动冲正，其面向的是一次服务调用，所以使用请求流水号。也就是说，需要在人机交互切面上（渠道），进行全局流水号和请求流水号的转换，客户在主动发起冲正时，输入的是全局流水号，而渠道需要根据此全局流水号，找到原始的请求流水号，并使用此请求流水号向下游系统发起冲正。下游系统再转换为本系统的请求流水号发起后续冲正服务调用，以此完成整个交易链路的反向冲正。
系统间冲正应使用请求流水号的第二个原因是，部分业务场景可能涉及到对统一系统的多次服务调用，而冲正时可能只冲正部分服务。这时候如果使用全局流水号就无法将前后多次调用的请求区分开，比如某些银行在跨分支行记账时，对记账失败的流水只冲正当前节点，而不是对整个交易请求进行冲正。
也有一些银行系统为了简化系统调用关系，只冲账务性流水，而对中间的业务状态（比如中间业务的状态、支付的状态等）并不关注，为了简单起见，直接到核心冲正站账务流水，这种方式也叫抹账。根据我们上面的分析，这时候如果使用请求流水号则找不到当前业务的交易流水，需要使用全局流水号进行冲正。
总结：原则上，对于冲正业务，客户输入的应该是全局流水号，而系统服务调用应使用请求流水号；但是不能一概而论，需要根据业务场景分析是对整个业务场景的冲正还是一次服务调用的冲正。
基于单笔业务流水的后续操作，比如对原业务流水的查询、补录、修改等业务动作，严格来说冲正也属于这类操作；将冲正与此类业务分开主要是因为此类业务可能与原服务调用链路不一致。参考下图，有可能原始业务出于组装服务场景的需要，经过了B系统，而后续业务因为指向性、针对性较明确，不需要复杂的处理逻辑，这时候可以直接调用C系统的其它服务。
对于此类业务，除需要传递本业务的全局流水号、请求流水号以外，还需要将原业务的流水号作为服务调用参数传递。 这类服务应使用全局流水号还是请求流水号？ 这又是一个没有标准答案的问题。如果后续业务的服务调用路径和原业务调用路径一致，比如说原业务是A->B->C->D，后续业务也是A->B->C->D，那么此时可以使用“原业务请求流水号”作为服务参数；如果调用路径不一致，比如说后续业务是后续业务也是A->B->D，那么使用“原业务请求流水号”作为调用参数则找不到原业务流水，更无从谈起后续业务。参考上图，其实是一个错误的示例，你发现了吗？🙃
批量业务指的是前台提交一个文件，或者直接在页面上录入多笔，进行提交的场景。与单笔业务不同的是，批量业务中一个业务流水号对应多个业务明细，为了标记每一笔业务明细，需要对每一笔业务明细都生成独立的流水号。这涉及到两种模式：真批量和假批量。
在此我们不讨论两种模式的优劣，从对流水号的应用来说，批量数据在哪里拆解，就会在哪个系统产生流水号与批量数据明细号的对应关系。如果在前端拆解，则全局流水号和业务明细是一一对应关系，如下表。
如果在后端拆解，则全局流水号和业务明细是一对多的关系，这时候与业务明细对应的是后台的系统内业务流水号，如下表。
好，该死的问题又来了： 应该使用真批量还是假批量？ 这一次我们可以做一个有倾向性的回答：请尽可能的使用真批量。从业务角度，批量业务是后台应用本身应提供的一种服务；从技术角度，假批量对性能、网络消耗、客户体验等方面都不佳。从流水号使用的角度，对批量业务的查询应基于全局流水号和批量业务序号两个条件查询。如果是对后台交易流水的查询，则可以通过全局流水号查询出整个批量信息后，再对具体某笔后台流水定位。总之在后台实现批量没有任何业务逻辑上的困难。
TO BE CONTINUED……
Ⅲ 什么是SOA架构
SOA架构即面向服务架构。
面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
(3)soa架构教程扩展阅读:
SOA具有以下五个特征：
1、可重用
一个服务创建后能用于多个应用和业务流程。
2、松耦合
服务请求者到服务提供者的绑定与服务之间应该是松耦合的。因此，服务请求者不需要知道服务提供者实现的技术细节，例如程序语言、底层平台等等。
3、明确定义的接口
服务交互必须是明确定义的。Web服务描述语言（Web Services Description Language，WSDL）是用于描述服务请求者所要求的绑定到服务提供者的细节。WSDL不包括服务实现的任何技术细节。服务请求者不知道也不关心服务究竟是由哪种程序设计语言编写的。
4、无状态的服务设计
服务应该是独立的、自包含的请求，在实现时它不需要获取从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当产生依赖时，它们可以定义成通用业务流程、函数和 数据模型。
5、基于开放标准
当前SOA的实现形式是Web服务，基于的是公开的W3C及其他公认标准．采用第一代Web服务定义的SOAP、WSDL和UDDI以及第二代Web服务定义的WS-*来实现SOA。
Ⅳ 什么是SOA架构图
SOA的核心主体是服务。所谓“服务（Service）” ，从业务角度而言，服务是一个可重复的经过标准封装的任务，例如: 检查帐号余额;开新帐户 等等…。SOA的目标是通过服务的流程化来实现业务的灵活性，所谓流程（Process）是由一系列相互关联的任务所组成，实现一个具体的业务功能。一个流程可以由一系列服务来实现。
标准架构图如下：
耦合关系
SOA架构在松耦合解耦过程也发展到了最后的境界。传统软件将软件之中核心三部分网络连接、数据转换、业务逻辑全部耦合在一个整体之中，形成“铁板一块”的软件，“牵一发而动全身”，软件就难以适应变化。分布式对象技术将连接逻辑进行分离，消息中间件将连接逻辑进行异步处理，增加了更大的灵活性。消息代理和一些分布式对象中间件将数据转换也进行了分离。而SOA架构，通过服务的封装，实现了业务逻辑与网络连接、数据转换等进行完全的解耦。
总之，从科学哲学的角度来看，SOA是一个不断解构的过程，传统软件强调系统性，耦合度过高，所以需要松耦合（解耦）；SOA也是一个组件粒度的平衡，集成电路趋势是集成度越来越高，软件发展的趋势是相反的过程；SOA是架构，更是方法，反映了人们对哲学思想的追求的原动力。
按照这个特性，SOA基本上来说与WebService并不是同一个概念，SOA并不一定需要WebService实现，理论上可以在其他技术体系下，实现SOA。但事实上，到目前为止，能够实现SOA架构风格的技术就是WebService，因为它的特性和厂商的支持力度，使得WebService成为了实现SOA实现技术的事实标准。也正因为WebService技术的成熟，才使得已经提出10多年了的SOA思想和概念，得以能够实现落地，成为一种可以使用的技术。这也就是回答了SOA和WebService的关系。
Ⅳ 什么是SOA架构，能不能简单通俗点说一下…谢谢！
SOA（Service-oriented architecture，面向服务架构）。1996年，Gartner最早提出SOA。2002年12月，Gartner提出SOA是"现代应用开发领域最重要的课题"，还预计到2008年，SOA将成为占有绝对优势的软件工程实践方法，主流企业现在就应该在理解和应用SOA开发技能方面进行投资。 更好支持商业流程 SOA并不是一个新事物，IT组织已经成功建立并实施SOA应用软件很多年了，BEA、IBM、等厂商看到了它的价值，纷纷跟进。SOA的目标在于让IT变得更有弹性，以更快地响应业务单位的需求，实现实时企业（Real-Time Enterprise，这是Gartner为SOA描述的愿景目标）。而BEA的CIO Rhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA，并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户化和人员技能的投入等方面取得了不错的成绩。 SOA是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和方法（例如消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。 SOA也不仅仅是一种开发的方法论–它还包含管理。例如，应用SOA后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模块。其原理是，通过分析服务之间的相互调用，SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。 SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户的（各种）需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能通过不断开发新应用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是，基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的–这是从上向下看的。这种角度同一般的从可用技术所驱动的商业视角是相反的。服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。相反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。 企业流程（enterprise process）是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方法。例如，会计可能是企业服务系统的一个组件–但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务组件在流程和逻辑实现过程中的装配操作。理解业务流程是定制服务的关键所在。 有利于企业业务的集成 传统的应用集成方法（点对点集成、企业消息总线或中间件的集成（EAI）、基于业务流程的集成）都很复杂、昂贵，并且不灵活。这些集成方法难于快速适应基于企业现代业务变化不断产生的需求。基于面向服务架构 (SOA) 的应用开发和集成可以很好的解决其中的许多问题。 SOA 描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。 不同于传统的应用集成方法，在 SOA 中，围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统，如 RPC、CORBA、DCOM、EJB 和 RMI，也同样如此。可是它们的实现都不是很完美的，在权衡交互性以及标准定制的可接受性方面总是存在问题。SOA 试图排除这些缺陷。因为几乎所有的通信中间件系统都有固定的处理模式，如RPC 的功能、CORBA 的对象等等。然而，服务既可以定义为功能，又可同时对外定义为对象、应用等等。这使得 SOA 可适应于任何现有系统，并使得系统在集成时不必刻意遵循任何特殊定制。 SOA 帮助企业信息系统迁移到"leave-and-layer"架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 Web 服务接口，这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，SOA 可以将系统和应用迅速转换为服务。SOA 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等 IT 架构中的功能和数据。因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能，所以基于SOA的应用能更快地应对市场变化，为使企业业务部门设计开发出新的功能应用
Ⅵ 什么是SOA架构
1. SOA并不是一个新事物，IT组织已经成功建立并实施SOA应用。
2. SOA架构，是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。
3. 通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活，且尽可能的与第三方软件产品互补兼容，以达到快速扩展，满足或响应市场或客户需求的多样化、多变性。
4. SOA体系架构带来的主要观点是业务驱动IT，即业务驱动和业务更加紧密地联系在一起。以粗粒度的业务服务作为基础来对公司业务进行建模，这样就可以产生简洁的业务和系统视图。
Ⅶ 如何通俗易懂地解释什么是SOA
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
特点：
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。
SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者更迅速、更可靠、更具重用性地架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。
Ⅷ 什么是SOA架构，能不能简单通俗点说一下…谢谢！
一、SOA（Service-orientedarchitecture，面向服务架构）。1996年，Gartner最早提出SOA。2002年12月，Gartner提出SOA是"现代应用开发领域最重要的课题"，还预计到2008年，SOA将成为占有绝对优势的软件工程实践方法，主流企业现在就应该在理解和应用SOA开发技能方面进行投资。二、SOA架构的作用：1，更好支持商业流程。2，有利于企业业务的集成。
Ⅸ SOA 架构
4.2.3.1 SOA 的概念
SOA 是一种架构模型，它将应用程序的不同功能单元(即服务)通过服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。
不同的厂商和个人对 SOA 有如下不同的定义:
(1)Service-architecture.com 将 SOA 定义为: “本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。”
(2)Looselycoupled.com 将 SOA 定义为: “按需连接资源的系统。在 SOA 中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，SOA 规定了资源间更为灵活的松散耦合关系。”
(3)Gartner 则将 SOA 描述为: “客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成……SOA 与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。”
虽然不同厂商或个人对 SOA 有着不同的理解，但是从以上定义可以看出 SOA 的几个关键特性: 一种粗粒度、松散耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。
SOA 并不是一种现成的技术，而是一种架构和组织 IT 基础结构及业务功能的方法。SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元(服务)的模型。SOA要求开发人员将应用设计为服务的集合，以及跳出应用本身进行思考，考虑现有服务的重用，或思索他们的服务如何能够被其他项目重用。“单独的”、“独立的”、“封装完善的”服务所具有的一个关键的好处是，可以采用多种不同方法将它们组合成较大型的服务，由此来实现重用。
4.2.3.2 构成 SOA 的技术
SOA 本身是 “如何将软件组织在一起” 的抽象概念。它依赖于用 XML 和 Web 服务实现并以软件的形式存在的更加具体的观念和技术。此外，它还需要安全性、策略管理、可靠消息传递以及会计系统的支持，从而有效地工作。还可以通过分布式事务处理和分布式软件状态管理来进一步地改善它。
SOA 服务和 Web 服务之间的区别在于设计。SOA 概念并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解以及如何交互。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面，Web 服务在需要交互的服务之间如何传递消息有具体的指导原则; 从战术上实现 SOA 模型最常见的方式是通过HTTP 传递的 SOAP 消息。因而，从本质上讲，Web 服务是实现 SOA 的具体方式之一。
虽然 Web 服务是实现 SOA 最好的方式，但是 SOA 并不局限于 Web 服务。其他使用WSDL 直接实现服务接口并且通过 XML 消息进行通信的协议也可以包括在 SOA 之中。例如 CORBA 和 IBM 的 MQ 系统通过使用能够处理 WSDL 的新特征也可以参与到 SOA 中来。如果两个服务需要交换数据，那么它们还会需要使用相同的消息传递协议，但是数据接口允许相同的信息交换。
4.2.3.3 SOA 的基本特征
SOA 是一种粗粒度、松散耦合的软件架构，其服务之间通过简单、精确定义的接口进行通讯，不涉及底层编程接口和通讯模型。这种模型具有下面几个特征(http://tech.ccidnet.com/art/1110/20060210/425863_ 1.html)［U1］。
(1)松散耦合。服务请求者到服务提供者的绑定与服务之间是松耦合的。松散耦合旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。服务接口作为与服务实现分离的实体而存在，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台等等。服务请求者往往通过消息调用操作请求消息和响应而不是通过使用文件格式。服务实现的修改完全不会影响到服务的使用者。
(2)粗粒度服务。服务粒度指的是服务所公开功能的范围，一般分为，细粒度和粗粒度。其中，细粒度服务是那些能够提供少量业务流程可用性的服务。粗粒度服务是那些能够提供高层业务逻辑的可用性服务。粗粒度服务可以灵活组合稳定性强、重用性高的细粒度服务，而快速形成新的业务逻辑。虽然细粒度的接口为请求者应用程序提供了更多的灵活性，它同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。粗粒度接口保证服务请求者将以一致的方式使用服务。面向服务的体系结构不要求使用粗粒度接口，但是推荐使用它们作为外部集成的最佳实践。服务编排可以用来创建运行由细粒度操作组成的业务流程的粗粒度接口。
(3)标准化的接口。服务描述的重点在于与几部分交互所用的操作服务、调用操作的消息、构造这种消息的细节和关于向何处发送用于构造这种消息的处理细节的消息。通过服务接口的标准化描述，从而使得该服务可以提供给在任何异构平台和任何用户接口使用。该接口隐藏了实现服务的细节，允许独立于实现服务基于的硬件或软件平台和编写服务所用的编程语言使用服务。
(4)无状态服务。服务应该是独立的、自包含的请求，在实现时它不需要从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当需要依赖时，它们最好定义成通用业务流程、函数和数据模型，而不是实现构件比如会话密钥。当然，请求者应用程序需要服务调用之间的持久状态，但是这不应该与服务提供者分开。
