SOA（面向服务的架构）

面向服务的架构（SOA）是一个组件模型，它将应用程序的不一样功能单元（称为服务）经过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操做系统和编程语言。
这使得构建在各类各样的系统中的服务能够以一种统一和通用的方式进行交互。
Service-Oriented Architecture           面向服务的体系结构        SOA          组件模型

定义介绍
面向服务架构，它能够根据需求经过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。
服务层是SOA的基础，能够直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
SOA是一种粗粒度、松耦合服务架构，服务之间经过简单、精肯定义接口进行通信，不涉及底层编程接口和通信模型。
SOA能够看做是B/S模型、XML（标准通用标记语言的子集）/Web Service技术以后的天然延伸。
SOA将可以帮助软件工程师们站在一个新的高度理解企业级架构中的各类组件的开发、部署形式，
它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。
较之以往，以SOA架构的系统可以更加从容地面对业务的急剧变化。

体系结构   松耦合的系统
这种具备中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。
松耦合系统的好处有两点，一点是它的灵活性，另外一点是，当组成整个应用程序的每一个服务的内部结构和实现逐渐地发生改变时，
它可以继续存在。与之相反，紧耦合意味着应用程序的不一样组件之间的接口与其功能和结构是紧密相连的，
于是当须要对部分或整个应用程序进行某种形式的更改时，它们就显得很是脆弱。
对松耦合的系统的须要来源于业务应用程序须要根据业务的须要变得更加灵活，以适应不断变化的环境，
好比常常改变的政策、业务级别、业务重点、合做伙伴关系、行业地位以及其余与业务有关的因素，这些因素甚至会影响业务的性质。
咱们称可以灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦须要，就能够对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物，但它倒是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年。
虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，可是其总体设计倒是面向服务的。
因为它考虑到了系统内的对象，因此虽然 SOA 是基于对象的，可是做为一个总体，它却不是面向对象的。不一样之处在于接口自己。
SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），
它已经出现很长时间了，其定义的概念与 SOA 类似。
然而， SOA 已经有所不一样了，由于它依赖于一些更新的进展，
这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。
经过使用基于XML（标准通用标记语言的子集） 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，
服务已经转到更动态且更灵活的接口系统中，非之前 CORBA 中的接口描述语言（Interface 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 模型大的改变。
这种分工，就是让开发人员集中精力于建立做为服务定义的功能单元，
而让架构师和建模人员集中精力于如何将这些单元适当地组织在一块儿，它已经有十多年的历史了，
一般用统一建模语言（Unified Modeling Language，UML），而且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。
对于面向同步和异步应用的，基于请求/响应模式的分布式计算来讲，SOA是一场革命。
一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并做为服务呈现给消费者或客户端。
这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。
应用开发人员或者系统集成者能够经过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来讲，一个服务能够用.NET或J2EE来实现，而使用该服务的应用程序能够在不一样的平台之上，使用的语言也能够不一样。

SOA服务具备平台独立的自我描述XML文档。
Web服务描述语言（WSDL， Web Services Description Language）是用于描述服务的标准语言。
SOA 服务用消息进行通讯，该消息一般使用XML Schema来定义（也叫作XSD， XML Schema Definition）。
消费者和提供者或消费者和服务之间的通讯多见于不知道提供者的环境中。服务间的通信也能够看做企业内部处理的关键商业文档。
在一个企业内部，SOA服务经过一个扮演目录列表（directory listing）角色的登记处（Registry）来进行维护。
应用程序在登记处（Registry）寻找并调用某项服务。
统一描述，定义和集成（UDDI， Universal Description， Definition， and Integration）是服务登记的标准。
每项SOA服务都有一个与之相关的服务品质（QoS， quality of service）。
QoS的一些关键元素有安全需求（例如认证和受权），可靠通讯（译注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。），以及谁能调用服务的策略。
不一样种类的操做系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这即是IT企业的现状。
一些现存的应用程序被用来处理当前的业务流程（business processes），
所以从头创建一个新的基础环境是不可能的。
企业应该能对业务的变化作出快速的反应，
利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求，
为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个能够支持有机业务（organic business）的构架。
SOA凭借其松耦合的特性，使得企业能够按照模块化的方式来添加新服务或更新现有服务，以解决新的业务须要，提供选择从而能够经过不一样的渠道提供服务，并能够把企业现有的或已有的应用做为服务， 从而保护了现有的IT基础建设投资。

