一旦选定了候选服务并在(分类)服务组合中进行了记录,则需要确定哪些应显现为服务。
虽然从理论上而言,可以通过将候选服务的接口导出为服务描述来显现任何候选服务,但并非每个候选服务都应当如此。这样做在经济上和实践中(可能危及非功能需求)可能都不是可行的。
尤其是显现“所有类的所有方法”的天真决定将使得服务的数量达到无法承受并且通常无法管理的程度,从而导致“服务增长综合症”。 这将产生巨大的性能和服务管理问题,更不要提可能浪费公司的知识资本。
而且,必须牢记我们选择显现的每个服务都与成本关联:服务的资金、管理和底层基础结构(其安全性、性能和管理)以及将实施它们的组件都必须纳入考虑范围中。
因此,需要一些标准来帮助决定是否显现某项服务,而最重要的是决定是否要资助创建提供服务功能的服务组件,以及该服务的维护、监视、安全性、性能和其他服务级别协议。
服务石蕊测试
项目经验表明服务石蕊测试形式的一组标准可以且应该用于过滤候选服务的集合。 此隐喻用于表示一组测试,如果应用,将决定给定的服务是否符合使用服务描述进行显现的条件。
这些测试将同时使用,有助于回答诸如“在候选服务列表中,应显现哪些服务” 以及“因此我们应资助哪些服务?”、 “哪些服务具有业务价值?”之类的问题。
在极端情况下,每个业务用例都可以被视为候选服务。而另一极端情况下,则将只选择显现少数服务。 应用石蕊测试通常会在两者之间折衷:选择业务希望显现且稍后可用在组合中的一组可管理服务。
通过所有服务石蕊测试的候选服务随后应显现为 SOA 中的服务。可能会有一些候选服务并未通过服务石蕊测试,但仍实施为服务。 服务石蕊测试是确定显现哪些服务的辅助方法;如果业务选择显现未通过服务石蕊测试的候选服务,则意味着与 SOA
关联的利益将不会实现。
不满足服务石蕊测试的候选服务必须以某种方式实施,因为它们是满足业务需求所必需的。 它们可以在服务组件上作为方法来实施,且无需生成 WSDL 或其他形式的服务定义;或者可以用作不可显现的实体。
考虑事项
服务石蕊测试的应用是一个迭代过程。对于精化的第一阶段,必须根据当前了解作出决策。 随着设计过程中获得的信息增加,应重访服务石蕊测试。
每个候选服务的服务石蕊测试应该由相应的主题事件专家或项目干系人应用和复审。
服务石蕊测试的复审结果是跟踪标准和服务详细程度是否合适的有效方法。 例如,如果通过特定测试的候选服务过多,则此测试的定义可能过宽,或者服务级别详细程度可能不适当。
某个服务可能未通过一个或多个服务石蕊测试,但由于某些特定于项目的决策(业务或 IT),该服务仍可显现。 这是正常的。可能会制定一些不理会服务石蕊测试而显现服务的体系结构决策或业务决策。
|