面向服务的体系结构(Service-Oriented Architecture,SOA)是一个不断发展的概念,适用于新的软件系统和现有软件系统。不过,将SOA应用到现有软件系统的最佳方法可能不甚明了。本文中将介绍若干此类方法,并说明这些方法可以如何使您的业务从中受益。
引言
很多年来,软件开发方面的发展主要是通过改进编程语言实现的。最近,这个重点开始转向了编程过程;例如,Java语言消除了将经过编译的模块链接到一起的需要。SOA是这个趋势所带来的最新创新。本文的目标读者是大型机软件开发人员和架构师,但也同样适用于其他环境(如Linux操作系统)的前SOA软件。
组件化和组件组装是SOA软件设计中的关键部分。SOA依赖于各种普遍存在的常见技术,如Internet、XML和HTTP。它是由标准定义的,个人和大小企业均可采用此技术。该技术是目前用于应用程序构造的最佳方案。
SOA在IBM SOA Foundation技术白皮书(有关更多信息,请参阅参考资料)中的定义如下:
现在应该清楚的是,SOA不仅仅涉及到技术领域。IBM将SOA视为业务和IT部门间的全方位关系。SOA包含用于捕获业务设计和使用设计信息帮助改进业务的各种工具和方法。它还包含用于在信息系统中实现业务设计的工具、编程模型和技术。它包含用于承载该实现的中间件基础设施。SOA包含该实现的管理,从而确保其对业务的可用性,并确保在执行该实现的过程中高效地使用各种资源。它包含指定谁具有权威的机制和用于控制业务设计中的更改以及其在信息系统中的实现的过程。最后,SOA可加快体现这些优势的价值。
其中的一些体系结构过程——特别是业务建模和业务流程设计——既可应用于大型机应用程序,也可应用于Java 2 Platform, Enterprise Edition(J2EE)环境和其他类型的应用程序。这可帮助将精力集中在专门为适应IBM大型机环境而设计的SOA实现工具、编程模型和技术。应该将本文作为其他有关各种环境(如批处理环境、IBM CICS、IMS和DB2环境)的IBM大型机应用程序SOA支持的文章以及其他SOA开发主题文章的补充。
在不改变应用程序原有功能的情况下提供软件SOA功能的技术更改称为SOA支持。通常,SOA支持这一术语并不适用于新软件的设计和构造。开发人员可能会择将SOA支持工作和应用程序的功能更改一起进行,但SOA支持并不要求进行功能更改。
为何使用SOA?
SOA应用程序设计可为IT提供很多优势。此处我们将特别重点讨论三个优势:
·几乎通用的连接,可消除由于专用技术和中介(仅用于解决技术不匹配问题)所带来的开销和复杂性。
·可通过在模型驱动的体系结构中良好工作的聚合进行构建,从而实现重用。
·适用于大部分编程语言和运行时环境。
按需问题
现代企业都在积极尝试抓住新市场所提供的各种机会,希望能够将效率提高到前所未有的程度。必须具有相当的灵活性才能抓住各种机会,而IT灵活性来自能够根据需要重新配置、修改和创建新软件的能力。效率的提高主要通过再工程和自动化业务流程实现。软件具有一定程度的延展性,可以方便地进行更改,以满足不断变化的业务需求。
从发明了存储程序计算机开始,设计和实现延展性软件就是一大挑战。虚拟化 ——将程序元素间的静态绑定替换为可以在操作期间更改的绑定,这是延展性的一个关键方面。不过,应该在高性能计算环境中小心使用,以避免其影响性能和资源使用。
我们已经了解到,要对软件进行恰当设计,以将流程序列逻辑、策略、基本计算、人机接口和数据管理分离开来。之所以进行分离,是因为序列逻辑和策略经常受到业务操作方面的更改的影响。将其他方面(用户界面和数据)进行分离可将应用程序软件从数据存储和用户界面(User Interface,UI)首选设置中的技术更改(包括从门户设备进行访问)隔离开来。绑定这些独立元素实际上就灵活地允许这些元素快速地分离并以不同的方式重新进行联接。例如,可以在不停止策略所属的整个软件进程的情况下删除并替换该策略。
软件组件的构造(无论是处理序列逻辑、策略、基本计算、人机界面或数据管理)都可以通过重用提高效率。它还避免更改多个软件模块的需求,从而提供跨多个业务流程的一致性和简化维护工作。
重用是一个发现过程,只要在新场景中采用共享组件,就会继续此过程。组件将通过积累各种功能自然地得到发展,并同时保留所有旧功能,以面对客户机进行再工程的麻烦。不过,应该定期对组件进行再工程和重构。尽管这通常可以在不影响用户的情况下完成,但在再工程和重构将影响组件用户的情况下,必须能够标识这些组件用户。
在SOA中,组件具有使用Web服务描述语言(Web Services Description Language,WSDL)描述的服务接口。组件的WSDL描述该组件提供的服务和该组件所需要的服务。WSDL是一个Web服务互操作性标准。如果WSDL描述匹配,服务提供者就可以连接到服务请求者。这就允许两个组件进行信息交换。
大型机环境
现代大型机出现在1964年。它迅速成为了企业计算的主流,并不断发展,始终保持着这个地位。令人惊讶的是,40年前编写的应用程序代码今天很可能还在大多数大型机环境中运行。目前可能有数百亿或数千亿行的COBOL代码在使用,其中很多最初都是在20世纪70年代和80年代编写的。这些应用程序中包含实现有价值的业务过程、计算和策略的逻辑。大型机环境的SOA支持包括用于发现这些逻辑并使其具有可重用性的各种实践、体系结构模式、工具和中间件。
IBM大型机具有高度的可伸缩性,可以每天执行数千万个事务。它们还经过了高度优化,处理器和I/O利用率可超过90%。其可靠性非常高,即使万一出现故障,也能快速恢复,且几乎没有信息丢失。系统配置支持故障转移和灾难恢复,而主系统和备份系统可以放置在距离很远的两个位置。IBM大型机及其主要应用程序承载环境具有独一无二的可伸缩性和可靠性。这些是大型企业中的关键IT的持续操作所必需的特质。IBM大型机通过各个领域不断的技术创新实现了这些特质,这些领域包括硬件虚拟化、故障转移、自我诊断、大范围共享内存多路处理和远程资源共享等。其中很多技术创新都在中型服务器中得到了应用。企业环境的SOA的设计也具有这些属性,可以在不降低效率和服务质量的情况下实现重用。
大型机环境的三种SOA支持
为企业实现SOA要求考虑三个重要的注意事项:
·应用程序中的更改,包括现有应用程序的再工程和要创建的应用程序中的设计更改
·IT技能的更改
·IT基础设施中的更改(硬件、系统、中间件和通信)
尽管本文的重点是应用程序更改,但要记住,SOA支持项目的成功依赖于所有三种类型的更改。最新版本的硬件、系统、中间件和通信——特别是虚拟化、软件管理和通信——均经过精心设计,能满足SOA最佳工作所需的条件。最好在开始SOA项目前对IT基础设施进行编目,并更新对项目的成功非常关键的设施设备。另外,对可用技能进行编目,并安排培训。有时候,可以要求服务供应商(如 IBM Business Consulting Services)进行一个概念验证项目,并让IT人员参与其中,以从中学习所必需的技能。
SOA技能对于SOA系统的初期实现和维护非常必要。企业中的所有组件开发人员——包括COBOL语言开发人员——都必须进行SOA设计,因为组件的可重用性受限于设计者和实现者对组件服务的可能重用方式的预见。应用程序架构师(包括负责现有应用程序的架构师)也必须了解并使用一项新的SOA技能,即集成设计,其中包括组件组装、流程自动化和数据集成。
对于大多数企业,实现SOA的过程是漫长的,要通过能提供短期价值和长期价值的增量更改来完成。很多IT组织(特别是在金融服务和保险行业中的IT组织)都已经开始增量型开发项目,以在其部分现有软件投资组合中实现SOA支持。他们的经验表明,即使最低程度的SOA支持,也能使应用程序集成、流程自动化和快速软件重新配置变得更易于实现。
我们建议将SOA支持作为增量更改过程的一部分进行规划,而不要将其作为所属交付内容要替换现有系统的独立过程。较大的替换项目风险很大,开销也很大,只有现有系统不再能满足业务需求时才能进行。这其中的原因包括所带来的成本、项目进行过程中会变化的要求以及当前实现的干系人的反对。相反,增量式IT基础设施更改则是通常采用的方法,几乎不会造成中断,而技能和应用程序结构方面的更改通常也可以方便地通过增量方式完成。
为现有应用程序添加SOA支持
我们的讨论集中在SOA如何提供两种类型的价值:访问和重用/灵活性。新的SOA应用程序将同时体现这两种价值。为其添加SOA支持的现有应用程序通常采用以下模式之一:
·包装——现有应用程序及其现有接口不加更改地附加到提供一个或多个SOA接口的网关。此模式可提供访问,但并不能提高重用或灵活性。
·重构——修改或扩展现有应用程序,以提供更适合将其作为服务使用的新接口。此模式可提供服务和一定的重用/灵活性。
·组件化——现有应用程序被分解为组件,然后对这些组件进行重新组合,以促进重用,并将以前不可访问的功能作为服务操作公开。此模式可以提供最大价值的访问和重用/灵活性。
这其中的每种模式都具有优缺点。通常,IT组织会首先尝试采用包装模式来获得低成本访问。如果包装模式的操作成本较高,IT将对使用频繁的应用程序进行重构或组件化来提高性能。重构或组件化的一个相关动机是,为了公开以前只能通过需要与公开的服务不直接相关的信息的复杂对话框进行访问的应用程序服务。
接下来让我们对每种模式进行详细分析。
包装
大型机应用程序的包装在客户机/服务器时代就开始了,已是一项具有成熟技术支持的成熟做法。WebSphere Host Access Transformation Services(以下称为HATS)等IBM网关产品支持包装3270和5250应用程序。HATS最近经过了增强,可提供Web服务访问。最新版本的CICS提供通过Web服务的直接访问。此功能与可链接的3270网桥和访问流运行时功能一起使用,可以将CICS基本映射支持(Basic Mapping Support,BMS)应用程序作为Web服务发布。IMS使用支持通过IMS Connect软件连接的Web服务的J2EE应用服务器来提供类似的功能。
大型机应用程序可能设计为具有一个终端接口或消息接口。有时候同时具有这两种接口,并将UI、代码和业务逻辑分离开了。CICS和IMS应用程序的一个最佳实践是将3270 UI支持从业务逻辑拆分出来,然后使用消息接口实现这两个层间的耦合。这个设计原则与模型/视图/控制器体系结构有些类似,但却是独立出现的。它将UI中的更改与业务逻辑中的更改隔离开了,让UI在经过优化、可获得最佳UI处理效率的独立容器中执行。
设计SOA访问时,3270接口的两个限制尤为突出。
首先,在每个事务中,请求和应答均不能包含超过1,920字节的信息。更大的传输需要使用多个事务,添加路径长度和资源使用。例如,搜索John Smith的查询事务中可能会返回数百个客户。如果第一个3270屏幕(仅一次显示15个客户)并未显示正确客户,操作员则要请求后续屏幕,每个请求都是一个新事务,会带来CPU、I/O和内存开销。一个更好的接口(尤其是程序间的通信)将一次性返回所有John Smith记录。
其次,3270终端是对话型终端。这意味着对于每个已登录的用户都有一堆大型机资源与其关联,甚至空闲终端也是如此。此外,某些较老的应用程序编写为缓存特定中断请求的信息(如名为John Smith客户的完整列表)。虽然此类应用程序代码可提供show the next 15 customers named John Smith类事务的性能,但却对其他系统特征造成了负面影响。此类应用程序的用户无法更改终端,或者临时从应用程序断开,中间件无法进行负载平衡,系统无法管理信息缓存,不能在用户思考时或不在时将缓存交换出去来检查内存使用量。
更大的消息允许每个事务中包含更多的信息,能减少开销和提高响应时间。大型机中间件(如CICS和IMS)支持在消息接口中每个事务包含多达32KB的消息。当应用程序的UI逻辑和业务逻辑拆分开时,SOA支持通常可以在业务逻辑的消息接口上应用,而完全忽略UI代码。此中间件最近的版本已经开始支持更大的消息;不过大于32KB的消息要求对应用程序进行更改。
这就引出了下一个模式:重构。
重构
重构模式的目的在于向现有应用程序添加消息接口——通常为SOA接口,适合作为服务使用,使用WSDL进行描述。该接口必须采用不同的方式实现,具体取决于用户类型和性能需求。重构模式要求进行少量的应用程序更改,可以作为实现完全组件化过程中重要的一步。
重构通常是在不对应用程序进行重新设计的前提下完成的。
可以在UI和业务逻辑间引入一个消息接口。此方法可能比较复杂,但能在性能、可重用性和灵活性方面得到很大的提高。
或者,可以复制和编辑现有的应用程序代码,同时保留最初的UI和业务混合的情况。这就要添加所需的功能,但并不对原始代码进行大幅度修改,成本和风险可能更低。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
如何避免云计算与SOA冲突