SOAP， WSDL， UDDI
WSDL，UDDI和SOAP是SOA基础的基础部件。
WSDL用来描述服务；UDDI用来注册和查找服务；而SOAP，做为传输层，用来在消费者和服务提供者之间传送消息。
SOAP是Web服务的默认机制，其余的技术为能够服务实现其余类型的绑定。
一个消费者能够在UDDI注册表（registry）查找服务，取得服务的WSDL描述，而后经过SOAP来调用服务。

WS-I Basic Profile
由Web服务互用性组织（Web Services Interoperability Organization）提供，是SOA服务测试与互用性所须要的核心构件。
服务提供者可使用Basic Profile测试程序来测试服务在不一样平台和技术上的互用性。
J2EE 和 .Net  尽管J2EE和.NET平台是开发SOA应用程序经常使用的平台，
但SOA不只限于此。像J2EE这类平台，不只为开发者天然而然地参与到SOA中来提供了一个平台，
还经过他们内在的特性，将可扩展性，可靠性，可用性以及性能引入了SOA世界。
新的规范，
例如 JAXB（Java API for XML Binding），用于将XML文档定位到Java类；
JAXR（Java API for XML Registry）用来规范对UDDI注册表（registry）的操做；
XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1

优势
服务导向架构并非一种全新的解决方案；相反，SOA是技术与架构的天然进化。系统架构一直在不断进步，与商业保持高度一致。
系统设计师与商家很早就认识到将技术与商业流程相协调的重要性，包括充分应用并合理化技术资源，以及为商业提供更好的支持。
SOA也在必定程度上源于早已有之的企业架构理论。
企业架构对技术进行评估，可是更重要的是，它关注整个企业和所有的商业流程并提供了作出技术决策的背景信息。
SOA工具则融合了互联网技术，如HTTP和XML，以及综合技术，如消息总线、转译技术和链接技术。
虚拟桌面基础设施、资源平衡和应用程序级高可用性多是其它的将来应用实例。这些解决方案有一些技术的和经济的障碍。
这些障碍必需要在虚拟化普遍应用前克服。可是，考虑到虚拟化的重点，这些障碍已经在开始克服。
虚拟化还将成为SOA(面向服务的架构)技术应用的推进因素。 面向服务的体系结构基于这些实际活动或业务服务进行组织，而不是造成公司所维护的不一样的信息竖井 (Silo)。

优点
一，SOA可经过互联网服务器发布，从而突破企业内网的限制，实现与供应链上下游伙伴业务的紧密结合。
    经过SOA架构，企业能够与其业务伙伴直接创建新渠道，创建新伙伴的成本得以下降。
二，SOA与平台无关，减小了业务应用实现的限制。要将企业的业务伙伴整合到企业的“大”业务系统中，
    对其业务伙伴具体采用什么技术没有限制。
三， SOA具备低耦合性特色，业务伙伴对整个业务系统的影响较低。在企业与各业务伙伴关系不断发生变化的状况下，节省的费用会愈来愈多。
四， SOA具备可按模块分阶段进行实施的优点。能够成功一步再作下一步，将实施对企业的冲击减小到最小。
五， SOA的实施可能并不具备成本显著性。这要分三种状况加以讨论：
    (1)当企业从零开始构建业务系统时，采用SOA架构与不采用SOA架构成本可看作是相同的。
    (2)当企业业务发展或发生企业重组等变化而原有系统不能知足须要，而须要重构业务系统时，
       采用SOA架构与不采用SOA架构成本可看作是相同的。
    (3)当企业业务发生缓慢变化并可预见到未来须要重构业务系统时，因为能够按模块分阶段逐步实施SOA以适应变化的须要，
       这样企业不需一下投入一大笔经费进行系统改造，而是根据企业业务发展状况和资金状况逐步投入，缓解了信息投入的压力。
       
SOA优点
SOA不一样于现有的分布式技术之处在于大多数软件商接受它并有能够实现SOA的平台或应用程序。
SOA伴随着无处不在的标准，为企业的现有资产或投资带来了更好的重用性。
SOA可以在最新的和现有的应用之上建立应用；SOA可以使客户或服务消费者免予服务实现的改变所带来的影响；
SOA可以升级单个服务或服务消费者而无需重写整个应用，也无需保留已经再也不适用于新需求的现有系统。
总而言之，SOA以借助现有的应用来组合产生新服务的敏捷方式，提供给企业更好的灵活性来构建应用程序和业务流程。

