简介：服务基本要素

　　我们通常是按照服务定向的原则、功能以及数据来构建IT远景规划的。我们可以按照国际标准用统一的形式定义这些服务（XML、SOAP、WS-*），或者也可以依据更多传统或者专有媒介来定义服务。

　　许多集成技术，像ESB，可以不计服务的位置、平台或者编程语言而使用服务。按照喜欢的方式组织服务，并通过系统内部和外部的功能和数据支持业务流程。

　　除了SOA的受欢迎程度不断增加以外——我们在行业范围内也开始了有关识别服务的大讨论。什么时候“服务太大”或者“太小”，什么时候“太过具体”，“或者“太过普遍”或者更具体的说“非常合适”？在讨论具体的方法之前，我们需要建立一些基本要素。

　　首先，存在着许多服务普遍的架构原则。在识别服务之前，这些设计原则，起了极为重要的作用。这八条既定原则[REF-1]包括：标准化服务合同、服务松耦合、服务抽取、服务重用性、服务自动化、服务无边界性、服务可发现性、服务可组合性。

　　要想成功识别服务，其中的一条黄金法则就是服务必须遵守这些原则。

　　其次，还有其它许多使用服务分类或者服务模型的打字服务。例如，表示服务、流程服务、业务服务、应用服务和数据服务[REF-2]。当然每一种类型的服务都有其合适的方法。这篇文章中，我们主要关注以业务为中心以及以应用为中心服务的方法。这些服务还可以分为以下子类别（例如，可分为创建、读取、升级、删除、转换、生成、选取、评价、验证以及计算等服务[REF-3]）。

　　最后，以下几个方面决定了一个服务的好坏成败：一个管理员的要求应该和设计师以及试验员的要求不一样。最后，我们是按照服务为机构带来的价值来判断一个服务的好坏。

　　十种识别和定义服务的方法

　　尽管，我们将这些方法逐条列出，在实践中，往往需要这几种方法共同作用，塑造一个独特的方法和方法论。

　　方法1：分解业务流程

　　我们通常是从业务流程开始来识别和获取服务的。业务流程可以下分为几个子流程或者被分解为几个颗粒活动或者任务。最底层的任务是由许多小型、连贯的“任务逻辑单位”组成的，我们通常会利用不同服务所提供的功能构成的。这样就会生成由“需求驱动”的服务。

　　这个方法的一大好处就是可以满足机构的功能需求。这种方法的直觉性也很强，可以供项目小组证明概念，并且实验项目。

　　当然太过关注需求面也产生许多负面问题。如果只是按照业务流程定义规范塑造模型，不考虑实施，业务流程和应用之间就会形成差距。

　　此外，除非在建模过程中考虑到迭代，才能按照业务流程的具体任务、活动量身订做服务(这样生成的服务无法重用)。

　　尽管要从众多流程中获取服务，有些活动要求的功能是相似的。要想避免服务间无意识冗余，需要进行服务间的相互协调工作。这些服务是由不同项目小组分别设计的。

　　方法2：业务功能

　　正如我在上文中所提到的，识别服务的关键是要确保：在一个业务流程中流程和服务之间保持松耦合关系。这和我们通常所提倡的服务应该为业务逻辑和IT设施提供去耦合的方式这一基础概念是相违背的。

　　解决这一问题的有效方案就是从业务功能模型着手。该服务功能模型是从业务流程的实施方式中抽取出来的。这一点和业务流程方法极为相似，进一步完善了服务的使用。在这种情况下，大部分具体的业务功能按照功能被分解，转化成各种各样的服务。

　　如同建立在流程基础之上的方法，基于功能的方法通常是由业务驱动的，并且潜藏着同样的风险。如果从一开始就使用业务功能，可以降低服务的冗余度，同时还可以通过业务功能模型减轻功能叠加。