SOA：尚待改进的五大缺憾

客户世界 | 2015年7月12日 | 文库 | 评论已关闭 | 1421

||2005-01-07

日渐成熟的Web服务标准让SOA显得切实可行，那么你是应该现在开始布署呢？还是等到这些标准的不足被弥补之后呢？在媒体和厂商都在大肆鼓吹SOA带来的好处时，您是否能够清醒地看到SOA存在的不足呢？

大吹大擂的面向服务架构(SOA)概念继续在吸引IT界。不过，SOA是否能实现通用应用集成尚不清楚，这让那些仔细研究它的人困惑不解。人们不难发现，SOA在可靠性、安全性、编制、遗留系统支持和语义方面还存在严重不足。

Peter Underwood是经纪行Wall Street Access负责软件开发的副总裁，他说，他手下的队伍在规划SOA集成之前，事先作了慎重考虑。

“大家开始以为SOA只是一项普通的技术。换句话说，它就是一个框架，” Underwood说。虽然SOA“因为Web服务标准的成熟而发展起来，”但Web服务的潜能和现有功能之间还是有相当大的距离。

企业主管们乐意用Web服务来满足简单需求，譬如把信息发到基于Web的门户网站。但复杂的关键任务事务又是另一回事，它们可能需要一些尚在开发中的Web服务标准。所以说，何时选用采用Web服务的SOA策略较为明智？何时采用普通的企业应用集成(EAI)比较好？这完全取决于你想要做什么、你会遇到Web服务功能的哪些不足。

缺憾之一：可靠性

客户在高可靠性异步消息传送方面的需求恐怕最难满足的，至少短期看来是这样。EAI巨擘――Tibco公司负责企业集成的总经理Aiaz Kazi认为，这种消息传送“对企业应用的集成而言至关重要。”

Web服务基础设施厂商Blue Titan的营销副总裁Sam Boonin说，对可靠性的需求类似“我们在其他计算范例中经常讨论的需求，SOA还没有完全为事务的最高可靠性――不可否认性(nonrepudiation)、消息一定会被传送且仅传送一次(once-and-only-once delivery)以及恢复原状(rollback)――作好准备，不过等标准和实施技术成熟到可以满足这一需求的地步只是个时间问题。”

实际上，有关Web服务的几项规范草案已经可以解决关键任务和长时间运行流程所遇到的问题。譬如，Web服务可靠消息传送(WS-ReliableMessaging)就是为了确保SOAP消息能到达目的地而设计的。Web服务原子事务(WS-AtomicTransaction)、Web服务事件(WS-Eventing)及其他几项拟议规范将为处理复杂的、有状态的、长时间运行的商业事务定义方法。但与许多跟安全有关的协议不同，诸如此类的可靠性标准还没有广泛应用起来。

Thomson Prometric是一家提供基于计算机的测试和评估服务的厂商，其企业架构副总裁Chris Crowhurst说，在此之前，“可靠消息传送对Web服务来说是相当大的负担，不过到最后，应用软件只需要围绕它来构建就可以了，”因为Web服务提供的兼容性具有诸多优点。

眼下，“围绕它来构建”就是编制应用软件，以便事先预料错误状况并加以应付。这也意味着利用提供标准化抽象层的中介产品(譬如Web服务管理代理程序)，支持点对点的SOAP关系。这类产品由Actional、AmberPoint和Blue Titan等独立软件开发商提供，使管理人员能够提供故障替换(fail-over)到软件端点及升级到软件端点的功能，生产系统受到的干扰极小(实用的Web服务管理应当能够跨众多平台工作，这可以解释BEA、IBM和微软等大厂商为什么缺少类似的解决方案。)

另一方面，正如Web服务管理厂商Actional的CTO Dan Foody所言，“不是每个问题都需要同一样的可靠性。”必须确保可靠性的是有着诸多相互关系的长时间运行的异步事务，譬如复杂的金融交易。至于要求不太高的事务，HTTP上的SOAP就相当可靠，特别是对简单的同步事务而言。

Rajan Jena是百时美施贵宝子公司Oncology Therapeutics Network的架构设计师，他在公司的集成基础设施中都用到了面向消息传送的传统中间件和Web服务。他说，如果事务数量多、成批传送，消息传送方案非常适合；另一方面，如果事务数量少，但必须完全具有实时性时，Web服务就很适合。

