第五代呼叫中心之SOA（二）
北京商路通信息技术有限公司 黄河
2009/11/06
第五代呼叫中心之SOA（一）
SOA的解决之道
SOA面对的难题和梦想是：第一、软件复用与成本摊薄；第二、需求满足与变化适应；第三、软件整合与软件立旧。那么SOA的解决之道是什么？
在说明这个问题之前，我们先看看古人的一个故事，很有意思。
秦国的兵工业
纵览两千年前秦国的战争史几乎就是一部典型的大军团作战史，在文治方面“略输文采，稍逊风骚”的秦始皇在武功上却是功勋卓著，战绩非凡。他驱使着秦军这支历史上著名的“虎狼之师”短短十年间，竟吞并六国，席卷中原，进而又北逐匈奴，南服百越，最终一统天下，坐拥天下。
究竟是一种什么样的技术力量在背后强力支撑着秦军，使其能够频繁发动着大军团作战，面对不同的对手不断地取得胜利而最终在军事上强势崛起呢？历史文献中一直不曾给出过真正完整的答案。
随着大量秦国兵器的考古发掘，专家逐步为我们解开了这个千古迷团，一支装备精良，武器先进的秦帝国军队被完整地复原，一个庞大的秦国武器设计生产场面也随之真实地情景再现。其武器设计质量在让人为之叹为观止的同时，也给我们当今装备研制生产领域带来许多有益地启示。原因很多，其中装备设计制造标准化最是令人叹为观止。
专家们对春秋战国时期的兵器进行考古研究时发现，那时各个诸侯国即使在同一地点遗留下的兵器，也存在着轻重不等，大小不一，形式多样等普遍现象，而只有秦国的兵器，却不论时间相隔多年，地点相距多远，其造型和尺寸却是几乎惊人地完全一致。例如：在兵马俑坑中发现的三棱箭头有4万多支，其制作得极其规整，箭头底边宽度的平均误差只有正负0.83毫米。北京理工大学的冶金专家对秦军箭头做了金相分析，结果发现它们的金属配比基本相同，数以万计的箭头竟然是按照相同的技术标准铸造出来的。
专家们还对秦佣坑兵器的弩机进行测试，结果发现数百件弩机的牙、栓、刀和其他部件，完全可以互换通用，轮廓误差不超过1毫米。在战场上，秦军士兵可以随时把损坏的弩机中仍旧完好的部件重新拼装使用。专家同时还发现在青铜剑上有三条90多厘米长的棱线，将细长的剑身分成八个面，秦军戈的圆弧部分加工得也十分规整，箭头上三个流线型的表面也完全对称。手工要完成这样的表面加工有很大的难度，但实际情况是，兵马俑坑中几万件兵器几乎都是相同的质量。如何保证质量的同时大批量生产呢？实施标准化一定是其重要手段。尽管按今天的工业标准看，这些兵器的标准化仍旧是比较粗糙和初步的，但是，在两千多年前，秦人执著于统一标准，保证了所有秦军战士使用的都是当时最优秀的武器。
由秦国兵工业的强健发展直至最后奠基秦国的霸主地位，软件从业者可以得到如下启示：
一 制造业和软件业的相互羡慕
制造业羡慕软件业，因为虽然设计成本很高，但是，设计完成后，软件的生产成本极低。
而软件业其实更羡慕制造业，生产成本很高，但是设计成本被成千上万的生产过程摊薄了。
从秦国的兵工业看看我们羡慕的地方。
首先，看看复用与成本摊薄的问题，兵器的设计成本很高，需上百人年才能完成。但是，设计被复用了上百万次后，成本被摊薄到很小很小。
其次，看看满足需求和变化适应的问题，恰恰是软件行业无法做到的，秦军的需求非常统一。
最后，看看整合与立旧的问题，由于标准，弩机的牙、栓、刀和其他部件，完全可以互换通用，轮廓误差不超过1毫米。在战场上，秦军士兵可以随时把损坏的弩机中仍旧完好的部件重新拼装使用，这是软件业最想做到的。
其实，软件业一直在努力向这个方向发展。
于是，软件工程、软件工厂、软件蓝领等概念一直被软件业追捧。当然，软件的复杂度远远高于秦国的兵器，那么我们看看SOA对于几个方面的解决之道。
二 软件复用与成本摊薄
当SomeThing软件开发完成，实现了某种功能，如果无需在其他很多地方再重新编写或维护它，那么无疑会提高生产率。然而，重用实现起来并不轻松，也并非自动化的。首先，必须以一种可重用的方式来组织或编写代码。然后，必须知道存在一段可以被重用的代码。在组织代码方面，不同的编程语言以不同的方式为重用提供内置支持。过程和函数是大多数程序员所熟悉的基本单元。面向对象的语言，比如C++和Java，还提供了定义和扩展自定义的类型或类的手段。这些特性背后的基本理念就是封装（也就是说，只需通过一些定义良好的接口来访问其中的功能，实现对于您而言是一个黑盒子）。这些特性有其用途和优点，但是当涉及到支持更大规模的重用时，它们也存在一些局限性。
首先，SomeThing软件是用C++开发的，只有特别熟悉C++的程序员才能进行有效的重用。
其次，如果A公司的开发人员开发了SomeThing软件，A内部的其他开发人员要发现SomeThing软件可以被他使用也不是一件容易的事情，更不用说B公司、C公司的开发人员了。
最后，这个层面上的代码并不支持网络，这意味着无法跨机器调用这些代码，也无法在另一种编程语言中透明地重用它们。例如，SomeThing软件是C++开发的，那么不费一番工夫，我是无法在Java中调用SomeThing软件的。
为了这个目标，软件业前赴后继，用了大量的概念和方法，如面向过程、面向对象、CORBA技术，ActiveX、COM技术、COM+技术、DCOM技术和Agent技术等等。
SOA是如何解决这一问题的呢？首先让我们看一看SOA中的术语“服务”。
服务很难精确的定义，可以理解为被调用的功能。
这个功能有以下几个重要的特征：
- 容易被找到：一个做好的服务，一定告诉别人；
- 明确说明能干什么：接口明确描述；
- 独立：不要依赖于其他的系统的功能和状态；
- 谁都能调用：不依赖于操作系统、编程语言和软件部署。
上面几个特征表述是非常形象的表述，其实目标只有一个“希望大家都来调用我”。
一方面，不限制操作系统、编程语言、软件部署的机器；
另一方面，更方便的让其他软件调用。
W3C把SOA定义为“一组可调用的组件，其接口描述可以被公开和发现”。
SOA是一种思想，它绝对不是万能的，它需要开发者根据自身行业的特征，设计哪一部分功能作为一个组件。
只有你的功能划分得非常合理，才能做到软件复用和成本摊薄。
三 需求满足与变化适应
SOA的方法在需求的满足和变化的适应方面并没有太多其他独到的地方，它依然是基于软件的复用和成本的摊薄。
需求的满足和变化的适应要求服务合理地提供出来：
第一、需要满足服务的几个重要特征；
第二、服务要适合行业需要，是对行业需求的抽象，要考虑到行业其他软件如何调用；
第三、需要有合适的颗粒度，以便可以组合出各种各样的需求，并且需求变化时可以快速重组，同时，服务的一个部分需要变更，则不要影响全局；。
那么从本质上来讲，SOA对需求的满足和变化的适应方面的建议不是直接满足需求和需求的变化，而是通过接口的调用和调用的组合来满足的。
四 软件整合与软件立旧
讨论完软件复用与成本摊薄和需求满足与变化适应后，软件整合与软件立旧就是一个非常容易理解的问题了。
软件以接口的形式出现，自然软件的整合更加容易，软件的立旧更加轻松。
SOA的软件整合似乎是很理想的一件事情，如果你要开发一个软件，用于自己网站的会员在网上预订酒店，软件整合的过程大致如下：
- 你发现美国的一台服务器，上面是一个提供房源的服务，你调用其中一些服务，解决了房源信息问题；
- 你发现了日本的一台服务器，上面提供了展示酒店的服务，你调用其中的一些服务，解决了酒店信息展示的问题；
- 你发现中国的一台服务器，提供地图服务....
- 你发现法国的一台服务器，提供客户服务的服务...
- ....
组合后，你的软件快速实现。
由于你可以选择的服务众多，可以任意组合服务的各种功能，很好的满足了客户的需求。而那些服务的提供商，也通过你对他的服务的使用，获取了收益，达到了他的软件的复用和成本的摊薄。
SOA的支持与其中重要的概念
“孤木难成林”，既然这个概念是解决软件行业问题的概念，那么就需要整个软件行业支持。目前，几乎所有的软件巨头都在支持SOA，包括IBM、微软、Oracle、BEA、SAP等等，还有一家AVAYA--我们行内非常熟悉的厂商。SOA已经不是一个大家争论的概念了，而是实战了。
SOA还有两个重要的概念，即ESB和BPM。
第一个概念 ESB企业服务总线
SOA的服务组件暴露的是一种粗粒度的接口，其目的是使应用之间能够异步共享数据。而使用ESB，一种集成架构将应用程序和分离的集成组件拉在一起，以产生服务装配组合从而形成复合的业务流程，进而自动化一个即时企业中的业务功能。
ESB为SOA提供实现骨架。那就是说，它通过一个跨越多种协议的消息总线来提供一个有关命名路由目的地的高度分布的世界来提供松散耦合的，事件驱动的SOA。ESB中的应用程序(和集成组件)在理论上是彼此解耦的，而且通过总线彼此连接为暴露为事件驱动服务的逻辑端点。
通过分布式的部署配置基础设施，ESB能有效率地提供对在扩展企业中分布的服务的中心配置、部署和管理。一种普遍集成的新方式应用诸如SOA、EAI、B2B和Web服务之类的技术的通常目标主要是创建一个集成架构，且能够深入并且跨越整个扩展企业。对于一个集成基础设施到达到这种普遍性，它必须具有下列各项特性:
- 它必须能够适应多种集成情形项目的通常目的需要，不管是大型的还是小型的。适应性包括提供一个能够经受协议、接口技术、甚至流程模型的变化趋势的持久架构。
- 它必须以一种单一和统一的方式，以及一个通用的基础设施来连接扩越扩展企业的各种应用。
- 它必须能够扩展超出单一公司IT中心的边界。并且自动化伙伴关系，比如在B2B 和供应链的情况下。
- 它必须具有设计的简单性和较低的进入门坎，使得日常的IT专业人员也能够成为自我修练的集成架构师。
- 它必须提供一个跨越普遍集成的 SOA，它能使集成架构师能够对公司的应用资产和自动化业务流程有一个广泛的、抽象的视图。
- 它需要有能够反应和符合不断变更的业务需求和竞争的压力需要的灵活性和能力。
在ESB中，应用和事件驱动服务以一种松散耦合的方式紧密地联系在SOA中。这使得它们能够彼此独立运行，并且仍然能够提供广泛的业务功能价值。
ESB架构解决了这些需要，并且正在被各种通用的集成项目所采用。它也能够在企业应用层面普遍地伸展，不管是物理位置还是技术平台。任何应用都可以通过大量的连接选择插入到一个ESB网络中，并且可以立即参与到与那些通过总线暴露为共享服务的应用之间的数据共享之中。这是
ESB 为什么经常被称为集成网络或集成构造的缘故。
简单一点，下面两种构架的方式，第一种，杂乱无章，第二种，非常清晰，第二种用的就是ESB的方式。
第二个概念 BPM服务流程管理
业务流程管理系统（Business Process Management简称BPM)。BPM的定义分为合作战略部分与软件部分。其注重点是通过建模、自动化、管理和优化任意一种业务流程，来管理公司业务流程的效率和效果。
而SOA中的服务也是需要流程的，二者之间是需要融合的。
没有SOA，BPM一样会出现并得到实现，但是，在SOA将更多标准和系统整合成为可能的基础上，通过SOA而在整体范围内实现BPM将会得到最大程度的简化。就我听到的最为形象的一个比喻则是，在脱离SOA协助下的BPM如同一个将一只手捆绑在背上的人努力想要去达到的目标。”
而目前面临的主要的问题是，当大家都去支持SOA的时候，BPM如何去实现，或者如何去整合原有的BMP。
第五代呼叫中心之SOA（三）
第五代呼叫中心之SOA（四）
第五代呼叫中心之SOA (五)
第五代呼叫中心之SOA（六）
第五代呼叫中心之SOA(七)
第五代呼叫中心之SOA(八)
第五代呼叫中心之SOA(九)
CTI论坛编辑
相关阅读: