对于我们的那些一直关注与XML，Web services和面向服务的技术的那些分析师，他们备受鼓舞的看到我们的那些听众，包括用户，供应商，以及咨询公司，他们都在问一些关于如何正确的建立构架的更加复杂而深入的问题。

　　对于我们的那些一直关注与XML，Web services和面向服务的技术的那些分析师，他们备受鼓舞的看到我们的那些听众，包括用户，供应商，以及咨询公司，他们都在问一些关于如何正确的建立构架的更加复杂而深入的问题。这一切看起来似乎是我们已经通过了低谷，并且我们的架构师已经有了关于什么是SOA和为什么他们需要它的一些好的想法。不再试着重新定义SOA是什么和它对于商业是什么意义，人们反而关注于如何正确的使用SOA这些更加重要的问题上。在那些方面，我们最近的一些对话都集中于如何构建“正确的” 服务.关于这个问题的一个关键答案是确信我们构建的服务是以合适的粒度水平。

　　粒度是一个关于一个功能的需求模块必须以什么样的规模来满足即将到来的需求。组织细致的服务满足小单位的功能或者少量的数据。因此，为了构建复杂的商业过程，公司需要编排大量的类似的服务来有效的使这个过程自动操作，而这个处理过程是很困难的，通常是需要付出巨大努力的任务。粗糙组织的服务，尽管在一个单独的抽象接口中封装了大量的能力，减少了必须的服务请求的数目来完成一个任务，但是从不好的一面来说，这样就会返回过多的数据，或者很难再修改他们来满足不断变化的商业需求。这个选择的平衡，当然也是面向服务架构的一部分。

　　什么可以组成一个良好定义的服务?

　　在试图明白如何来划分适合粒度的服务的时候，第一个问题就是需要明白一个良好定义的服务接口必须是什么样的。一些人可能认为你所需要的就是正确的标准，然后你将会有一个良好定义的服务接口。从本质上而言，可以说良好定义的接口是一些可以被电脑理解的东西。尽管如此， 你使用哪个具体的标准来定义一个服务接口并不重要，只要它为松耦合提供足够的信息。在一个SOA 中，我们的确更倾向于基于标准的交换，而不是非标准的交换，并且这似乎看起来WS-*概念栈的好的部分(特别的是 WSDL, XML Schema, WS-Security, WS-Policy,以及可能的 BPEL或者 WS-CDL)正在广泛的受到人们的接受。尽管在机器可理解的标准中有一些元数据契约是好的，但是如果简单的让这些规范对于用户来说是可以获得的，这样并不能为如何定义服务接口和解决粒度挑战的问题提供任何的线索。确定的，很重要的是一个电脑能够理解一个提供的服务，但是这并不能使得一个服务有价值。实际上，其他的一些形式的架构也依赖于基于标准的接口，并且也没有产生我们所希望的松耦合的服务。在这一点，我们必须去掉我们的开发者的帽子，把我们的架构放上。

　　在我们最近的ZapFlash确定了一个服务契约有那些东西，我们讨论的事实是一个服务算不上服务，除非它是使用一个元数据编码的契约定义的。这个契约必须包含两个关键元素:规定了服务消费者和提供者两端的功能性和非功能性信息。在这种情况下，至少的 ，一个服务七月必须提供关于服务会做什么的明确的信息。还一句话说，一个服务必须清楚的说出它是意味着什么，并且它说了的意味着什么。用户不应该被留下来抓脑袋想在要求的输入被提供之后将会发生什么。所以，一个关于良定义的服务的更好的争论是一个服务是良定义的应该不只是意味着它只是可以被一个电脑理解的，而是要和服务所承诺提供的要完全的一致。基本地，一个人也可以理解这个服务契约，而不需要咨询额外的资源或信息。

　　现在，这个关于明确性的需求也逐渐的被松耦合的系统所要求了。通过一些东西，我们称之为架构的可以把这个明确的要求完成并且把服务的内部工作提供出来，或者可能提供具体的如何一个商业过程被组成的细节。尽管如此，为了让松耦合的系统工作， 我们可以知道一些关于服务是如何工作的或者关于组装的过程，从而能够完成任务。即便这样，我们也许会有在与语义紧耦合的协作称之为可操作的松耦合。换一句话来说，我们需要了解服务将会做什么，同时也要知道它将会怎样通讯以使得它是有用的。从而，第一个挑战是构建一个够具体细致的服务契约元数据，但是不要太多的细节。

　　聚焦复用

