SOA

 

    对这篇文章我有些东东我自己也不是很赞同，只是把很多人的理解贴出来，备案之用:-)

 

 

转自百度知道：http://zhidao.baidu.com/question/30514098.html?fr=qrl

 

IT doesn’t matter. Nicolas G. Carr认为“IT 将成为一种无处不在的物品，像电网或铁路一样稀松平常。”2003年，这句话在“Harvard Business Review”上出现后引起了不小的争议，有人不认同他的看法。但是“企业IT是必不可少的物品”一说的确有他的道理：当今的企业高度依赖于IT基础结 构，以支持几乎所有的业务流程，如制造、发布、销售、客户管理和记账等。经济全球化营造了一个激烈的竞争环境，给企业带来更大盈利空间的同时，业务流程也 不断变化：企业必须敏锐观察市场条件的变化，并迅速调整策略，来适应这些更改；企业IT部门必须根据公司策略的变化，快速有效地调整执行策略的主干—— 企业IT系统。

当今，在企业IT系统中， 企业软件的开发陷入进退维谷的境地。在企业软件开发中，总遇到“不敏捷”和“效率不高”两大难题。由于“不敏捷”，企业不能依赖企业IT系统来快速满足业 务需求的变化，缺乏有效应对市场需求的能力。由于“效率不高”，企业软件开发的成本过高，投入的资金往往“得不偿失”。

我们来具体分析一个典型的企业软件系统。在系统使用初期，敏捷性和生产效率都令人满意，处于“绿色区域”，此时的系统拥有很多新功能，也能较快、 较有效地满足“更改请求”。但是好景不长，在初期系统实现就绪，并执行了一些更改请求后，系统适应更改的能力显著下降，随着时间的推移，维护难度越来越 大。如图1所示。


图1 随着时间的推移，系统渐渐不能满足“更改请求”



这不是个别现象，几乎所有企业软件系统都要经历这样一个停滞阶段。起因很多，归纳起来有以下几点：

（1）、与软件技术有关，例如，很难对现行代码库进行结构性更改。

（2）、与项目负责人的调动有关。例如，在一个企业软件系统启动后，项目管理人员和关键的技术领域专家可能调动到一个新项目，维护系统的任务交给技术不大熟练的工程师。而在这种情况下，交接往往都是匆匆完成的。

（3）、行政支持减少。在新系统大功告成的“喜悦”散去后，系统的关注度日益下降，行政支持也渐渐消失。项目预算紧张，系统的修复和更改满足不了系统的实际要求。企业往往拿不出时间和资金合理地重构系统，以确保系统的维护性。

（4）、关键的结构决策只是权宜之计，控制不合理。例如，一名工程师可能为了同步两个系统间的数据，快速编写一个小批处理程序；到10年后，公司可能需要安排一个小型开发团队来消除这个不正规决策留下的后遗症。

在对企业软件系统分析时，通常看不到一个个独立的系统。多年的反复改造使很多系统之间具有复杂的交叉依赖，异质和冗余度相当高。无法对各种系统做 到了如指掌，面对的都是不同的设计和编程风格。随着业务流程的不断扩大，最终逐渐习惯于“迁就”，忘记了何为“完美”的结构。于是没有哪家企业能够拥有“ 银弹”解决方案。

毫无疑问，今天的企业IT环境纷繁复杂、维护费用高并且缺乏实时的灵活性。为了在经济全球化所营造的竞争环境中赢得一席之地。企业需要更好的途径 来塑造企业IT功能，以便更好的满足日新月异的各种需求；需要让IT资源是可复用的，并且能够以标准、灵活以及结构化的模式实现对企业业务应用的灵活配 置。应用于企业业务应用环境的采用面向流程、由事件驱动的SOA架构应运而生，并且让企业在纷繁的竞争环境中看到了出路。

2、 初步认识SOA

SOA是指为了解决在Internet环境中业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。这种面向服务的构架 是一种It战略，它把包含在各种企业应用中的分散的功能组织为可互操作的、基于标准的服务，而这些服务可以被迅速的组合和重用以满足业务需求。一个服务就 是一个代码模块，它可以由通过基于标准的接口访问的服务水平协议管理。每个服务是代表企业的一部分功能，它明确地映射到业务流程中的一个单一步骤。一个服 务可以从头开始编写，也可以通过公开原有孤立的企业应用系统程序中现有服务功能模块来挖掘。经过一段的时间后，可以建立起服务目录，允许不同系统流畅地访 问和重用业务功能。在支持战略变革的同时，能够消除数据冗余。

