文档介绍：下载
第 1 章理解分布式应用开发
D C O M、Java RMI及C O R B A等分布式应用技术已在多年的发展中一直与日益增长的企业需
求同步前进。在当今的环境中,分布式应用技术应当具有高效的、可扩展的、能够支持事务、
可与其他不同技术协同工作、可高度配置、在 I n t e r n e t上运行等特点。但是,并不是所有的应用
程序在规模上都大到需要所有这些支持。在支持较小的系统时,分布式应用技术往往提供常见
的默认行为,还要易于配置,这样才能让这些系统的分布尽可能的容易。单个远程技术看上去
似乎不可能满足这些所有的需求。事实上,当今大多数分布式应用技术都是从较为适中的一类
需求开始的,然后,经过多年发展取得了对其他需求的支持。
洗心革面常常是个好方法, Remoting的设计所采取的方法。.NET Remoting提
供了具有可扩展性钩子的连贯对象模型以支持迄今为止开发人员使用 D C O M建立的各种系
统。.NET Remoting的设计者采用了那些最初不为 D C O M设计者所知的最新技术。
尽管本章的意图并不在于帮助你决定使用哪种分布式应用技术,但是,如果你正在使用
. N E T进行所有的新开发, Framework实现客户端和服务器, Remoting
可能是最佳选择。另一方面, Remoting技术实现的, . N E T
F r a m e w o r k则提供了与传统技术之间空前的互操作性:
•如果现有系统是C O M / D C O M,.NET Framework的“. N E T- t o - C O M”互操作层功能完备且
易于使用。 Remoting进行增量移植。
•如果现有系统是基于诸如 J a v a远程方法调用( R M I)或公用对象请求代理体系结构
(C O R B A)的非M i c r o s o f t分布式技术,这里仍有好方法。因为其他商家都采用了诸如 X M L
和简单对象访问协议( S O A P)这样的开放标准, Remoting对这些开放标准的
支持可以提供跨商家、跨平台环境的通信。目前,基于 J a v a的S O A P工具比比皆是。尽管
C O R B A的S O A P支持有些滞后,但是对象管理组织( O M G)目前正致力于形成官方
C O R B A / S O A P标准。
简短历史
从最广泛意义上来讲,分布式应用程序是一种将应用程序的处理分成几部分、联合两台或
更多机器执行的程序。处理的划分意味着涉及到的数据也是分布式的。
分布式体系结构
.NET Remoting之前出现了大量的分布式应用解决方案。从这些早期系统技术中, . N E T
R e m o t i n g获得了许多有关分布式计算的经验,并形成了最新形式。
2部分第1章
下载
1. 模块化编程
除了最不重要的软件程序之外,适当地管理复杂度是所有开发的重要一步。对复杂度进行
管理的最基本技术之一就是把代码按功能组织成相关单元。可以在多种级别上应用这种技术:
把代码组织成过程、把过程组成类、类组成组件以及组件组成更大的相关子系统。分布式应用
程序从这个概念中获益匪浅,而且在很多情况下都有助于实施这个概念,因为需要模块化将代
码分布到各台机器。实际上,各种分布式体系结构的主要区别在于:赋予不同模块的职责以及
提供模块间的不同交互。
2. 客户端/服务器
客户端/服务器是最早也是最基础的分布式体系结构。广义上来说,客户端/服务器只是向服
务器进程请求服务的客户端进程。一般客户端进程负责表示层(或用户接口),该层包括验证用
户输入、向服务器发送调用,还有可能执行一些业务规则。然后服务器担当起引擎—通过执
行业务逻辑并与数据库和文件系统这样的资源协同合作完成客户端请求。通常有许多客户与一
个服务器进行通信。尽管本书是关于分布式应用程序开发的书籍,但我们也应当指出,客户端
和服务器的职责一般不必划分到多台机器。应用程序的功能划分对运行在单一机器上的多进程
来说是个好的设计方式。
3. N层(N - Ti e r)
客户端/服务器应用程序也称为两层应用程序,因为客户端直接与服务器对话。两层结构通
常实现起来相当容易,但只拥有有限的可扩展性。过去,开发者经常是由于如下原因发现需要 n
层设计的:一个应用程序运行在单个机器上。由于某些原因有人决定需要分布应用程序,这些
理由可能包括想要向多个客户提供服务、开启资源访问或者利用一