　　我们仍然还没有回答那个问题及如何来决定服务的粒度的水平，尽管最后，我们可以构建良好组织的，良定义的服务和粗糙组织，良定义服务。很重要的是要知道一个特定的服务是否是单独使用的还是多用途的。你可以说最好的服务是最有用的一个，这是事实，恰到要点。毕竟具有怎么多的冗余，良好组织的服务导致了大量的开销和低效率。很明显的具有更小的可用的粗糙组织的服务的集合在很多情况下都是一个更好的选择。尽管如此，很多开发者会把这条准则推向一个极端，并试图构建一个单独的服务，称之为，或者说，“做一些东西”是可以满足每一个单独得需求的。做某些东西将可以具有能够支持一些任意服务功能需求的一个简单接口，并且它将会产生一个相应的服务结果。

　　这个能做某些事情的服务的问题对于任何曾经试图实现这样的东西的人来说都是很明显的。从本质上来看，它不再是以恶可以使用的服务了，因为我们已经基本上只是把责任推给别人了，而不是让服务自己来决定自己的语义。我们只是把决定推延到更低水平的代码块上去了。本质上，我们只是把SOA看成某种类型的路由协议或者消息系统而不具有任何的固有的功能。这样的服务，明显的不能满足SOA的需求。

　　所以，如果通用目的的服务是一个转移注意力的问题，那么单独目的服务呢?这个问题的答案有一点拖拽。一些单目的的服务，尽管他们可能是非常良好组织的，并且只是完成特定的任务，但是他们可能异常的容易复用。那就是说，架构师也许能够把这些服务组装起来，从而能够满足很多情况的使用。相反的，可能面向领域的服务可能只能应用于特定的情况，但是事实是他们是特定于问题或者问题集合的，这正是使得他们对于商业是有价值的。并且这也是我们找到的关于试图解决服务粒度问题的第一个线索:不要关注与一个单独的服务，而是应该着眼于整个商业处理过程和在商业中服务是怎样满足多处理的需求的。 一个公司越能让一个服务来完成更多的服务，那么这个服务也就越有用。对应的，如果可以调整一个服务在多个不同的处理中使用，那么需要知道的是它是否是在合适水平的粒度。

　　分解处理的角色

　　服务不是一格真正的技术概念，它只是商业想要从它的技术中获得他们的价值的一种抽象表示。同样的，我们应该关注于如何从商业的角度来定义服务——这就是说，从商业处理的角度来看，因为商业处理根本的定义了商业。

　　一个具体实现正确的服务的途径是:以某种商业过程为开始，然后把它分解成为递增的更小的处理子过程，直到你不能再作进一步的分解了。这些分解出来的子过程就变成了那些实现系统的候选服务。如果一个公司越多的把商业过程以这种方式分解，他们就越能看到子过程之间的公共性，从而能够有机会构建一个合适的可服用服务集合。

　　尽管如此，这种由上而下的过程分解方法有一个致命的弱点，那就是我们最后可能定义了一些不可能或者不够实际来实现的服务。从而，很重要的是同时经过现有商业逻辑的练习，就是基于代码级别的而不是元数据，并把它作为服务提供出来，这些服务将会作为具体的而不是全部的商业处理的候选服务，而不是采用实现处理的机制。这将跨越两个服务种类:在多处理之间的可服用的商业功能性服务和可以在组织内部为不同的服务提供值的良好组织功能性服务。

　　ZapThink的感受

　　通过这种服务定义训练的公司应该保证不要陷入这种常见的现象，致命的思维缺陷是认为一旦定义了他们的服务，就完成任务了。SOA，天生就需要不断的发展，即使公司开展的服务对于一段时间的商业是完美无缺的，但是商业会连续经历持续的变化，就需要新的服务以及新的公司服务。那些在一些时候还有刚好合适水平的粒度的服务，也许仅仅几周之后就会变得不适合了。

　　结果，把服务的粒度水平转化为特定的形式是没有意义的。公司必须不断的重复他们的服务设计，在一个粒度范围内构建良好定义的服务接口，然后当这些服务是合适的时候，就可以发布和使用这些服务了。面向服务架构将花他们相当多的时间把服务接口集合在一起，从而在及时地提供了足够多的关于他们商业的知识，他们可以实现在良好粒度同粗粒度组合以及单独目标同多用途之间的最优组合。

　　结果，开发者和建筑师们会抵制这种得到正确服务的激励。实际上，使他正确并不是那么重要，因为今天正确的明天或许就是完全错误的。毕竟，建立服务并不是SOA的目标——它正在构建一个架构，这个架构允许商业持续的改进他们的为商业所需要的有用服务的集合，并且能够调整不断进行的变化。建设这种有用的服务是为了打破多用途和特殊领域的服务以及过度的定义和过多的不明确服务分界之间的平衡。这里没有固定的和已成定局的答案来说明哪些服务该针对特殊的公司，但是这里显然有更好的途径来是那些服务成为现实。刺激和奖励在商业中正在进行的争论将能够使得SOA对商业更有用，从而更值得去不断的书写和谈论。