最近评论
正在载入评论列表...
构建分布式应用程序
创建能与其他软件进行通讯的软件是现代应用程序开发的一个标准组成部分。然而不同的应用程序拥有不同的通讯需求。为了适应这些各异的需求，.NET框架类库包含三种截然不同的分布式应用创建技术。图1-7描绘了这三种选择。
|
ASP.NET Web Services允许经由SOAP的通讯 |
ASP.NET Web Services主要定义在System.Web.Services内，允许应用程序利用Web services进行通讯。由于是ASP.NET的组成部分，因此这项
图1-7 分布式应用程序可以使用ASP.NET Web Services、.NET远程系统（Remoting）或企业服务（Enterprise Services）
技术允许开发人员使用类似的模型来创建分布式软件。正如图1-7所示，“将方法开放为Web services”的应用程序可根据扩展名为.asmx的文件进行开发，每个文件仅含有代码。客户端使用标准Web services协议SOAP产生请求，尔后适当的网页被装载并执行。因为这项技术是ASP.NET的组成部分，所以请求和响应同样经由IIS（Internet Information Services，Windows上的标准Web服务器）进行处理。
|
.NET远程系统专注于基于 .NET框架的应用程序之间的通讯 |
经由Web services的通讯特别适用于和构建在非.NET框架的平台（例如Java环境）上的软件进行互操作，但它并非总是合适的解决方案。在
观点：非Windows系统上的.NET框架
_______________________________________________________________
使用.NET框架编写的应用程序，会被编译为与处理器无关的MSIL形式，并藉由.NET框架类库与变化多端的特定操作系统隔离开来。这很像Java的世界：Java应用程序被编译为字节码（bytecode），并依赖Java标准库而不直接调用特定操作系统。Java被清楚而明白地设计为可在多种处理器和操作系统上工作，.NET也是这样吗？
从某个程度上说，答案是yes。微软自个儿已经提供了一个针对UNIX FreeBSD的框架基础移植版本，即所谓的共享源码CLI（Shared Source CLI）。理论上 .NET框架的确可以成为广泛系统之间的跨平台解决方案。
然而仍然存在一些技术方面的原因。尽管MSIL是平台中立，但 .NET框架类库的某些部分并非平台中立。例如企业服务（Enterprise Services）支持可伸缩、面向事务（transaction- oriented）的应用程序，而它乃是根植于名为COM+ 的早先的Windows技术。因此这一部分只能运行于COM+ 存在的地方。另外一部分类库也明显或多或少地泄漏了它的Windows血统。
同样重要的是，微软必须努力让客户严肃地相信，微软将在非Windows系统上长期支持 .NET框架。这个公司向来把所有焦点放在它自己的操作系统上，这已经成为其商业特点，同时也是它成功的首要因素。假如微软想让 .NET框架真正成为Java的一个多平台竞争对手，技术上的潜力正源于此。但至少到今天为止，.NET从根本上说还是一项Windows技术。
事实上，作为现今最显著的 .NET平台之非Windows实现，Mono项目，亦尚未博得更多的商业注意力。有些打算构建 .NET应用程序的企业，曾寄希望于Mono提供所需的安全的非微软替代方案。然而在实践中，这个选项对于许多企业组织来说并不具备吸引力。不论你喜欢与否，在构建基于.NET框架的软件的人员中，绝大多数期望将其代码运行于某个版本的Windows之上。
某些情形下，所谓的 .NET远程系统（Remoting）是更佳的选择，它被定义在System.Runtime.Remoting命名空间内。和ASP.NET Web Services不同，.NET远程系统专注于构建在.NET框架之上的应用程序间的直接通讯。在支持SOAP的一个实现的同时，它还提供了一个二进制协议，连同使用任何其他协议进行扩展的能力。.NET远程系统并不是最常用的通讯选择，但对某些种类的应用程序而言它可以发挥重要的作用。
|
企业服务提供了分布式事务以及其他服务 |
利用.NET框架创建分布式应用程序的第三个选择是企业服务（Enterprise Services）。它被定义在System.EnterpriseServices命名空间内，为应用程序提供诸如分布式事务等服务。图1-7阐明了这点，它展示了一个服务器应用程序（server application）访问两个数据库的情形。倘若一个事务包括对这两个数据库的更新，企业服务可能是使用该事务的应用程序的恰当的选择。远程客户端（Remote clients）可以利用DCOM直接与企业服务应用程序通讯，ASP.NET应用程序也可以视需要使用企业服务。
这三种选项在不同的场合下发挥自己的才能，对它们均有个基本的了解是件好事。要想了解各自的详情，请阅读第7章。
图书导读
