Microsoft.NET为什么难于理解

>>原标题如此，其实我觉着这是非常自然的事情<br>
--------------------------------------------------------------------------------<br>
<br>
分析：Microsoft.NET为什么难以理解<br>
<br>
--------------------------------------------------------------------------------<br>
<br>
http://www.sina.com.cn 2000/08/08 15:34 日经BP社<br>
<br>
　　2000年6月22日美国微软公司公布了“Microsoft.NET”。该公司为此曾经在日本国内举行了两次新闻发布会。在7月26日～28日期间举行的微软研讨会“Tech Ed2000”上“Microsoft.NET”也成了热门话题。.NET是用来建立被称为NGWS(即下一代Windows服务之意)的新一代服务/软件的基本构想。<br>
<br>
　　举个例子，微软制作的.NET所描绘的宣传录像片中有这样的一个场面。一个男人出差到外地，在机场租借手机电话。他向该终端插入自己的IC卡后，自动下载他的地址簿和计划簿，随即就变成了他专用的PDA(便携式信息终端)。<br>
<br>
　　确实方便，不过如果被告知“这就是.NET”，反而把人搞得似懂非懂、糊里糊涂。笔者觉得如果要选一下最近几年微软公布的晦涩难懂的计划，那么.NET无疑要名列前茅。<br>
<br>
　　究竟什么地方不易理解呢。笔者认为难就难在它没有能够明确与目前微软推出的概念之间的相互关系。比如.NET的基础、分布式应用软件的思想，为了实现这一思想微软本身提供的机制，在此机制上微软或者由第三方提供的服务，以及实际计划提供的产品是什么样的，等等这些关系一下子人们很难理清。<br>
<br>
　　建立方案的框架其实就是Windows DNA2000 <br>
<br>
　　不过，仔细考虑后就会发现，.NET与过去的概念之间的关系其实很简单。<br>
<br>
　　在.NET中，通过因特网可以利用的单功能服务(构造块，Biulding Block)组合在一起来建立方案。微软本身已经宣布向消费者提供门户网站MSN.NET、办公软件的ASP服务Office.NET等的.NET方案以及认证服务Passport等，用来建立.NET方案的基本的构造模块，由于所有这些参杂在一起，所以令人难以理解，其实这一流程正是Windows DNA2000本身。<br>
<br>
　　为了利用构造模块，使用SOAP(简单对象访问协议，Siple Object Access Protocol)作为通信协议，使用XML(可扩展的标记语言)做为数据格式。也正是从DNA2000开始，才提倡通过采用SOAP/XML组合，使得在Windows以外的平台上也能够建造用来建立方案的构造模块。<br>
<br>
　　构造方案的实体如同上述宣传录像带中显示的那样有多种服务。例如只需要插入IC卡就可以使用自己的地址簿及计划簿的手机电话服务等。<br>
<br>
　　构成方案的零件就叫做构造模块，它是各种服务的群体。还是以上述手机终端为例，终端读取的IC卡信息并进行用户认证服务，以及从个人电脑及手机电话经由网络传递地址簿及计划簿的服务，等就是构造模块的实例。也就是说，在这一手机服务中，建立了一个使用SOAP/XML，经过认证服务接受认证，然后凭着通过认证的证据从计划簿服务公司通过SOAP/XML接收用户计划簿的流程。<br>
<br>
　　不再为COM而苦恼<br>
<br>
　　通过组合构造模块来建立方案的部分，只是DNA2000改了个名字而已，而关于构造模块本身，.NET则比DNA2000更前进了一步。<br>
<br>
　　在DNA2000中表明，使用COM(零件对象模型、Component Object Model)、DCOM(分布式COM)以及Windows2000 Server的COM+服务建立构造模块(在DNA2000中称为Mega服务)。另一方面，在.NET中COM这一术语消失了。取而代之公布了被称为.NET Framework用来建立构造块的框架。<br>
<br>
　　COM虽然做为术语消失了，不过实际上.NET框架的实质是将COM+改进的结果。事实上，在.NET框架的SDK(软件开发套件)的发行文件中还残留着COM+2.0的影子。而COM+是在不改变COM框架的基础上，改由OS方面进行安全性及负荷分散处理等处理，从而减轻了安装时间的运行时间(Run Time)。<br>
<br>
　　这是因为虽然COM本身是一个并不太复杂的标准，但是由于存在着众多的约束事项，因此安装时非常费时。而在.NET框架中将“交给OS处理”部分进一步扩大，从而完全除去在COM+中依然残留的COM框架。这样一来，就不再需要安装做为COM项目的对象了。<br>
<br>
　　目前正在流行这种实现方式。一言以蔽之，就是将COM对象变成与Java程序一样。也就是说，.NET框架的对象，不是被编译成处理器的本地代码(Native Code)，而是被编译成被称为IL(中间语言)的虚拟机代码。而在执行时，则由相当于Java虚拟机的被称为CLR(Commom Language Runtime)的模块将IL代码转换成本地代码后执行(实际上只是在第一次才真正转换)。<br>
<br>
　　对象之间的通信不必描述为COM，只需描述为普通调入手续即可。只要移植CLR就可以在Windows以外的客户及服务器上运行同一个代码。而且可以使用任何开发语言。微软的开发环境Visual Studio除了在下一个版本中使C/C++、Visual Basic以及新开发的C#对应.NET框架以外，目前已经有多个第三方加入，将来有可能使用除了Java以外的所有主要语言。<br>
<br>
　　在7月11日～14日PDC(专业开发人员会议)上，当美国微软的副社长鲍尔·马里茨(音译)表示“已经不再需要(COM的典型约束事项)IUnknown及GUID”时，开发人员们兴奋得鼓掌喝彩，这一点完全可以理解，先不去考虑.NET框架减轻了开发工作量或者与Java相似等问题，做为纯粹的软件技术，.NET框架确实是一个很有意思的结构。<br>
<br>
　　实际上在公布的.NET中还包括用来建立.NET方案的多种服务，不过最后在理解了.NET的平台部分是Windows DNA2000和COM+以后，就感到“原来它和现有的相比其实没有什么大的改变”。而另一方面，从微软故意将内容搞得晦涩难懂，淡化Windows色彩来强调其新意的做法，可以感到他们要在因特网时代继续生存下去的坚定意志。(BizIT) <br>