能不能简单的说一下SOA面向服务架构是什么意思? 要形象的，做好举个易理解的实例，不要百度百科！
就是在原有系统基础上实现信息互联互通。
soa架构原理实例 soa架构的内容
soa架构原理实例 soa架构的内容
soa架构原理实例 soa架构的内容
比如：
某人就职，要经过一系列手续，使用实现SOA的话，
人事系统直接拿系统的人员资料作为员工档案的基础
完成员工档案后，安排职务岗位，
这个确定后，财务系统有了这个人的工资标准，ERP中多了这个资源信息，IT部门自动开EMAIL，该人入职完成。
看上去很普通的功能，但如果这些系统都不是一家厂家实现的，实现难度相当大。
举一个需要使用SOA架构饿商业应用实例，并说明使用SOA后会带来什么好处
作为的百货商业之一，大商遍布全国各地的店铺、每天不计其数的运营数据、丰富多种的促销优惠政策、数以十万计的员工日常考核管理、激烈的行业竞争等“内忧外患”，每时每刻都给大商的 IT 架构施加着巨大的压力。各自为政的 POS、MIS、ERP、CRM 等系统，汇集了手数据和信息却无法及时、精准地汇总至；同时，多个异构的系统之间无法进行横向跨系统共享，导致了大量冗余重复的数据和信息浪费了有限的资源空间，造成IT 系统维护成本的虚高。
锐易特通过自主知识产权产品--企业服务总线（ESB）、企业应用门户（Portal）等信息整合套件为大商构建出了一个健壮、灵活、高效的全新 IT 架构，形成 了新一代基于 SOA 架构的 ERP 平台，实现了数据大集中，搭建出可供全国一百多家分 店访问的企业应用门户以及全国通惠的会员、团购卡系统。它们从根本上梳理了大商原有分散、的各种应用系统、数据资源和互联网资源，贯穿大商各个业务流程。
什么是soa roa 谈谈两种技术的原理及适用场景
本真REST当然是对面向资源架构的一种实现，而并非一种纯粹的技术决策。所以当讨论本真REST时，真正应该讨论的问题是：其基础支撑——面向资源的架构（ROA）——是否真的适合作为你的SOA实现。
为正确评估该问题，让我们首先回想一下SOA的架构风格，它是基于企业业务架构的功能性分解，并且引入了两个高层次的抽象：企业业务服务和业务流程。企业业务服务代表的是现有IT能力（和企业的业务功能相一致）。业务流程编排业务服务，并定义业务的整体功能。
而REST是一组被称之为面向资源架构（ROA）的架构准则。ROA构建在资源这一概念之上；每个资源都是一个能够直接访问的分布式组件,可通过一个标准的、通用的接口来处理。所以，面向资源的架构（ROA）其最根本的还是一种基于资源的分解[3]。
为了评估本真REST是否适用于面向SOA的实现，我们真正需要回答的问题是，“服务和资源之间到底是什么关系？”
服务 vs. 资源
何为服务？
在最简单的情况下，服务可以被定义为一个自包含、开发、可部署、可管理和可维护的软件实现，它从整体上为企业提供特定的与业务相关的功能，并且在设计上是“可集成的”。“服务”可以通过动词（verb）来定义（例如，“验证客户信用积分”，这描述了服务实现的业务功能）。
服务并不是某个编程结构或一组APIs，而是一个用于实现企业解决方案的架构（设计单元、实现以及维护）和部署构件。服务接口（尤其对某个给定的服务而言）定义服务功能，并且可由多种方式实现。存在两种基本的定义服务接口的方法——RPC风格和消息（messaging）风格，RPC风格实现使用服务调用语义并且通过服务接口中的一组参数来定义。而消息风格的服务接口被有效地固定（本质上只需要进行“执行”作）使用XML文档作为输入和输出（这和GoF设计模式非常相似）。在这种情况下，服务语义是由输入和输出消息的语义来确定[4]。
过去，服务通常被定义为一组方法的，但正如参考文献[2]中解释的那样，这些方法彼此相互[5]，但作为整体它们共享同一个命名空间，这样简化了对服务的管理。
何为资源？
在最简单的情况下，资源可以被定义为一个可直接访问的、开发的、可部署的、可管理的和可维护的软件构件，它支持特定的数据。资源可以通过名词（noun）来定义，比如“医生的预约”就描述了资源提供的数据。某一资源也可以和其他资源相关联并为它们提供引用（链接）。实际上，一个资源就类似于一个对象[6]，不过它是带有预定义（CRUD）接口语义的对象。
REST中的语义基于HTTP作集，如下所示[5]：
createResource——创建一个新的资源（以及相应的标示）– PUT
getResourceRepresentation——获取资源信息– GET
deleteResource ——删除资源（可选地包括相关联的资源）– DELETE（只是引用的资源），POST（当需要删除相关联的资源时使用）
modifyResource——更改资源— POST
getMetaInforatmion——取得资源元数据信息—HEAD
资源通过两部分定义：资源URL和资源所提供的所有作上定义的输入/输出参数[7]。这和服务不同，服务的方法之间是完全，并且能够以端点（endpoints）的方式部署，而资源上的方法遵循OO语义，这意味着所有的方法（除createResource以外）都必须依附于底层的某个资源（同一个URL）。
资源和服务之间的根本异
基于上述对资源和服务的定义，凭直觉它们显然是不同的。我们先继续深究这些别，然后再讨论它们是如何对最终架构产生影响的。
正如文献[6]中描述的：
REST不仅不是面向服务的，相反，面向服务和REST风马牛不相及
文献[7]中进一步阐明了二者之间的区别：
如果把WS-比作是互联网世界的RPC，那么REST就是互联网世界的数据库管理系统（DBMS）……传统的基于SOA的集成表现了不同软件构件之间通过各种过程或方法进行交互。REST有效地将每个软件构件看作一组数据库表，而这些构件之间使用SELECT, INSERT, UPDATE和DELETE来通信。（或如你所想的使用GET, PUT, POST, DELETE）。那业务逻辑放在哪里呢？在存储过程中？不太对，其实在触发器中。
这里我们用J2EE打个稍微不太恰当的比方。我们把服务想象成无状态会话bean，而资源想象成实体bean。
服务(或会话beans)作为控制执行所需的作，不管底层是哪个资源。打个比方，某个支出账户服务可能会用到账户ID、支出金额和支出所需账户。这样的服务可以支出任何现有账户。
资源（或实体bean）充当数据访问机制，其面对给定数据类型的某一实例。比如，为了从某一账户支出，需要先找到这一账户相关的信息，然后才能更新它，从而向所需账户进行支出。另外提醒一下，与能实现任意所需的方法的实体bean不同的是，一个REST资源只有一个更改资源的方法。这意味着真实的业务作——支出——只能编码成消息请求的一部分。
什么是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）。
SOA 架构
4.2.3.1 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架构指面向服务的体系结构，是一个组件模型，一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活，且尽可能的与第三方软件产品互补兼容，以达到快速扩展，满足或响应市场或客户需求的多样化、多变性。
它将应用程序的不同功能单元通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该于实现服务的硬件平台、作系统和编程语言。
SOA体系架构带来的是业务驱动IT，即业务驱动和业务更加紧密地联系在一起。以粗粒度的业务服务作为基础来对公司业务进行建模，这样就可以产生简洁的业务和系统视图；以业务服务为基础来实现的IT系统更灵活、更易于重用、也更快地应对企业业务需求的变化；以业务服务为基础，为业务服务模型和相关IT业务之间提供了更好的"可追溯性"。