﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>博客园-Artech-随笔分类-J. WCF</title><link>http://www.cnblogs.com/artech/category/156733.html</link><description>Develop every application as an art using the most suitable technologies!</description><language>zh-cn</language><lastBuildDate>Sun, 05 Jul 2009 12:08:28 GMT</lastBuildDate><pubDate>Sun, 05 Jul 2009 12:08:28 GMT</pubDate><ttl>60</ttl><item><title>[原创] WCF技术剖析之十：调用WCF服务的客户端应该如何进行异常处理</title><link>http://www.cnblogs.com/artech/archive/2009/07/05/1517257.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Sun, 05 Jul 2009 10:33:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2009/07/05/1517257.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1517257.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2009/07/05/1517257.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1517257.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1517257.html</trackback:ping><description><![CDATA[摘要: 在前面一片文章（<a href="http://www.cnblogs.com/artech/archive/2009/07/04/1516908.html">服务代理不能得到及时关闭会有什么后果?</a>）中，我们谈到及时关闭服务代理（Service Proxy）在一个高并发环境下的重要意义，并阐明了其根本原因。但是，是否直接调用ICommunicationObject的Close方法将服务代理关闭就万事大吉了呢？事情远不会这么简单，这其中还会涉及关于异常处理的一些操作，这就是本篇文章需要讨论的话题。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2009/07/05/1517257.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1517257.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创] WCF技术剖析之九：服务代理不能得到及时关闭会有什么后果?</title><link>http://www.cnblogs.com/artech/archive/2009/07/04/1516908.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Sat, 04 Jul 2009 09:58:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2009/07/04/1516908.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1516908.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2009/07/04/1516908.html#Feedback</comments><slash:comments>9</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1516908.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1516908.html</trackback:ping><description><![CDATA[摘要: 我们想对WCF具有一定了解的人都会知道：在客户端通过服务调用进行服务调用过程中，服务代理应该及时关闭。但是如果服务的代理不等得到及时的关闭，到底具有怎样的后果？什么要关闭服务代理？在任何时候都需要关闭服务代理吗？是否有一些例外呢？本篇文章将会围绕着这些问题展开。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2009/07/04/1516908.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1516908.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF技术剖析之八：ClientBase&amp;lt;T&amp;gt;中对ChannelFactory&amp;lt;T&amp;gt;的缓存机制</title><link>http://www.cnblogs.com/artech/archive/2009/07/03/1516573.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Fri, 03 Jul 2009 12:36:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2009/07/03/1516573.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1516573.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2009/07/03/1516573.html#Feedback</comments><slash:comments>9</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1516573.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1516573.html</trackback:ping><description><![CDATA[摘要: 和传统的分布式远程调用一样，WCF的服务调用借助于服务代理（Service Proxy）。而ChannelFactory<T>则是服务代理的创建者。在客户端，我们具有两种典型的服务代理创建方式，其一是通过诸如SvcUtil.exe这样的工具导入服务的元数据生成相应的服务代理（一个继承自ClientBase<T>的类型）代码和相关配置；其二是直接通过相应的终结点信息（通过代码指定或者配置）创建ChannelFactory<T>对象，并借助该对象直接进行服务代理的创建。实际上，即使通过ClientBase<T>对象进行服务调用，其内部也是调用ChannelFactory<T>创建的服务代理。整个ChannelFactory<T>的创建是一项相对复杂并且费时的工作，会涉及很多诸如反射、配置文件的读取等操作。为了提高服务调用的性能，在.NET 3.5中，WCF在ClientBase<T>中引入了ChannelFactory<T>的缓存机制。

