面向模式构建系统架构
关于SOA设计原理系列
这是一系列研究设计更有效的网络服务为目标的论文集的第一步.这第一篇论文是在微软的模式与实践小组的协助下完成的,以后的论文也可能会包含与其他组或个人的协作成果,不仅限于微软内部小组或个人.读者应该记住关于样本代码的警告,这些代码只是为了SOA设计原理系列开发的,它们仅用作举例说明目的.建议读者学习这些样本代码,而不应该试图将这其中的任何代码用于实际的开发环境.如果读者决定将样本代码用到实际开发环境中,微软公司不承担任何可能由此引发的损失.
样本代码的系统配置要求:

Microsoft Window XP(在其他平台上没有试过)

Microsoft .Net Framework 1.1

Microsoft Internet Information Server 6.0

Microsoft SQL Server or Microsoft Access

Microsoft Visual Studio 2003 不是必需的,但它会提供一个更好的全面的过程.
如果发生不支持样本代码的情况,本文的作者期待你的反馈.
注意:SOA不断地迅速发展,在这系列中的论文和样本代码也许会被修正,使其更加成熟.
面向服务的体系结构(SOA)简介
SOA是很难去描述的,因为设计理论无法作为一个实体显示出来.
SOA是一种创建那些从自治服务中构建出的系统的途径,它使得整合变得可预见性而不是在事后进行计划,最终的解决方法很可能就是组合由不同语言开发的各种服务,这些服务以多种安全模式和业务流程运行在不同的平台.这个概念听起来是难以置信的复杂,但它已经不是新的了,一些人也许会认为,SOA是从那些基于已有技术的分布式系统的设计和开发中发展而来,有许多与SOA相关的概念,比如服务,发现以及后来的绑定,也与CORBA和DCOM密切相关.同样地,一些服务设计原理也很大程度上与早期的基于封装,抽象和接口的OOA/OOD技术有共同点.
SOA也提示了一个很明显的问题——严格地来讲,服务是什么 简单来说,一个服务是一段程序,能通过定义完整的信息交换机制来进行互动,服务必须设计得可用而且稳定,当服务配置等为了改变而重新构建时,服务也要随之构建并持续下去.灵活性经常被视为SOA带来的最大的利益之一,举个例子,一个机构的业务流程如果在一个松耦合的底层结构上运行,那么它肯定比那些束缚于潜在的单一的应用软件的机构组织更开放更能适应变化,因为后者需要几周时间去改变以适应最小的变化.松耦合的系统导致了松耦合的业务流程,因为业务流程不再受制于潜在底层结构的限制.服务以及相关的接口必须保持稳定,而且使它们可以被重新设置,整合以满足业务上的不停的变化.服务通过标准的接口和定义明确的消息来维持稳定,换句话说,SOAP和XML schemas用作消息的定义.如果服务被设计成仅仅知道信息如何传递或得到,而且只执行简单的粒度较小的函数,那么它极有可能被一个更大SOA底层结构所重用.正如早前所提到的,回想OO设计原理中的封装和接口设计会有助于我们设计和构建重用的网络服务.通过进一步理解和掌握面向服务的四个原则,我们能将OO原理扩展到世界上所有的网络服务.
原则1:明确清楚的分界线
服务通过在明确定义的分界点上的消息传递而相互作用,跨区域层次的服务可能因为地理位置,信任因素或者其他执行要素而花费很大的代价.一个分界点就是在一个服务的公共接口和它内部的执行之间的边界,一个服务的分界点通过WSDL来发布的,而且也许包含了已有服务的期望声明.跨区域的服务因为下面几点原因而被认为是一项昂贵的任务:
目标服务的物理位置是个不可知因素;
安全以及信任模式一般在跨越每个分界点时会发生变化;
在一个服务的公共和私有部分之间,数据的编组和广播需要对于其他资源的信任,对于服务本身来说,其中的某些资源是外部
不可见的.
当服务配置被构建以适应改变时,服务也被构建以持续下去.这意味着,由于网络的重配置或者迁往其他物理位置时,一个原
本可靠的服务而突然发生改变甚至退化.
用户一般都不知道内部流程实现的保密程度.一个用户只能有限地控制所指定服务的运行.
面向服务集成模式告诉我们,广域服务受限于网络的潜伏因素,网络故障和分布式系统故障,但是一个本地服务不会出现这样的问题.大量的错误检测和改正方案必须写出以处理使用远程对象接口带来的问题.我们假定跨区域是花费很高的,但也必须处理一些本地方法的配置中出现的警告,这些本地方法的作用就是使得跨区域的可能减到最小.一个只有单一本地方法和对象的系统也许会获得更高的性能,但是无法重用已经定义的服务(这种技术可比喻成OOP中的拷贝和粘贴,它在服务的版本上也遇到一样的问题).

下一页