之前工作上偶尔用到WCF，都靠之前的一些知识对付过去了。现在终于下决心要来系统地学习一下。
拿出先前买的O'reilly的"Programming WCF"来读。
第一章对SOA做了个简单的介绍，其实这些概念之前也基本了解的，不过还是浏览一过来加深下印象，结果到也看到不少有趣的地方。
比如书里提到Service的自主性，理论上讲Service除了应该有明确地边界之外，应该还是自主的，不和其它的Service共享数据，需要交互都应该以Message的形式来进行。但是书上也提到，现实中的Service其实对这一条是没办法完全做到。因为业务数据通常是统一存放在一个关系型数据库中的，而其上的Service，例如业务或者报表，必然会共用数据。
于是想到，如果要改变这种状况，必然要把数据的供给也独立成一个Service，而其它的Service都使用这个Service。这里必然要面临的一个问题是性能下降，如果Data Object也要跨边界Serialize和Deserialize，效率应该会有很大的损失。这里，不禁异想天开：既然WCF已经做到Protocol透明，那么是不是也可以封装出一个进程内的，不Serialize的Channel呢？多少有点不切实际吧？
另外，联想到DP Group的Astoria项目已经改名叫ADO.NET Data Service，似乎和我想的这个东西有点类似。突然又联想到自己的工作，是不是给Reporting Services做一个Astoria的data processing extension呢？
拿出先前买的O'reilly的"Programming WCF"来读。
第一章对SOA做了个简单的介绍，其实这些概念之前也基本了解的，不过还是浏览一过来加深下印象，结果到也看到不少有趣的地方。
比如书里提到Service的自主性，理论上讲Service除了应该有明确地边界之外，应该还是自主的，不和其它的Service共享数据，需要交互都应该以Message的形式来进行。但是书上也提到，现实中的Service其实对这一条是没办法完全做到。因为业务数据通常是统一存放在一个关系型数据库中的，而其上的Service，例如业务或者报表，必然会共用数据。
于是想到，如果要改变这种状况，必然要把数据的供给也独立成一个Service，而其它的Service都使用这个Service。这里必然要面临的一个问题是性能下降，如果Data Object也要跨边界Serialize和Deserialize，效率应该会有很大的损失。这里，不禁异想天开：既然WCF已经做到Protocol透明，那么是不是也可以封装出一个进程内的，不Serialize的Channel呢？多少有点不切实际吧？
另外，联想到DP Group的Astoria项目已经改名叫ADO.NET Data Service，似乎和我想的这个东西有点类似。突然又联想到自己的工作，是不是给Reporting Services做一个Astoria的data processing extension呢？
