- 易迪拓培训,专注于微波、射频、天线设计工程师的培养
解决服务粒度挑战 构建正确服务 合
录入：edatop.com 点击：
对于那些一直关注于XML，Web services和面向服务技术的分析师们，他们备受鼓舞的看到听众，包括用户，供应商，以及咨询公司，都在问一些关于如何正确的建立构架的更加复杂而深入的问题。这一切看起来似乎是我们已经通过了低谷，并且我们的架构师已经有了关于什么是SOA和为什么他们需要它的一些好的想法。不再试着重新定义SOA是什么和它对于商业是什么意义，人们反而关注于如何正确的使用SOA这些更加重要的问题上。在那些方面，我们最近的一些对话都集中于如何构建"正确的" 服务。关于这个问题的一个关键答案是确信我们构建的服务是以合适的粒度水平。
粒度是一个关于一个功能的需求模块必须以什么样的规模来满足即将到来的需求。组织细致的服务满足小单位的功能或者少量的数据。因此，为了构建复杂的商业过程，公司需要编排大量的类似的服务来有效的使这个过程自动操作，而这个处理过程是很困难的，通常是需要付出巨大努力的任务。粗糙组织的服务，尽管在一个单独的抽象接口中封装了大量的能力，减少了必须的服务请求的数目来完成一个任务，但是从不好的一面来说，这样就会返回过多的数据，或者很难再修改他们来满足不断变化的商业需求。这个选择的平衡，当然也是面向服务架构的一部分。
什么可以组成一个良好定义的服务?
在试图明白如何来划分适合粒度的服务的时候，第一个问题就是需要明白一个良好定义的服务接口必须是什么样的。一些人可能认为你所需要的就是正确的标准，然后你将会有一个良好定义的服务接口。从本质上而言，可以说良好定义的接口是一些可以被电脑理解的东西。尽管如此， 你使用哪个具体的标准来定义一个服务接口并不重要，只要它为松耦合提供足够的信息。在一个SOA 中，我们的确更倾向于基于标准的交换，而不是非标准的交换，并且这似乎看起来WS-*概念栈的好的部分(特别的是 WSDL, XML Schema, WS-Security, WS-Policy,以及可能的 BPEL或者 WS-CDL)正在广泛的受到人们的接受。尽管在机器可理解的标准中有一些元数据契约是好的，但是如果简单的让这些规范对于用户来说是可以获得的，这样并不能为如何定义服务接口和解决粒度挑战的问题提供任何的线索。确定的，很重要的是一个电脑能够理解一个提供的服务，但是这并不能使得一个服务有价值。实际上，其他的一些形式的架构也依赖于基于标准的接口，并且也没有产生我们所希望的松耦合的服务。在这一点，我们必须去掉我们的开发者的帽子，把我们的架构放上。
在我们最近的ZapFlash确定了一个服务契约有那些东西，我们讨论的事实是一个服务算不上服务，除非它是使用一个元数据编码的契约定义的。这个契约必须包含两个关键元素：规定了服务消费者和提供者两端的功能性和非功能性信息。在这种情况下，至少的 ，一个服务七月必须提供关于服务会做什么的明确的信息。还一句话说，一个服务必须清楚的说出它是意味着什么，并且它说了的意味着什么。用户不应该被留下来抓脑袋想在要求的输入被提供之后将会发生什么。所以，一个关于良定义的服务的更好的争论是一个服务是良定义的应该不只是意味着它只是可以被一个电脑理解的，而是要和服务所承诺提供的要完全的一致。基本地，一个人也可以理解这个服务契约，而不需要咨询额外的资源或信息。
现在，这个关于明确性的需求也逐渐的被松耦合的系统所要求了。通过一些东西，我们称之为架构的可以把这个明确的要求完成并且把服务的内部工作提供出来，或者可能提供具体的如何一个商业过程被组成的细节。尽管如此，为了让松耦合的系统工作， 我们可以知道一些关于服务是如何工作的或者关于组装的过程，从而能够完成任务。即便这样，我们也许会有在与语义紧耦合的协作称之为可操作的松耦合。换一句话来说，我们需要了解服务将会做什么，同时也要知道它将会怎样通讯以使得它是有用的。从而，第一个挑战是构建一个够具体细致的服务契约元数据，但是不要太多的细节。
聚焦复用
我们仍然还没有回答那个问题及如何来决定服务的粒度的水平，尽管最后，我们可以构建良好组织的，良定义的服务和粗糙组织，良定义服务。很重要的是要知道一个特定的服务是否是单独使用的还是多用途的。你可以说最好的服务是最有用的一个，这是事实，恰到要点。毕竟具有怎么多的冗余，良好组织的服务导致了大量的开销和低效率。很明显的具有更小的可用的粗糙组织的服务的集合在很多情况下都是一个更好的选择。尽管如此，很多开发者会把这条准则推向一个极端，并试图构建一个单独的服务，称之为，或者说，"做一些东西"是可以满足每一个单独得需求的。做某些东西将可以具有能够支持一些任意服务功能需求的一个简单接口，并且它将会产生一个相应的服务结果。
这个能做某些事情的服务的问题对于任何曾经试图实现这样的东西的人来说都是很明显的。从本质上来看，它不再是以恶可以使用的服务了，因为我们已经基本上只是把责任推给别人了，而不是让服务自己来决定自己的语义。我们只是把决定推延到更低水平的代码块上去了。本质上，我们只是把SOA看成某种类型的路由协议或者消息系统而不具有任何的固有的功能。这样的服务，明显的不能满足SOA的需求。
粒度是一个关于一个功能的需求模块必须以什么样的规模来满足即将到来的需求。组织细致的服务满足小单位的功能或者少量的数据。因此，为了构建复杂的商业过程，公司需要编排大量的类似的服务来有效的使这个过程自动操作，而这个处理过程是很困难的，通常是需要付出巨大努力的任务。粗糙组织的服务，尽管在一个单独的抽象接口中封装了大量的能力，减少了必须的服务请求的数目来完成一个任务，但是从不好的一面来说，这样就会返回过多的数据，或者很难再修改他们来满足不断变化的商业需求。这个选择的平衡，当然也是面向服务架构的一部分。
什么可以组成一个良好定义的服务?
在试图明白如何来划分适合粒度的服务的时候，第一个问题就是需要明白一个良好定义的服务接口必须是什么样的。一些人可能认为你所需要的就是正确的标准，然后你将会有一个良好定义的服务接口。从本质上而言，可以说良好定义的接口是一些可以被电脑理解的东西。尽管如此， 你使用哪个具体的标准来定义一个服务接口并不重要，只要它为松耦合提供足够的信息。在一个SOA 中，我们的确更倾向于基于标准的交换，而不是非标准的交换，并且这似乎看起来WS-*概念栈的好的部分(特别的是 WSDL, XML Schema, WS-Security, WS-Policy,以及可能的 BPEL或者 WS-CDL)正在广泛的受到人们的接受。尽管在机器可理解的标准中有一些元数据契约是好的，但是如果简单的让这些规范对于用户来说是可以获得的，这样并不能为如何定义服务接口和解决粒度挑战的问题提供任何的线索。确定的，很重要的是一个电脑能够理解一个提供的服务，但是这并不能使得一个服务有价值。实际上，其他的一些形式的架构也依赖于基于标准的接口，并且也没有产生我们所希望的松耦合的服务。在这一点，我们必须去掉我们的开发者的帽子，把我们的架构放上。
在我们最近的ZapFlash确定了一个服务契约有那些东西，我们讨论的事实是一个服务算不上服务，除非它是使用一个元数据编码的契约定义的。这个契约必须包含两个关键元素：规定了服务消费者和提供者两端的功能性和非功能性信息。在这种情况下，至少的 ，一个服务七月必须提供关于服务会做什么的明确的信息。还一句话说，一个服务必须清楚的说出它是意味着什么，并且它说了的意味着什么。用户不应该被留下来抓脑袋想在要求的输入被提供之后将会发生什么。所以，一个关于良定义的服务的更好的争论是一个服务是良定义的应该不只是意味着它只是可以被一个电脑理解的，而是要和服务所承诺提供的要完全的一致。基本地，一个人也可以理解这个服务契约，而不需要咨询额外的资源或信息。
现在，这个关于明确性的需求也逐渐的被松耦合的系统所要求了。通过一些东西，我们称之为架构的可以把这个明确的要求完成并且把服务的内部工作提供出来，或者可能提供具体的如何一个商业过程被组成的细节。尽管如此，为了让松耦合的系统工作， 我们可以知道一些关于服务是如何工作的或者关于组装的过程，从而能够完成任务。即便这样，我们也许会有在与语义紧耦合的协作称之为可操作的松耦合。换一句话来说，我们需要了解服务将会做什么，同时也要知道它将会怎样通讯以使得它是有用的。从而，第一个挑战是构建一个够具体细致的服务契约元数据，但是不要太多的细节。
聚焦复用
我们仍然还没有回答那个问题及如何来决定服务的粒度的水平，尽管最后，我们可以构建良好组织的，良定义的服务和粗糙组织，良定义服务。很重要的是要知道一个特定的服务是否是单独使用的还是多用途的。你可以说最好的服务是最有用的一个，这是事实，恰到要点。毕竟具有怎么多的冗余，良好组织的服务导致了大量的开销和低效率。很明显的具有更小的可用的粗糙组织的服务的集合在很多情况下都是一个更好的选择。尽管如此，很多开发者会把这条准则推向一个极端，并试图构建一个单独的服务，称之为，或者说，"做一些东西"是可以满足每一个单独得需求的。做某些东西将可以具有能够支持一些任意服务功能需求的一个简单接口，并且它将会产生一个相应的服务结果。
这个能做某些事情的服务的问题对于任何曾经试图实现这样的东西的人来说都是很明显的。从本质上来看，它不再是以恶可以使用的服务了，因为我们已经基本上只是把责任推给别人了，而不是让服务自己来决定自己的语义。我们只是把决定推延到更低水平的代码块上去了。本质上，我们只是把SOA看成某种类型的路由协议或者消息系统而不具有任何的固有的功能。这样的服务，明显的不能满足SOA的需求。
