探究将软件重用到面向服务的体系结构(SOA)时对其起负面作用的因素，了解重用工程如何给SOA价值实现过程带来积极影响。
引言
对于许多组织而言，有效而系统的软件重用仍然是一个很难达到的目标。现在真的存在很多与重用相关的业务促进因素。首当其冲的可能就是IT成本削减以及对IT体系结构和基础系统中的灵活性和响应能力的迫切需要。
通常，您同样也会发现阻碍进行更为成功的重用起负面作用的因素(或者，至少看起来是这样的)。不过，要应付这些起负面作用的因素却并不容易。同时，面向服务的体系结构(SOA)方面的技术演变为实现软件重用提供了基础。SOA价值方面的关键部分就是通过软件重用得到的益处。
作为重用的关键实现技术的SOA
一项对developerWorks和其他开发人员参考资料中的各种SOA最佳实践文章的调查表明，有大量的对SOA中的接口的重要性的论述。服务接口是集成设计的关键。通过与标准的使用相结合，接口成为了创建松散耦合(服务客户机与服务提供程序的通信不受编程语言和平台的限制)的基本元素。服务需要独立，以使客户机无需了解服务组件的内部工作;实质上，服务作为“黑盒”进行操作。“白盒”重用(或复制与粘贴)中将对源代码进行修改，以在另一个上下文中使用，这种方法很有用，但通常不如“黑盒”重用的好处多。“由于在整个生命周期中可以从黑盒重用获得较多的好处，因此系统的重用程序可以在不进行更改的情况下进行重用”(摘自Measuring Software Reuse:Principles,Practices,and Economic Models，请参阅参考资料)。服务对功能进行封装，此功能可以是业务功能或实用功能。在developerWorks文章“Migrating to a service-oriented architecture”中对SOA属性进行了更为详细的讨论(请参阅参考资料)。
SOA的所有这些特征提供了可进行软件重用的技术环境。不过，即使有了SOA概念和技术提供的重用关键组件，传统的重用阻碍因素仍然是个问题。
重用阻碍因素
在大多数开发组织中，会频繁进行软件重用(至少会临时出现这种情况)。项目之间以一种非正式的方式共享。SOA提供了更为正式的重用，当服务客户机访问服务以给定功能时，将出现重用。重用方(服务客户机)甚至都不知道其所重用的代码是什么，而且也不需要知道。它们只知道服务正向其提供所需的功能。那么，问题是什么呢?此处，我们将分析一些与可重用服务的创建与使用相关的挑战。
教育培训与文化：对某些项目团队而言，Web服务之类的SOA技术可能还是新事物，因而在利用可用服务之前，他们需要学习一些新的技能技巧。项目团队有效找到可用服务，理解其功能并确定给项目带来的好处的能力水平决定了该团队实现服务重用价值的可能性。UDDI注册中心非常重要，但单单这个还不够。WSDL文档设计用于供机器读取，人也能读懂其内容，希望重用服务的团队通常需要其他信息。服务学习曲线会对重用价值造成影响，因此，这也是项目团队要考虑的因素，以确定是进行重用，还是重新编写代码。
可重用服务的可用性：显然，必须存在有价值的可重有服务才能实现服务重用。确定在给定组中的这些服务，并实际创建和提供它们，可能是一大挑战。必须进行某种层次的域分析，以确定在整个域中存在的共性，从而确定哪种类型的服务具有重用价值。组中的项目团队为其解决方案创建的软件中可能包含可硬编码为可重用服务的良好候选服务，这些服务能够以经济高效的方式在更广泛的范围内使用。了解何种情况下可以进行重用是一个挑战，而提供允许在已确认可以进行重用的地方执行重用的组织构造则更是一大挑战。
重用工程
对工程进行重用的核心是担任跨项目边界的职务的专家(重用工程师)的重用工作。他们在资产的使用和生产方面为项目团队提供帮助。Robert Fichman和chris Kemerer在“Journal of Systems and Software”发表的一篇文章“Incentive compatibility and systematic software reuse”(请参阅参考资料)中提供了这个描述：
“重用中心的重用工程师实际上是‘外借’给应用程序开发团队以通过重用实践为他们提供帮助。在重用使用方面，重用工程师提供关于潜在的可重用内容的知识，并在任何必要的重用的采用过程中提供帮助。在生产方面，重用工程师识别何处最适合产生新组件，并帮助实现这些组件的可重用性。而对项目而言，重用工程师将记录域的知识、可重用的新资产以及关于哪些现有资产本身已经很好了，哪些尚需要修改或增强的知识。”
重用工程师必须技术熟练，有项目级的经验，且能最终促进重用的实现。重用工程师角色的一个关键特点就是其职位是跨多个项目组的。软件重用是重用工程师的“日常工作”，他们通常在其影响范围内有与重用结构相关的目标和措施。就取得重用程序的成功以及对SOA活动而言，对此类涉及的工作领域超过单个项目的角色的投资非常重要。很少有组织通过一次只专注于一个项目而实现了成功的系统重用(Software Reuse: Architecture, Process and Organization for Business Success——请参阅参考资料)。就我对组织应用重用的经验而言，我发现采用这个方法处理传统重用阻碍因素(如前面所述的那些因素)非常有效。对于这些阻碍因素中的每一个，我都将讨论重用工程的影响。