&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2009/07/03/1516573.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1516573.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF技术剖析之七：如何实现WCF与EnterLib PIAB、Unity之间的集成</title><link>http://www.cnblogs.com/artech/archive/2009/06/29/1513317.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Mon, 29 Jun 2009 08:03:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2009/06/29/1513317.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1513317.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2009/06/29/1513317.html#Feedback</comments><slash:comments>6</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1513317.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1513317.html</trackback:ping><description><![CDATA[摘要: 在这之前，我写过深入介绍MS EnterLib PIAB的文章（参阅《MS Enterprise Library Policy Injection Application Block 深入解析[总结篇]》），也写过WCF与PIAB的集成（参阅：《WCF后续之旅（8）：通过WCF Extension 实现与MS Enterprise Library Policy Injection Application Block 的集成》）、WCF与Unity的集成（参阅《WCF后续之旅（7）：通过WCF Extension实现和Enterprise Library Unity Container的集成》）以及Unity与PIAB的集成（参阅《Enterprise Library深入解析与灵活应用（1）：通过Unity Extension实现和Policy Injection Application Block的集成》、《Enterprise Library深入解析与灵活应用（7）：再谈PIAB与Unity之间的集成》）。由于部分实现时基于EnterLib、Unity前一个版本，在新的版本中（Ent&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2009/06/29/1513317.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1513317.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创] WCF技术剖析之六：为什么在基于ASP.NET应用寄宿（Hosting）下配置的BaseAddress无效</title><link>http://www.cnblogs.com/artech/archive/2009/06/26/1511916.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Fri, 26 Jun 2009 11:33:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2009/06/26/1511916.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1511916.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2009/06/26/1511916.html#Feedback</comments><slash:comments>12</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1511916.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1511916.html</trackback:ping><description><![CDATA[摘要: 本篇文章来源于几天前一个朋友向我咨询的问题。问题是这样的，他说他采用ASP.NET应用程序的方式对定义的WCF服务进行寄宿（Hosting），并使用配置的方式对服务的BaseAddress进行了设置，但是在创建ServiceHost的时候却抛出InvalidOperationException，并提示相应Address Scheme的BaseAddress找不到。我意识到这可能和WCF中用于判断服务寄宿方式的逻辑有关，于是我让这位朋友将相同的服务寄宿代码和配置迁移到GUI程序或者Console应用中，看看是否正常。结果如我所想，一切正常，个人觉得这应该是WCF的一个Bug。今天撰文与大家讨论，看看大家对这个问题有何见解。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2009/06/26/1511916.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1511916.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF技术剖析之五：利用ASP.NET兼容模式创建支持会话（Session）的WCF服务</title><link>http://www.cnblogs.com/artech/archive/2009/06/25/1511165.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Thu, 25 Jun 2009 10:17:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2009/06/25/1511165.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1511165.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2009/06/25/1511165.html#Feedback</comments><slash:comments>20</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1511165.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1511165.html</trackback:ping><description><![CDATA[摘要: 在《<a href="http://www.cnblogs.com/artech/archive/2009/06/24/1510497.html" >基于IIS的WCF服务寄宿（Hosting）实现揭秘</a>》中，我们谈到在采用基于IIS（或者说基于ASP.NET）的WCF服务寄宿中，具有两种截然不同的运行模式：ASP.NET并行（Side by Side）模式和ASP.NET兼容模式。对于前者，WCF通过HttpModule实现了服务的寄宿，而对于后者，WCF的服务寄宿通过一个HttpHandler实现。只有在ASP.NET兼容模式下，我们熟悉的一些ASP.NET机制才能被我们使用，比如通过HttpContext的请求下下文；基于文件或者Url的授权；HttpModule扩展；身份模拟（Impersonation）等。

