面向服务体系和遗留系统
李小翔
2015-06-29 18:32

内容列表

转自：http://kb.cnblogs.com/page/520024/
作者: Nicolas Serrano  来源: infoQ  发布时间: 2015-05-07 原文链接
英文原文：Service-Oriented Architecture and Legacy Systems
企业系统已经从单片孤岛（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不足之处在于：
在应用间很难实现异步通信；
SOA实现实时响应和高数据传输时会非常有挑战，这是因为XML强调地是健壮而非速度（尽管还可以选择其它方案，如JSON）；
SOA有很多安全性缺陷，这是由于应用和系统使用了进程共享；并且
在逻辑上分离的系统间交互时，SOA会涉及到复杂的事务管理。
向SOA迈进并不容易，有此意愿的企业必须意识到困难和固有的那些问题。无需多言，每个IT组织在SOA实现时都会经历许多权衡和折中，而且每条道路的距离也不尽相同。为了效率和灵活性，我们推荐在遗留环境中用增量方法来迁移到SOA。
Web服务（Web Services）
对于大多数组织来说，Web服务是实现松耦合体系最简单的方式。通过一组基于XML的公开标准，如WSDL、SOAP和UDDI，就可以具有互操作的能力，这些标准提供了定义、发布和使用Web服务的通用方法。
Web服务是从Web应用演进而来的，实际上，它们是简化版的Web应用。Web服务不再提供用户接口及其数据，而仅仅提供数据接口；呈现信息 给用户的任务转而由客户端的应用程序来负责。因此，Web服务是实现SOA最通用的方法，实际上，许多系统使用了Web服务但并没有把自己定义成SOA。
SOA（和Web服务）的主要优势在于相同的服务可以被不同的客户端来使用。原先为Web应用设计的数据仍会被任何类型的客户端使用而无需更 改。这其中的例子包括从服务器获取数据而无需提供显示SQL数据库查询的桌面应用，或者是那些从SOA服务获取数据的付费或公众的信息客户端。
遗留系统可以封装成SOA服务并对HTTP协议直接做出响应，或者它工作在代理服务器的后面，代理服务器负责将请求翻译成遗留系统的语言。最终，HTTP中的消息是明文的，它可以来自任何系统或编程语言。
技术（Technologies）
当需要创建灵活的应用时SOA是一个好的选项，但如何去选择正确的技术来实现则依赖于你的需求和环境。为了那些愿意在自己的业务处理中选择SOA的组织，让我们一起来回顾那些最相关的技术考量。
SOAP和REST的对比
当设计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的优选。
遗留系统的更新改造（Legacy Modernization）
尽管SOA体系是无缝连接企业系统并减少协议5和平台阵痛的最好选项，但大多数人仍需要同现存的框架来打交道。当你试图采纳SOA体系来改造遗留系统时，并不存在一个完美方案，这是因为涉及到方方面面的因素。你需要对当前的技术堆栈进行考量，然后基于全局性的成本风险分析进行最优的系统迁移。
因为遗留系统通常都在支持关键性的业务处理，所以必须采取step-by-step方式的改造计划，并设计可行的演进方案使现有系统通过混合方法（hybrid approach）变为完全的SOA体系。这里有几种策略可以使遗留系统转化为SOA体系。
第一个方法是将当前遗留系统用另一个或一组系统替换。通常，如果当前商用现货系统（COTS）能够满足遗留系统的需求和功能，那么这种替换就是 个好办法。这个方案减少了维护但增加了未来修改的成本。第二种选项是用中间件来封装现有遗留系统并通过Web服务来提供遗留系统的接口。用这种方法，遗留 系统功能被封装在服务层里面并插接在SOA环境里面。这可能解决不了一些问题：遗留应用可以集成不同的几种服务，这时就不能象期望的那样对它们解耦。然 而，当重写遗留系统代价太大、遗留系统可以重用，并需要性价比好的解决方案时，这也是个好办法。最后，也是第三个选项是重写开发和编码现有的遗留系统。这 是个非常好的办法，因为你可以对应用的架构施加作用并得到最优的解耦层级。但是，遗留应用通常是关键性的，而且因为涉及到之前的技术以及缺乏文档，有些时 候修改它们会非常困难或代价很高，这种修改可能会引起一些问题并增加项目风险。这种情况下，正确的评估涉及的所有风险是必不可少的。
企业应用集成（Enterprise Application Integration）
当在任何SOA行动中计划应用集成时，许多供应商的产品可以帮助你来简化这种迁移。然而，不同的产品在能力和复杂性上有所不同，所以选择正确的方案对于成功至关重要。你可以将这些选项基于集成的复杂性级别划分为三个不同的组（看图1）
图1 三种企业应用集成的框架
集成框架（Integration frameworks）是所有选项中最轻的，它基本由不同开发环境中的API实现库组成。集成框架的例子有Apache Camel、JAVA环境下的Spring Integration以及.NET下的 NServiceBus。
企业服务总线（Enterprise Service Bus）产品提供集成框架的能力以及部署、管理和运行时监控的工具。ESP支持在服务生产者和消费者之间的连接，因此在提供工具上具有优势，它可以显著减 少成本和复杂性并且能在更高的抽象层来解决集成的问题。ESB产品的例子包括Oracle Service Bus和Mule ESB。
集成套件（Integration suites）提供全套的软件栈，它不仅提供ESB的能力，而且提供更多特定业务的工具，比如业务过程管理、业务活动监控、主数据管理和一个知识库。所有 这些特性可以帮助你快速响应变化。一层层去理解这些竞争性的方案是比较困难的，所以表1对这三种集成方案做了一个对比。
表1:三种集成方案的对比
做出选择
很明显，做出最好的选项依赖于特定的需求和复杂性。首先，你先得决定框架是否已足够满足需求。例如，当你只有两个应用要连接或者你可以只用单个 技术（如REST）就能满足需求时，你就可选择最简单的方法（集成框架）而不用考虑它对工具和支持的缺乏；如果不是，那么ESB是一个不错的选择。但是， 如果需要更多的特性，你就最好用一个更多能力和更复杂的栈，比如集成套件。
继续向前，下一个演进的步骤将是如何使SOA汇聚和使云计算变得容易。云的出现给企业带来的益处包括：云计算可以按需来提供资源，以容纳数据、服务和进程。
如此，在云上进行集成就成为企业今天要面对的一项主要挑战。在这样的场景下，iPaaS（integration platform as a service）作为可以满足广泛集成需求的适合选项就应运而生了。iPaaS作为云服务套件，可以使户创建、管理并治理连接广泛应用和数据源的集成流 （integration flows），而无需安装或管理任何的硬件或中间件。
展望未来，调研咨询公司Gartner预测到2016年，全世界至少35%的大中型组织将会使用一个或多个某种形式的iPaaS产品。然而，专 家们以为iPaaS并不能取代SOA，对于复杂集成场景传统的SOA仍然是需要的，比如企业内部或企业间的低延迟消息系统和数据密集交易系统。
参考
· 	N. Gold et al.， “Understanding ServiceOriented Software,” IEEE Software, vol. 21, no. 2, 2004, pp. 71–77.
· 	S. Jones, “Toward an Acceptable Definition of Service,” IEEE Software, vol. 22, no. 3, 2005, pp. 87–93.
· 	S. Mumbaikar and P. Padiya, “Web Services Based on SOAP and REST Principles,” Int’l J. Scientific and Research Publications, vol. 3, no. 5, 2013, pp. 1–4.
· 	P. Louridas, “SOAP and Web Services,” IEEE Software, vol. 23, no. 6, 2006, pp. 62– 67.
· 	S. Vinoski, “REST Eye for SOA Guy，” IEEE Internet Computing, vol. 11, no. 1, 2007, pp. 82–84.
·