在SOA体系中，服务是SOA的基础结构，属于堆栈的最低水平。它是SOA的基本功能单位。但是，大多数企业对结构比较重视，而对基本服务却很少关注。为了创建并保持一个健康的SOA，我们需要对服务设计、创建和测试的过程进行改进。那么，什么是最好的服务应用呢？

　　这个问题的核心是，我们趋向于把服务看成是简单的基础结构，认为它会永远存在，总是有很好的设计和相关模式，并始终处于良好的运行状态。但是，情况并非如此。的确，服务是SOA的基础结构，就像一所房子或建筑物的砌块一样，品质将决定成品的价值，在此情况下，成品就是指SOA执行本身。因此，花费时间确定服务的功能、定义、设计以及创建方式，从时间上来看，是一项很划算的投资，而许多架构中却逐渐失去这一行为。

　　为了建立更好的服务，在SOA项目开始时，澄清以下几项服务问题：

　　第一，SOA的服务并不需要一定是Web服务。ZapThink公司已经很清楚这一点。不过，如果你一直在接受夸张的炒作，你可能会对这个表述产生困惑。但事实是，你可以不使用Web服务，而选择更为传统的方式建立SOA，比方说交易、分布式对象、或定制的软件系统。而且，如果是“特殊需要架构”的话，比如那些需要高性能的架构，毫无疑问，更不可能采用Web服务。

　　同时要记住，服务契约语言不止包括WSDL。因此，虽然这些服务（或更确切地说，服务接口）都与Web服务相类似，但是与WSDL相比，它们的契约中含有更多的信息。

　　第二，服务产生行为和数据，而不仅仅产生数据。设计、创建和/或提供服务的大多数人都认为服务只能提供数据，而在多数情况下也的确如此。当服务被启用时，数据在结构中生成，然后被另一个系统使用。然而，尽管许多服务都是面向数据服务，但它们仍能提供行为，或者能做一些与数据有关的事情，或者也许是提供不含半个数据的行为。

　　第三，服务不是应用程序，你不应该按设计程序的方式设计服务。正如下面所介绍的，每个服务都有各自具体的设计方向。定义和设计服务的方式，不同于许多人认为的传统的程序设计方式。你需要在许多系统中建立一个更小的系统，因此，你要特别注意系统的互操作性、间隔尺寸、核心目的以及测试方法。

　　服务不是完整的应用程序或系统，而只是程序的一小部分。服务也不是子系统；但可以说是一小部分子系统。事实上，在服务设计方面，以及如何使用服务形成或详细或粗略的解决方案方面，服务更类似于传统的程序功能。知道了这一点，我们在处理服务设计问题时，就会有一个比较好的理解基础。

　　最后，每个服务都有特定的目的，而且这些服务并不复杂，也不自然依附于其他服务。因此，它们很容易被提炼成复合程序，其本质是，把这些服务当成是复合程序的本地程序一样使用。在此情况下，提供的服务很有可能会失败。因为它们不是被设计的，而是被提炼的，因而通常具有太多的依附关系，以至于无法像从一开始就被正确设计的服务一样起作用。这就需要权衡利害关系。服务应该拥有高度的自治。在任何可能情况下，它们都应该不依赖于其他服务而执行。这样，你就可以通过服务本身使用服务，并按照此思路设计服务，而不需要考虑服务是粗粒度还是细粒度。

　　服务的设计

　　那么，怎样设计一个服务呢？重要的是要遵循几个基本原则。虽然，遵循这些原则不能保证你一定成功，但是它肯定会把你送入正确的道路。首先，也是最重要的，你需要经常为复用进行服务设计。服务成为其它一些应用程序的一部分，因此必须将其设计成能够提供行为和信息，而不是设计成特定的程序。对于许多开发商来说，这种做法比较难，因为他们的生涯中大部分时间都在研究用户个人化软件。因此，服务模式必须适用于多个问题域或程序，而这就意味着你必须使用可复用的服务。否则，实践是徒劳的。然而，并非所有的服务都可以或应当是可复用的，因此，复用的标准应该是有选择性的。

　　此外，服务必须为不同种类而设计。创建服务，从而使本地接口或平台免于访问。要记住，服务，譬如说一个内置于Linux的服务，可以被Windows，Macs，甚至是大型机的程序使用。使用服务的这些程序都应该不用考虑如何创建该服务，而且这些程序应当是完全的平台独立。