这里，讨论SOA是为了解决在Internet环境中的不同商业之间的业务集成问题。有必要先讨论下Internet环境区别于Intranet环境的几个特点：

（1）、大量异构系统并存，计算机硬件工作方式不同，操作系统不同、编程语言也不同；

（2）、大量、频繁的数据传输的速度缓慢并且不稳定；

（3）、 版本升级无法完成，无法知道互联网上有哪些机器直接或者间接的使用某个服务。

为了解决Internet 环境中业务集成需要产生的SOA即不是一种语言，也不是一种具体的技术而是一种软件系统架构，尝试给出在Internet 环境下推荐采用的一种架构,也可以说是一种策略，与现行的许多软件技术是存在互补关系的而非互斥关系。SOA也并非包治百病，它是用于解决 internet环境下不同商业应用之间的业务集成问题。

3、 SOA的基本特征

（1）、服务本身的独立自主能力与服务之间的松耦合性

基于Internet松散的使用环境，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。 SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术一般采用宿主来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿 命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。

在不同服务之间，SOA要求保持一种松耦合的关系，也就是保持一种相对独立无依赖的关系。一个服务就是一个单独的代码模块

（2）、大数据量一次性交换

传统的分布式计算模型所提供的服务功能都是通过函数调用的方式，一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在 Intranet的环境下，调用带给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正 常工作的一个关键决定因素。因此SOA系统采用大数据量一次性交换的方法。

（3）、位置透明性

SOA 系统中的所有服务对于他们的调用者来说都是位置透明的，也就是说每个服务的调用者只需要知道他们调用的是哪一个服务，但并不需要知道所调用服务的物理位置在哪里

（4）、协议无关性

由于Internet中大量异构系统的并存决定了SOA系统中每一个服务都可以通过不同的协议来调用，也就决定了SOA必须采用基于文本而非二进 制的消息传递方式。在Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由 于基于文本的消息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。数据处 理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性，又保证系统的协议无关性。

通过 SOA 所具有的特性可以看到，SOA 的出现为企业系统架构提供了更加灵活的构建方式，如果企业架构设计师基于 SOA 来构建系统架构，就可以从底层架构的级别来保证整个系统的松耦合性以及灵活性。IT能够处理的需求与企业需求的提高之间差别所形成的IT缺口将变少。企业 对软件系统的改变将变得简单、快速、廉价，进而实现改变自动化的最终目标。

4、 对SOA的认识误点

毕竟SOA是个新兴的概念，对SOA的认识还存在很多的误点。

（1）、SOA是一个新概念

从企业组织中有不止一台计算机运行开始，企业就开始尝试围绕共享功能或服务创造各种解决方案和科技工具。事实上，最早的RPC协议试图提供这种类 型的架构，然后是IPC协议 ，到后来的分布式对象技术（比如COM和CORBA）。换句话说，它只是演变而不是革命。 SOA是实现共享服务的一个新的构架。

（2）、你必须用Web服务协议创建SOA

SOA只是关于共享和管理服务，所采用的技术只需要满足它的需要。 虽然Web服务协议到目前为止还是首选的创建和部署SOA架构的标准，但是也可以使用其他标准，比如CORBA、COM和 J2EE。你甚至可以采用私有技术创建SOA。

（3）、SOA总是公平的

企业采用SOA后会有两种结果：节省组织成本，提高主动适应性。在设计和部署SOA之前必须对成本和价值作个充分了解。由于部署SOA后大部分企业成本会降低，意味着企业可以从中获利，但并非都是如此。

（4）、部署SOA时，只能选择一个供应商

没有最好的，只有更好的，不变的理论。没有一个供应商可以为创建和部署大多数SOA提供的端到端的解决方案，只能选择一类当中更好的，已经够了，可以通过在项目早期进行POC测试解决兼容性问题。

（5）、当创建SOA时，选择好技术和供应商就可以了

