SOA 架构
4.2.3.1 SOA 的概念
soa构建层 soa架构三层
soa构建层 soa架构三层
soa构建层 soa架构三层
SOA 是一种架构模型，它将应用程序的不同功能单元(即服务)通过服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，它于实现服务的硬件平台、作系统和编程语言。
不同的厂商和个人对 SOA 有如下不同的定义 将 SOA 定义为: “本质上是服务的。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是定义、封装完善、于其他服务所处环境和状态的函数。” 将 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 是一种粗粒度、松散耦合的软件架构，其服务之间通过简单、定义的接口进行通讯，不涉及底层编程接口和通讯模型。这种模型具有下面几个特征( 1.html)［U1］。
(1)松散耦合。服务请求者到服务提供者的绑定与服务之间是松耦合的。松散耦合旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。服务接口作为与服务实现分离的实体而存在，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台等等。服务请求者往往通过消息调用作请求消息和响应而不是通过使用文件格式。服务实现的修改完全不会影响到服务的使用者。
(2)粗粒度服务。服务粒度指的是服务所公开功能的范围，一般分为，细粒度和粗粒度。其中，细粒度服务是那些能够提供少量业务流程可用性的服务。粗粒度服务是那些能够提供高层业务逻辑的可用。粗粒度服务可以灵活组合稳定性强、重用性高的细粒度服务，而快速形成新的业务逻辑。虽然细粒度的接口为请求者应用程序提供了更多的灵活性，它同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。粗粒度接口保证服务请求者将以一致的方式使用服务。面向服务的体系结构不要求使用粗粒度接口，但是使用它们作为外部集成的实践。服务编排可以用来创建运行由细粒度作组成的业务流程的粗粒度接口。
(3)标准化的接口。服务描述的重点在于与几部分交互所用的作服务、调用作的消息、构造这种消息的细节和关于向何处发送用于构造这种消息的处理细节的消息。通过服务接口的标准化描述，从而使得该服务可以提供给在任何异构平台和任何用户接口使用。该接口隐藏了实现服务的细节，允许于实现服务基于的硬件或软件平台和编写服务所用的编程语言使用服务。
(4)无状态服务。服务应该是的、自包含的请求，在实现时它不需要从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当需要依赖时，它们定义成通用业务流程、函数和数据模型，而不是实现构件比如会话密钥。当然，请求者应用程序需要服务调用之间的持久状态，但是这不应该与服务提供者分开。
什么是SOA架构?
SOA（Serv-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 帮助企业信息系统迁移到"lee-and-layer"架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 Web 服务接口，这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，SOA 可以将系统和应用迅速转换为服务。SOA 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等 IT 架构中的功能和数据。因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能，所以基于SOA的应用能更快地应对市场变化，为使企业业务部门设计开发出新的功能应用。
B/S架构C/S架构SOA架构分别是什么呀_c/s架构和b/s架构
三层架构（表现层、业务逻辑层、数据访问层），现在一般软件项目采用的都是应用、中间件和data这样的三层.是现在一般软件项目的主流架构.
-SOA（servoriented）是面向服务的体系架构,主要是一种软件开发的思想.按照不同对象的需求开发、封装相应的程序，并且于实现服务的硬件平台、作系统和编程语言,这样可以有效节省投资，并大大提高软件的扩展性.
京东云百度云,这些称为云的是什么东西?
电脑中的云是云技术的意思，是分布式计算技术的一种，云技术（Cloud technology）是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。
云技术最基本的概念，是透过网络将庞大的计算处理程序自动分拆成无数个较小的子程序，再交由多部所组成的庞大系统经搜寻、计算分析之后将处理结果回传给用户。透过这项技术，网络服务提供者可以在数秒之内，达成处理数以千万计甚至亿计的信息，达到和“超级计算机”同样强大效能的网络服务。
云计算技术体系结构分为4层：物理资源层、资源池层、管理中间件层和SOA构建层，如图所示。物理资源层包括计算机、存储器、网络设施、数据库和软件等；
资源池层是将大量相同类型的资源构成同构或接近同构的资源池，如计算资源池、数据资源池等。构建资源池更多是物理资源的集成和管理工作，例如研究在一个标
准集装箱的空间如何装下2000个、解决散热和故障替换的问题并降低能耗；管理中间件负责对云计算的资源进行管理，并对众多应用任务进行调度，
使资源能够高效、安全地为应用提供服务；SOA构建层将云计算能力封装成标准的Web
Servs服务，并纳入到SOA体系进行管理和使用，包括服务注册、查找、访问和构建服务工作流等。管理中间件和资源池层是云计算技术的最关键部
分，SOA构建层的功能更多依靠外部设施提供。
soa是什么
SOA
（面向服务的架构）
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该于实现服务的硬件平台、作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
定义介绍
面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件交互的人为依赖性。
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Serv技术之后的自然延伸。
SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。
SOA系统是一种企业通用性架构。
SOA（Serv-Oriented-Architecture）面向服务的架构，是把服务拼装形成应用整体的架构。SOA中的服务是指“可重用的业务模块”。微服务架构与SOA很像，同样都是将整个应用拆分，形成的业务模块的思路。但在许多关键点上，微服务架构与SOA不同。
SOA很大程度上依赖于基于XML的消息格式和基于SOAP的通信协议，微服务架构大量的依赖于REST和JSON。
SOA架构中有ESB（服务总线）的概念，ESB负责服务之间的通信转发和接口适配，在SOA实现中，ESB处于核心地位，有很多专业的ESB厂商提供ESB中间件，例如WebSphere ESB、Oracle ESB、Dubbo等。
ESB本身是非常“重”的技术，在云化软件体系和微服务架构中，强调更轻量级、更迅速、去中心化的技术，所以在微服务架构中，不需要ESB，而通过API这样的技术来负责服务接口转发。（由于软件全面云化是一个过程、需要适配、调整来全面完成转变，所以在一段时间内，面对大量的遗留系统，ESB仍然会充当微服务改造过程中用来适配老系统的一个重要组件。）
SOA的设计思路是把一些组件和服务，通过服务总线组装，形成更大的应用系统（从小到大）；而微服务的设计思路是把应用拆分成自治的小的服务（从大到小）。
SOA设计架构强调分层，通常会分为展现层、业务层、总线层和数据层。微服务架构中的服务更松散。
SOA中的服务不强调业务领域的自治性，微服务架构强调基于领域的服务自治性。
从上述的对比来看，二者的区别基本上都在实现方式上。微服务与SOA本质上是同一种设计思想在不同时代的不同实现。过去在容器、K8S技术没有出现的年代，造就了SOA的实现方式。
soa架构的优点有哪些？
利用SOA架构开发的时候，其好处有以下三点：
1、编码灵活性
可基于模块化的底层服务，采用不同组合方式创建高层服务，从而实现重用,这些都体现了编码的灵活性.。此外由于服务使用者不直接访问服务提供者，这种服务实现方式本身也可以灵活使用。
2、明确开发人员角色
可以让熟悉BES的开发人员可以集中精力在重用访问层，协调层开发人员则无须特别了解BES的实现，而将精力放在解决高价值的业务问题上。
3、支持多种客户类型
借助定义的服务接口和对XML，Web服务标准的支持，可以支持多种客户类型。
包括PDA，手机等新型访问渠道。
管理中间件层和soa构建层是云计算技术的最关键部分对吗
云计算关键技术 云计算是分布式处理、并行计算和网格计算等概念的发展和商业实现，其技术实质是计算、存储、、应用软件等IT软硬件资源的虚拟化，云计算在虚拟化、数据存储、数据管理、编程模式等方面具有自身独特的技术。云计算的关键技术包括以下几个方向： 虚拟机技术 虚拟机，即虚拟化是云计算底层架构的重要基石。在虚拟化中，虚拟化软件需要实现对硬件的抽象，资源的分配、调度和管理，虚拟机与宿主作系统及多个虚拟机间的隔离等功能，目前典型的实现（基本成为事实标准）有Citrix Xen、VMware ESX 和Microsoft Hype-V等。 数据存储技术 云计算系统需要同时满足大量用户的需求，并行地为大量用户提供服务。因此，云计算的数据存储技术必须具有分布式、高吞吐率和高传输率的特点。目前数据存储技术主要有Google的GFS（Google File System，非开源）以及HDFS（Hadoop Distributed File System，开源），目前这两种技术已经成为事实标准。 数据管理技术 云计算的特点是对海量的数据存储、读取后进行大量的分析，如何提高数据的更新速率以及进一步提高随机读速率是未来的数据管理技术必须解决的问题。云计算的数据管理技术最的是谷歌的BigTable数据管理技术，同时Hadoop开发团队正在开发类似BigTable的开源数据管理模块。 分布式编程与计算 为了使用户能更轻松的享受云计算带来的服务，让用户能利用该编程模型编写简单的程序来实现特定的目的，云计算上的编程模型必须十分简单。必须保证后台复杂的并行执行和任务调度向用户和编程人员透明。当前各IT厂商提出的云的编程工具均基于Map-Reduce的编程模型。 虚拟资源的管理与调度 云计算区别于单机虚拟化技术的重要特征是通过整合物理资源形成资源池，并通过资源管理层（管理中间件）实现对资源池中虚拟资源的调度。云计算的资源管理需要负责资源管理、任务管理、用户管理和安全管理等工作，实现故障的屏蔽，资源状况监视，用户任务调度，用户身份管理等多重功能。 云计算的业务接口 为了方便用户业务由传统IT系统向云计算环境的迁移，云计算应对用户提供统一的业务接口。业务接口的统一不仅方便用户业务向云端的迁移，也会使用户业务在云与云之间的迁移更加容易。在云计算时代，SOA架构和以Web Serv为特征的业务模式仍是业务发展的主要路线。 云计算相关的安全技术 云计算模式带来一系列的安全问题，包括用户隐私的保护、用户数据的备份、云计算基础设施的防护等，这些问题都需要更强的技术手段，乃至法律手段去解决。
什么是SOA架构,能不能简单通俗点说一下...谢谢
面向服务的体系结构（serv-oriented ，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该于实现服务的硬件平台、作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求体系结构（Common Object Request Broker ，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。
然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Servs Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Intece Definition Language，IDL）可比了。
Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的作和业务中所使用的软件的作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。
此外，动态业务的工作流不仅可以包括部门之间的作，甚至还可以包括与不为您控制的外部合作伙伴进行的作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和作策略的形式。
，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。
我可以用面向服务的体系结构做什么？
对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。
下面举一个具体的例子。一个服装零售组织拥有 500 家连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务作基本上都保持不变。这里，业务接口可以作少许改变，而内部作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。
另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。
为了延续内部改变的观念，IT 可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。
垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。
正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven ，MDA）。