﻿<?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-随笔分类-Windows Communication Foundation (WCF) </title><link>http://www.cnblogs.com/artech/category/76626.html</link><description>Develop every application as an art using the most suitable technologies!</description><language>zh-cn</language><lastBuildDate>Fri, 26 Sep 2008 02:57:09 GMT</lastBuildDate><pubDate>Fri, 26 Sep 2008 02:57:09 GMT</pubDate><ttl>60</ttl><item><title>[原创]WCF后续之旅（18）：谈谈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>11</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>9</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>10</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>10</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>12</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后续之旅 [17篇]</title><link>http://www.cnblogs.com/artech/archive/2008/08/26/1276559.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Tue, 26 Aug 2008 04:33:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/08/26/1276559.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1276559.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/08/26/1276559.html#Feedback</comments><slash:comments>20</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1276559.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1276559.html</trackback:ping><description><![CDATA[摘要: 《我的WCF之旅》系列自开篇以来，得到了园子里很多朋友的厚爱，并荣登了博客园2007年度系列博文Top 10。由于工作原因，沉寂了一阵，两个月前开始WCF新的旅程。如果说《我的WCF之旅》主要是对WCF基本原理概括性介绍，而对于这个新的系列，我将和大家分享我对WCF的一些实现机制、设计原理的理解，以及我在实际的项目开发中的一些实践经验（比如在后续的一些文章中，我将介绍通过WCF Extension实现一些在真正的分布式项目开发中很有现实意义的功能）。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/08/26/1276559.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1276559.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>16</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>22</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>9</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>11</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>6</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>14</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>15</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>9</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><item><title>[原创]WCF后续之旅(3): WCF Service Mode Layer 的中枢—Dispatcher</title><link>http://www.cnblogs.com/artech/archive/2008/07/15/1243092.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Tue, 15 Jul 2008 01:14:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/07/15/1243092.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1243092.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/07/15/1243092.html#Feedback</comments><slash:comments>30</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1243092.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1243092.html</trackback:ping><description><![CDATA[摘要: 在本系列的第一部分、第二部分中，我们对WCF的channel layer进行了深入的讨论。我们接下来继续讨论WCF的ser vice mode layer。本篇文章着重介绍service 端的ServiceMode。写作此篇文章旨在达到以下两个目的：
希望读者对ServiceMode有一个大致的了解，结合前面介绍的channel layer的相关知识，帮助读者了解WCF的整个实现机制和执行的流程。 
介绍ServiceMode涉及到的绝大部分extension point，让读者在具体的项目开发中能够根据实际的需要灵活、自由地对WCF进行扩展。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/07/15/1243092.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1243092.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(2): 如何对Channel Layer进行扩展——创建自定义Channel</title><link>http://www.cnblogs.com/artech/archive/2008/07/09/1238626.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Wed, 09 Jul 2008 01:14:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/07/09/1238626.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1238626.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/07/09/1238626.html#Feedback</comments><slash:comments>12</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1238626.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1238626.html</trackback:ping><description><![CDATA[摘要: 在上一篇文章中，我们通过一个直接借助BasicHttpBinding对象实现Client和Server端进行通信的例子，对WCF channel layer进行了一个大致上的介绍。由此引出了一些列通信相关的概念和对象，比如Channel，Output channel， Input channel，Request channel, Reply Channel，Duplex channel， Channel Shape，Channel manager，Channel factory, Channel listener, Binding element 等。通过这些元素，我们很容易地实现对WCF channel layer进行扩展。
在本章节中，我们将继续讨论WCF channel layer。我们将通过如何创建和应用custom channel来介绍channel layer一些知识。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/07/09/1238626.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1238626.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]WCF后续之旅(1): WCF是如何通过Binding进行通信的</title><link>http://www.cnblogs.com/artech/archive/2008/07/08/1237902.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Tue, 08 Jul 2008 01:03:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2008/07/08/1237902.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/1237902.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2008/07/08/1237902.html#Feedback</comments><slash:comments>38</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/1237902.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/1237902.html</trackback:ping><description><![CDATA[摘要: 《我的WCF之旅》系列自开篇以来，得到了园子里很多朋友的厚爱，并荣登了博客园2007年度系列博文Top 10。由于工作原因，沉寂了几个月，今天开始WCF新的旅程。如果说《我的WCF之旅》主要是对WCF基本原理概括性介绍，而对于这个新的系列，我将和大家分享我对WCF的一些实现机制、设计原理的理解，以及我在实际的项目开发中的一些实践经验（比如在后续的一些文章中，我将介绍通过WCF Extension实现一些在真正的分布式项目开发中很有现实意义的功能）。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2008/07/08/1237902.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/1237902.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]谈谈WCF中的Data Contract（4）：WCF Data Contract Versioning</title><link>http://www.cnblogs.com/artech/archive/2007/11/27/974671.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Tue, 27 Nov 2007 13:06:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2007/11/27/974671.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/974671.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2007/11/27/974671.html#Feedback</comments><slash:comments>23</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/974671.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/974671.html</trackback:ping><description><![CDATA[摘要: 软件工程是一门独特的工程艺术，需要解决的是不断改变的需求变化。而对于WCF，对于SOA，由于涉及的是对多个系统之间的交互问题，如何有效地解决不断改变的需求所带来的问题就显得更为重要：Service端版本的变化能否保持现有Consumer的正常调用，Consumer端的改变不至于影响对Service 的正常调用。对于Data Contract来说就是要解决这样的问题：Service端或者Client对Data Type的改变不会影响Service的正常调用。<br><br>在系统开发过程中，通过对Data Type添加额外的字段进而对其进行扩展，是一个种很常见的场景。本部分就作中介绍Data Contract的这种变化，Service或者Client的Data Contract在本地添加一个新的Data Member会造成怎样的影响，WCF可以采用怎样的机制来解决这种单方面Data Contract版本的改变。<br>&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2007/11/27/974671.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/974671.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]谈谈WCF中的Data Contract（3）：WCF Data Contract对Collection &amp; Dictionary的支持</title><link>http://www.cnblogs.com/artech/archive/2007/11/27/974665.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Tue, 27 Nov 2007 12:55:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2007/11/27/974665.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/974665.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2007/11/27/974665.html#Feedback</comments><slash:comments>9</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/974665.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/974665.html</trackback:ping><description><![CDATA[摘要: 在本篇文章上一部分Order Processing的例子中，我们看到原本已Collection形式定义的DetailList属性（public IList<TDetail> DetailList），在Data Contract中却以Array的方式体现（public OrderDetail[] DetailList）。我们现在就来详细地讨论一下基于Collection & Dictionary 的Data Contract。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2007/11/27/974665.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/974665.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]谈谈WCF中的Data Contract（2）：WCF Data Contract对Generic的支持</title><link>http://www.cnblogs.com/artech/archive/2007/11/27/974639.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Tue, 27 Nov 2007 12:43:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2007/11/27/974639.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/974639.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2007/11/27/974639.html#Feedback</comments><slash:comments>16</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/974639.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/974639.html</trackback:ping><description><![CDATA[摘要: 通过第一部分的介绍，我们可以体会到，WCF 的Data Contract在CLR Type和Neutral Contract之间搭建了一座桥梁，弥合了.NET世界和厂商中立世界的差异。通过WCF Data Contract我们将CLR Data Type暴露成一个厂商中立的数据结构的描述，同样通过WCF Data Contract我们将一个现有的CLR Data Type和既定的Neutral contract进行适配。<br><br>在.NET中，基于Primary Type，比如Int32，String等等，他们具有一个简单的默认的序列化方式和结构，可以说他们不需要Data Contract。接下来我们主要讨论的是一些相对比较特殊的、完全基于.NET的Data Type，比如Generic、Collection，和Dictionary。首先，我们结合例子来谈谈基于Generic的Data Type的Data Contract。<br>&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2007/11/27/974639.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/974639.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]谈谈WCF中的Data Contract （1）：Data Contract Overview</title><link>http://www.cnblogs.com/artech/archive/2007/11/27/974627.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Tue, 27 Nov 2007 12:32:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2007/11/27/974627.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/974627.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2007/11/27/974627.html#Feedback</comments><slash:comments>13</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/974627.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/974627.html</trackback:ping><description><![CDATA[摘要: SOA一个主要的目标就是促进不同技术平台的互操作，要真正实现这样一个宏伟的目标是一件极不容易的事情，需要不同的厂商和标准组织相互协作，制定一个大家一致遵循的标准。这样一个标准就是WS-* 。我们很清楚，无论个个厂商各自的标准怎样千差万别，但是有个标准是他们必须要遵循的，那就是Internet的标准，如果哪家公司拒绝Internet，那肯定要被淘汰的。而对于Internet，基于Http的网络协议和基于XML的数据表达已经成为了事实上的标准。对于SOA来说，XML不仅仅用于表示Service调用携带的数据（参数和返回值），更用于表示这个调用本身，以及满足各种要求的控制信息, 比如基于Security、Session、Reliable Messaging、Transaction等等的控制信息。WS-*就是一个基于XML的标准。而对于SOA中的Contract所要做的就是寻求一种厂商中立的方式来表示Service的接口、和用于交互的数据结构。前者就是Service Contract、后者就是Data Contract。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2007/11/27/974627.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/974627.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]"我的WCF之旅"系列阶段性总结</title><link>http://www.cnblogs.com/artech/archive/2007/09/15/893838.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Sat, 15 Sep 2007 05:01:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2007/09/15/893838.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/893838.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2007/09/15/893838.html#Feedback</comments><slash:comments>61</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/893838.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/893838.html</trackback:ping><description><![CDATA[摘要: WCF是构建和运行Connected System的一些列技术的总称，它是建立在Web Service Architecture上的一个全新的Communication Infrastructure。你可以把它看成是.NET平台上的新一代的Web Service。WCF为我们提供了Secure & Reliable的Messaging，也为我们提供了更好的Interoperability是的我们可以和其他的平台进行互操作。
在过去半年之后，我陆陆续续写了一些关于WCF介绍的一些文章，我把它命名为“我的WCF之旅”，目的在于向大家分享我学习WCF这一段旅程。现在把把这个系列做一个阶段性的总结，以飨读者。这个总结并不是意味着我将结束这个系列，这个系列还会继续，新加的内容我会补上。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2007/09/15/893838.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/893838.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]我的WCF之旅(13)：创建基于MSMQ的Responsive Service</title><link>http://www.cnblogs.com/artech/archive/2007/07/01/802069.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Sun, 01 Jul 2007 08:06:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2007/07/01/802069.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/802069.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2007/07/01/802069.html#Feedback</comments><slash:comments>36</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/802069.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/802069.html</trackback:ping><description><![CDATA[摘要: 我们知道MSMQ天生就具有异步的特性，它只能以One-way的MEP（Message Exchange Pattern）进行通信。Client和Service之间采用One-way MEP的话就意味着Client调用Service之后立即返回，它无法获得Service的执行结果，也无法捕捉Service运行的Exception。<br>但是在有些场景 中，这是无法容忍的。再拿我在上一篇文章的Order Delivery的例子来说。Client向Service提交了Order，却无法确认该Order是否被Service正确处理，这显然是不能接受的。我们今天就来讨论一下，如何创建一个Responsive Service来解决这个问题：Client不再是对Service的执行情况一无所知，它可以获知Order是否被Service正确处理了。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2007/07/01/802069.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/802069.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]我的WCF之旅（12）：使用MSMQ进行Reliable Messaging</title><link>http://www.cnblogs.com/artech/archive/2007/06/29/799529.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Thu, 28 Jun 2007 16:57:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2007/06/29/799529.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/799529.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2007/06/29/799529.html#Feedback</comments><slash:comments>26</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/799529.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/799529.html</trackback:ping><description><![CDATA[摘要: 在一个分布式的环境中，我们往往需要根据具体的情况采用不同的方式进行数据的传输。比如在一个Intranet内，我们一般通过TCP进行高效的数据通信；而在一个Internet的环境中，我们则通常使用Http进行跨平台的数据交换。而这些通信方式具有一个显著的特点，那就是他们是基于Connection的，也就是说，交互双方在进行通信的时候必须保证有一个可用的Connection存在于他们之间。而在某些时候，比如那些使用拨号连接的用户、以及使用便携式计算机的用户，我们不能保证在他们和需要访问的Server之间有一个的可靠的连接，在这种情况下，基于Messaging Queue的连接就显得尤为重要了。我们今天就来谈谈在WCF中如何使用MSMQ。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2007/06/29/799529.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/799529.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]我的WCF之旅 (11): 再谈WCF的双向通讯-基于Http的双向通讯 V.S. 基于TCP的双向通讯</title><link>http://www.cnblogs.com/artech/archive/2007/06/18/788071.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Mon, 18 Jun 2007 10:32:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2007/06/18/788071.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/788071.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2007/06/18/788071.html#Feedback</comments><slash:comments>56</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/788071.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/788071.html</trackback:ping><description><![CDATA[摘要: 在一个基于面向服务的分布式环境中，借助一个标准的、平台无关的Communication Infrastructure，各个Service通过SOAP Message实现相互之间的交互。这个交互的过程实际上就是Message Exchange的过程。WCF支持不同形式的Message Exchange，我们把这称之为Message Exchange Pattern（MEP）, 常见的MEP包括: Request/Reply，Request/Forget（One-way）和Duplex。通过采用Duplex MEP，我们可以实现在Service端Callback Client的操作。虽然WCF为我们实现底层的通信细节，使得我们把精力转移到业务逻辑的实现，进行Transport无关的编程，但是对底层Transport的理解有利于我们根据所处的具体环境选择一个合适的Transport。说到Transport， WCF 经常使用的是以下4个：Http，TCP，Named Pipe，MSMQ。由于不同协议自身的差异，他们对具体MEP的支持方式也会不同，我们今天就来谈谈Http和TCP对Duplex&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2007/06/18/788071.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/788071.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]我的WCF之旅（10）：如何在WCF进行Exception Handling</title><link>http://www.cnblogs.com/artech/archive/2007/06/15/784090.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Thu, 14 Jun 2007 18:18:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2007/06/15/784090.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/784090.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2007/06/15/784090.html#Feedback</comments><slash:comments>19</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/784090.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/784090.html</trackback:ping><description><![CDATA[摘要: 在任何Application的开发中，对不可预知的异常进行troubleshooting时，异常处理显得尤为重要。对于一般的.NET系统来说，我们简单地借助try/catch可以很容易地实现这一功能。但是对于 一个分布式的环境来说，异常处理就没有那么简单了。按照面向服务的原则，我们把一些可复用的业务逻辑以Service的形式实现，各个Service处于一个自治的环境中，一个Service需要和另一个Service进行交互，只需要获得该Service的描述（Description）就可以了（比如WSDL，Schema和Strategy）。借助标准的、平台无关的通信构架，各个Service之间通过标准的Soap Message进行交互。Service Description、Standard Communication Infrastructure、Soap Message based Communication促使各Service以松耦合的方式结合在一起。但是由于各个Service是自治的，如果一个Service调用另一个Service，在服务提供方抛出的Exception必须被封装在S&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2007/06/15/784090.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/784090.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]我的WCF之旅（9）：如何在WCF中使用tcpTrace来进行Soap Trace</title><link>http://www.cnblogs.com/artech/archive/2007/06/14/782845.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Wed, 13 Jun 2007 16:19:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2007/06/14/782845.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/782845.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2007/06/14/782845.html#Feedback</comments><slash:comments>30</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/782845.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/782845.html</trackback:ping><description><![CDATA[摘要: 无论对于Web Service还是WCF，Client和Service之间交互的唯一形式是通过发送和接收Soap Message。在我们对Web Service和WCF进行深入学习的时候，借助一些Soap Trace 工具对Soap Message进行深入剖析是非常有必要的。在这些工具之中，我觉得最好用的就是Microsoft Soap Toolkit中的Soap Trace Utility和tcpTrace。我们今天就来讲讲如何在WCF中使用tcpTrace这个工具。&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2007/06/14/782845.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/782845.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]我的WCF之旅（8）：WCF中的Session和Instancing Management</title><link>http://www.cnblogs.com/artech/archive/2007/06/13/781216.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Tue, 12 Jun 2007 17:59:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2007/06/13/781216.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/781216.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2007/06/13/781216.html#Feedback</comments><slash:comments>32</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/781216.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/781216.html</trackback:ping><description><![CDATA[摘要: 我们知道，WCF是MS基于SOA建立的一套在分布式环境中各个相对独立的Application进行Communication的构架。他实现了最新的基于WS-*规范。按照SOA的原则，相对独自的业务逻辑以service的形式封装，调用者通过Messaging的方式调用Service。对于承载着某个业务功能的实现的Service应该具有Context无关性、甚至是Solution无关性，Service才能实现最大限度的重用。<br>在一个C/S（Client/Service）场景中，Context无关性体现在Client对Service的每次调用都是完全不相关的。但是在有些情况下，我们却希望系统为我们创建一个Session来保留某个Client和Service的进行交互的状态。所以，像Web Service一样，WCF也提供了对Session的支持。对于WCF来说，Client和Service之间的交互都通过Soap Message来实现的，每次交互的过程就是一次简单的Message Exchange。所以从Messaging的角度来讲，WCF的Session就是把某个把相关的Messag&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2007/06/13/781216.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/781216.html?type=1" width = "1" height = "1" />]]></description></item><item><title>[原创]我的WCF之旅（7）：面向服务架构（SOA）和面向对象编程（OOP）的结合——如何实现Service Contract的继承</title><link>http://www.cnblogs.com/artech/archive/2007/04/11/708510.html</link><dc:creator>Artech</dc:creator><author>Artech</author><pubDate>Wed, 11 Apr 2007 03:12:00 GMT</pubDate><guid>http://www.cnblogs.com/artech/archive/2007/04/11/708510.html</guid><wfw:comment>http://www.cnblogs.com/artech/comments/708510.html</wfw:comment><comments>http://www.cnblogs.com/artech/archive/2007/04/11/708510.html#Feedback</comments><slash:comments>44</slash:comments><wfw:commentRss>http://www.cnblogs.com/artech/comments/commentRss/708510.html</wfw:commentRss><trackback:ping>http://www.cnblogs.com/artech/services/trackbacks/708510.html</trackback:ping><description><![CDATA[摘要: 当今的IT领域，SOA已经成为了一个非常时髦的词，对SOA风靡的程度已经让很多人对SOA，对面向服务产生误解。其中很大一部分人甚至认为面向服务将是面向对象的终结，现在的面向对象将会被面向服务完全代替。在开始本Blog之前，我先来谈谈我对SOA和OO的区别......<br>OO和SO之间具有共同的部分，在运用的领域上存在交集，只有在基于他们交集层面上谈论谁是谁非才有意义......<br>&nbsp;&nbsp;<a href='http://www.cnblogs.com/artech/archive/2007/04/11/708510.html'>阅读全文</a><img src ="http://www.cnblogs.com/artech/aggbug/708510.html?type=1" width = "1" height = "1" />]]></description></item></channel></rss>