成功的面向服务架构SOA开发的方法(二)

 
   | |

导读:SOA的持续的解构意味着经常更改服务接口和服务组合。SOA中这种敏捷需要实现项目中的敏捷。当实现项目采用敏捷方法并接受改变时,SOA中真正的敏捷将起作用。

关键词:SOA 服务接口 服务组合 敏捷

 
正在加载数据...

  原则4:尽可能快地交付

  拉系统

  敏捷开发中的拉系统(Pull System)借助于信息发射源(Information Radiator)使人们能够自己确定去做什么(例如,走廊上可能有一个白板,所有相关的用户素材都写在上面的卡片上;分配工作意味着将素材卡片(Story Card)从白板的“to-do”区移到“checked-out”区)。

  在SOA环境中,您可以在卡片上编写用户素材和服务。通过添加服务,工作单元甚至变得更小,因为正如本系列的第1部分的SOA Application部分中所述,功能性是在用户界面应用程序、服务编排以及服务应用程序之间分配的。排队论指出,更小的工作包产生更高的吞吐量,例如功能的更快交付。

  众所周知的用于面向对象(OO)设计的CRC卡片(类(Class)、责任(Responsibility)、协作(Collaboration))技术可以修改成SOA设计中的SRC卡片。“面向服务的分析与设计原理”包括这种技术的初始示例。

  约定的经济模型

  传统上,软件开发有时被看作是产生成本。近来,软件开发被看作是产生收入,可以帮助利用经济期权。基于期权的软件经济从金融市场提取出相似之处:交付运行的软件的短期迭代被看作是实物期权(Real Option)。就像金融期权(Financial Option)一样,实物期权通过现在非常少量的投资,来向您提供可能从未知的将来获得收益的机会。

  但是并不需要走那么远:如果您创建约定的简单经济模型并使用它来驱动开发决策,甚至SOA约定也将从中受益。有了这个经济模型,就可以向团队成员授权,让他们自己明确什么对于业务是重要的:他们可以都从相同的假定开始工作。如果您考虑减少一些特性,销售部门可能推测出,没有这些特性,他们将少销售百分之“X”单位的产品。

  原则5:向团队授权

  对于任何软件开发,最有资格作决定的人就是在第一线工作的人。在解决方案体系结构层次上仍然需要严格的控制,而基础服务开发应该尽可能地灵活。通过授权给最接近实现的专业人员去做微观决策,您可以确保服务的最终代码满足所需要的功能性。在企业SOA中,您可以从授权和委托设计决策给服务的开发人员(在定义的范围内)中受益。

  无论何时沿着层次结构向下委派决策权,您都必须确保所有的决策者都理解了统帅全局的愿景。通常,决策应该始终的是大家共同参与的活动,而不是孤立的活动。跨功能团队的环境(出现在敏捷项目中)促进了决策协作。

  原则6:构建完整性

  构建在概念上具有高度完整性的SOA的方法是从客户到开发团队、以及开发团队的上游流程和下游流程之间都有良好的信息流。从我们的角度来看,我们认为这一原则在服务开发层次以及服务编排中具有很高的价值。通过维持业务和IT专业人员之间良好的通信水平,可以确信您所交付的IT解决方案满足当前以及未来的业务流程和需求。随着结构良好的SOA中的业务和IT之间的联系越来越紧密,逐渐要求所交付的服务能够满足和紧密配合超出目标的业务流程。如果没有这种高层次的完整性,那么交付的服务不满足必要的业务要求或QoS的风险将会增加。

  解构

  现在,在IT产业中解构开发代码的实践得到认可已经有一段时间了。在SOA的环境中,这种实践同样重要。由于与业务的配合越来越紧密,以及需要确保所交付的服务可以支持不断变化且敏捷的业务环境,因此需要从本质上确保持续地评审和解构基础服务的设计。如果不能做到这一点,就将导致服务僵硬、不灵活,这对支持不断变化的业务环境没有益处。正如本系列的第1部分中的Agile architecture部分所述,该服务模型是控制持续解构的出色工具。

  原则7:眼观全局

  SOA的一项基本原则就是企业层次上的业务联合。对于任何企业体系结构(Enterprise Architecture)约定,都存在一个内在的需求,即确保始终维护统帅全局的“城市规划(city planning)”视图,并专注于将在SOA中部署的单个服务的详细设计。如果陷入以牺牲整体为代价来换取最佳的单个部分(或者服务)的诱惑中,您将承受交付不灵活的SOA的风险,它与企业中的关键业务流程是不相配的。

  结束语和展望

  正如我们在本系列中展示的,SOA可以从敏捷软件实践和LSD的已证明有效的原则中获得极大的好处。敏捷和SOA这两种实践的匹配基于一个共性——两者都极力设法处理变化。服务接口应该当作实现可能将改变的应用程序的必要条件。敏捷项目为要求它们实现的服务接口的改变做好了准备。

  SOA的“持续的”解构意味着经常更改服务接口和服务组合。SOA中的这种敏捷需要实现项目中的敏捷。基于本文中所强调的要点,我们要说,当实现项目采用敏捷方法并接受改变时,SOA中真正的敏捷将起作用。

  通常油和水并不能溶合在一起。不可否认,极限编程的想法和以可控的方式建立企业级服务体系结构之间存在着文化差异。但这仅仅是初步估计,在写完本文之后,我们可以声明存在一种乳化剂,即LSD的原则。

  所以,最后我们将声明,在SOA和LSD原则的上下文中,“油和水确实可以溶合”!


