服务设计原理：服务模式和反模式.doc

　　服务设计原理：服务模式和反模式 　　服务设计系列的法则已经发展到最佳通信实践和取样相关编码的程度。作为一系列相关论文的开始，本文提供了设计和实现网络服务的基本原理，并且对面向服务的体系结构(SOA)的相关概念做了一个简要的回顾，以及有关于几种模式和反模式的详细讨论，当构建网络服务时，开发者可以利用它们。它可应用于能进行网络服务开发和配置的任何编程语言或平台。 关于SOA设计原理系列 这是一系列研究设计更有效的网络服务为目标的论文集的第一步。这第一篇论文是在微软的模式与实践小组的协助下完成的，以后的论文也可能会包含与其他组或个人的协作成果，不仅限于微软内部小组或个人。 　　读者应该记住关于样本代码的警告，这些代码只是为了SOA设计原理系列开发的，它们仅用作举例说明目的。建议读者学习这些样本代码，而不应该试图将这其中的任何代码用于实际的开发环境。如果读者决定将样本代码用到实际开发环境中，微软公司不承担任何可能由此引发的损失。 　　样本代码的系统配置要求： 　　bull; Microsoft icrosoft SQL Server or Microsoft Access bull; Microsoft Visual Studio 2003 不是必需的，但它会提供一个更好的全面的过程。 　　如果发生不支持样本代码的情况，本文的期待你的反馈。 　　注意：SOA不断地迅速发展，在这系列中的论文和样本代码也许会被修正，使其更加成熟。 面向服务的体系结构(SOA)简介 SOA已经变成一个众所周知的缩写词，如果你问其他两人关于SOA的定义，你极有可能会得到两个完全不同，甚至可能相互矛盾的答案。一些人将SOA描述成了一个业务上的IT行业基础或底层结构，其他人则希望SOA能提高IT行业的效率。在许多方面，SOA有点象Godfrey Saxe写的盲人和大象的故事，每个人都各有不同地描述大象，因为他们中的每个人都被他们的个人经历所左右（比如，摸大象鼻子的人相信大象是一条蛇，而摸大象长牙的人则认为大象是一杆矛），Saxe的大象太容易描述了，因为它就是一个存在的实体。然而，SOA是很难去描述的，因为设计理论无法作为一个实体显示出来。 　　SOA是一种创建那些从自治服务中构建出的系统的途径，它使得整合变得可预见性而不是在事后进行计划，最终的解决方法很可能就是组合由不同语言开发的各种服务，这些服务以多种安全模式和业务流程运行在不同的平台。这个概念听起来是难以置信的复杂，但它已经不是新的了，一些人也许会认为，SOA是从那些基于已有技术的分布式系统的设计和开发中发展而来，有许多与SOA相关的概念，比如服务、发现以及后来的绑定，也与CORBA和D密切相关。同样地，一些服务设计原理也很大程度上与早期的基于封装、抽象和接口的OOA/OOD技术有共同点。 　　SOA也提示了一个很明显的问题严格地来讲，服务是什么？简单来说，一个服务是一段程序，能通过定义完整的信息交换机制来进行互动，服务必须设计得可用而且稳定，当服务配置等为了改变而重新构建时，服务也要随之构建并持续下去。灵活性经常被视为SOA带来的最大的利益之一，举个例子，一个机构的业务流程如果在一个松耦合的底层结构上运行，那么它肯定比那些束缚于潜在的单一的应用软件的机构组织更开放更能适应变化，因为后者需要几周时间去改变以适应最小的变化。松耦合的系统导致了松耦合的业务流程，因为业务流程不再受制于潜在底层结构的限制。服务以及相关的接口必须保持稳定，而且使它们可以被重新设置、整合以满足业务上的不停的变化。服务通过标准的接口和定义明确的消息来维持稳定，换句话说，SOAP和XML schemas用作消息的定义。如果服务被设计成仅仅知道信息如何传递或得到，而且只执行简单的粒度较小的函数，那么它极有可能被一个更大SOA底层结构所重用。正如早前所提到的，回想OO设计原理中的封装和接口设计会有助于我们设计和构建重用的网络服务。通过进一步理解和掌握面向服务的四个原则，我们能将OO原理扩展到世界上所有的网络服务。 　　原则1：明确清楚的分界线 　　服务通过在明确定义的分界点上的消息传递而相互作用，跨区域层次的服务可能因为地理位置、信任因素或者其他执行要素而花费很大的代价。一个分界点就是在一个服务的公共接口和它内部的执行之间的边界，一个服务的分界点通过L schema的消息来进行服务通信的方式对于编程语言和平台是不明确的，它只能确保服务边界之间的互动性，Schema定义了消息的结构和内容，服务的协约则定义服务本身的行为模式。 　　总之，一个服务的协约包含了下列元素： 　　bull; XML Schema定义的消息相互交换格式 bull; L Schema（xsd : any）的扩展性质和SOAP过程模型（可选择报头），应该尽可能清楚地设计出