发展效益
A. 平衡最初的旧系统投资(Leverage initial investment)：
组织过去所投资的系统、软硬体，若是能再利用等于赋予其新的价值，这也替组织下降成本并增长竞争力。
B. 基础建设的便利性(Infrastructure Commoditization)：让全部的应用程式能相互沟通(互通性)。
C. 快速的接近市场(Faster time-to-market)：服务的重复使用(再利用)，来缩短过去的组织流程，更快速的提供服务来接近市场。
D. 减小支出(Reduce Cost)：服务的重复使用，可下降开发成本。由于开发新系统的成本，大部份比更新旧有系统来的花费大。
E. 减低风险(Risk mitigation)：开发新系统的风险远大于更新旧系统。
F. 持续改善商业流程的循环(Continuous improvement cycle for business process)
G. 中心流程处理(Process-centric processing)

服务品质
在企业中，关键任务系统（mission-critical system，译注：关键任务系统是指若是一个系统的可靠性对于一个组织是相当重要的，
那么该系统就是该企业的关键任务系统。
好比，电话系统对于一个电话促销企业来讲就是关键任务系统，而文字处理系统就不那么关键了。）
用来解决高级需求，例如安全性，可靠性，事物。
当一个企业开始采用服务架构做为工具来进行开发和部署应用的时候，基本的Web服务规范，像WSDL，SOAP，以及UDDI就不能知足这些高级需求。正如前面所提到的，这些需求也称做服务品质（QoS，quality of services）。
与QoS相关的众多规范已经由一些标准化组织（standards bodies）提出，
像W3C（World Wide Web Consortium）和OASIS（the Organization for the Advancement of Structured Information Standards）。
安全质量
Web服务安全规范用来保证消息的安全性。该规范主要包括认证交换， 消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准，
例如，SAML（as Security Assertion Markup Language）来实现web服务消息的安全。OASIS正致力于Web服务安全规范的制定。
可靠信度
在典型的SOA 环境中，服务消费者和服务提供者之间会有几种不一样的文档在进行交换。
具备诸如“仅且仅仅传送一次”（ once-and-only-once delivery），
“最多传送一次”（ at-most-once delivery），“重复消息过滤”（duplicate message elimination），
“保证消息传送”（guaranteed message delivery）等特性消息的发送和确认，在关键任务系统（mission-critical systems）中变得十分重要。
WS-Reliability 和 WS-ReliableMessaging是两个用来解决此类问题的标准。这些标准都由OASIS负责。
策略计划
服务提供者有时候会要求服务消费者与某种策略通讯。好比，服务提供商可能会要求消费者提供Kerberos安全标示，才能取得某项服务。
这些要求被定义为策略断言（policy assertions）。一项策略可能会包含多个断言。
WS-Policy用来标准化服务消费者和服务提供者之间的策略通讯。
控制能力
当企业着手于服务架构时，服务能够用来整合数据仓库（silos of data），应用程序，以及组件。
整合应用意味着例如异步通讯，并行处理，数据转换，以及校订等进程请求必须被标准化。
在SOA中，进程是使用一组离散的服务建立的。
BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用来控制这些服务的语言。WSBPEL也由OASIS负责。
管理能力
随着企业服务的增加，所使用的服务和业务进程的数量也随之增长，
一个用来让系统管理员管理全部运行在多相环境下的服务的管理系统就显得尤其重要。
WSDM（Web Services for Distributed Management）规定了任何根据WSDM实现的服务均可以由一个WSDM适应（WSDM-compliant）的管理方案来管理。其它的qos特性，
好比合做方之间的沟通和通信，多个服务之间的事务处理，都在WS-Coordination 和 WS-Transaction 标准中描述， 这些都是OASIS 的工做。
Web服务
在理解SOA和Web服务的关系上，常常发生混淆。
根据2003年4月的Gartner报道，Yefim V.Natis就这个问题是这样解释的：“Web服务是技术规范，而SOA是设计原则。
特别是Web服务中的WSDL，是一个SOA配套的接口定义标准：这是Web服务和SOA的根本联系。”
从本质上来讲，SOA是一种架构模式，而Web服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。
用Web服务来实现SOA的好处是你能够实现一个中立平台，来得到服务，
并且随着愈来愈多的软件商支持愈来愈多的Web服务规范，你会取得更好的通用性。

CRM(客户关系管理)
ERP(企业资源计划)

 

备注：随笔中内容来源于网上资料整理,仅供参考。