有五种能够帮助我们创建五种组件的精神图像的桥梁元素。一个机构需要将深埋在其核心企业系统内部的价值展露出来并将该价值延伸为一个现代的面向服务架构,什么是SOA,为什么它如此令人向往? 尽管SOA非常复杂,但是其基本前提非常简单。其主旨就是避免每次建立新的应用程序,同时也避免复制程序,数据,业务规则。这些在一个组织中的业务规则已经存在于另一个组织的其它部分了。
相反的是,应用程序从现有的块中建立起来,并从组织的不同地方获取信息而不用真正改变信息存在的位置。 将数据和业务规则“打包”的这种发生方式叫做服务,该服务在核心系统被显示为一个独特的组件。它将为一个崭新的业务应用或流程所使用。这些服务可……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
有五种能够帮助我们创建五种组件的精神图像的桥梁元素。一个机构需要将深埋在其核心企业系统内部的价值展露出来并将该价值延伸为一个现代的面向服务架构,什么是SOA,为什么它如此令人向往?
尽管SOA非常复杂,但是其基本前提非常简单。其主旨就是避免每次建立新的应用程序,同时也避免复制程序,数据,业务规则。这些在一个组织中的业务规则已经存在于另一个组织的其它部分了。相反的是,应用程序从现有的块中建立起来,并从组织的不同地方获取信息而不用真正改变信息存在的位置。
将数据和业务规则“打包”的这种发生方式叫做服务,该服务在核心系统被显示为一个独特的组件。它将为一个崭新的业务应用或流程所使用。这些服务可以在不同的应用程序中被反复使用也可以在一个被称作服务组合的流程中同其它服务连在一起。重用这些服务和服务组合可以避免每一次从新建立应用程序。恰当实施的SOA的可以获得更大的灵活性、更好的响应用户和市场需求以及更大的降低成本。
一组和桥梁类似的元素更值得人们的关注。首先,核心企业系统形成了桥梁最深的根基。而且涉及到根基的桥桩都是对于业务成功来说意味着一个非常重要的核心企业系统。核心企业系统的实例就是一个零售业的供应链接系统、一个制造行业的客户服务系统、一个大型财政机构的存货交易系统、一个在保险行业经营保险业务的系统。在每个实例里,这些核心系统存在于主机当中,并且能够区分建立在此基础上的业务。这些系统的服务可行性将其独特的商业价值一直传到了机构的最顶层——就像桥桩能为整个结构提供牢固的稳定性一样,如果没有这些深入岩床的桥桩,这些桥梁可能最终会移位而不能用了。
桥面这个比喻也非常合适。就像一个桥梁的桥面把物理支持的服务价值传送到了穿越桥梁的每辆机动车。SOA的桥面直接将埋于业务服务的价值传送到业务用户那里。在两个例子里,桥面是接口。另外,就像物理桥梁能够支撑各式各样的交通工具一样。通向SOA的最高层的桥梁可以用许多方式使用服务。可以在业务流程管理实施中建立复合应用程序时使用服务。服务也可以在业务流程中被用作组件或者可以被用作直接为业务提供服务的一项技术。
通向SOA的桥梁有五个要素
·应用程序组合从众多不需要或很少需要解码的业务服务里装配新应用程序。
·SOA规则管理和执行在其整个生命周期定义、管理并实施服务规则。
·SOA控制可以便利在机构内部和机构之间的Web服务最大限度的重用。
·高价值的业务服务可以使Web服务连在一起或组合在一起建造一个新高价值的业务服务,该业务服务可以用IT为业务提供更大的定位调整。
·服务可行性可以将重要的核心应用伸展到SOA环境,而不用进行多方面的程序设计。
数据和业务规则
在建立通向SOA的桥梁时,最好先从最熟悉的已经在大多数机构中存在的部分开始。数据和业务原则形成了核心的企业系统,帮助将机构区分开,使机构更成功。
为了在未来的应用程序中重用核心主机资产。它们应该在不同层次粒度中显示为服务。服务颗粒性对于SOA来说非常重要,并和功能的复杂性程度有关。粗糙颗粒性的服务执行一个复杂功能。细颗粒性的服务执行简单的功能。将核心应用程序展示为具有不同层次颗粒性的可重用性服务叫做服务实现。有三种办法实现服务:对话集成、交易集成、数据集成。
许多核心主机应用只有通过终端数据流才可以存取。这主要是指“绿光屏”终端。这就意味着核心应用以一种方式写成,即业务规则和数据存取接口没有和能够在绿光屏终端——图像层看到的部分程序清楚的分离开。
为了完成服务实现,从对话中分离单独的业务规则和数据存取非常昂贵,耗费时间,并且对于一些机构来说非常冒险。对话集成截住了在主机和终端之间往返的信息。并能够把信息变为可以在Web 浏览器展示的HTML或者是能够被转化成服务的对话信息,该服务可以为其它应用程序所重用。
在有些实例里,核心企业应用可能和数据存取独特层很好的结合在一起。这种状况为服务实现的发生提供了极大的可能性。在该实例中的机会即交易可以被展示为服务,这和对话集成很相似。
将一小块软件集成化的这个技术在交易周围贴上了“包装纸”,因此这些交易具有一个服务的模块化特征。这和在一个通信网络传递信息的方式非常相似。
如果核心系统不能马上组建起来,它就要继续被开发,并且扩展为更多的功能。这也许值得花资金重新设计应用以便交易集成能够取代对话集成。这就确保了可以满足未来各式各样需求的一个灵活的环境。通过提供对应用逻辑、相互依赖性和外部触点的深入理解,这些工具可以帮助我们重新设计流程。
一个成功的交易集成方案一定能够访问各种类型的交易,不管它们的语言和操作方式是怎样的。
在一些特定的实例中,绕过图像层和业务规则层,机构需要直接访问主机数据库中的数据。这就叫做数据集成,这也是完成服务实现的第三种方法。在该实例中数据存取逻辑被用来建造一个Web服务适配器。从另一个应用里可以呼叫这个新的数据存取服务,该数据存取服务还可能支持建立一个复合应用程序、共同入口,甚至为业务信息或报告工具提供数据。
数据存取服务同样为生成报表提供了一个很好的方法。尽管可以通过一个现有的应用屏,或者通过执行一个用户接口服务或者成千上万遍的来生成报表获取这些数据并不是最好的方法。
服务实现
一旦核心服务系统可以令服务实现,我们很正常的就能发现这些Web服务向IT环境引进了更为复杂的事物。比如,早些时候我们提到过由围绕核心系统交易建立的Web服务研磨的太细致以至于对于企业里的其它应用程序来说没有太大的价值。出于许多原因这些细致研磨的服务也许是不得已的选择甚至是最好的选择。
当许多服务研磨的太细致而无法通过SOA为终端应用或流程的需要提供服务时,我们要如何采取行动呢?在该实例中,通过插入额外的业务逻辑的连续步骤来执行研磨的Web服务。这样,一个粗糙研磨的服务建立起来了,对于大量的业务应用来说这些服务更为重要。将细致的服务连在一起就叫做服务组合。并且一个在这种流程中建立的复合服务叫做经过组合的服务或者高价值的业务服务。
过去常常用于执行服务组合的这项技术是一个企业服务总线(ESB)。服务组合不仅是由ESB和面向服务架构一同执行的唯一功能。ESB同样也执行高速的信息传递,路由选择以及系统间的协议变换,同时也支持不同层次的安全性。这就意味着可以确保你的服务层协定(SLAs)或者其它的性能得以实现。
SOA管理
服务实现像桥桩、服务组合、桥梁一样是通向SOA这座桥梁最开始的两个要素。它们是建立一个灵活可重用IT架构的有力工具,该IT架构能够使一项业务对市场情况和用户期望做出快速反映。但是,当服务的采用延伸到了几十个、几百个甚至成千上万的服务时,许多新的挑战随之出现。随着许多精心研磨和粗糙研磨的服务被建立并重用,这些机构必须能够跟踪和服务相关的信息。
最显著的问题是一个单独的服务或一套工具能够使SOA管理流程得以实现。分析人士同意具有各种特色注册表/存储库能够为SOA管理程序提供绝佳的支持。一个注册表/存储库能提供标准接口这样生产服务的人就能将其公布并且准许机构中的其他人找到并重用这些服务。一个注册表/存储库也准许服务生产商把服务合同附在他们的服务上,规定使用权利、安全设置以及其它任何想重用服务的人都要考虑的重要参数
我们可以保证无论用户何时捆绑或连接到一个服务,它们同样也会和最近的服务合同连接或捆绑在一起。同样,服务生产商能够跟踪他们的服务被谁使用,如何被使用的。这些服务注册表/存储库的实施加大了服务生产商和用户以及开发团队间的通信。这是个中央机制,在该机制中不同开发团队能够获得他们需要的服务的最新消息。
服务实现将核心应用的价值带到了面向服务架构。通过ESB,服务组合建立了粗研磨的服务,这些服务对于业务来说很有用,并能在许多新应用中重新使用。通过注册表/储存库,SOA管理能够控制服务重用流程,促进了机构中服务创造者和服务用户间的积极关系。
一旦服务被揭示并能被不同的应用所消费,他们还处于生命周期的初期。当服务在不同的应用中使用时并且系统发生变化时,每个服务都有自己的寿命,在系统的变化中服务呼叫数据和业务规则。在服务的生命里,所有的这些变化都是不定的。除非不同的SOA规则被建立管理并执行,服务有潜力在企业基础设施内部消除这些破坏。这些规则被用来管理每个服务。
调节SOA生命周期需要特定的技术,一个具有伸缩性的SOA规则管理平台,该平台能够跨越设计、运行时间并能改变时间管理要求。该平台有时也包括注册表/储存库并结合了在单一伞下SOA管理的各个方面。
在SOA生命周期里,通过使规则执行同步更为简单,SOA规则管理平台的上半部分可以加速SOA的采用。另一部分就是SOA规则实施技术能够令机构一贯的满足SLAs和关键性能指示器(KPIs)并能使支持业务目标的SOA流程实现自动化。
服务实现和组合出现在SOA运动的早期,只有当SOA被机构在世界范围内广泛采用时,扫除SOA管理和实施的需要才会变得更加明显。最先采用SOA技术的人似乎对于在企业内部他们开创性的方法表面的成功所造成的麻烦知之甚少。SOA管理,包括注册表/储存库以及规则管理和实施能够帮助IT机构确保这的确是件好事。
复合应用
很显然,正如这篇文章前面所讨论的一样,这些新应用以及其服务的商业目的都是我们要首先建立SOA的原因。这些新应用是一个叫做应用复合的结果,人们通常称其为复合应用。
它们不是以传统方式开发的,即用Java 、NET 或者COBOL.语言编写的。相反,复合应用是用模块化的方式创建的,该模块化方式结合了在企业内部和外部都可使用的Web服务。
通过类似Google 或者Yahoo 的Web浏览器,业务用户可以访问复合应用。并且事实上,Google Maps是许多在Web和业务环境下的复合应用。但是这些应用必须同样有企业级的速度、性能、以及和桌面程序相关的图形交互。
对于用户来说,高效、无代码的复合程序组合要求一个企业类的开发环境。这样的开发环境往往有令人印象深刻的内置功能,例如Web 2.0的功能,完善的用户管理、基于角色安全以及文档管理能力。
应用程序的复合完成了通向SOA的桥梁,因为复合应用的用户真的会使用服务从机构的核心系统中呼叫重要信息。该业务使用者可能事先通过从IT请求报告或坐在特殊的绿光屏终端前独自存取信息。现在他们可以在自己电脑上的图形浏览器中获取信息。这对解决特殊的业务问题很有意义。
作者
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
购买应用集成工具可以采取平衡做法
购买应用程序集成工具需要好好看看你的公司需求,知道从供应商里面要寻找哪些关键功能。