服务重用是
SOA的核心价值。在实施服务重用的过程中，许多企业纷纷体验到应用开发和维护成本的降低显著，并实现了更简化的操作，与更好的商业灵活性。
带着一系列问题，记者走访了IBM的专家，共同探讨了关于服务重用的挑战与机会，以及他对成功实施SOA的看法。
问题1：SOA成功与服务重用的关联性有多高?在企业中鼓励服务重用的最佳方法又是什么?
服务重用是SOA的核心价值。它解决了从终端到终端的商业问题或流程。
建立最终服务并强迫人们重用已成为过去式。如今有越来越多的公司开始寻找能够符合企业最佳实践，并推动用户自动过渡的服务。
我们的目标就协助企业找出适合自己的方法来发掘服务，并判别是否可以重用。
问题2：哪类应用或服务是重用的最佳对象?企业又该如何鉴别出这类服务?
去寻找那些能在企业中被不断重复的功能。比如员工检索、采购单状态查询、安全服务等。
问题3：太多的服务重用是否会徒增风险，比如在系统绩效和可用性方面?如何规避这类风险?
有许多公司都在大量使用服务重用，随着服务规模的成长，这些公司也在极力维护着服务的完整性。在这里顺便提一下RESTful服务(一种基于表述性状态转移协议的服务)。用RESTful的形式来调用服务是一种常见的方式，因为它有着易于创建、使用和查找的特点。然而在具体实施中，人们往往会发现其基础架构并没有跟上使用任务。
提高服务质量的方法有很多，比如WebSphereMQ(一种信息列队系统)就是其中之一。WebSphere MQ可以被安插到RESTful服务的前端或后端，作为一种治理或补偿来大幅提高服务的可靠性与运行时间。通过这种方式，你无需改变服务定义就能在现有实施中体验到更高的运行时间。
问题4：网络服务标准(SOAP、WSDL、REST)是否是建立可重用服务的最佳途径?
SOA中的S(即service)涵盖了各种服务类型，而不仅仅是指网络服务。企业会根据自己需要来选择一些主打的重用服务类型，以求获取更好的可持续性。
不过在实际操作中，其它服务会存在一种长尾现象。这些服务并非那么重要，但你又不得不去访问。要解决这一问题，我们就须通过OASIS来开发SCA(服务组件架构)和SCO(服务组件目标)，将长尾现象中的各种服务融合起来，让他们以一种更标准的方式构成。无论这些服务源自于哪里，我们的首要目标都是提高服务重用的灵活性。
问题5：在不同的开发和运行环境下实现服务重用会面临什么问题?比如在JavaEE环境下部署.NET服务?
我们与微软保持着密切的合作，以确保在WebSphere和.NET之间可进行一些高级的互操作。此外，我们也正致力于确保Web-Sphere应用服务器能够在.NET上稳定运行，同时从该平台本地递交服务。.NET的另一大问题就是被局限在Windows操作系统中，而通过WebSphere与.NET之间的互用，我们就能支持更广泛的操作系统平台与数据库平台。
问题6：Web 2.0(比如混搭)现在是否也被运用在服务开发中?这一趋势是否会逐渐普及?
混搭(Mashup)是一种以创新的方式来构成服务的优秀方法。不过问题是，如何才能让现有的系统可以“混搭”?继而让WebSphere MQ列队可以通过RESTful服务被访问?现在WebSphere最新的功能包就可允许RESTful服务访问应用服务器。如果混搭要求一套全新的基础架构，那么实施的代价就会大幅提高。因此，我们追求的是在现有的服务、功能和基础架构上实现混搭。
问题7：重用服务的设计权是应当交到用户手里，还是仍由IT开发人员负责?
企业一般都想对运行在治理环境范围内的应用加以控制及授权。问题是对哪些用户群体授权，对哪些群体设限?我们在WebSphere门户也致力于解决这一问题。它能协助企业控制哪些用户群体拥有混搭权，或扁平工具拖放权，而哪些用户群体应被限定在一定范围内。
(ccnew)
