有人认为可重用的好处被夸大了。Inaganti的实践经验将证明他们的看法是错误的。

　　面向服务的架构（SOA）经常被奉为代码重用的关键，关于这一点，专家们说起来容易，做起来却难。理想情况下，我们可以通过代码重用降低成本，并从中获益。但即使是那些狂热支持SOA的人们也不得不承认，如果仅仅只是通过未经深思熟虑的简单规划，想轻松地获得收益是不现实的。今年1月底在旧金山举行的Open Group企业架构师大会上，这一话题备受关注。

　　在这次大会中，Wipro技术公司的高级咨询师Srikanth Inaganti提出，应该为SOA建立一个可重用的框架。过去的两年半时间里，他一直致力于研究某客户的网站，希望通过有效地服务划分来改善可重用性。因此，作为Wipro公司SOA框架和工具开发团队的一员，他的建议可以说是来自实际应用需求的。

　　在他的介绍中，Inaganti谈到了在向SOA转换的过程中重用的重要性，讨论了在企业内部让员工接受重用思想所面对的问题，以及被他称为“试验性”的解决办法。

　　Inaganti表示，SOA从根本上改变了人们开发应用软件的方式。你可以在自己的生态系统中消费服务，并通过增加新的服务组合来提高整个系统价值。当然，如果仅仅只是增加一些个别人可访问的服务，或者增加的服务并未被加入整体系统中，这些情况下是不涉及重用问题的。

　　根据Inaganti的理论，重用与那些经得起时间考验的服务关系最为密切，或者可以理解为那些生命周期长的服务更有重用的必要。原因显而易见，企业可以通过对这些服务的重用来降低风险，缩短上市时间，减少维护和实施成本等。

　　重用的瓶颈

　　在重用过程中，Inaganti也遇到了许多困难和阻碍。下面列举出四个在企业架构（EA）方面存在的问题：

　　缺乏公司/企业的支持
　　缺乏支持重用的IT流程
　　缺乏相关IT标准
　　缺乏广泛接受的重用指标

　　他还列举来四个涉及SOA的更大的问题：

　　缺乏对可重用服务的意识和推广
　　缺少SOA质量保证（QA）
　　服务设计不足
　　时机把握不足

　　Inaganti指出，很少有客户会在规划阶段花足够的时间和精力来进行计划。因此，“并非有了组合服务的观念就一定能带来通用的设计”。

　　在整个过程中，相当多的人参与进来，他们都需要了解这些可重用信息。比如有人会告诉开发者，某个服务需要在不同场景下重用。服务开发完成，测试人员需要对代码进行测试，以确保其正常工作，他同样必须知道该服务是可重用对。另外，服务的使用者也需要知道哪些是具备SOA功能的应用。

　　有些人认为，SOA并不真正地需要标准。但Inaganti坚持认为，从成本的角度来看，我们需要IT标准。例如，他发现一个用户可能会通过访问10个网站使用5个搜索引擎。实际上，我们可以保持该多样性，而无需扼杀创新。但显然，仅仅有服务登录和集合（registries/repositories）是不够的。我们所需要的就是找出这样一个带头人，并组建一支用于支持重用的团队。

　　Inaganti表示：“确实会有很多阻力阻碍你使用组件——尤其是公司内部系统。相对定制的商业系统，阻力会小一些。”通常，支持重用理念常用到的例证是对于成本节约的好处，而重用支持者们也往往只停留在这一点上。要想使人们真正接受重用的观点，就必须有一个真实的管理案例，要实现这一点则需要一个成本分配模型。这是刺激某一业务部门为其他部门提供服务的最直接有效的方法。同时，还需要定义重用规则和进行一致性检查等。

　　使能重用

　　Inaganti希望，该可重用框架能够解决可重用过程中的困难和阻碍，并列举出四个与EA相关的解决方案领域，他们包括：

　　EA charter的定义
　　IT过程的完善
　　遵从检查
　　成本节省和可用性模型

　　同时，他也列举了四个与SOA相关的解决方案，包括：

　　服务登录和集合
　　重用测试、敏捷测试和性能测试
　　服务设计指南
　　业务流程和IT前景研究

　　Inaganti称，这需要研究整个企业完整的价值链，并将这些过程分布到各个运行中的不同应用，所用方法既可以是自上而下，也可以是自下而上的。

　　此后，再增加的服务则必须经过周密设计，体现出针对不同用户的最佳实践，数据则应统一规划和存储。在开始开发服务的第一步，需要通过一个合适的应用契机切入。有可能你找到的正是一个应用瓶颈。不过没关系，瞄准实际目标，通过性能测试来解决实际的负载问题。

　　然后，一旦开发出一定数量的服务后，下一个需求就是用来存放所有服务的服务库，以保证整个公司都能方便使用这些服务。服务库用于管理所有的可重用服务，帮助新用户从中获得所需的服务。Inaganti告诫说，虽然服务登记和服务库很重要，但它们的帮助是有限的。例如，从不同地方查询服务登记时可能就会出现问题。

　　当有需要时，用户必须能够找到他们所需的服务。同时，这些服务必须是能够正确使用的，这将是一项挑战。

　　建立可重用框架

　　一个具体的可重用框架需要大量离散的元素。例如，你可以从如何识别开展可重用的时机开始，但这也仅包括了业务流程研究、IT前景研究，以及消费能力、组合能力和数据利用研究。

　　Inaganti认为，这样一个框架的关键部分是可接受的重用指标和重用的发展，包括软件开发生命周期的检查点。

　　重用指标包括：

　　服务部署的数量
　　每一服务增加服务用户的数量
　　某时间框架内向服务发出请求的数量
　　每用户节省的成本
　　使用收入

　　对这些指标数据制图，可以产生一个随时间呈S形的开支/节省曲线。波峰则是新用户被加入到服务客户组合的时刻。

　　Inaganti接着谈到他的实际经验，他的这位客户是一个大型服装、食品和饮料服务公司。在该案例中，Inaganti遇到了一长串的挑战：

　　没有正式的EA规范用来连接业务目标与IT目标
　　一个较新的集中架构群
　　缺乏正确的IT项目清单，甚至从未被持续维护过
　　业务连续性有待改善
　　重用时机有待改善
　　过于冗长的应用部署时间周期
　　企业层面过高的软件许可费用
　　需要更低的总体拥有成本，并减少维护成本

　　Inaganti说，通过面向整个企业传播可重用和SOA概念与方法，他顺利解决了所有这些挑战。他准确地识别出改进系统的时机，并致力于建立全新的架构重审过程，以更好地联系IT和业务流程。

　　成功尽在细节
 
　　不可避免地，一批相当数量的、经验丰富的IT人员对于SOA和可重用持有不同的看法。他们把SOA和可重用称之为“白日梦”（pipe dreams），认为SOA和可重用的支持者们必然会遭遇失败。

　　如果魔鬼在细节中，那么天使亦然。从Inaganti的经验，我们看到，如果企业想成功实施SOA和可重用，想顺利克服实施过程中不可避免的阻碍，那么在实施过程的每一步都需要提供尽量详细的计划和路线图，并做好准备付出更多持久的努力。