由于在ASP.NET兼容模式下，ASP.NET采用与.aspx Page完全一样的方式处理基于.svc的请求，换言之，我们就可以借助当前HttpContext的SessionState维护会话状态，进而创建一个支持会话的WCF Service。接下来，我们就通&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2009/06/25/1511165.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1511165.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF技术剖析之四：基于IIS的WCF服务寄宿（Hosting）实现揭秘</title><link>http://www.cnblogs.com/artech/archive/2009/06/24/1510497.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Wed, 24 Jun 2009 12:33:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2009/06/24/1510497.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1510497.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2009/06/24/1510497.html#Feedback</comments><slash:comments>5</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1510497.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1510497.html</trackback:ping><description><![CDATA[摘要: 通过《<a href="http://www.cnblogs.com/artech/archive/2009/06/20/1507165.html">再谈IIS与ASP.NET管道</a>》的介绍，相信读者已经对IIS和ASP.NET的请求处理管道有了一个大致的了解，在此基础上去理解基于IIS服务寄宿的实现机制就显得相对容易了。概括地说，基于IIS的服务寄宿依赖于两个重要的对象：<b>System.ServiceModel.Activation.HttpModule</b>和<b>System. ServiceModel.Activation.HttpHandler</b>。 &nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2009/06/24/1510497.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1510497.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF技术剖析之三：如何进行基于非HTTP的IIS服务寄宿</title><link>http://www.cnblogs.com/artech/archive/2009/06/21/1507945.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Sun, 21 Jun 2009 14:12:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2009/06/21/1507945.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1507945.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2009/06/21/1507945.html#Feedback</comments><slash:comments>14</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1507945.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1507945.html</trackback:ping><description><![CDATA[摘要: 在<a href="http://www.cnblogs.com/artech/archive/2009/06/20/1507165.html" target="_blank">上面一篇文章中</a>，我们对不同版本的IIS，以及ASP.NET得的实现机制进行了详细而深入的分析。在介绍IIS7.0的时候，我们谈到，HTTP.SYS+W3SVC实现了基于HTTP的请求监听，在此基础上引入了三组网络监听器（Listener）和监听适配器（Adapter），实现了基于TCP、Named Pipes和MSMQ的网络监听。由于IIS 7提供了基于非HTTP网络协议的监听支持，那么就意味着当我们当我们通过IIS进行WCF服务寄宿（Hosting）的时候，可以采用非HTTP的通信方式。在本篇文章中，我们将通过一个简单实例介绍进行非HTTP的IIS服务寄宿，Source Code下载<a href ="http://files.cnblogs.com/artech/WasHostingDemo.zip" target="_blank">WasHostingDemo.zip</a>。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2009/06/21/1507945.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1507945.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF技术剖析之二：再谈IIS与ASP.NET管道</title><link>http://www.cnblogs.com/artech/archive/2009/06/20/1507165.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Fri, 19 Jun 2009 16:19:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2009/06/20/1507165.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1507165.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2009/06/20/1507165.html#Feedback</comments><slash:comments>27</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1507165.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1507165.html</trackback:ping><description><![CDATA[摘要: 在2007年9月份，我曾经写了三篇详细介绍IIS架构和ASP.NET运行时管道的文章，深入介绍了IIS 5.x与IIS 6.0HTTP请求的监听与分发机制，以及ASP.NET运行时管道对HTTP请求的处理流程：
[原创]ASP.NET Process Model之一：IIS 和 ASP.NET ISAPI<br/>
[原创]ASP.NET Process Model之二：ASP.NET Http Runtime Pipeline - Part I<br/>
[原创]ASP.NET Process Model之二：ASP.NET Http Runtime Pipeline - Part II<br/>
很多人留言为何没有IIS 7的介绍。在写作《WCF深入剖析》中，为了剖析基于IIS的WCF服务寄宿（Hosting），再次对相关内容进行了研究，在这里一并与大家分享。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2009/06/20/1507165.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1507165.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF技术剖析之一：通过一个ASP.NET程序模拟WCF基础架构</title><link>http://www.cnblogs.com/artech/archive/2009/06/18/1506163.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Thu, 18 Jun 2009 13:24:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2009/06/18/1506163.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1506163.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2009/06/18/1506163.html#Feedback</comments><slash:comments>63</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1506163.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1506163.html</trackback:ping><description><![CDATA[摘要: 细算起来，已经有好几个月没有真正的写过文章了。近半年以来，一直忙于我的第一本WCF专著《WCF技术剖析》的写作，一直无暇管理自己的 Blog。到目前为止《WCF技术剖析（卷1）》的写作暂告一段落，初步预计于下个月由武汉博文视点出版。在《WCF技术剖析》写作期间，对WCF又有了新的感悟，为此以书名开始本人的第三个WCF系列。本系列的目的在于对《WCF技术剖析》的补充，会对书中的一些内容进行展开讲述，同时会囊括很多由于篇幅的原因忍痛割弃的内容。本系列的第一篇，我将会对WCF的基本架构作一个大致的讲解。不过，一改传统对WCF的工作流程进行平铺直叙，我将另辟蹊径，借助于我们熟悉的ASP.NET作为请求处理平台，通过一个简a单的托管程序模拟整个WCF客户端和服务端的架构。本篇文章的大部分内容节选自《WCF技术剖析（卷1）》第八章。Source Code下载：<a href="http://files.cnblogs.com/artech/Artech.WcfFrameworkSimulator.zip">Artech.WcfFrameworkSimulator.zip</a>&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2009/06/18/1506163.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1506163.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[WCF的Binding模型]之四：信道工厂（Channel Factory）</title><link>http://www.cnblogs.com/artech/archive/2008/12/05/1348618.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Fri, 05 Dec 2008 09:11:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/12/05/1348618.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1348618.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/12/05/1348618.html#Feedback</comments><slash:comments>9</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1348618.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1348618.html</trackback:ping><description><![CDATA[摘要: 由于信道管理器在客户端和服务端所起的不同作用，分为信道监听器和信道工厂。和服务端的信道监听其相比，处于客户端的信道工厂显得简单。从名称就可以看得出来，信道工厂的作用就是单纯的创建用于消息发送的信道。我们先来看看与信道工厂相关的一些接口和基类的定义。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/12/05/1348618.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1348618.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[WCF的Binding模型]之三：信道监听器（Channel Listener）</title><link>http://www.cnblogs.com/artech/archive/2008/11/18/1335773.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Tue, 18 Nov 2008 04:00:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/11/18/1335773.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1335773.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/11/18/1335773.html#Feedback</comments><slash:comments>14</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1335773.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1335773.html</trackback:ping><description><![CDATA[摘要: 信道管理器是信道的创建者，一般来说信道栈的中每个信道对应着一个信道管理器。基于不同的消息处理的功能，将我们需要将相应的信道按照一定的顺序能组织起来构成一个信道栈，由于信道本身是由信道管理器创建的，所以信道对应的信道管理器也构成一个信道管理器栈，栈中信道管理器的顺序决定由它所创建信道的顺序。 对于WCF的信道层来说，信道管理器在服务端和客户端扮演着不同的角色，服务端的信道管理器在于监听来自客户端的请求，而客户端的信道仅仅是单纯的创建用于消息发送的信道。因此，客户端的消息管理器又称为信道监听器（Channel Listener），客户端的信道管理器则成为信道工厂（channel factory）。 