错误的想法。理解需求所在才能寻求解决需求的办法。理解需求所在这意味着你必须要做一系列工作，包括弄懂代码、安全性、完善性、已经存在的服务、需要创建的服务，等等方面。最后，再来讨论技术，注意：别忘了做POC测试以验证系统的有效性。

（6）、拥有SOA后，不再需要应用整合技术

虽然SOA使系统整合更容易，但是你会发现你仍然需要核心的整合技术，例如转换、挖掘、流程整合、适配器，等等。 实际上，这些整合手段可以成为你的SOA的一部分，但你的SOA不会自动把他们包含进来，他们必须成为架构和规划中的组成部分。

二、规划SOA

SOA架构被视为下一代Web服务的基础架构，目前业界领先的Web服务厂商所开发的相关产品大多是基于SOA架构。国际市场上SOA架构中间件市场狼烟四起，很多国际厂商纷纷倾力于此。

国内基于SOA架构Web服务目前还是集中在企业内部，如一些查询、浏览、数据调用，而涉及安全性、可靠性要求高的如企业级交易方面的应用还很不 成熟。此外，涉及新的商业机会，新的商业模式所牵动的各种产业环境也尚未丰满，所以Web服务大规模启动尚须时日。但是我们可以看到，国内一些有影响的行 业用户正在搭建其核心业务系统，比如金融行业的大集中正在起步。因此当企业需要更好地服务客户，需要更好地与上、下游合作伙伴协同工作，并且自己内部的核 心业务之间也需要协同工作时，基于SOA架构中间件产品就会为这类新的业务应用提供理想的底座，这种新的应用被称作面向服务的业务应用。通过应用，SOA 架构就能依次使用Web服务，以便业务流程能够实时产生。对于那些想更容易且更快地与商业伙伴进行集成的企业而言，这无疑是很实惠的事情。

1、规划之前：尝试用SOA思维

企业中大多数业务流程是基于实际的程序，这些程序异常复杂还要求多个异步步骤。企业一个简单的采购订单，可能涉及几天的复杂工作流，并且要求几个 负责人签署意见。这个过程中将面对无意义的副本，乱七八糟的数据以及缺少集成。要在这一种采购订单服务和整个系统之间保持灵活性是困难的，对SOA架构师 和开发人员都是一样的。即使能够实现一些高效率的服务架构和开发，但服务和服务之间也是一种头疼的事情。核心应用程序基础、公用服务层、门户层，必须保证 每个层次的独立性。

尝试着用SOA思维吧！SOA的目标是灵活性、可重用性和互操作性。对于一个企业的具体业务流程，有时看来是一个服务，有时却不是。怎样找到那个美妙的结合点，不是技术方面的问题。那就不可能完成吗？不时地的，一个更大的视角是必须的。

为目前的需求进行构架开发是艰难的，对将来的需求进行构架开发更是一项巨大的挑战。只要服务是考虑到将来的需求才可能用于将来的应用程序。如果服 务完全与当今业务实践相匹配，那么对于未来的出线的业务实践的更改就不支持。可以尝试下：如果服务接收特定的输入，那就使输入通用化吧！如果服务处理五个 进程，那就让他处理十个进程或者更多，折衷的艺术是不可言的。如果要将结果传输给另一个服务，不要让这个服务是固化的。

常常站在未来的角度。试着想象从现在起三年后，正在将这种服务转换到一个新职能。希望该服务如何为你服务？记住，这种思维会产生神奇的价值，提高企业的劳动生产率和降低成本，并且节约系统的开发时间。

2、正确规划SOA

在开发IT架构时显而易见的是，要真正实现商业利益就要从根本上改变关于系统设计的思维方法。Albert Einstein曾说过，“如果我们面临的重大问题在思维认识水平与我们创建它们时处于同一水平上，我们不可能解决这些问题。”把这个概念应用到当今的企 业计算领域，如果我们不改变关于IT的思维习惯，就不可能解决IT界所面临的提供成功商业解决方案的挑战。对于开发人员和企业架构师，SOA为这种变革提 供一种结构。要考虑的问题是：我们如何迁移到这种新水平呢？我们如何为这种根本变革做准备呢？我们如何保证以成本最低、企业创伤最少的方式实现这种变革 呢？全部答案始于正确的规划。

