WCF的外观模型

我把这个标题写为：WCF的外观模型
我的意思是想从这中外观或者说不探讨细节的情况下来写WCF的大体梗概，尽管非常抽象，但我还是希望你认真的读完，因为把握了实质才能触类旁通，其实本身WCF的远程结构并不难，如果你觉得的很难阅读的话，那肯定是我阐述的能力和水平的问题，你不防参考一下相关资料。
在这个话题下，我想写三篇文章：
一，WCF的远程基础架构
二，应用程序域与进程
三，示例上下文

   (一) WCF的远程基础架构

WCF编程的一般模型简单介绍如下：

服务端：

一，写一个服务类

二，在服务端注册这个服务类

三，编译上述程序集

在.NET托管的环境下，程序集是MSIL类型（microsoft中间语言）并且包含元数据信息。什么是元数据信息？简单理解为包含类的类型，数据成员的相关成员的数据集，因此我门可以反射这个程序集，获得你写的类，简单理解元数据集是存储信息的介质。什么是反射？反射就是某中机制，它预实现了一系列操作，通过反射，我门可以从元数据集中获得你所写的类的信息。你确信理解了吗？

WCF是远程基础框架，它解决通讯的问题，我门所考虑的就是如何部署服务端以及客户端的问题。

假设一个服务类：
public class ActionOfkiss
{
      public true IsCompletedOfKiss(Boy boy,Girl girl)
     {
           行为
      }
}

我门把这个类部署在服务端，（服务端是相对来说，可以是任何一台提供确切地址的电脑）.我门在客户端仅仅需要部署一个函数原形，然后让代理传递这个函数原形，譬如public true IsCompletedOfKiss(Boy boy,Girl girl)，远程基础框架会将它进行一系列操作，譬如序列化等等，然后传到服务端的应用程序域，什么是应用程序域？它是你包含你编写程序的一个最小单位，它象进程一样具有边界。然后执行，请务必注意执行是在服务端的应用程序域，并将结果传给远程框架，最后它将结果返回给我门。这个过程，就好象远程调用函数的场景，我门在客户端传递参数，而在服务端执行。

那么我门如何获得这个函数原形呢？

一，直接把这个类布置在客户端，因为这个类里包含了你想要操作的函数调用。

二，把服务端编译的程序集布置在客户端，因为我门可以利用反射饿，还原原来的函数原形。

三，把服务端的类写成接口和实现接口的类的形式，然后把接口布置在客户端。

我门之所以如此做，是模拟一中假象，模拟服务端的行为，但是它对客户来说又是透明的。这中在客户端的假象，表面上简单理解为仅包含类的基本骨架的类型，我门称之为代理。（可以简单如此认为，实际代理又比较复杂，又分透明代理与实际代理，关与代理而又可以单独成文），我是想让你先熟悉这个名词。以读下文。

我想从一定的高度来阐述远程基础框架（袄，对了，我所指的远程基础框架意思是指WCF,在.net remoting中叫习惯了）

简单的说：

WCF由代理，通道和消息组成。代理是模仿远程对象的本地对象，也就是说它提供了与远程对象一样的方法和属性。不过，要实现指定方法的代理，通常需要将调用传给通道对象。通道对象代表了到远程对象的连接，每个通道对象都包含了一个将方法调用转换为以知格式消息的格式化远程对象。然后将消息发送到服务器上，服务器上有一个客户端通道对象的镜象，这个镜象能够斟听请求。这个通道对象还包含了一个格式化程序对象，它可以将消息反串行化后发送给内部对象Dispatcher(我理解为堆栈管理器），该对象接受到消息转换成方法调用，并调用远程对象的方法。

详细阐述如下：
   

WCF提供了大量有价值的支持包括可靠性，事务，并发管理，安全，事例激活，所有的这些功能依靠与WCF的基于侦听（拦截）的架构。让客户与代理打交道，意味着，WCF框架是仅仅连同客户端和服务端，拦截调用，实现发送的消息和接受的消息的预处理。请注意，服务端的侦听并不是客户端反射元数据形成代理的时候，而是当代理把调用栈砧序列化成消息并且把消息发送到通道链的时候。我想解释一下，MSDN用the call stack frame来形容调用栈砧，如果你了解递归的话相信不难理解，简单解释一下。

Static void Main(string[] args)

{

     Docallback();

}

Docallback()函数的执行肯定与Main函数不在一个栈砧中，Main函数保存Docallback函数地址,现场，以便函数调用返回。应该抽象的来理解。继续我门的话题，通道仅仅是一个拦截器，它的目的是实现一个特定的任务，每个客户端通道对传递的消息做预处理。其实基础架构的复杂性完全取决与我门，为什么这么说呢？WCF基础架构的通道是可定制的，就想当于一个挂钩，我门在默认挂个Windows正版软件的时候可以拿下来堂堂正正挂个倒版的，定制性完全取决于我门，前提是你得实现“能够挂”这个接口。那么通道的作用通常是我门关心的问题，每个通道各管其责，（下文所指通道是客户端的部分），有的通道专门负责编码消息（把函数调用转化为binary,text,Mtom）,有的通道负责多播事务，有的通道维护可靠的会话，有的通道负责加密消息，还有其他的通道等等，最后一个通道是最为关键的一个通道，这个通道是传输通道，他负责把消息按照你配置的远程端口发送到远程端，所以说他的功能不仅仅是传输通道，而且还具有路由的功能。在远程端，也有一系列的通道，不过他们的顺序正好与客户端的相反，我想这不难理解，就相当于你按照一定的操作破坏了一个文件，我必须按照你操作的逆序来恢复这个文件。不过这些通道链的作用一般是与客户端相反的作用，客户端一个通道负责加密消息，那么在远程端有一个通道是负责解密的作用，远程端的最后一个通道，同样，我请大家注意，在经过服务端的一些列通道的作用后，在到达最后一个通道前，现在的消息已经就是客户段发送之处的函数调用了，最后一个通道将这个函数调用消息传个Dispatcher,（可以理解为堆栈管理器），由它负责调用服务示例，也就是函数调用的执行，同时它要交出控制权，等函数调用（服务示例的某个函数）执行完后，服务示例再将控制权还给Dispatcher ，它再将返回值按照预定义的通道从远程端传给客户端。经过客户端的种种通道提交给代理。最后代理将返回值递交给你所写的应用程序，交出控制权。
    
    
    这是服务端的宿主架构。这 个最大的模块是进程，在进程下是一个或者几个应用程序域,请注意可能不是一个。在一个应用程序域下，可以包含一个或者几个Service Host(我们叫它服务运行时)，通常我门提供一个服务（就是我门写的一个需要提供服务的类）的话，就必须在Service Host里注册，服务运行时主 要做两件事，一是暴露服务类的地址（这里地址就Endpoints），这样远程客户才能找到这个服务。二是斟听端口,以便客户端传过来函数调用时，能够知晓。Service Host的里面具有多个上下文对象，关于上下文对象比较复杂，我想另写一篇祥谈。

写这篇文章竟写了四个多小时，前两个小时写完了，准备提交，提交失败，文章全没，我的心情很沉痛，这件事很严重。突然想起一件事，前段时间一新闻，一大学男生欲寻短见，从楼上跳下竟将一女生砸死，哎，这个世界太疯狂，，，，老鼠给猫当伴娘，虽重写了便是。

本文参考了:
       MSDN
       <<Distributed .NET Programming in C#>>
       <<Programming WCF Services>>