这篇文章首次出现在IEEE软件杂志上。IEEE软件对当前战略性技术问题提供可靠的、业内同行的评述信息。为了应对可靠、灵活地运行企业的挑战,IT管理者和技术领导者需要依靠IT 专家来获得最先进的解决方案信息。
企业系统已经从单片孤岛(monolithic silos)快速发展为使用机制灵活、面向服务的分布式应用系统。为了跟上这一趋势,IT组织必须近乎实时地调整他们的遗留系统,以面对商业变化的挑战,这一机会稍纵即逝。面向服务的体系(SOAs)已经演进成可灵活进行操作,并能连接业务进程和底层系统。Nicolas Serrano、Josune Hernantes和Gorka Gallardo提供了当前SOA技术的概述以及如何在遗留环境中去演进。我很期待听到来自读者和这个领域具有前瞻性的专栏作家的见解,以及你们更多想知道的东西。— Christof Ebert
今天的业务必须能够灵活、快速地适应市场需求,但是即使很小的处理变化也会引起多个IT系统的重新返工,因为它们原本是设计成应用孤岛(application silos)的。为了保持它的竞争力,维护性的开发工作必须减少,然而IT系统却必须持续地演进。面向服务的体系(SOA)可以使基于孤岛(silo-based)的系统演进到面向服务的系统。它的设计思想包括松耦合、底层逻辑抽象、灵活性、重用和可发现性(discoverability)。1,2在SOA Manifesto 中还描述了其它一些指导原则。
SOA初级知识中,最新奇之处在于它的基础框架设计是基于服务的,而不是聚焦在整个应用上。服务是小的、离散的软件单元,能提供特定的功能并在多个应用间被重用。SOA应用了松耦合的设计理念,这意味每个服务都是分割的实体,它们对其它共享资源的依赖是有限的,如数据库、遗留应用或者API。它在生产者和消费者之间帮助提供一个抽象层,从而有利于在不影响消费者的情况下来灵活改变服务的实现。SOA对业务提供了许多益处,但它也不是灵丹妙药,可以包治百病。SOA的优势在于:
向SOA迈进并不容易,有此意愿的企业必须意识到困难和固有的那些问题。无需多言,每个IT组织在SOA实现时都会经历许多权衡和折中,而且每条道路的距离也不尽相同。为了效率和灵活性,我们推荐在遗留环境中用增量方法来迁移到SOA。
对于大多数组织来说,Web服务是实现松耦合体系最简单的方式。通过一组基于XML的公开标准,如WSDL、SOAP和UDDI,就可以具有互操作的能力,这些标准提供了定义、发布和使用Web服务的通用方法。
Web服务是从Web应用演进而来的,实际上,它们是简化版的Web应用。Web服务不再提供用户接口及其数据,而仅仅提供数据接口;呈现信息给用户的任务转而由客户端的应用程序来负责。因此,Web服务是实现SOA最通用的方法,实际上,许多系统使用了Web服务但并没有把自己定义成SOA。
SOA(和Web服务)的主要优势在于相同的服务可以被不同的客户端来使用。原先为Web应用设计的数据仍会被任何类型的客户端使用而无需更改。这其中的例子包括从服务器获取数据而无需提供显示SQL数据库查询的桌面应用,或者是那些从SOA服务获取数据的付费或公众的信息客户端。
遗留系统可以封装成SOA服务并对HTTP协议直接做出响应,或者它工作在代理服务器的后面,代理服务器负责将请求翻译成遗留系统的语言。最终,HTTP中的消息是明文的,它可以来自任何系统或编程语言。
当需要创建灵活的应用时SOA是一个好的选项,但如何去选择正确的技术来实现则依赖于你的需求和环境。为了那些愿意在自己的业务处理中选择SOA的组织,让我们一起来回顾那些最相关的技术考量。
当设计Web服务时,我们需要定义一组规则用来交换信息。当前最适合完成这个任务的工具是SOAP和REST。3SOAP是个老一点的协议,它是类似CORBA这样已有技术在互联网环境下的实现。SOAP可以利用多种传输协议(HTTP、SMTP等等),这给了它更多的灵活性。由于数据是在XML中交换的,所以当信息量和传输的消息较大时会有性能问题。SOAP可以和Web服务安全(Web Services Security)一起使用,后者是个签名和加密消息的协议,它为消息交换提供了更多的安全性。4
REST是新的协议,它也用HTTP作为传输协议,但它可以处理更多的数据格式,如XML、JSON等等,它依赖于特定的URL而不是XML。REST是SOAP轻量级的替代者。REST在实现上没有那么多约束,所以他的灵活性更高,也更轻,对文档的依赖更少。与SOAP只能使用POST方法不同,REST可以使用Get方法,所以缓存不仅可以在业务设计中去实现,也可以通过基础框架来完成。
具体选择REST或SOAP取决于组织需求和限制条件。一些时候,我们会选择企业应用能力更强的SOAP,另一些时候,我们则选择更好性能和更轻量的替代者,如REST。因为SOAP有更好的安全和故障处理能力,大多数企业级的IT商家都会把它作为优选的Web服务实现。而REST则具有简易、性能好以及实现上不那么严格的特性,这些使它成为Internet业务中实现协同工作API的优选。
尽管SOA体系是无缝连接企业系统并减少协议5和平台阵痛的最好选项,但大多数人仍需要同现存的框架来打交道。当你试图采纳SOA体系来改造遗留系统时,并不存在一个完美方案,这是因为涉及到方方面面的因素。你需要对当前的技术堆栈进行考量,然后基于全局性的成本风险分析进行最优的系统迁移。
因为遗留系统通常都在支持关键性的业务处理,所以必须采取step-by-step方式的改造计划,并设计可行的演进方案使现有系统通过混合方法(hybrid approach)变为完全的SOA体系。这里有几种策略可以使遗留系统转化为SOA体系。
第一个方法是将当前遗留系统用另一个或一组系统替换。通常,如果当前商用现货系统(COTS)能够满足遗留系统的需求和功能,那么这种替换就是个好办法。这个方案减少了维护但增加了未来修改的成本。第二种选项是用中间件来封装现有遗留系统并通过Web服务来提供遗留系统的接口。用这种方法,遗留系统功能被封装在服务层里面并插接在SOA环境里面。这可能解决不了一些问题:遗留应用可以集成不同的几种服务,这时就不能象期望的那样对它们解耦。然而,当重写遗留系统代价太大、遗留系统可以重用,并需要性价比好的解决方案时,这也是个好办法。最后,也是第三个选项是重写开发和编码现有的遗留系统。这是个非常好的办法,因为你可以对应用的架构施加作用并得到最优的解耦层级。但是,遗留应用通常是关键性的,而且因为涉及到之前的技术以及缺乏文档,有些时候修改它们会非常困难或代价很高,这种修改可能会引起一些问题并增加项目风险。这种情况下,正确的评估涉及的所有风险是必不可少的。
当在任何SOA行动中计划应用集成时,许多供应商的产品可以帮助你来简化这种迁移。然而,不同的产品在能力和复杂性上有所不同,所以选择正确的方案对于成功至关重要。你可以将这些选项基于集成的复杂性级别划分为三个不同的组(看图1)
图1 三种企业应用集成的框架
表1:三种集成方案的对比
很明显,做出最好的选项依赖于特定的需求和复杂性。首先,你先得决定框架是否已足够满足需求。例如,当你只有两个应用要连接或者你可以只用单个技术(如REST)就能满足需求时,你就可选择最简单的方法(集成框架)而不用考虑它对工具和支持的缺乏;如果不是,那么ESB是一个不错的选择。但是,如果需要更多的特性,你就最好用一个更多能力和更复杂的栈,比如集成套件。
继续向前,下一个演进的步骤将是如何使SOA汇聚和使云计算变得容易。云的出现给企业带来的益处包括:云计算可以按需来提供资源,以容纳数据、服务和进程。
如此,在云上进行集成就成为企业今天要面对的一项主要挑战。在这样的场景下,iPaaS(integration platform as a service)作为可以满足广泛集成需求的适合选项就应运而生了。iPaaS作为云服务套件,可以使户创建、管理并治理连接广泛应用和数据源的集成流(integration flows),而无需安装或管理任何的硬件或中间件。
展望未来,调研咨询公司Gartner预测到2016年,全世界至少35%的大中型组织将会使用一个或多个某种形式的iPaaS产品。然而,专家们以为iPaaS并不能取代SOA,对于复杂集成场景传统的SOA仍然是需要的,比如企业内部或企业间的低延迟消息系统和数据密集交易系统。
Nicolas Serrano是Navarra大学工程学院的计算机科学和软件工程教授 。他的研究方向包括信息技术及其在个人和职业发展上的应用。可以通过[email protected]来联系他。
Josune Hernantes是Navarra大学工程学院的计算机科学和软件工程教授 。她的研究方向包括软件工程和信息系统。Hernantes从Navarra大学工程学院得到了计算机科学博士学位。可以通过[email protected]来联系他。
Gorka Gallardo是Navarra大学工程学院的信息系统教授 。他的研究方向主要是信息技术。可以通过[email protected]来联系他。
这篇文章首次出现在IEEE软件杂志上。IEEE软件对当前战略性技术问题提供可靠的、业内同行的评述信息。为了应对可靠、灵活地运行企业的挑战,IT管理者和技术领导者需要依靠IT 专家来获得最先进的解决方案信息。
查看英文原文:Service-Oriented Architecture and Legacy Systems