前面说到：SOA与其说是一种技术，不如说是一种的思维方式。它是一项大胆的基础架构变革议程，表达我们如何通过技术和协同工作来实现文化变迁。 它的突然普及不是大规模宣传的结果，而是对SOA作为一种使业务和IT系统更密切结合的演化的认知。这种演化是震撼的，必将为企业的成功带来深远的影响。

（1）新的基础架构范例

SOA的部分范例转移是一个从应用基础架构（Application Infrastructure）迁移到服务基础架构（Service Infrastructure）的过程。在SOA之前，各种应用程序用点对点的连接方式孤立地组织在一起。除了利用一个聚合的服务基础架构层 （Service Infrastructure Layer）之外，SOA使用同样的后端应用引擎和中间件。

（2）实施SOA

按以下步骤开始实施SOA：

从战略上考虑，从战术上实施：首先，用简单的、跨越多个业务单元的不可知服务来实现单一的核心过程。

从上到下考虑：找出支持这个单一核心过程所需的服务。

从下到上考虑：找出现有系统中能作为服务公开以支持这个过程的功能。

考虑基础架构服务：找出公共的支持功能需求。

缓慢扩展：在最初的项目证明成功之后，可以同时承担技术上富有挑战性的项目。

建立一个应用目录：在逐个项目的基础上，经过一段时间后，获取和重用服务模块，降低成本。

关注受益：按投资回报率(ROI)分阶段实施项目，在每一阶段要巩固原有的水平。

（3）使用BEA域模型有效地规划

为了保证成功，SOA以一种新的方式要求IT和业务协同工作。开始SOA规划时，需要在技术性和非技术性要素之间进行有效的平衡。为此BEA开发了一个域模型（如图2所示），帮助指导规划必须同等重视的六个关键方面，以确保成功实施。



图2. BEA域模型

最好从业务战略与过程、架构以及成本与受益三个方面开始规划。

①业务战略与过程：把SOA映射到业务

SOA把IT功能映射到业务流程，使业务随着时间而改善。这个映射过程的最佳表达如下：

分析：研究业务流程，找出所需的支持功能。

开发：从现有的IT资产中获取功能，开发新的功能，确保所有服务都有清晰的服务水平协议。

利用：将服务编排进流程，让其与战略保持一致，识别最佳机会。

②架构: 定义长期需求

为IT组织建立参考架构很重要。这种参考架构不是当前的状态图，而是一个长远视图，合并了未来2到3年架构上的发展需要。花些时间来定义架构的指导原则和策略，但要避免使这些指导原则走入死胡同。优先考虑SOA系统的灵活性和模块化。

③成本和受益：直接证明业务价值

SOA反对四处出击，重要的是按成本受益顺序确定服务开发的优先级，这样SOA从一开始就显示出ROI。通过仔细的规划，启动成本要限制在现有预 算内。经过一段时间后，服务模块的重用会确保以后每个新业务应用程序的启动成本很低。在实施开始时设置好基线，确保可测量性，避免临时修路的效果。

三、 从1996年到现在，再到未来，SOA该何去何从？

1996年，Gartner最早提出SOA的思想；
2002年12月，Gartner提出SOA是“现代应用开发领域最重要的课题”；
2005年，一些IT组织成功建立并实施SOA应用软件，IBM等厂商看到其价值，也纷纷推出自己的SOA解决方案；
2008年，预计SOA将成为占有绝对优势的软件工程实践方法。
……

按照Gartner的预测，作为一种面向未来的构想，SOA到成为占有绝对优势的软件工程实践方法显然还有很长路要走。目前基于SOA构架的中间 件产品发展很快，但同所有的新生事物一样，成长绝非是一个一帆风顺的过程。对于现实的意义而言，SOA又有什么样的魅力价值? 今天所能说的是，面向未来发展，SOA为应用的动态整合提供了一个非常好的思路，一个解决问题的方法。然而目前SOA相关技术和应用还处于探索和发展之 中，对此一定要有一个清醒的认识。

未来的饼，怎么解决今天的温饱？厂商和企业都应该认真考虑，在中间件市场上，技术遥遥领先的巨无霸是不可能存在的 。