Adhesive框架中的WCF分布式服务模块基于原来写的WCF扩展修改而来，主要的修改如下：
1）原先使用数据库的元数据配置，现在统一改为配置服务，主要是为了统一，不用再去开发一个WCF的配置后台
2）原先直接存储到Mongodb中的各种日志，现在统一使用Monodb数据服务，也是进行了一个统一
3）和信息中心模块中的网站请求状态（统计每一个请求的情况）一样，这里也提供了WCF客户端和服务端的执行状态
这个模块主要实现如下功能：
1）集中化的配置：地址、绑定、契约、端点等等信息都无需在配置文件中配置，直接在统一的配置服务中进行配置。不管是客户端还是服务端都没有配置文件。这么做的好处是可以集中管理，也方便了负载均衡环境多台机器的配置修改。
2）4*2种自动日志的记录：服务端客户端启动（服务端启动WCF服务、或客户端第一次调用WCF服务）日志、服务端客户端异常日志、服务端客户端调用WCF服务日志、服务端客户端发送的消息日志。这8种日志都具有独立的开关，自动记录，无需写一行代码。
3）允许进行调用的请求验证（通过消息头），可以进行请求和响应的双向验证也可以配置为单向，服务端允许开启Unity的依赖注入。
4）允许向.NET Remoting那样直接通过接口进行服务调用，实现了WCF服务的定位器，内部缓存信道工厂并处理调用错误的情况。
具体每一个功能的实现就不具体介绍了，有兴趣的可以看以前的WCF扩展的相关文章，其基本原来还是一致的。
现在就来介绍对于一个新的服务要使用的话如何进行配置，首先打开配置服务后台：
在配置服务后台的全局配置中可以找到Wcf的配置，点击下一级进入：
1、首先需要配置需要的绑定，点击进入绑定配置：
这里，我们已经定义了一个叫做UnsecuredTcp的绑定，当然你也可以新建一个自己需要的绑定，我们来看一下绑定里面可以配置哪些东西：
1）绑定的类型，可以是NetTcpBinding、BasicHttpBinding、WSHttpBinding、NetNamedPipeBinding、NetMsmqBinding等，默认值是NetTcpBinding。
2）绑定的优先级，数字越小优先级越高，所谓优先级就是优先选择哪一个绑定，客户端在选择服务端的时候会优先选择优先级比较高的绑定
3）绑定行为XML，这个和配置文件中的绑定行为配置是一样的
4）绑定协议，这个需要和绑定类型对应起来，比如http、net.pipe、net.msmq等
2、在定义了绑定之后，先可以定义服务的配置，进入服务配置节点：
这里可以看到我们有两个服务，我们Mongodb数据服务使用的WCF配置也在这里，点击进入MongodbServer服务看看：
1）服务类型名，配置的是服务实现类的完整限定名
2）服务行为XML，这里没有配置，这也是和配置文件中配置的是一样的，比如可以配置：
<behavior name="ServieBehavior"><serviceMetadata httpGetEnabled="false" /><serviceThrottling maxConcurrentCalls="200" maxConcurrentInstances="200" maxConcurrentSessions="200" /></behavior>
3）服务端机器IP，可以针对不同的服务端机器有不同的服务配置，*就是针对所有机器的
4）服务集群名，集群主要用来配置对外的负载均衡地址，这里我们的服务对应LocalFarm
5）服务端设置，点击进入查看详细：
这里有核心配置、日志配置和安全配置三类。
1）核心配置：
也就是是否开启Unity为服务实现的构造方法进行依赖注入，默认是关闭的。
2）日志配置：
这就是之前说的服务端的4种日志的开关，其中无非是开关的配置，对于消息类型的日志，还可以配置记录消息的方向：
这是一个枚举：
3）安全配置：
这里主要配置的是是否启用调用的密码验证：
当然，也可以配置验证的方向：
是在请求的时候验证还是在回复的时候验证，还是都需要验证。
3、在完成了服务的配置之后，需要进行服务端点的配置：
在这里，我们之前配置的每一个服务都有配置一个端点，还是进入Mongodb服务的端点看看，注意到这里名称是契约名而不是服务实现的类型名了：
1）服务类型名，这是和服务配置中对应的，也就是需要配置契约的实现类型的完整限定名
2）契约类型名，也就是接口名
3）契约版本，在这里可以针对不同的接口程序集的版本配置不同的端点
4）服务器IP，在这里可以针对不同的服务端的IP地址配置不同的端点
5）服务端点行为的XML，在这里没有特殊的配置，格式按照配置文件，比如可以这么配置：
<behavior name="ServiceEndpointBehavior"><dataContractSerializer maxItemsInObjectGraph="10000" /></behavior>
6）服务端点绑定名，也就是需要对应绑定配置中的绑定名
7）端口，通讯端口
8）端点名，这是作为通讯地址的一部分，通常可以使用契约名
4、服务端的配置部分差不多结束了，接下去可以配置服务集群对外的地址，进入集群配置：
还记得吗，我们之前配置的Mongodb数据服务是用的是LocalFarm，在这里我们看到定义了两个集群。分别来看一下每一个集群：
可以发现这两个集群的友好名字和集群名都是LocalFarm，也就是说Mongodb的数据服务对应这两个集群，那么客户端在选择的时候怎么判断是哪个集群呢？
这里通过客户端机器IP来决定的，*的优先级是比较低的，如果遇到客户端IP是192.168.136.202的话，选择127.0.0.1作为集群地址，这个IP地址是我机器的IP，也就是说我希望在本机开发的时候使用本地的服务端，方便调试。而对于其它客户端IP使用192.168.129.143，这是开发测试服务器的IP地址，也就是希望开发服务器环境上的其它客户端在使用服务的时候定位到开发测试服务器。
5、然后我们就需要配置客户端部分了，首先是客户端端点：
还是进入IMongodbServer：
1）契约类型名，接口类型的完整限定名
2）客户端机器IP，可以根据不同的客户端机器IP配置不同的客户端端点
3）客户端端点行为XML，这个和XML中配置的客户端行为配置节点的内容是一样的
4）客户端设置：
这里的配置其实和服务端的配置是差不多的，只不要需要注意，WcfCoreSetting中没有内容，因为客户端没有Unity的选项。而WcfSecuritySetting是不需要配置的，客户端是否进行调用密码验证根据服务端的配置来的，客户端的配置是不会使用到的。
6、为了安全，我们还要进行客户端允许和客户端禁止的配置，在这里我们配置了刚才配置的那个集群需要允许所有的客户端访问：
必要的话，还可以进行Deny的配置，这里没有进行配置。
在完成了配置之后现在就可以写服务端和客户端的代码了，服务端：
AdhesiveFramework.Start();
var host = WcfServiceHostFactory.CreateServiceHost<MongodbServer>();
host.Open();
Console.WriteLine("Adhesive.Mongodb.Server started...");
Console.ReadLine();
host.Close();
AdhesiveFramework.End();
当然，服务端还需要添加如下程序集的引用：
其中TestService就是服务端实现的程序集，也就是FuckService所在的程序集。
在服务端运行后，需要修改本地Config文件夹下的配置文件来进行最基础的配置：
<?xml version="1.0" encoding="utf-8"?>
<AdhesiveConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<ApplicationName>AdhesiveMongodbServerConsoleHost</ApplicationName>
<LocalLoggingServiceLevel>Debug</LocalLoggingServiceLevel>
<WcfConfigServiceAddress>192.168.129.143:18888/WcfConfigService</WcfConfigServiceAddress>
<ConfigServiceAddress>192.168.129.143:18989/ConfigService</ConfigServiceAddress>
<StateServiceDefaultReportStateIntervalMilliSeconds>10000</StateServiceDefaultReportStateIntervalMilliSeconds>
</AdhesiveConfig>
这也是所有用到Adhesive的程序都需要进行的配置，Adhesive除了这些最最基础的配置之外，其它配置都在配置服务中。
1）应用程序名
2）本地日志服务的记录等级
3）配置服务服务端地址
4）Wcf配置服务服务端地址
5）状态服务默认的汇报时间间隔
最后一步就是编写客户端的代码了，对于客户端程序来说首先需要引用框架必要的程序集，然后就是需要引用服务的客户端程序集（当然对于测试项目你也可以把客户端和服务端放在一个程序集中）。调用方式如下：
private static IMongodbServer service = WcfServiceLocator.GetSafeService<IMongodbServer>();
只需要使用WcfServiceLocator就可以获得服务的实例：
public class WcfServiceLocator { public static T GetService<T>() where T : class { return (T)(new ServiceRealProxy<T>().GetTransparentProxy()); } public static T GetSafeService<T>() where T : class { return (T)(new ServiceRealProxy<T>(true).GetTransparentProxy()); } }
WcfServiceLocator提供了两个获得服务的方法，安全的和非安全的。所谓安全就是即使服务端访问不到，服务不存在也不会出现异常，只会没有结果，客户端不用进行异常捕获。对于非安全的方式，在服务端连不上或服务端调用服务出现异常的时候会出现异常，需要进行异常处理。需要注意的是，对于非安全方式的调用，如果服务在执行过程中出错，那么客户端收到异常的HelpLink中会给出服务端异常的ID，异常ID是通过从服务端传过来的上下文获得的，代码片段：
var exceptionID = ClientApplicationContext.Current.ServerExceptionID ?? ""; exception.HelpLink = "服务端异常Id：" + exceptionID;
