与SOA相关的ESB
IBM SOA Foundation白皮书描述了IBM交付SOA价值的整体方法。SOA Foundation的参考体系结构的核心中具有ESB。该参考体系结构的描述声明“ESB 的存在是简化服务调用任务的基础”。虽然该白皮书是在2005年末发布的,但是其中预述的论点却随着时间推移而通过我们在采用SOA的客户方面的经验得到加强。
通过ESB实现的松散耦合的部分优点(包括本系列的第1部分详细描述的服务虚拟化和面向方面的连接中所固有的优点)如下:
请求程序和提供程序不必就消息格式、消息传输甚至目标地址达成一致。
请求消息可由多个提供程序中的任何一个进行处理,请求程序不必显式地确定提供程序。这种路由可以基于相应的版本、服务质量或其他度量。
现有的请求程序无需更改即可连接到新的提供程序。
现有的提供程序无需更改即可对新的请求程序公开。
可以对请求程序做出更改而不影响提供程序,或者对提供程序做出更改而不影响请求程序。
解决方案的横切方面,例如安全性和管理等等,可由ESB进行添加、执行或加强。
可以实现新级别的动态行为,因为ESB能够为请求程序和提供程序之间的每个交互实时执行策略。
作为SOA入口点的ESB
一次性全面采用SOA可能是一项艰巨的任务。IBM已确定了五个SOA入口点,这些入口点提供了有关如何开始渐进地采用SOA的指导。渐进的采用方法允许企业以最适合需要的方式和步调采用SOA。为什么我们要确定五个入口点?简单的原因在于众口难调;企业的在成熟度级别和特定需求方面各不相同,适合于一家企业的入口点可能不适合于另一家企业。这五个入口点基于已导致我们的客户成功实现了SOA的方法。存在两种类别的入口点:
以业务为中心的入口点——人员、信息和流程——允许您从一种侧重于基本企业资产的方法开始。
以IT为中心的入口点——连接性和重用——允许您为SOA奠定技术基础。
您也许已经从SOA Foundation 白皮书中预料到,连接性 意味着使用ESB来“通过更加安全、可靠和可伸缩的方法简化IT环境,从而在企业内外进行连接”。IBM认为,虽然ESB无疑是一种以IT为中心的SOA方法,但是“它本身交付了实际业务价值,并且是将来的 SOA计划的核心构件”。本文中的一个关键问题(将在下面进行讨论)是如何最好地使用ESB来形成将来的SOA计划的构件,以及如何通过连接性入口点获得最大的业务价值。
存在多种利用连接性入口点的方法。有时客户已经在其环境中定义了一些服务(也许是通过合作伙伴),不过是直接连接的服务;这种情况导致缺乏灵活性并增加管理成本。如上所述,在此类环境中插入ESB可以提供直接的松散耦合优点。此外,ESB的存在为将来定义附加服务、创造附加重用机会、支持新的重用渠道、降低管理成本和获得更多敏捷性的工作创造了条件。
客户通常知道ESB的价值并渴望开始从ESB中实现好处,但是他们还没有在其环境中定义服务。我们看到了两种已采用过的成功技术,这两种技术帮助在这种情况下从ESB获得好处。客户经常混合使用重用和连接性入口点。他们确定需要作为服务来连接的功能或应用程序(请求程序或提供程序)。同时,他们将 ESB 插入该体系结构,以提供新的服务请求程序和提供程序之间所需的松散耦合。混合方法得以流行的一个重要因素是ESB产品的转换和变换功能。此类功能允许使用同一个 ESB 产品作为某种形式的适配器,以便以更加可重用的形式公开功能或应用程序,并提供所需的服务虚拟化和面向方面的连接。这里成功的关键是谨慎地开始,公开少量的服务并开发对应的中介,但是这些服务和中介都在为考虑中的整个最终范围而设计的体系结构之内。
有些客户插入ESB以建立组织中连接的所需方向,尽管起初还没有确定要连接的服务。在此情况下,ESB是组织的总体参考体系结构的一部分;参考体系结构 提供了体系结构方向,并强制要求最终将作为解决方案一部分而创建的所有服务(请求程序和提供程序)进行松散耦合连接。ESB是用于实现该松散耦合的首选机制。采用ESB实际上消除了解决方案中的直接连接不知不觉地增长的可能性。这里成功的关键是:
采用一个要求并演示ESB使用的参考体系结构。
考虑解决方案的整个最终范围,并支持最佳的ESB产品选择。
随着解决方案的发展而实施强有力的治理,以确保利用ESB来连接到引入解决方案的新服务(请求程序和提供程序)。
SOA入口点最佳实践
存在一组IBM强烈建议用于任何SOA采用的最佳实践。这些最佳实践的最重要元素是建立一个路线图并渐进地实现该路线图,该路线图定义了实现所需业务目标的采用计划(请参见参考资料部分以获得指向文章“Service Oriented Architecture:An Introduction for Managers”的链接)。该路线图包括两个重要组成部分:
战略远景,业务或IT的方向陈述(包括参考体系结构和治理计划),可用作决策制定、组织参与和标准采用的指导原则。
一组项目计划,定义实现项目以满足当前业务驱动因素的即时和将来需要。
此类路线图允许您渐进地实现SOA,以在每个项目步骤中回报业务价值。
您应该在执行该路线图的早期确定您业务的最佳SOA入口点。您应该基于从您的总体战略远景和当前SOA成熟度级别得出的要求来选择该入口点。该入口点可能是也可能不是连接性入口点;它可能是上述入口点的混合。但是,连接性入口点是最普遍的入口点,因为有如此多的客户具有将请求程序连接到提供程序的即时需要,并希望获得ESB提供的松散耦合的好处。IBM提供了一个在线工具 Business Value Analyzer,以帮助您选择SOA入口点。
另一个最佳实践是建立治理框架以确保组织遵循该路线图(请参见参考资料以获得指向文章“SOA Governance and Service Lifecycle Management”的链接)。SOA 所促进的灵活性增强和跨组织性质要求组织建立治理框架,以实现主动的决策制定、准确的跟踪、改进的服务能力和更好的交流。有效的治理通过在增添价值的同时平衡风险和回报,从而帮助实现企业的业务目标。
正如上面所建议的,渐进的SOA采用是成功的关键。IBM建议从试验项目开始,该试验项目:
处理得到充分了解、重要但不关键的业务需要。
实现参考体系结构的某些重要方面(也许是ESB和一组示例服务、提供程序、请求程序,这些方面用于演示SOA的使用)。
需要一个超出当前能力的可达范围。
积累SOA技能。
用作对采用SOA治理和新的服务生命周期管理流程所进行的试验。
产生将会投入生产应用并将交付投资回报的结果。
通过SOA实现的关注事项分离甚至允许试验项目以能够积累专业经验和验证业务价值但不中断主要操作的方式引入SOA。
SOA连接性入口点最佳实践
除了SOA最佳实践以外,还存在其他更特定于ESB的最佳实践:
仅当ESB在您的路线图中有意义时才采用ESB。例如,如果SOA入口点以业务为中心,您可以推迟通过ESB实现的松散耦合,尽管您的参考体系结构中包括了ESB。
基于您的参考体系结构和一组跨全套项目计划的实际要求来设计ESB并选择ESB产品。我们说实际 是因为您应该集中于未来几年中的需要;到您超过该时间期限时,产品和需求已经发生了改变。如果仅考虑即时需求,尤其是忽略服务请求程序和提供程序的预期需要,则会导致选择非最优ESB产品。您必须明确地在公司的约束内行事,例如年度资金周期和预算,但您同时还希望将短期采购和决策与考虑中的长期(三至五年)目标保持一致。
根据情况考虑ESB联合。更大型的异构企业通常作为某种自治域的联合体出现,这些自治域基于各个业务部门或者职能或治理方面。在此类环境中,某些服务可以在单个域中进行共享或重用,而其他服务可以在整个企业中进行共享或重用。在这些情况下,我们建议采用某种形式的ESB联合,该形式的ESB联合与域联合的需要相匹配。ESB联合允许在不同的域中使用不同的ESB产品,并支持域需求与产品功能之间的最佳匹配。路线图和参考体系结构应该为任何给定域的产品选择提供指导原则甚至选项,以确保实现企业范围的优化。我们进一步建议使用联合服务注册中心和存储库,为企业范围的管理和可重用服务的治理提供帮助。
您是否需要ESB来成功采用SOA?
前面几个部分说明了从ESB开始成功的SOA之旅。另外四个入口点不需要ESB即可开始该旅程。然而IBM认为,无论其入口点是什么,绝大多数成熟的面向服务的解决方案都将包括ESB,以最大化SOA中所需的敏捷性和灵活性。因此,虽然初始项目可以不包括ESB,但是在您的长期业务和IT路线图中,ESB应该是参考体系结构的一部分,以实现成功的SOA。如果没有ESB提供的敏捷性和灵活性,您会发现在面临不可避免的变更时,管理解决方案将变得非常困难,并且开销很大。
这是否意味着在准备好包括ESB在内的所有体系结构组件之前,您还没有拥有真正的SOA呢?此问题没有正确或错误的答案,并且可能存在许多选项。在某种程度上,此问题并不重要——重要的是在实现新的SOA项目以及解决方案根据您的路线图逐渐变得成熟时,您要渐进地向业务交互越来越多的价值。
我们的客户好像同意这个观点。几乎我们的所有采用SOA的客户都从ESB开始,或最终在解决方案中使用了ESB,并从ESB支持的灵活性和敏捷性中获得了重大的IT和业务价值。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
总线技术究竟该不该用?
曾几何时企业服务总线(ESB)被视为企业IT的核心。今天,不仅ESB受到了比被废弃还要糟糕的攻击,若干开发趋势似乎对更简单的消息总线也发起了质疑。