缺憾之二：安全性

对IT管理人员来说，如果要考虑采用基于Web服务的集成方式，则授权、验证和加密要求就变得特别重要。

在过去，访问控制只需要登录和验证；而在分布式Web服务环境中，由于一个应用软件的组件很容易去跟属于不同域的其他组件进行对话，所以确保迥然不同又相互连接的系统之间的安全性就复杂得多了。

与可靠消息传送一样，业界为Web服务类型的交互制定了一批标准，其中有两个标准特别重要，并且得到了广泛实施：Web服务安全(WS-Security)和安全断言标记语言(SAML)。前者描述的是详细列出系统安全功能各个层面的极具扩展性的框架；后者定义的是传送安全断言的标准方法，为单点登录(Single Sign On，简称SSO)这一认证模式提供便利。

对企业的SOA而言，分析人士特别提到了第三种但还不成熟的提案：WS-Policy。WS-Policy 将为不同系统在认可连接之前宣布需要哪种安全机制提供一种手段。如果没有WS-Policy标准，则实现跨域松散耦合的功能将会受到严重限制。

虽然提议的标准没有哪一项能够独立解决Web服务的安全难题，但这些标准结合起来就能够为日常性安全策略规划提供保障。的确，Web服务兼容性组织(WS-I)最近认可Web服务安全的一部分作为基本安全概要(Basic Security Profile)，这是一系列最佳安全策略，旨在确保兼容性。预计该组织会在不远的将来增加对SAML及其他标准的支持。

从短期来看，保护Web服务安全有一种相对实用的方法，那就是采用保护基于Web的标准应用安全所用的技术：传输层机制，譬如SSL。

SSL的一个优点就是通过客户机/服务器证书这种形式支持双向验证。不过如果客户机数量众多，那么证书基础设施的日常维护就会成为难题。现有的一种补充方案就是采用能够理解XML的通用防火墙(代表厂商包括DataPower、Forum Systems和Reactivity)和XML数字证书，为Web服务网络流量提供另一道防护措施。

分布式安全架构落实到位后，IT管理人员应当可以喘一口气。过去，应用安全的日常维护工作往往落在编程人员肩上――但结果是他们无法施展手脚，同时留下了安全隐患。有了基于Web服务的安全管理，完全由授权的操作人员来负责这项任务就要合理得多。

Oncology Therapeutics Network的Jena声称，他所在的公司在改用SOA时，这种安全方法对其CRM及订单管理系统来说非常重要。他说：“这意味着我们可以从策略角度来实施安全管理，而不是由开发人员实际上把安全功能编入应用软件中。我们认为这是一和很大的优点，这种方式实实在在地提高了应用软件的安全性。”

缺憾之三：编制

统一协调分布式软件组件以便构建有意义的业务流程是最复杂的，但它同时也最适合面向服务类型的集成，原因很显然，建立在SOA上面的应用软件可以被设计成可以按需要拆散、重新组装的服务。

作为目前业务流程管理(BPM)解决方案的核心，编制功能(orchestration)使IT管理人员能够通过已经部署的套装或自己开发的应用软件的功能，把新的元应用软件(meta-application)连接起来。

Blue Titan的Boonin说，这项功能对许多采用SOA集成策略的用户来说很重要。Boonin说：“他们在SOA基础设施上构建复合应用软件，并且把服务编制成可以重用的业务流程。”乍一看，把这些部分组装起来、引导商业事务的流向是一项简单的任务，毕竟，BPM解决方案一直以来最主要的绊脚石就软件缺乏灵活性；另一方面，Web服务可以把软件分解成多个组件，每个组件与某项业务功能相关。

事实上，最大的难题不是建立模块化的应用软件，而是改变这些系统表示所处理数据的方法。Thomson Prometric公司的Crowhurst建议“应当确认业务核心的模式”，而不是围绕孤立的单个系统和数据记录来设计流程。”，换句话说，就是最好把业务流程的结果看成文档，文档里面包含了所遇到的每个重要问题的答案。作为Web服务的基本要素，XML能够让这一概念成为现实。

