ACM通信
观点
来自第一线:SOA DOA
Roy L. Angeles摄影
看来今天终于是我们都知道的那一天了，这只是时间问题。软件经理Marty因为未能兑现仅仅采用面向服务的体系结构(SOA)就能保证的节约成本、改进软件重用和缩短上市时间的承诺而受到老板的抨击，一辆救护车刚刚停了下来，要把他拖走。一切都应该如此不同。与目前正在展开的涉及救护车的场景不同，马蒂在脑海中对未来的想象是一辆布林克斯(Brinks)卡车疾驰到现场，把他的金库从现金泛滥的压力下解救出来。
有人真的应该感到惊讶吗?毕竟，Marty可能还在炫耀他嘴里的鱼钩，那是供应商Victor的SOA鱼竿钓上来的。马蒂吞下的诱饵上的大肆宣传一定引起了一种麻木的欣快感，导致了他的决定被忽视的商业和技术理由。Marty已经成功地相信，他的项目是唯一一个没有从蓬勃发展的SOA银弹财源中获利的项目。
尽管Marty轻率地进入了SOA领域，但他很难三次以同样的方式描述它。然而，为他辩护的是，许多其他人对SOA是什么和不是什么有不同的想法。幸运的是，我家里有一个十几岁的女儿，所以在任何话题上都不缺乏专家的意见。出于好奇，我问她，她认为面向服务的体系结构意味着什么。她告诉我，这是她用来建造购买时尚服装的商店的一种方法。关于SOA可能是什么当然有不同的观点，但这一个可能有点极端。
有些人可能会说，他们仅仅通过使用XML、WSDL、SOAP和UDDI技术就完成了SOA的探戈。其他人可能认为，如果他们使用工作流并且他们的类是无状态的，那么他们就是在向SOA旗杆敬礼。实际上，SOA描述的是一种独立于使用特定技术的体系结构风格。这种体系结构风格涉及以某种形式的注册中心发布服务，用户可以自行发现、内省、连接和调用该注册中心。当然，SOA是由这里提到的那些技术支持的，但是其他技术，如CORBA和DCOM已经支持它很多年了。
对于一些软件组织来说，主要的困境不是决定采用SOA是否有助于实现其开发目标，而是决定应该使用哪些技术和设计策略来实现这一目标。并不是所有的SOA用户或潜在用户都意识到，当涉及到应该如何使用SOA开发软件时，他们有其他选择。不幸的是，没有考虑到这些选项的SOA菜鸟实际上有可能对他们的软件体系结构造成负面影响，而不是利用SOA真正提供的一些好处。
我想知道到底是哪根稻草压垮了马蒂的SOA。为了成为优秀的SOA实践者，Marty的软件人员是否将一些服务一般化到甚至不能满足他们自己产品的需求的程度?开发分布式中缀服务的想法听起来不错，但是仅通过加减法调用远程流程对性能的影响可能有点超出SOA的要求。尽管这些中缀服务的编写具有可发现、无状态、可组合和不依赖于任何其他服务的标志性SOA特性，但Marty还是落入了如今许多项目似乎都陷入的陷阱。他没有将他的架构和设计决策与描述他的项目目标的信标(质量属性)联系起来。一个相反，他让猖獗的SOA炒作和宣传蒙蔽了自己。结果，他没有看到对灵活性的不懈追求已经超过了他的产品中性能和可用性的重要性。
也许Marty的不幸是他解雇了所有系统工程师的后果，因为他相信采用SOA将传统的软件生命周期转变为只涉及开发和集成的活动?假设“盒子里的玩具”架构会在杂乱无章的服务集合中突然出现，而不需要投入与传统软件工程方法相关的时间和精力，这样可以节省大量的资金。
也许还有另一种可能是Marty的救护车之旅的根源:他是否选择了错误的抽象级别来实现SOA?与服务用户直接在“存根”级别与它们挂钩相反，通常情况下，封装此类存根的服务层有可能改善包括性能、可用性和生存能力在内的重要属性。具体来说，如果之前已经获取了请求的信息，则可以通过缩短远程方法调用来提高性能。在出现故障或SLA违反的情况下，可以通过服务层与备用服务提供者连接来提高可用性。即使到实际服务提供者的连接暂时不可用，也可以通过向服务用户提供一定的响应保真度来提高生存能力。
并不是所有的SOA用户或潜在用户都意识到，当涉及到应该如何使用SOA开发软件时，他们有其他选择。
正如刚才所建议的，在选择最佳实现SOA的策略时，不应忽视封装的好处。事实上，即使在我女儿对SOA的相当有趣的定义的上下文中，她也认识到封装的价值，“爸爸，我可以享受我的衣服，而不必知道它们是如何制作的任何细节。”也许您的SOA使用策略应该注意这些明智的话，并对服务用户隐藏适用的实现细节?例如，当产生的副作用可能是编写连接到服务的代码比实现服务本身所需的代码更多时，一个极其简单的服务的用户为什么要费心去了解UDDI呢?从质量属性实现的角度来看，首选的实现可能是将UDDI隐藏在一个瘦服务层下面。
采用SOA并不是抛出一个开关，突然可以避免卷起袖子的工程，或者意外地获得可用的时间和金钱来使用业务流程分析正确标识服务。当然，由于重用某些组件或购买其他组件，一些开发活动可能会被缩短，但是，人们能够实际购买提供产品核心“业务逻辑”的预先存在的服务的频率有多高?有多少软件经理实际上愿意在他们的开发计划中增加风险，以找出如何将迫切需要的特定服务一般化以满足未知或未来用户的需求?为了实现SOA的好处，仍然需要工程和计划，而不是仅仅希望通过工作流引擎将一堆随机的服务粘在一起来完成工作。
遗憾的是，马蒂没能赶到医院。无论错误的业务决策和实现策略的组合可能最终导致了他的死亡，Marty在到达时就已经死了，就像他的SOA项目一样。事情本不必是这样的。采用SOA并不意味着Marty可以忽略最佳实践或蔑视常识。是的，Marty的架构是灵活的，但是当其他关键的架构属性被忽略或忽略时，灵活性还有什么价值呢?
您的SOA运行状况如何?您是否认为SOA只能由Web服务启用?您是否认为性能和抽象等属性的好处只在“老式”架构中重要?您是否将SOA的使用与您的质量属性保持一致?密切关注您的回答，您一定不想错过未来SOA可能出现的DOA的警告信号。
脚注
a.驱动软件架构的非功能性属性(L. Bass, P. Clements, R. Kazman，软件体系结构实践，第二版， Addison Wesley, 2003)。
DOI: http://doi.acm.org/10.1145/1400181.1400191
©2008 acm 0001-0782/08/1000 $5.00
允许为个人或课堂使用本作品的全部或部分制作数字或硬拷贝，但不得为盈利或商业利益而复制或分发，且副本在首页上附有本通知和完整的引用。以其他方式复制、重新发布、在服务器上发布或重新分发到列表，需要事先获得特定的许可和/或付费。
数字图书馆是由计算机协会出版的。版权所有©2008 ACM, Inc.
没有发现记录