CLR Hosting (1) -- 可扩展体系结构和CLR Hosting
CLR Hosting (1) -- 可扩展体系结构和CLR Hosting
1 可扩展体系结构
对于可扩展体系结构，有许多不同的定义，大到一个网络集群系统，小到只有几个组件相互作用构成的小软件，对可扩展体系都可以有不同的理解和定义。同样，在谈到CLR Hosting话题时，不可能不谈到可扩展系统结构，我们宿入(host) .Net CLR的一个重要目的就是获得一个可高度定制的可扩展体系。
在本系列文章的上下文中对可扩展体系结构的理解是指，一个定义了扩展模型体系、可动态加载其特定“扩展体”到自己的进程中运行的任何一个应用系统。对于这个定义需要展开来讲述一下。
第一，说一个应用具备可扩展体系，其内必须定义并实现了一套内在的模型体系，即对象模型(Object Model)体系。这里所说的对象，并不是我们在程序编码中所涉及的C++或C#等语言层面的对象，它指的是一个更高层次上的组件对象，它可能是一个二进制级别(物理指令空间上)的组件对象(如COM组件)，也可能是一个由IL代码和Metadata支持(逻辑空间上)的.Net Assembly，这种高层次上的组件对象，一般由一个或多个语言层面的对象来实现完成；这里所说的的模型体系，是指这些应用内部的组件对象，按照应用内部的特定关系形成一个层次结构，在这种层次结构的定义和约束下，应用把这些组件对象组织起来并开放、暴露出去，形成一个外部可访问的对象模型，供“扩展体”(如Addins、Extension Modules、脚本)或其它外部Client来使用。对象模型体系的一个典型的例子是MS Office应用，例如其中Excel的内部Application、Workbook、Worksheet、Range等对象以及它们所形成的关系模型，还有VBA或COM Addin对它们的访问。
第二，说一个应用具备可扩展体系，它必须具备动态特性。动态特性是一个可扩展应用的关键，它有三层含义。首先，对于这个应用的扩展部分(如Addins、Extension Modules、脚本)，用户通过配置或其它方式是能够控制它们的加载情况的。其次，这个应用在运行时可依照用户的配置或其它方案动态地把这些扩展部分装入进程。第三，这些扩展部分程序实体，不是和应用本身一起开发创建的，是应用发布以后，高端用户为特定需求、出于定制或扩充目的为应用单独开发和再发行的。
第三，说一个应用具备可扩展体系，它一般要有“扩展点”方面的设计考虑。虽然这一点不是必须的，但良好的扩展点设计，可以使一个可扩展的应用系统的生命力更加长久。扩展点，指的是一种设计因素，就是它决定了一个应用在哪些层面上可以被扩充或定制，决定了一个应用会支持哪些形态的扩展体。下面是常见的的扩展点设计所支持的扩展体形态，一般一个应用不必支持全部的扩展体形态。
1)Addins 这是一种小规模、任务相对单一、宿主约束较多的一种扩展、定制方案。但完全可能实现很强大的功能。
2)Extension Modules 简称Extensions，这是一种面向某一方面的、宿主约束较少的方案。设计中通常可以用它来完成某一个完整方面的若干任务单元。
3)Scripts 即脚本，这是一种较强大的扩展、定制方案。通过脚本，可以全方位访问宿主应用内置的对象模型(调用宿主内对象的接口方法、响应其事件等)，也可以设计用来实现脚本方式的、特定于宿主应用的Gadgets形式的扩展组件。
4)Code Behind Document 这个方案本质上利用了脚本技术，但它强调的是设计与应用的统一。宿主应用的主体功能完全或部分承载于脚本代码之上，实现“扩展定制方式”与“主体功能实现方式”两者的高度统一。脚本代码成为完成应用主体功能的不可缺少的部分。
以上从三个方面，讲述了本系列文章上下文中对可扩展体系的定义和理解，与读者达成一种一致的认识，方便以后的讨论。但这不是我们的重点，我们的重点是一种实现可扩展系统的方式。
2 可宿环境和CLR Hosting
关于如何实现一个可扩展体系结构，方式不外有二。一是完全自定义设计实现，另一个则是宿入一个现存可用的可宿入环境(Hostable environment)。后者的优势是显然的。即使选择前者方式，完全自定义设计实现，那么当这个应用系统完善到一定程度、系统结构设计优秀到一定程度，那么也相当于自定义完成了一个不一定完整的可宿环境，可见，两种方式并不是完全矛盾的。
宿入一个现存可用的可宿环境，就相当于我们直接站在了一个较高的起点上。一般地，一个可宿环境，由于它特别的应用需求，就决定了它设计上对通用范围、结构合理性、自身可定制性等方面要做出更多的考虑，所以它的体系合理性是值得信任的。另外，当你的应用宿入了这样的一个环境，也必然从设计上要适应它的某些体系层次上的特点或要求，这种反向作用的结果，就是提升了你的应用的总体设计水平。由此可见，这种方式实现可扩展体系的益处很明显。如果你正在设计一个可高度扩展、定制的应用，那么选择宿入一个现存可用的可宿环境的方式是很值得推荐的。
那么在MS的技术平台上，有哪些常见的可宿入环境供我们选择呢？列举一下。
1) Active Script Engine 如VBScript或JScript脚本引擎，通过宿入这种引擎来获得对脚本的支持能力，使得应用程序支持定制和扩展。
2) VBA APC 即通常说的Visual Basic for Application环境的宿入。这是MS在Win32平台上非常成熟的可宿环境，也是大家最可能熟悉的一个。MS自己的Office系统、AutoDesk的AutoCAD、Intellution的iFix、金山公司的WPSOffice开发版等等，都是实现为它的宿主。
3) .Net CLR 这是MS的最新的可宿入环境技术。它为MS Win32/64平台或.Net平台上的应用提供了更加强大的Managed Code方式的可扩展定制的能力。它也是本系列文章的唯一主要要讲述的内容。
值得一提的是，上面我没有列出Trident(IE Browser的核心)和ASP.NET。从可宿环境角度来看，Trident(MSHTML)实际上是一个本身宿入了Active Script Engine的一个可宿环境，被用于浏览器类程序、邮件客户端、游戏客户端等应用中。而ASP.NET是一个本身宿入了.Net CLR的一个更大的可宿环境，被IIS或其他系统用于宿入以提供对ASP.NET Web Application和ASP.NET Web Service的发布支持。
在上面的常见可宿环境的列表中，大家看见了.Net CLR，也就可以知道了.Net CLR Hosting在整个Hosting大背景知识体系中的位置。那么，.Net CLR作为MS最新一代的可宿环境，除了ASP.NET，到目前为止还有其它的宿主应用吗？
MS SQL Server 2005和IE6/7是可以马上想到的例子。
到目前为止，还没有一家非MS的产品宿入了这个环境。但可以想见，不久这个局面就有可能会改观。.Net CLR核心技术逐步稳定，MS内部应用.Net CLR的方式和趋势，将直接影响外界对它的态度。Win32平台上大量的应用都面临着如何与.Net亲密接触的问题，大面积的向Managed环境移植或重写，几乎不可能，.Net CLR Hosting将是最为平滑的手段。到现在为止，.Net CLR Hosting还是比较新的应用话题，无论是桌面应用开发、服务器软件开发还是嵌入式环境的开发，CLR Hosting都将发挥它的作用。对有幸经历这个技术发展阶段的我们来讲，这难道不是一个机会吗？
如果答案是肯定的，那么我们还等待什么呢？
本文作为系列文章的第一篇，讲述了Hosting有关的背景知识，指出了CLR Hosting在这个知识体系中的位置，为后续的文章做些准备。另外，下面把Hosting相关的词汇列出并简单注释，方便读者阅读、理解这个系列的内容。
Host CLR -- 宿入CLR -- 这里Host是动词，表示宿入的动作含义。
CLR Host -- CLR宿主-- 这里Host是名词，表示一个宿入了CLR的主体应用系统，含义范围既包括宿主环境，也包括被宿入的可宿环境。
Host Envirenment -- 宿主环境 -- 名词词组，表示宿主系统中，主体程序为可宿环境提供的环境。含义中不包括可宿环境本身。
Hostable Envisionment -- 可宿环境 -- 名词词组，表示可被宿主系统宿入的环境实体。
Hosted Environment -- Hostee -- 被宿入环境 -- 同上，但有已经被装载入宿主环境的含义。
CLR Hosting -- CLR宿入 -- 动名词词组，表示宿入的过程、技术、概念等，具体含义依赖上下文。
