面向服务及其在互联系统策略中的角色

　　并不是所有的Web服务都是平等创建的。一个鸡蛋可能变成美味可口的蛋奶酥;但是如果将它放在荷兰辣酱油上，就将变成一次让人反胃的品尝;或者，如果掉在了地上，它就会变成一团粘糊糊的东西。每个人都可以通过服务构建任何事物：好的，坏的，或丑陋的。

　　在策划企业服务组合时，需要面对三个基本的挑战：

　　•面向服务的分析—为了支持组织的业务优先级，应该创建哪些服务?

　　•服务设计—应该怎样创建每项服务?

　　•服务管理—为了支持业务服务，应该部署哪些基础结构服务?了解和处理异常需要哪些支持?

　　本章节将探讨所有这些挑战，并进行总体的指导，告诉你现在应该怎样做才能获得面向服务带来的直接收益;同时，它还为你提供了一些提示，这样你就可以预测完成互联系统策略所需的未来投资。

　　面向服务的分析

　　面向服务的体系结构是组织机构业务流程的建模艺术，同时它也是网络可寻址的业务组件的结构完善的组合。

　　真正的挑战来自于那个看似平常的修饰语：结构完善的。在确定对组织功能的建模起关键作用的信息集(请将它作为“结构化业务文档”的一个令人讨厌的同义词来阅读)和行为时，总有一种“翻江倒海”的诱惑——设法为组织的所有行为创建一个完整的自上而下的视图，并在一个一致的企业体系结构中对其进行建模。同时，那些需要解决方案的业务单位目前正通过技术和业务流程重组投资而迅速发展。

　　“权宜之计”是一个强大的动力。利用它，但是也要对它进行适度的控制。在不断的尝试中学会爬;在不断的交流中学会走;在不断的协作中学会跑。

　　应该怎样权宜性地定义一个服务组合呢?这里有几个原则。

　　设计长期稳定的服务，设计灵活应变的系统

　　在一个企业服务体系结构中，功能服务是构成业务流程和业务系统的组件。对服务接口进行建模，从而紧密地结合业务功能模型，这是一个重要的最佳实践方法。例如，大多数制造商都有接收订购请求的业务需求;定义一个描述订购请求的信息集和一个接收此信息集实例的终点，即可构成一个井然有序的服务范例。

　　业务流程远比它们处理的信息不稳定。在流程中，操作者(人)的判断甚至是一时冲动都会对处理操作造成很大的影响，同时各种服务异常情况也会对业务实例造成干扰。每个业务流程实例都可以构成一条穿过你的服务组合的唯一路线。

　　因此，系统必须具有灵活性。流程的编制应该易于修改，甚至是完全动态的。对于成功的业务系统而言，将硬编码的业务流程排入已编译的可执行文件是一种反模式。

　　事件驱动的体系结构的概念对于有效的流程设计具有指导意义。流程应该能够洞察推动其发展或使其脱离正常路线的业务事件。当异常事件使某个流程脱离正常的轨道时，应该努力使流程恢复正常，并使其返回主要的轨道;如果对整个流程进行人工监控，将导致流程成本的激增，甚至远远超过流程本身带给组织的价值。

　　从全局着眼，从局部着手

　　大多数组织都拥有几个(也许多达10个)关键实体，这些实体在它们的核心业务流程里运行。一般的例子包括Customer(客户)、Employee(员工)和BusinessTransaction(业务交易，或通称为PurchaseOrder(采购订单))。应努力对这几个关键实体进行定义，以创建实体类型的组织模式，并开发实体建模的专业知识。同时，还应参阅关于指导和重复使用的正式标准和实际标准(如果你所在的垂直行业中存在着任何满足要求的标准，那么就可以使用此标准)。

　　我们已经建立了专业知识和一组观点，下面我们要更加深入地探讨如何应对业务机会和难题：

　　•确定进行改进的关键机会。

　　•对目前的业务方案进行建模，并适当参考现有的标准。

　　•与三到四个相关业务科目的专家一起检查此模型。

　　•根据他们的反馈扩展和修改此模型。

　　•开发业务服务。

　　•重复以上步骤。

　　结果将不会很完美。稍后就会发现某些业务案例需要附加的信息。必须向业务流程模型中添加步骤。不过，有了下一条原则，你就可以对变化做好充分的准备。