业界已经为编制和BPM提出了几项标准。其中一项是业务流程执行语言(BPEL)，它得到了业界的广泛支持，甚至出现在众多BPM产品当中。不过大家一致认同功能稳定的BEPL 2.0版本大概要在15个月后才能完成。作为BPEL的补充，Web服务原子事务和Web服务复合应用框架(WS-CAF)的主要目的就是为组成长时间运行和有状态业务流程的复杂事务提供便利。

BPM专业公司、传统的EAI公司以及主要的平台厂商都认为，利用这种基于标准的新BPM，实现流程可视化、执行及监控的功能是很有商业价值的，SAP和Oracle等企业应用软件厂商也加入到其中。去年，Oracle收购了BPM专业公司――Collaxa；SAP则采取了截然不同的方法――重新设计软件，以便集成其自有版本的面向BPM的中间件NetWeaver。最后，专门为SOA而设计的以XML为中心的数据库将成为处理业务流程模式中日益重要的一方面，这类产品包括Blue Titan公司的Data Director和Software AG公司的Tamino，

缺憾之四：遗留系统支持

一个优秀的遗留系统适配器的作用好比是一个设计良好的Web服务：它提供了一个抽象层，把应用基础设施的其余部分与各种棘手问题隔离开来。

用来连接应用软件和遗留系统的软件方案与到处旅行的那些人手提箱里的工具包没什么两样。就好比类型合适的电源适配器可以让美国观光客到希腊之后可以把便携电脑的电源线插到墙上的插座里一样，专用的应用适配器也允许一个系统能够从另一个系统里获取数据。

就好比各国都有自己的电源插座标准，每个遗留系统都需要自己的适配器。多年来，EAI厂商一直在强调各自拥有的一系列遗留应用适配器是区别服务好坏的关键因素，当然也是它们的重要收入来源。

幸好，由于Web服务等标准在兼容性方面越来越占据支配地位，简单连接的成本已有所下降。与此同时，第三方应用适配器专业公司如Attunity和iWay已经加强了竞争，从而大大增加了现有连接方案的数量。

遗留应用适配器有一个好处有时会被人忽略，那就是它们屏蔽了许多专利性API的复杂性和晦涩性。一个优秀适配器的作用好比是一个设计良好的Web服务：它提供了一个抽象层，把应用基础设施的其余部分与各种棘手问题隔离开来。Software AG等一些厂商就专门把遗留应用软件“语义集成”到基于XML的集成构架中。

Oracle和SAP等公司的套装应用软件或多或少提供了对基于标准的连接的支持，一般情况下，它们都利用SOAP接口把专利性的API(如SAP的Business API)包装起来。由于应用软件厂商正在利用Web服务，并且为各自的产品添加类似中间件的功能，因此集成套装应用软件的标准方法将逐渐体现出SOA的最佳策略。

即使这样，采用昂贵的专利性应用适配器仍然是把许多真正过时的系统连接到通用集成框架的唯一方案。

对采用IBM等公司的大型机以及那些已经积极地把基本的Web服务移植到旧设备的IT公司而言，还是有一线希望的。出人意料的是，借助SOAP显示这些公司的API远比为许多客户机/服务器系统中的API理清头绪来得简单。

缺憾之五：语义

定义事务和数据的业务含义是IT管理人员面临的最棘手问题。虽然语义难题早在Web服务之前就存在了――譬如多年来，垂直行业一直在开发自己的XML模式，但正是SOA把语义推到了前台。

语义关系是设计良好SOA架构的核心要素。

没有哪一项技术或软件产品能够真正解决语义问题。为针对特定行业和功能的流程定义并实施功能和数据模型是一项繁重的任务，它最终必须由业务和IT管理人员共同承担。不过，预制组件和经过实践证明的咨询技能可以简化许多难题。

EAI厂商认为自己在开发集成方案方面所拥有的丰富经验或许会减缓Web服务标准可能带来的冲击。Tibco的 Kazi对此直言不讳：软件集成“是我们多年前就涉足的领域，可以说，我们开辟了这个领域。”浏览一下Tibco公司的网站，您就会发现面向电信、医疗、运输等众多行业的特定方案。