面向服务的敏捷性
 成功的面向服务架构SOA开发的方法(二)
 成功的面向服务架构SOA开发的方法(一)
 敏捷式软件的特征
 敏捷SOA成功秘诀之IT运营和监测
 名师讲堂之Kent Beck——响应式设计,现接受报名
 敏捷开发的关键问题
 距离敏捷中国大会2009还有两周,报名从速!
 另一种层面的敏捷开发
 如何解决敏捷开发中的用人不当问题
 忘记成熟度模型 敏捷模型到来(一)
 忘记成熟度模型 敏捷模型到来(二)
 忘记成熟度模型 敏捷模型到来(三)
 敏捷中国大会2009顺利闭幕 大师云集精彩纷呈
 敏捷开发中的架构设计初探
 企业架构成熟度模型:四大阶段不能跨越
 如何处理敏捷开发中的迭代问题(上)
 如何处理敏捷开发中的迭代问题(下)

原文出处:http://www.ibm.com/developerworks/cn/webservices/ws-agile2.html
 
作者:Gottfried Luef,Christoph Steindl    
 
 
 
 
 

SOA开发

 
准备开始SOA是一种挑战。我们咨询了著名的Rolta SOA中心,它是跨国咨询公司Rolta和SOA实施支持厂商的一个软件部门。他们给出了在SOA上取得成功的几条技巧……
 
不论你是测试人员、开发人员还是普通人员,可能都熟悉预定航班和航空旅行的麻烦之处。软件测试和开发人员经常成为类似调度和迭代问题的牺牲品……
 
当运行高流量网站的应用程序时,需要按照规模进行时刻通知,开源应用服务器有时可能会比它们的商业同行更好地满足企业的需求。
 
在过去数年的架构模式中,我一直专注于与客户合作,与以网格相结合为基础,更传统的面向服务架构方法来构建应用技术。
 
David Chappell是Oracle副总兼首席SOA技术专家,他集中研究利用SOA环境中的网格的架构模式。他是《企业服务总线》的作者,在软件行业有超过20年……

热门技术手册排行

 

随着开源技术越来越成熟,一个稍有开发经验的人通过学习就可以用开源的产品和技术构建一套可用的系统。对于从事软件开发的人员,尤其是对Java或动态语言相关领域的人来说,“开源”也许是他们最喜爱的单词。但是,很多时候我们需要的不仅仅是一个可用的系统,而是希望这个系统开发更简易、性能更高和扩展性更好等。这确实是一个令人头痛的问题。本指南很多地方都是点到为止,要深入了解相关信息的读者请借助参考资料、网站等自行挖掘。

 

本专题分六部分探讨SOA设计模式,当初设计面向服务架构的一大初衷就是降低服务间耦合度,由此提高服务的灵活性和自由度。

 

业务流程管理(business process management,bpm)不是一个新概念,甚至不是一个新名词。它是从相关的业务流程变革领域,如业务流程改进(bpi)、业务流程重组(bpr)、业务流程革新中发展起来的。流程管理技术也是从早期的工作流管理、eai、流程自动化、流程集成、流程建模、流程优化等技术中发展起来的。

 

TOAGF是一个架构框架,简而言之,TOGAF是一种协助发展,验收,运行,使用,和维护架构的工具。它是基于一个迭代(Iterative)的过程模型,支持最佳实践和一套可重用的现有架构资产。

 

云计算的概念越来越流行,Amazon、Google和IBM是第一批将云计算引入公众视线的公司。云计算就是新的Web2.0,一种既有技术上的市场绽放。

 

Mashup是一个非常cool的新的应用程序种类。如果你想真正的了解它们,我们需要回过头来看看你现在的计算机,其实它就是一个非常好的帮助你理解mashup的模型。现在开源的操作系统无疑是非常好的apis的集合或应用程序编程接口,帮助开发者去构建其应用程序。计算机本身也是一个很好的为用户提供接口的例子,键盘和鼠标可以被理解为你通过计算机的接口而使用的不同的应用程序。本技术手册为读者提供了一些相关信息,如果需要深入了解mashup,读者可以借助其他参考资源。

查看更多
 
 

登录TechTarget中国

关闭
本服务仅向TechTarget中国的会员开放,请登录或立即免费注册
电子邮件地址:
请输入您的电子邮件地址
密码:
下次自动登录