&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/11/18/1335773.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1335773.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[WCF中的Binding模型]之二: 信道与信道栈（Channel and Channel Stack）</title><link>http://www.cnblogs.com/artech/archive/2008/11/14/1333372.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Fri, 14 Nov 2008 03:05:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/11/14/1333372.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1333372.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/11/14/1333372.html#Feedback</comments><slash:comments>4</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1333372.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1333372.html</trackback:ping><description><![CDATA[摘要: WCF采用基于消息交换的通信方式，而绑定则实现了所有的通信细节。绑定通过创建信道栈实现了消息的编码与传输，以及对WS-*协议的实现。在这一节中，我们就来着重介绍WCF中的信道和信道栈。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/11/14/1333372.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1333372.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[WCF中的Binding模型]之一: Binding模型简介</title><link>http://www.cnblogs.com/artech/archive/2008/09/22/1295639.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Mon, 22 Sep 2008 00:53:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/09/22/1295639.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1295639.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/09/22/1295639.html#Feedback</comments><slash:comments>19</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1295639.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1295639.html</trackback:ping><description><![CDATA[摘要: WCF的通信是基于消息的，如果从消息交换（message exchange）的角度讲，信道层则可以看成是进行消息交换参与者之间的中介。信道层通过一个个信道组成一个连续的channel stack，该channel stack构成了一个消息流通的管道。消息的发送者通过该管道流到消息的接收者，消息的接收者对消息进行相应的处理，生成新的消息通过该管道回复给消息的发送者。本文将着重介绍WCF中的Binding模型，从该模型中，读者将会对WCF如何通过Binding创建channel stack的整个过程有一个大致的了解。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/09/22/1295639.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1295639.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅（17）：通过tcpTracer进行消息的路由</title><link>http://www.cnblogs.com/artech/archive/2008/09/19/1294227.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Fri, 19 Sep 2008 07:56:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/09/19/1294227.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1294227.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/09/19/1294227.html#Feedback</comments><slash:comments>18</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1294227.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1294227.html</trackback:ping><description><![CDATA[摘要: 对于希望对WCF的消息交换有一个深层次了解的读者来说，tcpTracer绝对是一个不可多得好工具。我们将tcpTracer置于服务和服务代理之间，tcpTracer会帮助我们接获、显示和转发流经他的消息。 从本质上讲，tcpTracer是一个路由器。当启动的时候，我们需要设置两个端口:原端口（source port）和目的端口（destination port），然后tcpTracer就会在原端口进行网络监听。一旦请求抵达，他会截获整个请求的消息，并将整个消息显示到消息面板上。随后，tcpTracer会将该消息原封不动地转发给目的端口。在另一方面，从目的端口发送给原端口的消息，也同样被tcpTracer截获、显示和转发。 
&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/09/19/1294227.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1294227.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(16): 消息是如何分发到Endpoint的--消息筛选(Message Filter)</title><link>http://www.cnblogs.com/artech/archive/2008/09/18/1293185.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Thu, 18 Sep 2008 03:56:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/09/18/1293185.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1293185.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/09/18/1293185.html#Feedback</comments><slash:comments>12</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1293185.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1293185.html</trackback:ping><description><![CDATA[摘要: 在上一篇介绍<a href="http://www.cnblogs.com/artech/archive/2008/09/18/1292198.html#1320329">逻辑地址和物理地址</a>文章中,我们介绍了终结点的ListenUriMode, 我们提到了两个特殊的对象ChannelDispatcher和ChannelListener。这两个对象在整个WCF的消息分发系统中具有重要的地位，在这节里，我们对WCF的整个消息分发过程作一个简单的介绍。 &nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/09/18/1293185.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1293185.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(15): 逻辑地址和物理地址</title><link>http://www.cnblogs.com/artech/archive/2008/09/17/1292198.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Wed, 17 Sep 2008 01:32:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/09/17/1292198.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1292198.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/09/17/1292198.html#Feedback</comments><slash:comments>11</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1292198.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1292198.html</trackback:ping><description><![CDATA[摘要: 在WCF中，每个终结点都包含两个不同的地址——逻辑地址和物理地址。逻辑地址就是终结点Address属性表示的地址。至于物理地址，对于消息发送放来讲，就是消息被真正发送的目的地址；而对于消息的接收放来讲，就是监听器真正监听的地址...&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/09/17/1292198.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1292198.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅（14）：TCP端口共享</title><link>http://www.cnblogs.com/artech/archive/2008/09/16/1291401.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Tue, 16 Sep 2008 01:23:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/09/16/1291401.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1291401.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/09/16/1291401.html#Feedback</comments><slash:comments>15</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1291401.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1291401.html</trackback:ping><description><![CDATA[摘要: 在一般的网络环境中，尽可能避免网络攻击，都会通过防火墙将绝大部分的端口封掉，仅仅保留那些常用的网络服务所用的端口，或者为某一个类应用保留少量的端口。总而言之，我们不能保证每个跨防火墙通信的应用都具有一个唯一的端口，他们只能共享一个或者少量的几个端口。 无论是基于Intranet还是Internet，无论是采用何种传输协议，端口共享——让多个网络应用程序使用相同的端口进行通信，都具有重要的现实意义。 
对于采用不同的传输协议，我们有不同的解决方案，对于HTTP协议，我们可以通过IIS的寄宿方式实现端口的共享，对于TCP，.NET Framework3.0提供了一个特殊的Windows服务，Net.TCP Port Sharing Service，帮助我们轻松的实现端口的共享。我们接下来就讨论这种端口共享解决方案&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/09/16/1291401.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1291401.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(13): 创建一个简单的WCF SOAP Message拦截、转发工具 - Part I</title><link>http://www.cnblogs.com/artech/archive/2008/09/01/1280939.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Mon, 01 Sep 2008 01:37:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/09/01/1280939.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1280939.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/09/01/1280939.html#Feedback</comments><slash:comments>16</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1280939.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1280939.html</trackback:ping><description><![CDATA[摘要: WCF是.NET平台下实现SOA的一种手段，SOA的一个重要的特征就基于Message的通信方式。从Messaging的角度讲，WCF可以看成是对Message进行发送、传递、接收、基础的工具。对于一个消息交换的过程，很多人只会关注message的最初的发送端和最终的接收端。实际上在很多情况下，在两者之间还存在很多的中间结点（Intermediary），这些中间结点在可能在实际的应用中发挥中重要的作用。比如，我们可以创建路由器（Router）进行消息的转发，甚至是Load Balance；可以创建一个消息拦截器（Interceptor）获取request或者response message，并进行Audit、Logging和Instrumentation。今天我们就我们的目光转向这些充当着中间人角色的Intermediary上面来。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/09/01/1280939.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1280939.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(12): 线程关联性（Thread Affinity）对WCF并发访问的影响</title><link>http://www.cnblogs.com/artech/archive/2008/08/25/1275691.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Mon, 25 Aug 2008 04:45:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/08/25/1275691.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1275691.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/08/25/1275691.html#Feedback</comments><slash:comments>8</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1275691.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1275691.html</trackback:ping><description><![CDATA[摘要: 在本系列的上一篇文章中,我们重点讨论了线程关联性对service和callback的操作执行的影响:在service host的时候，可以设置当前线程的SynchronizationContext，那么在默认情况下，service操作的执行将在该SynchronizationContext下执行（也就将service操作包装成delegate传入SynchronizationContext的Send或者Post方法）.对于Windows Form Application来讲，由于UI Control的操作执行只能在control被创建的线程中被操作，所以一这样的方式实现了自己的SynchronizationContext（WindowsFormsSynchronizationContext）：将所有的操作Marshal到UI线程中。正因为如此，当我们通过Windows Form Application进行WCF service的host的时候，将会对service的并发执行带来非常大的影响。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/08/25/1275691.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1275691.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(11): 关于并发、回调的线程关联性（Thread Affinity）</title><link>http://www.cnblogs.com/artech/archive/2008/08/21/1273021.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Thu, 21 Aug 2008 04:44:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/08/21/1273021.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1273021.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/08/21/1273021.html#Feedback</comments><slash:comments>26</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1273021.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1273021.html</trackback:ping><description><![CDATA[摘要: 对于一般的多线程操作，比如异步地进行基于文件系统的IO操作；异步地调用Web Service；或者是异步地进行数据库访问等等，是和具体的线程无关的。也就是说，对于这些操作，任意创建一个新的线程来执行都是等效的。但是有些情况下，有些操作却只能在固定的线程下执行。比如，在GUI应用下，对控件的访问就需要在创建该控件的线程下执行；或者我们在某个固定的线程中通过TLS（Thread Local Storage）设置了一些Context信息，供具体的操作使用，我们把操作和某个固定的线程的依赖称为线程关联性（Thread Affinity）。在这种情况下，我们的异步操作就需要被Marshal到固定的线程执行。在WCF并发或者Callback的情况下也具有这样的基于线程关联性的问题。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/08/21/1273021.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1273021.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]MS Enterprise Library Policy Injection Application Block 深入解析[总结篇]</title><link>http://www.cnblogs.com/artech/archive/2008/08/08/1263418.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Fri, 08 Aug 2008 01:15:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/08/08/1263418.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1263418.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/08/08/1263418.html#Feedback</comments><slash:comments>10</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1263418.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1263418.html</trackback:ping><description><![CDATA[摘要: Policy Injection Application Block（PIAB）是Enterprise Library众多Application Block中的一个。在我看来，PIAB和后来的Unity Application Block的推出在Enterprise Library的发展历程中具有重要的意思，它标志着Enterprise Library向真正框架上面发展。不再是仅仅关注于某个具体功能实现（比如Logging、Caching、DA、Security等等）。PIAB提供了一种易用的、可扩展的机制是你能够将你需要的Policy应用到对应的目标对象上。PIAB是为你实现AOP提供了又一个不错的选择。对了让读者全面地了解PIAB，能够灵活的使用PIAB为你项目开发服务，我先后写了6篇文章。现在将他们集中在一起，以飨读者。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/08/08/1263418.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1263418.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(10): 通过WCF Extension实现以对象池的方式创建Service Instance</title><link>http://www.cnblogs.com/artech/archive/2008/08/05/1260594.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Tue, 05 Aug 2008 01:00:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/08/05/1260594.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1260594.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/08/05/1260594.html#Feedback</comments><slash:comments>30</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1260594.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1260594.html</trackback:ping><description><![CDATA[摘要: 对于PerCall这种实例化方式来说，为每次service请求都创建新的service instance，有时候显得有点极端，频繁的对象创建会对系统的性能造成一定的影响。我们能够以池的机制进行对象的获取和创建呢：当service调用请求抵达service端，先试图从池中获取一个没有被使用的service instance，如何找到，直接获取该对象；否则创建新的对象。当service instance对象执行完毕，将对象释放到池中以供下次service 调用使用。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/08/05/1260594.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1260594.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(9): 通过WCF双向通信实现Session管理[Part II]</title><link>http://www.cnblogs.com/artech/archive/2008/08/04/1259613.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Mon, 04 Aug 2008 01:53:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/08/04/1259613.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1259613.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/08/04/1259613.html#Feedback</comments><slash:comments>26</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1259613.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1259613.html</trackback:ping><description><![CDATA[摘要: 我们都知道，WCF支持Duplex的消息交换模式，它允许在service的执行过程中实现对client的回调。WCF这种双向通信的方式是我们可以以Event Broker或者订阅/发布的方式来定义和调用WCF Service。今天我们就给大家一个具体的例子：通过WCF的duplex communication方式现在Session管理。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/08/04/1259613.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1259613.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(9)：通过WCF的双向通信实现Session管理[Part I]</title><link>http://www.cnblogs.com/artech/archive/2008/08/04/1259607.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Mon, 04 Aug 2008 01:49:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/08/04/1259607.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1259607.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/08/04/1259607.html#Feedback</comments><slash:comments>22</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1259607.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1259607.html</trackback:ping><description><![CDATA[摘要: 我们都知道，WCF支持Duplex的消息交换模式，它允许在service的执行过程中实现对client的回调。WCF这种双向通信的方式是我们可以以Event Broker或者订阅/发布的方式来定义和调用WCF Service。今天我们就给大家一个具体的例子：通过WCF的duplex communication方式现在Session管理。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/08/04/1259607.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1259607.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅（8）：通过WCF Extension 实现与MS Enterprise Library Policy Injection Application Block 的集成</title><link>http://www.cnblogs.com/artech/archive/2008/07/29/1255258.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Tue, 29 Jul 2008 01:22:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/07/29/1255258.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1255258.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/07/29/1255258.html#Feedback</comments><slash:comments>17</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1255258.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1255258.html</trackback:ping><description><![CDATA[摘要: 在上一篇文章中，我们通过自定义InstanceProvider实现了WCF和微软Enterprise Library Unity Application Block的集成， 今天我们已相同的方式实现WCF与Enterprise Library的另一个Application Block的集成：Policy Injection Application Block (PIAB)。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/07/29/1255258.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1255258.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅（7）：通过WCF Extension实现和Enterprise Library Unity Container的集成</title><link>http://www.cnblogs.com/artech/archive/2008/07/28/1254284.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Mon, 28 Jul 2008 01:15:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/07/28/1254284.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1254284.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/07/28/1254284.html#Feedback</comments><slash:comments>8</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1254284.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1254284.html</trackback:ping><description><![CDATA[摘要: 松耦合、高内聚是我们进行设计的永恒的目标，如何实现这样的目标呢？我们有很多实现的方式和方法，不管这些方式和方法在表现形式上有什么不同，他们的思想都可以表示为：根据稳定性进行关注点的分离或者分解，交互双方依赖于一个稳定的契约，而降低对对方非稳定性因素的依赖。从抽象和稳定性的关系来讲，抽象的程度和稳定程度成正相关关系。由此才有了我们面向抽象编程的说法，所以“只有依赖于不变，才能应万变”... ...&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/07/28/1254284.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1254284.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(6): 通过WCF Extension实现Context信息的传递</title><link>http://www.cnblogs.com/artech/archive/2008/07/24/1250181.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Thu, 24 Jul 2008 01:06:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/07/24/1250181.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1250181.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/07/24/1250181.html#Feedback</comments><slash:comments>16</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1250181.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1250181.html</trackback:ping><description><![CDATA[摘要: 在上一篇文章中，我们讨论了如何通过CallContextInitializer实现Localization的例子，具体的做法是将client端的culture通过SOAP header传到service端，然后通过自定义的CallContextInitializer设置当前方法执行的线程culture。在client端，当前culture信息是通过OperationContext.Current.OutgoingMessageHeaders手工至于SOAP Header中的。实际上，我们可以通过基于WCF的另一个可扩展对象来实现这段逻辑，这个可扩展对象就是MessageInspector。我们今天来讨论MessageInspector应用的另外一个场景：如何通过MessageInspector来传递Context信息。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/07/24/1250181.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1250181.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(5): 通过WCF Extension实现Localization</title><link>http://www.cnblogs.com/artech/archive/2008/07/17/1244878.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Thu, 17 Jul 2008 01:15:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/07/17/1244878.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1244878.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/07/17/1244878.html#Feedback</comments><slash:comments>17</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1244878.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1244878.html</trackback:ping><description><![CDATA[摘要: 在上一篇文章中, 我列出了WCF一系列的可扩展对象和元素，并简单介绍了他们各自的功能、适合的场景和具体解决的问题。从本篇开始我将通过一个个具体的例子来介绍如何利用这些扩展点对WCF进行扩展，从而解决一些我们在实现的项目开发中可能出现的问题。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/07/17/1244878.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1244878.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(4)：WCF Extension Point 概览</title><link>http://www.cnblogs.com/artech/archive/2008/07/16/1243956.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Wed, 16 Jul 2008 01:11:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/07/16/1243956.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1243956.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/07/16/1243956.html#Feedback</comments><slash:comments>13</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1243956.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1243956.html</trackback:ping><description><![CDATA[摘要: 在本系列的每篇文章中，我多次提到WCF是一个极具可扩展性的分布是消息通信框架。为了让读者对WCF Extension有一个总体的的认识，在这里我会简单列举了我们经常使用的绝大部分的扩展点，以及通过这些扩展点能够解决实现项目开发中的那些问题。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/07/16/1243956.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1243956.html?type=1" width = "1" height = "1" />]]></description></item></channel></rss>