套装应用软件厂商在支持SOA的过程中，也在宣传他们在特定行业和业务流程方面的经验作为资本。例如，SAP就在不遗余力地强调其xApps计划，该计划以Web服务为基础来实施业务流程，可跨越历来各自孤立的垂直系统和功能系统。

许多公司越来越认识到制定本行业XML标准的重要性。譬如说，金融服务业已开发出了金融信息交换标记语言(FIXML)，这是面向银行交易的一种交换协议；会计行业已提议用可扩展业务报告语言(XBRL)来描述及审查总账类型的记录；高科技行业的制造商继续使用衍生出诸多XML术语的RosettaNet标准，交换供应链上的产品和部件信息。

其实，许多观察人士认为，说到SOA潮流何时出现以及怎样出现，公司所在行业的动态可能是最重要的推动力之一。IBM公司的WebSphere基础设施主管Bob Sutor强调，金融服务业等行业采用SOA来得尤为积极。除了垂直行业标准等技术推动力外，他特别提到了大量的兼并活动是促成这股潮流的重要因素。他说，明智的采用者不是慢慢整理信息，然后把信息从一家公司的系统复制到另一家公司的系统，而是应当利用类似SOA的技术，迅速“把业务部门整合到网上”，这样就能减少干扰。

尽管面临以上所谈到的诸多挑战，但大多数IT管理人员一致认为，采用面向服务的集成基础设施是“何时采用”而不是“是否采用”的问题。即便如此，“三思而后行”这句老话仍然完全适用。如果缺乏明确的业务分析和开发指导原则，“最后就会重复构建接口，这确实很可怕，”Wall Street Access的Underwood说。

调研公司CBDi的CEO兼首席分析师David Sprott同意上述看法，不过他提醒：采用面向服务的策略不应当受技术驱动，他说：“站在服务的角度来考虑，有助于把业务和IT摆在同等地位。换句话说，不要仅仅为了赶什么浪潮而去实施服务，应当根据业务需求和投资回报准则来行事。”

Thomson Prometric的Crowhurst也认为：重要的是学会如何以服务来表示基本的业务流程。他说：“改变开发方式需要文化变迁，相比之下，解决技术难题只是一种智力操练。”

配文

性能：SOA的第六个缺憾？

抨击Web服务和SOA的人士经常会提到性能是阻碍采用的一个障碍，但技术的标准化总需要在速度方面有一些牺牲。我们已经谈到基于Web服务的SOA目前还存在的一些不足，这些不足是其松散耦合、分布式的性质所固有的。但怀疑人士经常会提到另一个问题――性能，并认为这是SOA的重大弱点。这种怀疑观点通常针对两方面：SOA的分布性质和Web服务协议的开销。

不可否认，任何分布式系统的执行速度都不如独立式系统，这完全是因为网络的制约作用造成的。当然，有些应用软件无法容忍网络引起的延迟，例如那些对实时性要求很高的应用软件，但我们也必须看到，并不是只有Web服务或SOA存在这种情况。在实际应用中，Web服务和SOA带来的灵活性以及让系统接近它们所表示的作业单元–以及跨组织或跨网络地把这些系统连接起来――获得的好处远远压倒了网络延迟带来的性能影响。

与这个问题关系更为密切的是，与采用二进制编码的事务相比，XML事务更为复杂和庞大。Java应用服务器等系统把SOAP请求转换成内部对象，其难度估计要比采用本地方法如远程方法调用(Remote Method Invocation)大10倍。这听上去很有道理，但你考虑一下从Web本身得到的经验，就会发现其实并非如此。与HTML一样，XML也是采用内容非常冗长的语句来描述信息，但也正是这种易读性和扩展性弥补了性能方面的损失。而随着时间的推移，摩尔定律以及XML加速器等专用设备更是会逐步消除性能方面的影响。

到最后，稳操胜券的既不是Web服务的拥护者，也不是Web服务的批评者，而是那些能够使用适当工具处理适当事务的人。今后一段时间，大容量事务处理将继续由采用二进制编码的专利性中间件方案来解决；而需要不太频繁但更灵活的交互关系的应用软件将越来越多地由Web服务来满足。

新浪网