摘要
在成功规划SOA系列第一篇文章中我谈到什么是服务导向架构(Service-Oriented Architecture, SOA)以及该如何确保它为贵公司带来价值。在「Domain Model」中我特别着重「业务策略与流程」、「架构」、「成本与效益」。第二篇文章则讨论了如何制定有效的SOA蓝图。
在最后一篇文章里,我将探讨说明Domain Model剩下的三部份:「构成元素」、「项目与应用」以及「组织与管理」,说明该如何它们融入到你的长期项目规划中。
长期SOA规划
图一所示的BEA SOA Domain Model可在你做SOA规划的策略提供有效指导。以下图表中标出的六个主要领域都必须均衡发展才能确保导入成功。
图一 BEA Domain Model
本系列第一篇文章检视的是前三大领域–「业务模型与流程」、「架构」及「成本与效益」。但开始导入后,你必须要走完SOA每一阶段才能算是完整的SOA规划。
「Domain Model」后三部份在你以重复而渐进的步伐前进时,特别有助于持续评估与确保项目的弹性。有效评估你的前进步伐可以让你在实践商业价值的道路上一旦偏离正轨能实时发现、及时矫正。接下来我们就要深入探讨这几个部份,说明他们如何协助你进行长期SOA规划。
构成元素(Building Blocks):重复使用你的资产
SOA的成功有赖于实践重复使用的文化。SOA的构成元素是一些分自分散而能重新使用的服务与架构元素,可相互组合成复合式应用与服务基础架构。每一个构成元素实作出来后就会成为你整个SOA的功能目录中的一员。而随着目录愈来愈健全,未来的项目需要开发的新程序代码与服务基础架构就会愈来愈少,维护成本逐渐降低,而ROI也将稳定大幅成长。
清楚定义出服务,并经常把它送进一个生产性IT布署计划中乃是SOA项目的成功关键。服务一般可用三项元素定义之:
‧服务实作:服务的实作包含实际程序代码、应用接口及其它可透过服务展现出来的功能。
‧服务接口:服务接口具备一些标准化服务工具,可供使用者依据合约取用功能。
‧服务合约:服务合约明订服务的用途、功能、限制及使用方式。安全条件、响应速度、传输量及可用性等合约细节也有举例说明。
你的服务可以从现有应用中取得,也可以全新打造,不过无论哪一种方式你都面临同样的问题:该从哪一种服务实作起呢?以贵公司最基础的简单服务为佳,最好先从各业务单位通用的服务做起,再慢慢延伸到特定单位适用的功能。
这种作法有助于你的同事逐渐适应组合、重复使用服务的作业方式,而不会一开始就被一堆复杂工作所困。同样地你也应该从技术难度较低的服务做起,然后渐次挑战更高难度的类别。最先建立的基础架构服务像是登入、稽核、错误处理(error handling)等类似功能。
项目与应用(Projects and Applications):实作你的SOA蓝图
服务蓝图可从找出贵公司目前可用的IT项目与功能着手。接着,企业再把能完备此一架构与具有业务价值的个别项目开发出来并排定优先级。
第一步是检视既有应用与项目的状况,决定哪些功能可以重复利用。完全无法运用到其它应用,或是还在开发中的项目则先放在一旁。
以下信息请务必要搜集到:
‧现有应用功能、服务与依存关系
‧既有服务的细致度与能力
‧现有应用与预定或开发中的项目的依存关系,以及相关开发与维护挑战
‧目前通用服务的使用状况
‧与应用开发相关的成本及其它测量值/测量标准
‧应用所存取与传递的信息
‧应用程序中所用到的数据模型、转换(transformation)及转译(translation)
‧应用所牵涉到的工作流(workflow)及流程流
‧服务的使用,像是单一签入(single sign-on)、登入、错误与例外处理、监控与通知
‧服务层级协议(service-level agreement)、服务质量与非功能性的相关业务信息
‧目前正在执行的里程碑(milestone)与较急迫的项目时程的细节
搜集到这些资料可以帮助你清楚掌握现有项目及应用状况,进而找出共同功能。
组织与管理(Organization and Governance):设定预期目标
建置SOA需要对贵公司员工作业文化做些改变。IT功能/部门间必须建立起更密切的协同以便大家都能一同参与实现业务价值的工作,而不只是由一个单位部门一肩挑。
本领域有两大主题。第一是必须提供充分教育,让成员们不只清楚SOA的技术面相,也能了解文化变革的必要。这些关键讯息若没能确实传达,将来也必然无法确实实践。
第二,「组织与管理」的宗旨是把导入SOA视为一项企业变革计划,而非只是带入最新潮的技术而已。争取高层主管的同意与长期支持有助于公司内跨部门合作,让你有确保大家遵循及宣扬理念的「尚方宝剑」。
不同公司基于企业成熟度与经营方针的差异,建立「组织与管理」的方法也有所不同。中央化、由上而下管理的组织最有利于初期导入SOA,接着依次是联邦或半联邦的治理方式,最后是地方自治式的阶层组织。中央化组织对结构、资金筹措、营过程及工具、标准、技能变革管理以及指导方针有全面而深入的掌握。它也有助于决定、执行与强化以下SOA FAQ(这里只是列举)的相关流程:
‧系统的定义与修改由谁负责?
‧谁有权存取服务?
‧我们该提供怎样的服务质量?
‧谁要负担服务的建置费用?
‧由谁负担服务基础架构的费用?
‧服务的相互依存性应如何管理?
‧如何把服务对外公开?
‧SOA成不成功应如何测量?
最后,「组织与管理」的功能可确保你SOA计划的进程,以及它所实现的业务价值可以被测量出来。如果没有达到该有的水平,则贵公司就可采取成本效益的修正措施了。
总结
本文目的是提供一套清楚指导准则以协助公司利用BEA的「Domain Model」作为规划、实作与检视的框架,来导入SOA。本文着重探讨长期规划,说明SOA要成功,必须将「软件重复使用」的观念落实到制度层面加以管理,也必须了解分析现有IT项目对搜集通用功能的重要性,以及「组织与管理」模型该如何建立。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
如何避免云计算与SOA冲突