　　其他好处还包括，服务提炼允许多个用户同时对服务进行访问;向服务开发商隐藏技术细节。使用服务提炼，必须绕开许多协议、数据存取层、甚至是可能已经部署的安全机制，从而将这些非常不同的技术隐藏在一个能模拟抽象层的数据层之后。同样，当我们建立或设计服务时，我们需要解释集合服务的概念。很多服务将成为其他服务的一部分。因此，这些服务将成为混合服务，继而被程序使用，而你必须在设计中就要考虑到这一点。举例来说，一个客户验证服务，可能是客户处理服务的一部分，而该客户处理服务又是库存控制系统的一部分。集合服务是一组能相互合作，最终解决问题的服务的集合。

　　服务不是程序，而且，正如我们在上文讨论过的，服务应该有应用的限制范围。换句话说，它们只能做简单的事情，比如检查库存品或计算订货点。如果你有更复杂的需求，你就需要编写更多的服务，而不是赋予一个服务过多的功能。如果一个服务有太多的功能，那么该服务就会显得太笨重，而且难以被复用——因为可能在你使用服务的地方，你只利用了其十分之一或更少的功能。

　　那么，既然我们已经了解了必须遵循的几个常见的设计模式，问题是：怎样设计服务？还有，可以使用哪些工具？架构设计师和开发商可以遵循特定的步骤。下面有一些关于新的服务设计的建议。

　　1.你需要说明服务的目的。服务将做些什么，目标用户是谁；是人，是程序，以及/或者其他服务？

　　2.你需要说明服务必含的信息，包括轮廓和其他元数据。你必须了解服务如何使用信息，什么函数需要什么数据。

　　3.你需要说明服务内含的函数（方法）；换句话说，就是你想要揭露的行为。在这一个环节中，我们也需要详细说明每个函数，包括解释在使用传统的函数分解图时函数如何失效。

　　4.你需要说明连接到服务的任何接口，包括计算机和人。这意味着我们需要说明服务如何与访问程序相互作用，以及通过什么样的机制发生作用。

　　5.你需要说明如何借鉴上述建议完成服务测试。测试是一个重要但往往被忽视的环节，你需要说明那些使用服务的程序如何按照它们的使用模式测试服务。你需要说明测试信息，服务调用以及结果的有效性。

　　SOA的成功，其核心是有一套清楚的服务设计、开发和测试方式。最后要说的是，真正发挥作用的是那些传统的优秀方式方法，而不是新技术、新工具和新的编程技巧。这不是那些听信喧闹炒作的人想听到的，但是，这却是事实。

　　ZapThink的反应

　　事实是，对开发商而言，服务是一个新的挑战，而且服务有它们自己的要求。从许多方面看来，这更像是想法的改变——从结构的分析、设计与开发，转向面向对象的分析、设计与开发。大家都知道这是一个长期的过程，而且现在这项工作仍然在进行中。

　　在短期内，我们可以看到你期望看到的任何一种新方式都会带来的问题——经过差劲的设计、开发和测试完成的服务将导致成本的增高和生产力的损失。这样一来，这次失败将引起企业的再思考，再学习，以及对设备的更换，从而最终获得服务设计权。这需要企业在未来3至6年内在培训、工具和测试设施方面投入大笔资金。同时，这也需要对整个SOA的概念的重新审视，因为人们知道，他们都是依赖于基础服务。因此，在开发商沿着这条学习曲线磕磕绊绊的前进时，SOA体系结构也会因此而受损。

　　同时，也必须注重把现有遗留系统作为服务集合提供的过程。虽然看起来，开发商不得不采用已经部署了的、现在作为服务而提供的接口，但事实上，他们可以做很多事情完成提炼的服务设计，从而使其更好地服务于架构。许多人认为，把APIs或交易直接转变成服务的工具和技术才是我们要找的方法，但是大多数人会发现采用这些方法建立的服务，终究只能提供很少的价值。

　　SOA当然是一种架构，但是它的基础是对服务的适当设计、开发和测试。这些服务揭示了SOA的核心，而软件工程师在这一工作中推行的方法过程意义重大。目前需要改变SOA服务的设计、开发和测试，同时也需要了解这一改变的意义。