2024年1月9日发(作者：)
.NET开发思想(1)－争辩
自从J2EE推向市场以来，以其安全性、稳定性和扩展性得到了开发者的青睐，迅速成为了大型Web应用的首选标准。为推广J2EE编程思想和编程技术，Sun在其Java官方站点上提供了一个Demo应用，即Petshop。
微软不甘在大型Web应用开发上的落后，在2000年推出了.NET技术，并展开了猛烈的市场攻势。J2EE是.NET的主要对手，也是其攻击的主要目标。于是微软在去年下半年推出了.NET版的Petshop，宣称其在代码量、性能、价格、易用性和拥有/开发/维护成本上与J2EE相比有不可比拟的优势，且完全基于Web Services技术。
在微软强大的市场攻势的影响下，各大主流IT媒体上，众多有关J2EE与.NET优劣比较的文章层出不穷。
事实上，J2EE不是一种产品，而是一种标准，Java官方站点上的Petshop只是一个展示J2EE基础结构和开放性的Demo，并没有进行性能上的优化（因不同的产品有不同的性能优化的方式）。而.NET不是一种标准，是一种产品。.NET的Petshop程序是基于.NET产品而进行了优化，如其对数据库的访问代码就是写在SQL Server的存储过程中。因此，对其比较是没有参照价值的。
对此，BEA和Sun不予置评。而IBM和Oracle则沉不住气，特别是在微软的Petshop文档中，比较的J2EE应用服务器采用的就是IBM的WebSphere 4.0。IBM和Oracle分别利用自己的产品（WebSphere
4.0和Oracle 9i iAS）实现J2EE方式的Petshop，给出了新的性能数据和比较说明。IBM还指出微软的一个错误：对Petshop实现的比较并不是开发Web Services的性能的比较。
微软立即进行了反击，并给出了新的说明，并针对IBM给出了.NET与WebSphere在实现Web
Services上的比较。IBM也有所反应。双方的争辩至今没有停息。
在去年12月的Web Services杂志上，Robert McGarvey写了一篇文章：Street Fighting Comes
to Web Services，分析了当前关于J2EE和.NET的争辩，提出了许多有价值的见解。他的文章出来以后，微软立即写了一篇文章对其中的若干点进行了澄清。而针对这两篇文章，又展开了一场白热化的争辩。
我们的观点是微软的.NET技术和产品确有其独到之处，但绝对不是和J2EE“有我没你”。今后的两年内将会是两者的并存，并相互促进和发展的一个状态。我们推出《.NET开发思想》系列，就是希望能将我们对.NET开发思想的理解与大家共享，在批判和碰撞中不断共同提高。
附加文献：
1、.NET Pet Store的最新版
.NET开发思想(2)－.NET的组成
.NET是什么？这是一个很有趣的问题，但没有一个简单而清楚的定义。这就象OO（面向对象），虽然我们很难下一个清晰的定义，但这并不影响我们对它的理解。就我的认识，.NET是微软的分布式运算技术的软件战略，目标是"Anytime, Anywhere, Anyone, Anydevice"(微软原语)。
既然.NET是微软押宝的一个软件战略，.NET由哪几部分组成呢？自.NET在2000年下半年推出以来，微软公司内部的策略专家们对此热烈的讨论就并未停止过，并给出了不同的划分方法。其中最为经典的，当数微软的平台策略VP－Sanjay Parthasarathy在.NET推出之初写的一篇文章－The
Simplest Way to Define .NET中给出的划分。我这里给出的划分主要便是基于他的这篇文章。
在下面的介绍中，大家可以发现其实.NET和J2EE其实包含的范围很不同，真正意义上的J2EE
只对应.NET中的其中一部分。
.NET包括平台和知识两部分。
.NET平台包括开发工具、服务器、.NET积木块服务（BBSs）和设备软件。其中，
开发工具包括.NET Framework和Visual Studio .NET。.NET Framework和J2EE相对应，包括.NET
CLR（公共语言运行环境，类似于Java虚拟机）和公共类库。Visual Studio .NET是Visual Studio开发工具的.NET版本，包括VB、VC、VBScript、JScript等的新版本，以及一门新的语言C#（完全面向对象，与Java对应），并基于.NET Framework开发。《.NET开发思想》系列后续的专题将围绕.NET
Framework和VS .NET展开。
服务器包括.NET Enterprise Servers和.NET Server。其中.NET Enterprise Servers包括SQL
Server、ISA Server、Biztalk Server等系统服务平台，与J2EE体系中的数据库服务器、目录服务器、工作流服务器、应用服务器等系统服务平台相对应。.NET Server是Windows的.NET版本。这两部分不在本系列的讨论范围内。技术研究处今年将推出.NET平台技术推广系列，将围绕这两部分展开。
.NET积木块服务（.NET Building Block Services）是指基于.NET技术构建的基于XML的基础性的Web服务，如文件存储、用户性能管理、日历管理等。这些基础性的Web服务将极大地扩展.NET服务的功能性。本系列也将探讨Web Services的基本知识。
设备软件是指应用在Smart Devices上的软件，使这些设备可以象PC一样享受.NET的强大功能。
.NET知识包括.NET开发思想、开发方法和用户开发经验，主要体现在MSDN中。
虽然.NET已推出一年多了，但以上这些内容现在并未完全正式推出。按微软的.NET愿景规划，将按.NET Enterprise Servers、.NET Framework、Visual Studio .NET、Window .NET和.NET积木块服务的顺序依次推出。
从下一个专题开始，我们将开始探讨.NET的基础技术－Web Services。
.NET开发思想(3)－Web services(1)：概述
Web services似乎在一夜之间就成了一个很热的名词。各大IT产商，IBM、Microsoft、BEA、Sun、HP、Oracle等都不断宣称自己的“Web services策略”，并推出“Web services-based”的产品。
但是Web services究竟指的是什么呢？几乎每个公司和团体都有自己的定义。W3C（制订HTML、XML等标准的行业标准组织）在2002年1月成立了Web Services Architecture工作组（WSA-WG），定义Web services的公共基础架构，我订阅了其的Maillist。在2月15日的时候，某公司的一位同志提出Web services的定义是什么的问题，立即引发了一场旷日持久的大辩论。数十位不同公司的专家据理力争，“殊死搏斗”（一位专家用"Desperate"来形容这场大辩论）。到今天（3月7日）为止，我的邮箱中关于这场辩论的邮件已近200封（个人认为，这些邮件是锻炼英语辩论能力的绝妙教材，:-）。
我们印象中Web services是在2000年底由IBM和Microsoft共同提出的，伴随着这个概念的，是XML，还有SOAP、WSDL、UDDI等名词。其实，早在1998年，Sun的CEO Scott McNealy和Oracle的CEO
Larry Ellison就提出了使用Web上的services替代应用的愿景（但他们并没有立即强力推行这一概念）。另一点需要说明的是，WSA-WG的Chairman不是IBM的，也不是Microsoft的，而是Sun的Christopher Ferris。
2001年11月的Web Services Journal上有一篇文章Web Services Fundamentals: From Whence
it Came，谈到我们不要从纯技术的角度谈论Web services，而要看促使Web services产生的业务问题。那促使Web services产生的业务问题究竟是什么呢？
众所周知，Web和Internet技术的出现，促进了企业业务模式的变革。从B2C到B2B，直到E2E（Enterprise to Enterprise），关键在于实现流程集成（BPI）和应用集成（EAI）。
先看EAI。我们知道，要实现EAI，最理想的解决方法是标准化一个企业中的体系结构和框架，但这往往不现实—因为不可避免需要采用不同公司的软件包。因此，需要有这样一个机制，使得内部和外部的系统可以用一种松散耦合的模式集成。个人认为，采用Adapter的方式（这是目前众多EAI产品所采用的方式）并不是真正的解决之道：因为应用的框架不断在演变。解决方法应是：将接口和实现相分离，公共的接口不变，实现变了以后，只要维护接口和实现之间的映射即可。
而BPI的真正实现，需要实现无缝的工作流，能无缝地调用各种不同应用的公共资源。而要实现无缝地调用这些资源，不仅要有统一的资源描述方式，还需要有公共的登记机制，以进行有效的发布、查询和管理－这样才能真正实现BPI。
Web services的出现，正是为了解决这些问题。我们可以将Web services想象为附加在现有应用或资源上的一个“包装”，通过这个包装，可以将应用或别的资源封装为一个服务。而Web services能确保这个服务有与技术无关的、通用的接口描述，并有统一的方式进行登记，便于访问和使用。
这里要注意的是，Web services的根本目的就是“与技术无关”。所以所谓.NET和J2EE谁更适合实现Web services的辩论是毫无意义的，因为Web services只是包裹在.NET、J2EE或其它不同技术编写的应用上的一个“一致的”包装，目的就是为了“屏蔽”后台所采用的技术。
其实，在Web services之前已有很多不同技术领域的efforts以“实现与技术无关的统一的接口描述”为目标，如CORBA、EDI等。但Web和XML技术的出现才真正带来了这一愿景实现的技术基础，于是有了由联合国贸易促进组织和OASIS共同发起的ebXML提案。可以说ebXML是一个相当不错的标准，但其和CORBA一样，没有得到各IT产商的全面支持，特别是Microsoft。而Web services的迅速“窜红”，则与各主要IT供应商的支持有极大的关系。当然，各IT产商对Web services的“支持”各有其力度和目的，Gartner的一篇分析报告Web Services: Evaluating the Major Vendors'
Strategies对Microsoft、HP、Sun、IBM、Oracle等五家IT产商的Web services策略，大家有兴趣的话可以看一看。
这里还要提一句，Web services虽然目标是“与技术无关”，但我们现在通常提的Web services是基于XML和XML相关技术，如SOAP、UDDI、WSDL等构建的，可以称之为XML Web services。本技术系列探讨的，正是XML Web services。
下一个专题，我们将讨论XML Web services的主要组成部分。
.NET开发思想(4)－Web services(2)：组成
XML Web services的目标是使用通用的Internet标准，如XML和HTTP，实现对服务的实现逻辑和使用逻辑的高度的抽象和分离。要达到这一目标，需要有一致的数据模型、通用的通讯模式，并要求实现松散耦合。此外，基础架构需包括以下机制：发现机制、服务描述机制和信报格式，以实现这些目标。
这样描述似乎抽象了一点。我们还是通过一个Metaphor来说明Web services的基本结构。
我们可以将Web services想象为一个电话系统。我们都知道，广义上的电话系统包括三个方面：电话网、逻辑上的电话系统和基于电话系统进行的一些业务。网络通讯协议（HTTP等）相当于电话网，业务流程协议（ebXML等）相当于基于电话系统进行的一些业务，而Web services则对应于逻辑上的电话系统。我们下面谈的电话系统，指的是狭义上的电话系统，即逻辑上的电话系统。
我们知道，电话系统首先要有语法规则，即用数字表达电话号码。而XML及其系列标准则是Web
services的语法规则。
然后，电话号码要通过交换机进行转接，再通过电话网进行通信。因此在Web services中也需要有将抽象的XML消息与网络通讯协议进行绑定，以便于XML消息传递的机制。由Microsoft提出的SOAP是这一领域事实的行业标准。目前W3C正在进行XMLP协议的开发工作，将取代SOAP的作用。
电话系统的目的是为了让别人能通过电话方便地找到自己，因此黄页是必不可少的。而黄页的基本组成要素是联系条目，一条联系条目包括电话号码、对应的单位、该单位的简单介绍、该单位提供的业务、这些业务的一些技术描述等，以便访问者能迅速找到符合自己的业务需求、并满足技术兼容性的某些单位的某些业务服务。这一联系条目就相当于是业务服务描述。Web services中也有相应的服务描述的协议，目前由（由Microsoft、IBM和Arriba组成）提出的WSDL是事实上的行业标准。另，Web services中与黄页对应的是目录和发现机制，UDDI是这一领域事实上的行业标准。
基于上面的比喻，我们可以知道，核心的XML Web services至少需要有语法规则、消息传递、服务描述、目录和发现机制等四个方面的协议和标准。从上面的介绍中也可以看到，Microsoft和IBM是推动XML Web services的主力军。然而，要得到业界的全面接受，特别是Sun、Oracle、HP等其它IT产商的支持，仅此是不够的。因此，Microsoft和IBM在2001年向W3C提出了Web services的标准提案。目前W3C对Web services的标准化工作正在紧锣密鼓地进行着。
由于XML Web services中涉及的SOAP、WSDL、UDDI等协议均尚未成为真正的国际或行业标准，因此建议大家暂不用对其进行深入的剖析，只需要知道其的作用即可。如果需要进行深入了解的话，电话系统的比喻应也能给您一些帮助。
下一专题，我们将介绍.NET Framework。
.NET开发思想(5)－.NET Framework(1)：CLR
.NET Framework是.NET应用开发的基础平台。其由两个主要组件组成：公共语言运行时（CLR）和.NET Framework类库。个人认为，还有第三个组件：公共语言规格——保障各类不同的编程语言能很好地运行在CLR上并充分利用公共类库。
CLR是一个软件引擎，即加载和执行应用程序，类似于Java虚拟机（JVM）的作用。
与传统的Windows应用程序引擎相比，CLR提供了许多新的特性。而要充分理解这些新的特性，我们可以从对应用程序执行的一些需求入手，看看CLR是如何满足这些需求的。
首先是希望应用程序的代码的执行受到控制，这样可以更方便地提高应用程序的执行效率，也提高了安全性，避免应用程序执行非受控操作。.NET中有一个概念：部件（Assembly），一个.NET应用程序是通过部件的形式进行发布的。部件内的代码是MSIL（微软中间语言）代码，而在CLR将应用程序加载后才将MSIL代码翻译为适合本机的机器代码。由于有对从MSIL代码到本机代码翻译的控制，使得CLR可以管理应用程序的执行并防止各类问题的发生，这也就有了术语已管理代码（Managed Code）。这里要注意的是，、C#等纯面向对象语言生成的都是已管理代码，而VC生成的则可能是未管理代码。
其次是希望应用程序能方便地安装、升级，在同一主机上可以方便地运行应用程序的不同版本。部件中除了MSIL代码之外，还有两个部分，就是元数据（Metadata）和清单（Manifest）。其中元数据描述MSIL代码正确执行所需的各种相关数据类型，而清单则列出了部件中所有的文件和软件组件，并指出CLR在哪里可以找到具有应用程序运行所需的组件的其它部件。有了这两部分之后，部件就可以实现“自描述”，并彻底解决了所谓的“DLL Hell”，使得在将应用程序XCOPY至其它主机后能直接运行。
另一个重要的需求是希望应用程序的编辑延迟至真正需要执行其的时候，避免编译那些不常用的代码。CLR提供了JIT（Just-in-Time）编译功能，实现代码的及时编译。当然，这样可能会在某主机初次运行应用程序时有额外的开销，但及时编译从总体上提高了应用程序执行的效率，并充分利用了机器的性能。
希望减少因编程错误带来的Bug和安全漏洞的数量。CLR通过监控代码以确保其不会有最常见的编程错误，例如试图使用一个整数作为函数指针，或者时载入数据时覆盖代码（由于缓存溢出）。这样也可以使恶意代码的运行更为困难。
提供应用程序执行所需的底层操作管理。CLR中有Garbage Collecter、Security Engine、Debug
Engine、Exception Manager和Thread Support等功能组件，分别提供应用程序执行所需的垃圾清理、安全控制、调试控制、例外管理和线程支持等功能。
在满足以上需求的基础上，CLR还肩负着一项重要的职责：在已管理代码和未管理代码间起中介作用。为此，CLR提供了COM Maeshaler（COM整合器）功能组件，使得.NET代码可以与现存的Window库和COM组件结合起来，并将一个应用程序逐渐地从老平台迁移到新平台上来。
下一专题，我们将讨论.NET Framework的类库和公共语言规格。
.NET开发思想(6)－.NET Framework(2)：类库
.NET Framework提供了一套OS级的对象函数库，可供支持.NET的所有程序语言调用。它将原有的Windows APIs、MFC等的功能集于一身。这样，将来程序员只需要学习不同程序的语法规则及程序流程即可，无须学习不同的函数库。
同时，.NET Framework提供的类库还按树状结构组织其命名空间（Namespace），利于程序员查找和使用（还记得以前查找Windows APIs和MFC的痛苦吗？），如下图所示：
vicesDescriptionDiscoveryProtocolsCachingCaSystem
CollectionsConfigurationDiagnosticsGlobalizationSystem
System是.NET对象结构中最重要的对象群集。在.NET对象结构中，所有对象都是由Systen中的Object继承出来的。Object声明了六个成员函数：Equals、GetHashCode、GetType、ToString、Finalize和MemberwiseClone，即所有.NET对象都拥有这六个成员函数。
包含了存取数据库所需的各类对象和命名空间。.NET使用取代原有的ADO结构。在后面的专题中我们将讨论。
提供了.NET应用程序处理XML文件的能力。提供了符合XML 1.0、DTD、IONetReflectionResourcesSecurityServiceProcessTextThreadingRuntimInteropRemotSeriali 下面简单介绍一下几个顶级的命名空间：
XML Schema、XSLT、DOM以及SOAP等标准的各类对象。
g
封装的是用来存取GDI系统的相关对象。
这是.NET开发Windows Forms的基础，提供了许多Windows Forms组件和控件。
使程序具有控制Web Server的能力。它提供的对象模型可以让程序存取Client的请求信息、Cookie等，并能控制Web Server的返回信息。其两个子命名空间和es是.NET Web应用开发的基础。
是.NET中Web Form的基础。提供了Web界面所需的控件和相关的控制功能。
es
提供XML Web Services的支持。
下一专题我们将介绍.NET中的ADO .NET
.NET开发思想(7)－ADO .NET
大家如果对VC或VB开发很熟悉的话，一定很熟悉ADO，以及Recordset等概念。ADO .NET是对ADO的改进，而其主要的改进，在于基于不连接的模型和利用XML进行数据交换。
大家可能知道，ADO采用的是连接的模型，每次调用数据库的时候都生成连接，并生成Recordset，并在完成全部操作之后才释放数据库连接。而非连接模型则是在开始时通过Data
Connection连接数据源，再通过Data Adapter将数据内容转换为Dataset（数据集），然后就断开连接。组件对数据的调用是通过Dataset进行的，不同的组件可以共享同一个Dataset。
不连接模型与连接模型相比，能有效地利用系统资源，能适应Web应用的特殊需求（HTTP本身即是非连接协议），并能实现数据集的有效共享。
Dataset是不连接模型的核心概念。如下图所示：
Dataset的工作方式类似虚拟的数据存储区。Dataset可以包含一个或多个表，还可以包含有关这些表之间的关系和约束，即数据库的一个精简的版本。这一点与ADO的Recordset有很大的不同（Recordset至多只能保存从多个表中返回的结果，只能代表视图，不能代表数据库）。
当组件对Dataset中的数据进行更新（增、删、改）时，Dataset通过Data Adapter对数据源执行相应的操作。
另一方面，ADO .NET是以XML为基础，Dataset是以XML格式存储，数据交换也以XML为基础。
由于Dataset不直接绑定数据源，加之其本身是XML格式的，所以其是来自多个源的数据的好的集成点。
下一专题我们将开始介绍.NET的一大卖点—ASP .NET。
.NET开发思想(8)－ASP .NET(1)：概述
也许大家对微软DNA的最直接印象就是ASP。在1997年，PHP一出现，就以其革命性的思想赢得了无数Web程序员的喜爱。（小插曲：我当时在用C和Perl编写CGI程序，看到PHP后立即喜欢上了它，我是国内第一批使用PHP的程序员。）
微软看好这一市场，适时推出了和PHP同一思想的ASP（而JSP则是步ASP的后尘）。可以说ASP培养了许多Web程序员，培养了许多微软DNA的“狂热份子”。但ASP和PHP、JSP一样，毕竟只是脚本语言，无法实现良好的程序逻辑，程序大了以后就几乎不可控了。
.NET中的ASP .NET其实并不是ASP的新版本，而只是套用了ASP的名号。可以这么说，以前的ASP已不复存在。为什么这么说呢？
因为，ASP .NET不再用ASP的语法和程序结构，而是可以采用.NET Framework支持的任何一种语言进行编写，如C#、VB等。ASP .NET是.NET Web应用的通用开发基础，即ASP .NET其实只是一套.NET
Framework的Web应用类库而已。ASP .NET编程，和其它.NET编程没有任何的区别。
由于ASP .NET是.NET开发，所以其可以和其它.NET应用一样实现及时编译，从而大大提高了其的性能。
ASP .NET能开发两类Web应用，即Web Forms和Web Services。其中Web Forms即我们通常所说的Web页面，而Web Services则是微软的Sales不断谈到的.NET的一个“亮点”。
下一专题，我们将介绍Web Forms的开发。
//--------------------------------------------------------------------------------------------------------------------------------
．NET框架与网络服务
网络服务（Web Service）是基于网络的分布式应用程序的基本构造模块，而这些程序是以平台、对象模板和多语言方式构建的。
网络服务是建立在象HTTP和XML之类的开放的Internet 标准之上的，并且由此形成了可编程网络理念的基础。
图1 网络服务应用模型
这篇文章详细讲述网络服务以及为其提供支持的技术，这些技术能确保服务被集成到应用程序里去。同时本文将讲述新的框架及其对生成和使用网络服务的支持。
现在开发中最紧迫的问题是应用程序的集成化：运行在不同操作系统上的不同的应用程序，通常是由不同编程语言对象模板建立的，获取这些程序然后把它们转化为易于使用的网络应用程序。建立在象HTTP和XML之类开放的网络标准之上的网络服务接受了这项挑战。
但是只支持标准协议是不够的，我们必须有途径来生成、部署、扩展和维护这些网络服务，这正是框架要解决的问题。
图2 Framework体系结构
下面笔者将介绍网络服务及框架的组件，包括通用运行语言（Common Language
Runtime）、服务框架和用于建立、集成网络服务的程序模板。
■网络服务一览
通常说来，网络服务只是一个作为服务发行的简单应用程序。换句话说，它是可通过URL定位的自动将信息返回到需要它的客户端那里的一种资源。网络服务一个重要的特点是客户不需要知道一种服务是怎样实现的。在本文中，笔者将向你解释网络及网络服务如何把基于组件技术的最好的方面结合在一起，并且介绍与网络服务通信所需的基本框架。
同组件一样，网络服务提供“黑匣子”函数，它可以被多次用而不用关心此服务是怎样实现的。网络服务还提供被称为契约的精确定义的接口，此接口描绘了所提供的服务。开发人员可以将远程服务、本地服务和定制代码组合在一起集成到应用程序中。例如，某公司可以使用如下服务组建一个在线商店：微软护照（Passport）服务用来验证用户身份、第三方个人化服务用来使网页匹配每一个用户的参数、信用卡处理服务、销售税服务、对每个运输公司的包裹跟踪服务，链接公司内部库存管理程序的内部目录服务以及少量定制代码，以使他们的商店能脱颖而出。图1显示的模型说明了为生成分布式网络应用程序应怎样链接网络服务。
然而，网络服务与现在的组件技术并不相同，它不使用需要在服务器和客户机有明确的、同类型基本构架的具体对象模型协议，例如DCOM、RMI或IIOP。尽管与具体组件技术紧密结合的实现在一个受控的环境中能很好地被接受，但它们在网络环境中变得不切实际。因为一个集成商业程序的参与者会发生变化，随着时间的推移，技术也在变化，所以在所有参与者间确保一个单一的、统一的体系架构就变得十分困难。网络服务采取了另外一种途径，它使用普便存在的网络协议和数据格式进行通信，如HTTP和XML。支持这些网络标准的任何系统都支持网络服务。
而且，网络服务契约描述的是以术语报文形式提供的服务，这些服务是由网络服务生成和接受的，而并不描述服务是如何实现的。通过把重点放在报文上，网络服务模板对语言、平台和对象模板变得完全透明。这样，用任何一套编程语言、对象模型和平台的完全特性集，都可实现网络服务。网络服务可以在任何平台上，被任何应用程序所使用。只要用于解释服务容量、报文序列和所期望协议的契约得到认同，那么所实现的网络服务及网络服务用户就可相互不同，而不会影响会话另一端的应用程序。
网络服务模板对最小体系架构的要求很低，目的是确保网络服务在使用任何技术和编程语言的平台上实现和访问。对网络服务互用性的解决可以只依靠网络标准。然而，为了使应用程序更容易使用网络服务，简单地通过标准网络协议访问网络服务是不够的。当网络服务和网络服务使用者依靠标准的方式（如XML）表示数据和命令、表示网络服务契约、算出网络服务所提供的容量时，网络服务才会更加容易
使用。
XML是定义一个标准的、可扩展的用于提供命令和典型数据的语言的明智选择。虽然为表示命令和典型数据可以定义使用其它技巧（比如编码为一种查询字符串）的规则，但XML被专门设计为描述数据的标准元语言。简单对象存取协议（SOAP）是以一种可扩展的方式使用XML表示数据和命令的工业标准。网络服务可选择用SOAP决定报文的格式。
XML是网络服务契约的一种常用技术。服务契约语言(SCL)是记录网络服务契约的XML语法。由于SCL是基于XML的，所以对开发者和开发工具来说，它更容易生成并解释契约。
图3 Services Framework类库
Disco规范为服务提供者发布网络服务契约和相应的机制描述了一个标准方式，这将使开发者或开发工具可找到契约文献。
象SOAP、SCL和Disco这样的标准有助于开发者，因为它们不需要明白和实现所使用的每一个网络服务的访问方式。支持这些标准的更好的、已充分测试的、高性能的体系架构将由开发平台提供，这会大大简化整个开发过程。
■ Framework
框架的目的是使你更容易建立网络应用程序和网络服务。图2显示了框架的体系结构。建立在操作系统最上层的服务，是管理运行代码需求的Common Language Runtime，这些代码可以用任何现代编程语言所编写。Runtime提供了许多服务，这些服务有助于简化代码开发和应用程序的开发，同时也将提高应用程序的可靠性。.NET Framework包括一套可被开发者用于任何编程语言的类库。在此之上是许多应用程序模板，这些模板为开发网络站点和网络服务提供了高级组件和服务，下面笔者将逐层描述。
■Common Language Runtime
运行语言(Runtime)可以调用并运行任何编程语言所写的代码。以运行为目标的代码被称为受控（Managed）代码，受控代码只是意味着在内部可执行代码与自身代码存在已经定义好的合作契约。对于生成对象、调用方法等这样的任务，被委托给了运行语言，这使得运行语言能为可执行代码增加额外的
服务。
运行语言具有交叉语言集成、自描述组件、简单配制、版本化以及集成安全服务等特点。
运行语言使用一种能表达大部分现代编程语言语义的通用类型系统，该通用类型系统定义了一套标准类型及生成新标准的规则。运行语言知道怎样生成、执行这些类型。编译器和解释器使用运行语言服务来定义类型、管理对象、进行方法调用。
类型系统的主要设计目的是使多种语言能深度集成。用一种语言所写的代码能继承用另一种语言所写的类，用一种语言所写的代码抛出的异常能被用另一种语言写的代码所捕获，象调试之类的操作会在完全封闭下进行，而不用考虑代码编写所用的语言。这就意味着编写可重用类库的开发者，不再需要为每一种编程语言或编译器生成一个版本，并且使用类库的开发者也将不再受到他们所使用的编程语言开发库的限制。
自描述组件简化了开发和配制，并提高了系统的可靠性。许多由运行语言提供的服务是由元数据及用于补充可执行代码的信息所驱动。因为所有的信息都储存在一起，只有可执行的代码才被称为自描述组件。
自描述组件的一个主要优点是，使用它们并不需要其它文件。类的定义不需要单独的头文件；通过检查元数据对类的定义可以从组件自身获得。跨语言或过程边界访问组件并不需要各自的IDL文件、类型文件或proxy/stubs；所必需的信息已存在于元数据之中。最主要的是，由于元数据是在编译过程中由源代码生成，并与可执行代码储存在一起，因此，它将永远和可执行部分同步。
除了改善对单个组件的配置，Microsft .NET框架定义了一个应用程序配置模板，以解决定制应用程序安装和DLL版本化（通常被称为“DLL Hell”）这一复杂过程的问题，运行语言提供了支持这个模板的服务。
框架引入了组合体的概念。一个组合体是一组资源和类型，并包括有关这些资源和类型的元数据，也就是被作为一个单元配置的。元数据被称为组合体的名单，它包含象类型和资源表之类能被组合体外看得见的信息，这个名单也包括有关从属关系之类的信息，例如组合体建立时的版本号。开发人员可以指定版本策略，以指示运行语言是否装入系统上已安装的依赖于组合体的最新版本，装入一指定版本，或在编译时使用的版本。
某软件组件的多个拷贝可以存在于同样的操作系统上，然而，通常只有其中的一个拷贝能被操作系统注册、调入内存并执行。对系统来说，定位和调入内存的策略是全局性的。.NET Framework Common
Language Runtime增加了所必须的体系架构以支持管理组件定位和调入的每个应用程序策略，这通常被称为并行配置。
组合体可以被一个应用程序私有，或被多个应用程序共享。一个组合体的多个版本可以同时配置在同一台机器上。应用程序的配置信息定义了应到何处去查找组合体，这样，Runtime就能为同时运行的两个不同的应用程序装入到同一组合体的不同版本中，消除了由组件版本的不兼容性引起的问题，提高了系统整体的稳定性。如果必要，管理员可以为配置时的组合体增加配置信息。
因为组合体是自描述的，所以并不需要在系统上进行注册。应用程序的配置简单到了只需将文件拷贝到目录中即可（如果为了使应用程序能够运行，必须安装未经组织过的组件的话，情况会稍微复杂一点）。配置信息保存在可被任何文本编辑器编辑的XML文件中。
最后，运行语言也提供完整的、普遍深入的安全服务，以确保未经授权的用户不能访问机器上的资源，并且代码不会执行未经允许的动作。这就提高了系统整体的安全性和可靠性。由于运行语言用于装
入代码、生成对象、执行方法调用，所以当受控代码装入内存并执行时，运行语言能进行安全检查，从而强化安全策略。
框架不仅规定代码访问安全机制，还规定基于角色的安全机制。通过代码访问安全机制，开发人员能为应用程序指定完成工作所必需的权限。例如，程序或许需要写文件或访问环境变量的权力。这类信息和有关代码标志的信息一起存储在配置级上。当代码装入内存并执行方法调用时，运行语言将验证是否能给予代码所要求的权限。如果不能，将记录一条安全冲突信息。给予权限的策略，被称之为信任策略，是由系统管理员建立的，并且是建立在关于代码的证据基础之上。比如：代码是谁发布的，是从什么地方获得的，以及在组合体中找到的代码标志和它要求的权限。开发人员可以指定他们具体的权限，以防止其它人恶意使用他们的代码。如果所需要的权限依赖直到运行时刻才会知道的信息，那么就可写入纲领性的安全检查。
除了代码访问安全机制，运行语言还支持基于角色的安全机制。基于角色的安全机制建立同代码访问安全机制一样的权限模板，只是这些权限是建立在用户的身份之上，而不是建立在代码的标志之上。角色表明了用户所属的类，并且可以在开发和配置阶段定义。给予权限的策略被分配到每个预定义的角色。在运行时刻，用户的身份被确定，代码将代表这个身份运行。运行语言决定用户是哪个角色的成员，然后给予基于这个角色的权限。
在查看框架的可编程模板前，先看一下它所提供的服务。
■服务框架
正如我们从图2所看到的那样，在Common Language Runtime之上是服务框架（Services Framework），此框架提供能被任何现代编程语言所调用的类。所有的类都遵循一套命名和设计方针，从而大大减小了开发人员学习过程中的难度。
图3显示了服务框架中的一些主要类库。框架包括一套开发人员希望在标准语言库中存在的基类库，例如：集合、输入/输出、字符串及数据类。另外，基类库提供访问操作系统服务如图画、网络、线程、全球化和加密的类。服务框架也包括数据访问类库及开发工具，如调试和剖析服务等。(译： 金志立)
■数据访问服务
几乎所有的网络服务都需要查询和更新永久性数据，不论是以简单文件，还是以相关数据库，或是以其它的存储类型存在。为了提供对数据的访问，服务框架包括ActiveX Data Objects+ (ADO+)类库。如同名字所暗示的那样，ADO+由ADO发展而来。ADO+为基于网络的应用程序和服务提供数据访问服务。图1阐明了ADO+的体系结构，表明任何数据，不论这些数据实际上如何存储的，都以XML或相关数据的格式被操作。
ADO+定义了那些链接数据仓库、对数据仓库发送命令及从中获取结果的类。这些类由受控数据提供者（managed data provider）实现。ADO+中链接和命令对象看上去和ADO中的是一样的，并且一个名为DataReader的新类提供了通过高性能API流获取结果的能力。DataReader在功能上与ADO的记录集（Recordset）是相似的，但是DataReader被设计用来最小化内存中生成的对象的数量，用以提高性能、避免垃圾积累。在.NET Framework中包含了针对Microsoft SQL Server的受控数据提供者以及可通过OLE
DB访问的任何数据仓库。
ADO+的一个主要创新是引入了数据集（Dataset）。一个数据集是内存中提供数据关系图的高速缓冲区。数据集对数据源一无所知，它们可以由程序或通过从数据仓库中调入数据而被生成、填充。不论数据从何处获取，数据集都是通过使用同样的程序模板而被操作的，并且它使用相同的数据缓冲区。使用.NET平台的开发人员能够用数据集代替传统ADO中无连接的记录集。
受控数据提供者为数据仓库和数据集公开的、名为DataSetCommand的接口对象。DataSetCommand使
用ADO+链接和命令从数据仓库中提取数据集，并把在数据集中发生的变化解析到数据仓库中。
就像DataReaders显示了对于相关数据的有效的流访问一样，XmlReaders显示了对XML数据的流访问。开发人员使用DataNavigator可以滚动和编辑内存中的XML文档。DataNavigator在功能上和Document
Object Model (DOM)是一样的，但它更有效，并提供了能很好映射关系数据表的对象模板。ADO+为那些希望继续使用DOM作为XML对象模板而不是使用更有效的DataNavigator模板的开发人员提供了一个XMLDocument类。
图1 ADO+体系结构
■表单应用模板
从概念上讲，在服务框架的最上面是两个应用程序模板：Windows表单应用模板和网络应用程序模板。尽管本文把重点放在把框架用作开发网络服务和网络应用程序的一种途径上，但框架也可用于开发较传统的基于Windows的应用程序（当然，这些应用程序也能使用网络服务）。
编写Windows客户应用程序的开发人员可使用Win表单应用程序模板以利用Windows丰富的用户接口特点，包括现在的ActiveX控件和Windows 2000的新特点，如透明的、分层的浮动窗口。开发人员会发现Win表单可编程模板和对设计阶段的支持非常直观。
Win表单利用了框架 runtime以减少基于Windows的客户应用程序的开销。只要应用程序和组件是用于Win表单应用程序的，那么它们就能被框架安全模板在客户机上安全地执行。
框架装配模板简化了应用程序的配制和版本化。应用程序可被配制为使用它们在编译和测试中所用的共享组件，而不是使用恰好在客户机器上安装的随便什么版本的组件，这就提高了应用程序的可靠性，减少了应用程序所支持调用的主要因素：用户接口控件和其它共享组件版本的不兼容性。
■网络应用程序模板
建立在框架上网络应用程序共享一个通用应用程序模板。包含用于生成在浏览器中观看的网页的网络应用程序和网络服务。下面，笔者将详细介绍Active Server Pages+ (ASP+)的网络应用程序可编程模板，如图2所示。
ASP+是由活动服务器页面（ASP）发展而来。ASP+利用common language runtime和服务框架网络应用程序提供了一个可靠的、自动化的、可扩展的主机环境。ASP+也受益于common language runtime集成模板，简化了应用程序的配制。另外，它提供简化应用程序开发的服务（如状态管理服务）以及高水平的编程模板（如ASP+网络表单和ASP+网络服务）。
ASP+的核心是HTTP运行语言，一个高性能的用于处理基于低级结构的HTTP请求的运行语言,而基于的结构与Microsoft Internet Information Services (IIS)所提供的ISAPI结构相似。由图2可知，HTTP运行语言（HTTP runtime）负责处理引入的所有HTTP请求，并对每个请求应用程序的URL进行解析，然后把请求分配到应用程序以进行进一步的处理。HTTP 运行语言是多线程的，并异步处理请求，因此劣质的应用程序代码阻碍不了它对新请求的处理。而且HTTP运行语言假定失败必会发生，因此它通常可以自动
地从访问冲突、内存泄漏、死锁等事故中恢复过来。
ASP+使用基于构件的Microsft .NET框架配制模板，因此它获得了如XCOPY配制、构件并行配制、基于XML配制等优点。ASP+另一个主要优点是，它支持应用程序的实时更新。管理员不必关掉网络服务器，甚至不用停止应用程序的运行就可以更新应用文件。应用程序文件永远不会被加锁，甚至在程序运行时文件就可以被覆盖。当文件更新后，系统会检测到文件变化，并用新的应用程序代码建立一个新的应用程序实例，然后将引入的请求传递到应用程序。当所有被现存的应用程序实例处理的未完成的请求处理完后，该实例就被销毁。
在应用程序中，HTTP请求（HTTP Request)通过HTTP模块的管道路由，最终到达请求处理程序。HTTP模块和请求处理程序是一些实现特殊接口的受控类，而这些接口是由ASP+定义的。这种管道结构使得为应用程序增加服务非常方便：只需补充一个HTTP模块。例如安全、状态管理及跟踪都被实现为HTTP模块。高级可编程模块，如网络服务和网络表单，通常被用于请求处理程序。一个应用程序能链接多个请求处理程序，每个处理程序对应一个URL，但是所有的HTTP请求都要通过同样的管道路由。
网络基本上是一个无状态模型，并且在HTTP请求间没有联系，这使得编写网络应用程序很困难，因为应用程序通常需要维护跨多个请求的状态。ASP+增强了由ASP引入的状态管理服务，以便为网络应用程序提供三种类型的状态：应用程序、会话和用户。就像在ASP中一样，应用程序状态特定于一个应用程序实例，并且不会持久。会话状态是特定于一个用户与应用程序间的会话的。与ASP会话状态不同，ASP+会话状态储存在一个独立的过程中，并且可把它配制成可以储存到一个独立的机器上。这使得会话状态当应用程序在网络群（Web farm）扩展时非常有用。用户状态类似于会话状态，但通常它不会超时，并且是永久性的。因此，用户状态对储存用户参数和其它个性化的信息是有用的。所有状态管理服务都被实现为HTTP模块，因此它们容易增加到应用程序管道中，或从中删除。
图2 ASP+网络应用模型
如果除了由ASP+提供的服务外，还需要额外的状态管理服务，那么可由第三方的模块提供。
ASP+同样提供高速缓冲服务，以改善性能。输出缓冲可完全节省网页翻译，段缓冲储存部分的网页。由于提供了相应的类，所以只要需要，应用程序、HTTP模块以及请求处理程序就可以在高速缓存中储存任意数量的对象。
下面让我们认识一下建立在ASP+可编程模块之上的两个高级可编程模块：ASP+网络表单和ASP+网络服务。
■ASP+网络表单
网络表单把基于Visual Basic表单的高生产性优点带到了网络应用程序的开发中来。网络表单支持传统的将HTML内容与脚本代码混合的ASP语法，但是它提出了一种将应用程序代码和用户接口内容分离的更加结构化的方法。引入的网络表单控件用于为封装通用用户接口元素提供了一种机制。这些新的特点使得开发工具在支持VB小应用程序的同时，也支持设计模块。
图3 ASP+网络服务
网络表单控件负责生成用户接口，典型情况是在HTML表单中。ASP+提供了一套映射传统的HTML用户接口小部件（包括列表框，文本框和按钮）的网络表单控件和一套附加的网络控件（如日历和广告转板）。这些控件的一个重要特点是，它们可以被编写以适应客户端的能力；同一网页把大范围的客户端平台和表单因素作为目标。换句话说，网络表单控件能“嗅”到正在查找表单的客户，然后返回合适的用户经验——可能是适合低级浏览器的HTML3.2或是适于IE5.0的动态HTML。
考虑到网络是一种无状态的联接模型，网络应用程序开发人员所面临的一个很复杂的问题是，他们要对用户与基于网络的接口的交互作用作出反应。网络利用ASP+的体系架构提供了一套丰富的服务，以帮助开发人员建立交互式网页。用户与网页交互作用的状态管理的复杂性被ASP+网络表单和网络表单控件隐藏起来了。对开发人员来说，提供的丰富数据绑定服务使得显示通过数据访问服务得到的数据变得非常容易。
代码与内容的分离使ASP+网页能动态地编译到受控类中，用以提高性能。每个引入的HTTP请求都被传递到一个新的网页实例中，因此开发人员不需要关心代码中的线程安全性问题。
■ASP+网络服务
ASP+网络服务体系架构为用ASP+建立网络服务提供了一个高级可编程模板。虽然建立网络服务并不需要使用网络服务平台，但是它提供许多的优点将简化应用程序的开发过程，并且它使用的编程模型对用ASP或VB工作的开发人员来说是很熟悉的。使用这个可编程模型，开发人员可以不需要理解HTTP、SOAP或其它任何网络服务规范。ASP+网络服务可编程模型如图3所示。
开发人员用ASP+生成一个扩展名为 .ASMX的文件，并把此文件配制为网络应用程序的一部分，就建立起了一个网络服务。ASMX文件包含受控类的引用，或这个类的定义。这个类是由ASP+提供的WebService类所派生的。公有的类方法在标记上WebMethod属性后，就会成为网络服务方法，把HTTP请求发送到ASMX文件中的URL后，这些方法就会被调用。你不必手工为你的网络服务建立一个契约。当被调用者发出请求时，ASP+会检查类的元数据，从而自动生成SCL文件。
客户可通过SOAP、HTTP GET和HTTP POST提交请求。对方法和参数进行编码的约定是：HTTP GET，将被编译为查询字符串；HTTP POST，将被编译为表单数据。HTTP GET和HTTP POST 的机制不如SOAP有力，但是它们使得客户在访问网络服务时不必支持SOAP。
ASP+网络服务模型假定了一个无状态服务结构。无状态结构通常比有状态结构更具可扩展性。每次收到一个服务请求后，就生成一个新对象，请求被转化为一个方法调用，当方法调用返回时对象被销毁。如果这些服务需要跨请求维护状态，那么它们将使用ASP+状态管理服务。基于ASP+的网络服务在网络应用程序模型中运行，因此它们得到了该模型的所有安全、配制和其它优点。
ASP+网络服务还提供了一个为在SCL文件中描述的网络服务生成分类的受控代理工具。代理生成器把SCL文件中描述的消息映射成受控类中的方法。代理对应用程序代码隐藏了所有的网络和引导设备，因此使用网络服务看起来就象使用其它受控代码一样。代理将优先使用SOAP链接网络服务，但是它同样支持HTTP GET和HTTP POST机制。
■结论
网络服务为在Internet上绑定应用程序提供了简单的、灵活的、基于多标准的模型，同时，最大可能地重用现存体系架构和应用程序。网络应用程序可以很容易地与本地开发的服务或已存在的服务集成在一起，而不用考虑开发平台、开发语言或使用的对象模型，以用于实现任何组成的服务或应用程序。
框架为开发人员提供了一个极为方便的开发环境，从而简化了安全、可靠、可扩展、高可用性的网络服务的建立、部署和不断的发展。
发布评论