并不是所有的Web服务都是平等创建的。一个鸡蛋可能变成美味可口的蛋奶酥;但是如果将它放在荷兰辣酱油上，就将变成一次让人反胃的品尝;或者，如果掉在了地上，它就会变成一团粘糊糊的东西。每个人都可以通过服务构建任何事物：好的，坏的，或丑陋的。
在策划企业服务组合时，需要面对三个基本的挑战：
•面向服务的分析—为了支持组织的业务优先级，应该创建哪些服务?
•服务设计—应该怎样创建每项服务?
•服务管理—为了支持业务服务，应该部署哪些基础结构服务?了解和处理异常需要哪些支持?
本章节将探讨所有这些挑战，并进行总体的指导，告诉你现在应该怎样做才能获得面向服务带来的直接收益;同时，它还为你提供了一些提示，这样你就可以预测完成互联系统策略所需的未来投资。
面向服务的分析
面向服务的体系结构是组织机构业务流程的建模艺术，同时它也是网络可寻址的业务组件的结构完善的组合。
真正的挑战来自于那个看似平常的修饰语：结构完善的。在确定对组织功能的建模起关键作用的信息集(请将它作为“结构化业务文档”的一个令人讨厌的同义词来阅读)和行为时，总有一种“翻江倒海”的诱惑——设法为组织的所有行为创建一个完整的自上而下的视图，并在一个一致的企业体系结构中对其进行建模。同时，那些需要解决方案的业务单位目前正通过技术和业务流程重组投资而迅速发展。
“权宜之计”是一个强大的动力。利用它，但是也要对它进行适度的控制。在不断的尝试中学会爬;在不断的交流中学会走;在不断的协作中学会跑。
应该怎样权宜性地定义一个服务组合呢?这里有几个原则。
设计长期稳定的服务，设计灵活应变的系统
在一个企业服务体系结构中，功能服务是构成业务流程和业务系统的组件。对服务接口进行建模，从而紧密地结合业务功能模型，这是一个重要的最佳实践方法。例如，大多数制造商都有接收订购请求的业务需求;定义一个描述订购请求的信息集和一个接收此信息集实例的终点，即可构成一个井然有序的服务范例。
业务流程远比它们处理的信息不稳定。在流程中，操作者(人)的判断甚至是一时冲动都会对处理操作造成很大的影响，同时各种服务异常情况也会对业务实例造成干扰。每个业务流程实例都可以构成一条穿过你的服务组合的唯一路线。
因此，系统必须具有灵活性。流程的编制应该易于修改，甚至是完全动态的。对于成功的业务系统而言，将硬编码的业务流程排入已编译的可执行文件是一种反模式。
事件驱动的体系结构的概念对于有效的流程设计具有指导意义。流程应该能够洞察推动其发展或使其脱离正常路线的业务事件。当异常事件使某个流程脱离正常的轨道时，应该努力使流程恢复正常，并使其返回主要的轨道;如果对整个流程进行人工监控，将导致流程成本的激增，甚至远远超过流程本身带给组织的价值。
从全局着眼，从局部着手
大多数组织都拥有几个(也许多达10个)关键实体，这些实体在它们的核心业务流程里运行。一般的例子包括Customer(客户)、Employee(员工)和BusinessTransaction(业务交易，或通称为PurchaseOrder(采购订单))。应努力对这几个关键实体进行定义，以创建实体类型的组织模式，并开发实体建模的专业知识。同时，还应参阅关于指导和重复使用的正式标准和实际标准(如果你所在的垂直行业中存在着任何满足要求的标准，那么就可以使用此标准)。
我们已经建立了专业知识和一组观点，下面我们要更加深入地探讨如何应对业务机会和难题：
•确定进行改进的关键机会。
•对目前的业务方案进行建模，并适当参考现有的标准。
•与三到四个相关业务科目的专家一起检查此模型。
•根据他们的反馈扩展和修改此模型。
•开发业务服务。
•重复以上步骤。
结果将不会很完美。稍后就会发现某些业务案例需要附加的信息。必须向业务流程模型中添加步骤。不过，有了下一条原则，你就可以对变化做好充分的准备。
对于可扩展性的设计
在时间的考验下，任何对于要求的理解都是不充分的。为了进一步证明你的服务和解决方案，你必须将可扩展性设计进来。可扩展性有两个关键领域：实体可扩展性和行为可扩展性。
在实体中扩展模式化信息的主要原则是容纳一系列可能包含任何内容的Extension(扩展名)元素。这些元素通常都会使用一个名称来鉴别自己，并引用它们自己的架构。通过在实体定义中包含这种支持功能，你就可以创建多态实体。一个已扩展的Employee实体仍然可以由任何了解基础实体的服务进行操作，不过它也可以支持那些了解实体的服务(也就是称为TravelProfile(旅游资料)的扩展名)进行扩展处理。
不同的地区需要不同的信息。例如，一个税号在不同的国家可能会有不同的构成方式。请勿将社会保险号作为你的Employee实体中的顶级元素;正确的做法是，包含一个可能将其子类型标记为“US-SSN”的TaxID(税号)元素。
与面向对象不同，面向服务对行为进行了延迟的绑定——只有在实体被传送到一个知道如何处理其内部包含的信息的服务时，实体的“行为”才会得到绑定。
因此，可通过操作实体增加价值的公开服务基本上实现了行为可扩展性。如果要将新的行为绑定到实体上，可以使用很多有效的模式，但是本文不会介绍这些模式，因为它们超出了本文讨论的范围。不过，一个具有指导意义的实例是，一个服务充当了另一个服务(该服务能够操作较大实体的元素)的门面。VerifyEmployeeAddress(验证员工地址)也许可以接收Employee实体，并提取它的Address(地址)元素，然后将它传送到更通用的VerifyAddress(验证地址)服务中，VerifyAddress服务是由合适的国家邮政服务提供的。
另外，一个关键的指导原则是从标准化的元素组成实体，从而最大限度地提高实用服务的可重用性和通用信息元素处理的一致性。
