博客园_彭成东

Adventure Works示例数据库介绍

2010-10-15T03:05:00Z

SQL Server 2005中引入了一个新的示例数据库AdventureWorks，这个数据库围绕着一个虚拟企业Adventure Works Cycles的商业数据应用，展现SQL Server 2005的功能、特性与数据库的结构设计。在SQL Server 2005的在线帮助和其它大量的技术资料中都引用了这个数据库中的内容。了解这个示例数据库的结构和对应的商业应用环境对于学习、研究和应用SQL Server 2005会有很大的帮助。

视频讲解地址https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032321320&EventCategory=3&culture=zh-CN&CountryCode=CN

在这次课程中将为听众系统地介绍AdventureWorks数据库和对应Adventure Works Cycles商业数据的组织。

ms-help://MS.MSDNQTR.v80.chs/MS.MSDN.v80/MS.SQL.v2005.chs/advwks9/html/fc98c380-518f-4e5e-8cde-14669aca308f.htm

本文链接

基于 SOA 的监测、诊断与预测系统架构

2010-10-12T08:34:00Z

1 概述
   软件设计经历 3 个阶段：基于过程(process-oriented)，基于对象(object-oriented)和基于组件(component-oriented)。在过去20 年里，这些远程过程调用(Remote Procedure Call)，
如分布式组件对象模型(Distributed Component Object Model)和通用对象请求代理体系结构(Common Object Request BrokerArchitecture)等，在许多领域取得较大成功[1-5]。
在设备故障诊断领域，研究者主要利用这些技术来开发状态监测和故障诊断系统实现对重要企业重要设备维修和维护，如风机、轴、蒸汽轮机、水力发电机等。然而，如果企业级系统功能繁多，
企业内部程序的开发平台、编程语言等很可能各不相同，要在企业内部实现诸多功能的整合是非常困难的事情。同时还需要考虑到系统的安全性、扩展性等方面的要求。
基于以往设计方法的诊断系统存在着重用性差、异构平台调用困难、互操作性差、紧耦合等诸多缺陷。要实现易于扩展的、功能可柔性组合、跨异构平台的企业级设备状态监测与故障诊断系统，
基于以往的设计方法已无法满足这样的要求。随着 IT 技术的发展，为解决异构性、互操作性以及软件系统不断改变的要求所带来的系列问题，面向服务架构(Service-Oriented Architecture, SOA)的研究已逐年深入并获得应用，
将SOA 及其相关技术引入机械设备的状态监测与故障诊断系统应用开发领域都具有重要意义。本文介绍基于SOA 的状态监测与预测系统的架构设计，并应用WCF 技术对预测模型加以实现并验证。
2 基于 SOA 的设备诊断和预测系统体系架构
   目前，各个企业使用自身的故障诊断系统实现对机器设备的监测和故障诊断，有一定的局限性。企业的知识库、规则库有限，可能无法对各种设备故障进行及时诊断。如果各个企业和科研院所都将相关的知识库、方法库等商业逻辑通过SOA 技术发布为服务，
那么企业就可以充分利用网络资源来实现机械设备的远程故障诊断，这能够大大提高效率，减少成本，并实现诊断资源共享的目的。将SOA 技术引入机械设备远程故障诊断领域，将在很大程度上提高故障诊断的准确性。
在分布式故障诊断系统中，应用SOA 技术能够更好地解决原有系统中的跨平台和跨防火墙等问题，并且很好地改善系统的可扩展性和伸缩性。SOA 的引入使得整个联合故障诊断系统体现松耦合、开放等特点，这就能随时允许故障诊断服务的加入或退出，
解决了以往无法在异构平台间共享数据和服务的问题，提高网络诊断资源的利用率。面向服务框架(Service-Oriented Framework Architecture,SOFA)是整个基于SOA 状态监测和预测系统体系结构中的核心，
它主要实现业务服务(Business Service)和业务处理逻辑(Business Process Logic)，为智能客户端(Smart Client)提供服务。SOFA 分为基础业务服务层、业务服务总线以及业务处理层。
基础业务服务层包括很多细粒度的服务，如特征提取、诊断算法、数据分析算法、数据实时存储、权限设定、报表、设备各种管理等。这些服务被包装成单个服务或者根据复杂性对几个细粒度的服务进行合成形成一个粗粒度服务。
最终，这些服务被继承到业务服务总线上成为面向业务的服务。为便于对业务进行访问，将基础业务层主要分为 4 种业务服务总线：权限验证，数据访问，诊断分析和文档报表服务。每个业务服务总线都是由若干个细粒度的服务集成的，
因此，每个业务服务总线都包含了多个面向消费者的、独立于底层组件的粗粒度服务。这样做的好处在于有利于实现独立于组件的业务，当需求变化时只需要调整服务而不用修改底层细粒度服务。利用业务服务总线更具有实际意义的是：
能够支持跨平台的不同服务组件之间的基本交互，还将异构平台间的基础结构功能整合为一体。
3 基于 SOA 的设备诊断和预测系统的实现
3.1 远程数据采集
   数据采集是系统的主要信息来源，一般情况下，数据采集位于工业现场，距离企业监测中心比较远。因此，为便于对数据采集系统进行操作，用WCF 技术实现对采集系统的远程监控，企业工程师可以在监测中心非常容易地实现远程启动、停止采集和实时获取等功能。
由于是基于面向服务的，因此客户端可通过配置服务的绑定(Binding)，实现安全可靠的消息传输，以达到对数据采集子系统进行管理的目的。这也是SOA 技术在远程故障诊断系统中的应用之一。程序(数据层)的各个逻辑功能以服务的形式发布，完全符合SOA 的概念，有利于整个系统的扩展和伸缩性。
3.2 故障诊断和趋势预测
   近年来，设备维护逐渐从事后维护到预防性维护，一直转变到现在的状态维护。状态维护主要侧重于设备的智能诊断和趋势预测，能够在事发之前给维护人员提供可靠的维护依据，制定维修计划，这样可以避免意外停机，减少停机次数，提高生产效率，减小维修成本。
基于上述特点，设备监测需要不间断进行并且能够给出设备的状态变化情况及运行趋势。关于故障诊断方面的系统应用很多，这里不再赘述，本系统采用多种模型对设备的运行趋势进行预测，并结合监测指标的报警阈值，
对设备的剩余寿命进行估算，本系统中采用的预测算法主要包括支持向量机(Support VectorMachine, SVM)[6]和神经网络(neural network)[7]等。下面给出用WCF 技术实现SVM 预测模型的具体方法。
4 结束语
   本文将 SOA 引入到设备的状态监测、故障诊断和趋势预测领域中，并提出基于SOA 的状态监测和预测系统的架构模型，实现不同软件平台的资源共享、降低系统间的耦合性、增加系统的可扩展性和伸缩性，因此，减少了开发时间。
本文在企业网内实现了基于SOA 的状态监测、故障诊断和趋势预测系统，如服务的发布和消费，并将该系统应用到企业现场中。但实现真正意义上的基于SOA 的远程分布式故障诊断系统，还需要做很多工作，尤其是安全性问题(跨企业网的安全问题)、部署、异构平台的解耦、记账和收费问题等。
基于 WCF 的数据采集，它是作为服务的提供者存在的，它将与数据采集相关的服务发布出来由监控端进行调用，从而达到监视实时数据、控制数据采集系统的目的。如果每台数据采集系统都将其服务发布到企业网内，可以通过一台监控机完成对多台数据采集机器监控，
有利于管理，从企业级设备监测和故障诊断系统的架构上看，好处在于将数据采集

本文链接

基于SOA的设备智能维护系统架构设计及实现

2010-10-12T08:28:00Z

基于SOA的设备智能维护系统架构设计及实现
发表时间：2009-9-19 朱义 陈进 刘雨 肖文斌来源：万方数据
关键字：SOA WCF 智能维护系统

结合面向服务架构(SOA)的技术特点及设备智能维护系统的应用需求，提出基于面向服务的设备智能维护系统的体系结构，该架构与传统软件架构相比具有松耦合、可扩展、服务的柔性组合等诸多优点。在．NET平台用面向服务的分布式编程模型WCF(Windows Communication Foundation)进行系统开发，用实际项目验证了该体系的有效性，指出SOA在开发设备智能维护系统的开发与应用中的重要价值。
    0 引言
    传统的设备维护是一种基于被动的维修模式FAF(Fail andFix)，已经不能完全满足保障设备正常、高效和安全运行的需求。智能维护是一种新兴的设备维护概念，是一种基于主动的维护模式PAP(Predict and Prevent)。它通过对设备性能的退化评估和预测，避免了传统维护方法的盲目性。要实现智能维护不仅包括理论算法的研究，也包括合适的系统平台的搭建。针对智能维护系统的研究近年来受到学术界和产业界越来越多的关注。
    由于智能维护系统包括特征提取、监测诊断、评估预测、维护决策等各种功能，每一种功能又有大量的方法可供选择，故分布式、松耦合、可柔性组合等特性对智能维护系统有着重要意义。目前DCOM、CORBA等面向对象的组件技术已广泛地应用于分布式系统的开发中。，然而这些方法存在重用性差、异构平台调用困难、互操作性差、紧耦合等诸多缺陷。
    近年来提出的面向服务架构(SOA)为解决上述问题提供了可行性。本文结合面向服务架构(SOA)及智能维护系统的特点，提出了一种基于SOA的智能维护系统体系结构，并用面向服务的编程模型WCF做了相关的开发，通过实例验证了该体系结构的可行性与有效性，指出了SOA在智能维护系统中的重要应用价值。
    1 面向服务架构(SOA)
    1．1 SOA的基本概念
    SOA是一种架构模型，在1996年由Gartner公司首次提出，它将应用程序不同功能单元(服务)通过定义良好的契约和策略联系起来，具有松耦合性、互操作性、开发迅捷、异构平台资源共享等明显优势。SOA的定义目前尚未完全统一，但其核心思想都是“面向服务”。
    在一个SOA体系有下列三个角色：服务提供者、服务注册中心及服务请求者，分别担任发布、查找和绑定任务。其关系如图1所示。
    图1实现SOA的各个角色的关系
    1．2基于SOA的典型体系结构视图
    典型的SOA体系结构如图2所示，显示了三种体系结构视图：1)应用程序体系结构：这是一种面向业务的解决方案，消费服务来自于一个或多个提供者，并将它们集成到业务处理过程中。2)服务体系结构：这为实现和消费应用程序之间提供了一个桥梁，创建了服务集的一个逻辑视图，我们可以使用这些服务，通过通用的接口和管理体系结构来调用它们。3)组件体系结构：实现了具体的功能、应用程序、业务对象等。
    图2三种体系结构视图
    2 基于SOA的智能维护系统架构
    智能维护系统是一种采用性能衰退分析和预测方法，对设备进行实时的监测诊断和性能的退化评估，并作出相应维护决策的系统。具体来说，智能维护系统集数据采集、状态监测、故障诊断、性能评估及维护决策等于一体，并辅以用户管理、权限验证、文档报表管理等系统管理模块，是一个复杂的应用程序。
    为构建功能可柔性组合的、易于扩展的、互操作性强的企业级应用程序，在图2体系结构的基础上，结合智能维护系统的需要，提出图3所示的基于SOA的智能维护系统架构图。该架构由下而上分别是数据层、基础业务服务层、业务服务总线、业务处理层和表现层，以下是对它们的详细说明。
    图3基于SOA的智能维护系统体系结构视

1)数据层，该层主要包括各类数据库及数据文件。其中数据库分为知识数据库、方法数据库、波形数据库、管理数据库等。知识和方法数据库为企业级设备维护提供规则和经验；波形数据库用于存储实时波形、历史波形及分析结果；管理数据库存储用户信息、配置文件等。

2)基础业务服务层，该层中包含诸多细粒度的基础服务，如数据库访问，权限验证，文档管理，特征提取，常用算法等。这些服务可以是包装为服务的组件，也可以是单个服务，并最终全部整合发布到业务服务总线上。
    3)业务服务总线，结合智能维护系统的业务逻辑，整合基础业务服务层上的各细粒度服务，形成了权限管理、数据访问、设备维护、文档报表等四条业务总线。每个业务服务总线都包含了多个面向消费者的、独立于底层组件的粗粒度业务服务。这样有利于实现独立于组件的业务，在需求更改时可以整合和调整服务而不用修改底层组件。
    4)业务处理层，该层根据表示层中客户端的消息请求，通过调用业务服务总线上的不同服务完成特定的业务流程，并最终返回结果给客户端。共包含系统管理服务，企业级设备维护服务及远程维护代理，如图4所示。其中企业级设备维护服务主要通过调用企业局域网内部发布的各类监测、诊断、评估、预测、决策及执行等服务完成相关的设备维护功能；远程维护代理则通过服务注册中心查询广域网中远程维护中心所提供的各类设备维护服务，调用其中合适的完成相关分析，并将分析结构返回给客户端。
    图4业务服务层结构视图
    5)表现层，该层首先通过U1处理模块，该模块主要作用是管理一些固定化的U1逻辑，并根据各种状态选择前端的用户界面视图。当用户登录，U1处理模块将对用户信息进行验证，并加载用户配置文件，通过用户配置文件决定该用户能浏览和使用哪些界面视图。
    3 系统实现
    本文依托“大型变频鼓风机故障预测与维护技术研究”项目(国家863计划)，基于．NET Framework3．0平台进行某风机智能维护系统的开发。该系统使用SOA的实现技术之一——WCF编程模型，把各类不同的服务部署在网络上，由客户端按需要调用，完成对风机智能维护。整个系统体现了可柔性组合、易于扩展、松耦合等优点。
    以下介绍WCF技术的基本理念，并以智能维护系统的核心模块——性能退化评估子系统为例，具体阐述WCF服务的实现、发布及消费。
    3．1 WCF技术
    WCF是SOA的实现技术之一，它将现有整套．NET分布式技术(如：.Net Remoting、ASMX、WSE和MSMQ等)整合为一个编程模型，通过稳定的结构、极大改进的功能性和互操作性以及良好的扩展性，全面改善了编程模式。
    本质上，WCF是完全面向服务的，它是真正的面向服务的编程模型。服务可以根据安全性、传输协议等需要发布为多个端点，每个端点由地址、合同和绑定三要素构成。地址指定了发送消息的目标位置，合同描述消息所包含的内容，绑定描述如何发送消息。客户端通过对这三要素的配置即可实现对服务的访问，而不用关心服务内部是如何实现的，如图5(其中A、C、B分别代表Address、Contract和Binding)所示。因此，利用WCF技术可以很方便的满足智能维护系统远程、分布式的需要。
    图5 服务和端点
    3．2性能退化评估子系统
    性能退化评估子系统是智能维护系统的核心模块之一。这里以基于SVDD(支持向量数据描述)坤。方法的性能退化评估服务为例。该方法通过训练正常数据以建立包络面，计算待评估数据与包络面的广义距离并将其归一化作为性能退化评估指标。
    (1)服务的实现与发布
    SVDD算法复杂，这里使用matlab6．5的COM组件技术把SVDD的性能退化评估matlab算法包打包为动态连接库(dll)，应用WCF技术在服务器端将打包的dll包装为服务，并用IIS承载的方式把服务端点发布到网上。
    首先在工程中引用System．ServiceModel创建服务接口。该接口定义了退化评估的各个方法，但并不实现。使用[Service．Contract]和[OperationContract]修饰接口和接口中定义的方法，以表明该接口和方法要作为服务的合同发布。如下申明了接口ISvdd及它的两个方法Train和Assess(省略了具体参数)。
    图6发布的WCF服务
(2)服务的消费
    客户端按SVDD服务的发布地址添加对SVDD的服务引用，命名为SVDDProxy，此时在客户端会自动从服务器端获取服务的端点信息，并生成一个app．config配置文件(如图7所示)。
    性能退化评估子系统的主界面如图8所示。其中的性能评估曲线模拟了风机某测点处发生转子不平衡且不平衡量逐渐加大时，风机整体性能也随之下降的情况。
    图8性能退化评估主界面
    4 结束语
    本文提出了一种基于SOA的智能维护系统的体系结构，并在．NET Framework3．0平台基于面向服务的分布式编程模型WCF进行系统开发，对该体系结构进行了初步的验证与实现，将SOA成功地应用到了实际项目中。
    与传统的基于组件的分布式编程技术相比，基于SOA的体系结构有着松耦合性、互操作性、可柔性组合、易于扩展、异构平台资源共享等诸多优势，因此，SOA在智能维护系统的研究中有广阔的应用前景。为了使系统更加完善，今后将重点进行SOA中远程维护中心之间的协作模式等研究。
http://articles.e-works.net.cn/SOA/Article71462_2.htm

本文链接

WCF基础知识问与答（转载）

2010-10-12T07:42:00Z

http://www.cnblogs.com/wayfarer/archive/2008/04/15/1153775.html 张逸:晴窗笔记

学习WCF已有近两年的时间，其间又翻译了Juval的大作《Programming WCF Services》，我仍然觉得WCF还有更多的内容值得探索与挖掘。学得越多，反而越发觉得自己所知太少，直到现在，我也认为自己不过是初窥WCF的门径而已。

“学以致用”，如果仅仅是希望能够在项目中合理地应用WCF，那么对于程序员而言，可以有两种选择，一种是“知其然而不知其所以然”，只要掌握了WCF的基础知识，那么对于一般的应用就足够了。要做到这一点就很容易了，微软秉承了一贯的方式，将WCF这门技术优雅地呈现给开发者，封装了复杂的实现逻辑，提供了易于调用的类库和相关的工具，使得开发者能够快速地完成WCF程序的开发。另外一种方式自然就是深度挖掘WCF的内部实现了，这是对WCF专家提出的要求。如果我们要应用WCF实现SOA解决方案，就会遭遇许多WCF的高级应用，如何合理、有效地应用WCF，并根据项目实际情况对WCF进行扩展，就成为了WCF专家必须解决的难题。

因此，如果要学习WCF，你必须找准自己学习的动机与目标，然后合理地安排自己的学习进度表，这才是正确的学习方式。本文试图对WCF的一些基础概念作一些试探性的阐述与分析，并以问答的方式组织，希望能够部分解答一些希望学习WCF，但犹自徘徊在门外的开发者。

1、WCF是什么？

从WCF所处的位置来看，它是包含在.NET 3.0（也包括.NET 3.5）之中的。我们注意比较.NET 3.0与.NET 2.0，其实唯一的区别就是.NET 3.0包含了WCF、WPF、WF（或者还有CardSpace）而已。因此，我们认为WCF是.NET框架的一部分，似乎并不为过。尤为关键的是，WCF并不能脱离.NET框架而单独存在（但非WCF客户端可以调用WCF服务），因此，虽然WCF是微软用以应对SOA解决方案的开发需求而专门推出的，但它并不是例如Spring、Struts那样的框架，也不是像EJB那样的容器或者服务器。微软真正符合SOA企业应用服务器角色的，我想应该是Biztalk Server。

严格的说，WCF就是专门用于服务定制、发布与运行以及消息传递和处理的一组专门类的集合，也就是所谓的“类库”。这些类通过一定方式被组织起来，共同协作，并为开发者提供了一个统一的编程模式。WCF之所以特殊，是在于它所应对的场景与普通的.NET类库不同，它主要用于处理进程间乃至于机器之间消息的传递与处理，同时它引入了SOA的设计思想，以服务的方式公布并运行，以方便客户端跨进程和机器对服务进行调用。实际上，WCF就是微软对于分布式处理的编程技术的集大成者，它将DCOM、Remoting、Web Service、WSE、MSMQ集成在一起，从而降低了分布式系统开发者的学习曲线，并统一了开发标准。

WCF与其它类库还有不同的地方，则在于WCF充分地体现了运行时环境的概念。对于早期使用WCF的开发人员而言，就可能知道如果在.NET 2.0下要开发WCF，还需要专门下载一个Runtime Component 3.0版，其中就包含了WCF、WF等内容。在.NET中一贯存在所谓“宿主”的概念，整个.NET Framework（或者说是CLR）就可以认为是一个大的宿主，就像Java的虚拟机一样。由于WCF对服务有着专门的需求，对于服务端，需要发布和运行服务；对于客户端，则需要调用服务；因而对于开发者，就需要编写定义、发布、运行、调用服务的相关代码。而服务就只能运行在特定的宿主上，这些宿主可以是控制台应用程序进程、Windows或Web应用程序进程，也可以是Windows服务进程，或者为最常用的IIS宿主。在宿主内部，则封装了通道堆栈，其中又包含了对协议、编码、消息传输、代理的处理。而在通道层的顶部，还提供了一个高级运行时，以针对应用程序的开发人员。

因而，我们可以这样认为，WCF是.NET Framework 3.x的一部分，它包含了用于服务定制、发布与运行以及消息传递和处理的运行时环境以及相关类的集合，它提供了在Windows平台下开发和部署服务的SDK。大致组成如下图所示：

2、WCF是怎样运行的？

如果从宏观的角度来分析WCF的运行机制，它的实现并不复杂。WCF的体系架构是基于一种拦截机制来实现的，负责传递和拦截消息的组件为通道，在客户端发出对服务端服务的调用时，首先会通过一个服务代理对象，将调用方提供的对象序列化到消息中，然后该消息则通过通道进行传递。通道不只是包括一个，而是多个通道对消息进行处理，包括传输、消息编码、管理会话、传播事务等，但最底层的通道总是传输通道。这些通道的构成形成了一个通道堆栈。由于对象已经被序列化，因而此时通道传递的消息可以跨进程或机器进行传递，利用传输通道传递到服务端。服务端的构成与客户端基本相似，仍然是通过通道栈中最底层的传输通道接收消息，然后解析消息编码，并一层层地往上传输。在服务端的通道栈之上，则是一个分发器（Dispatcher，或者说是调度器），它会首先对消息进行检查，然后选择一个客户端要调用的操作。在这个过程中，消息会被反序列化。

下图说明了WCF的整个运行过程：

由于WCF通过通道的方式传递消息，整个通道同时担当了侦听器和拦截器的功能，它可以根据服务的定义，在方法执行的前或后执行不同的操作，例如事务、会话管理、安全等。这些操作在WCF中，大多数都可以以Attribute的方式应用到服务契约上，这样的实现方式，就类似于采用了AOP（面向服务编程）的方法为服务提供了大量的基础功能，有助于简化服务开发者的工作。

3、为什么我们要选用WCF？
在Windows平台下，尤其是在.NET平台下开发面向服务的应用程序，或者开发分布式系统，最佳选择就是WCF。为什么呢？原因就在于WCF涵盖了之前微软推出的所有用于分布式开发的技术，包括Remoting、Web Services、WSE、MSMQ等，并以一种统一的编程模式来实现。

WCF既支持具有互操作性的Web服务，也能够实现.NET客户端与.NET服务端的通信，提供了分布式事务的支持，同时在安全性上，它完全遵循了WS-*的标准，此外，它还支持队列服务，可以非常方便地利用消息队列完成异步操作与脱机调用。而这些功能，以前的技术都只是部分的实现。如下表所示：

特性	Web Service	.NET Remoting	Enterprise Services	WSE	MSMQ	WCF
具有互操作性的Web服务	支持					支持
.NET到.NET的通信		支持				支持
分布式事务			支持			支持
支持WS标准				支持		支持
消息队列					支持	支持

WCF同时也使得面向服务编程更加简单而统一了。如果采用旧有的技术，由于各种技术的编程模型完全不一致，使得程序的迁移非常的困难。例如，最初采用.NET Remoting技术开发的分布式系统，由于业务需求的变化，要求发布具有互操作性的Web服务，就需要重新定义服务。并且，客户端的调用方式也发生了变化，需要添加Web引用，通过UDDI去发现服务。

采用WCF则不然。WCF引入了用通道，它封装了消息的通信细节，例如编码、事务处理、安全等，然后又通过引入绑定的概念，封装了通道的组成顺序与处理细节。最后，引入了独有的Endpoint元素，集成了地址、绑定和契约之间的“三位一体”，以最简单的方式定义和发布服务。

4、WCF基础的技术要素有哪些？

WCF的大部分功能都放在一个单独的程序集System.ServiceModel.dll中。WCF的几个最重要的技术元素包括：绑定、契约、端点。

如前所述，绑定封装了通道的组成顺序与处理细节，它直接决定了WCF的通信方式，消息的编码方式，通道的协议，消息传递的可靠性以及安全等内容。通过使用绑定，我们就无需了解消息在WCF通道中的实现细节，从而简化程序员的开发。正是因为此，WCF为开发人员提供了多个内置绑定，基本上涵盖了WCF应用的大部分场景。以下是Aaron Skonnard在《WCF深度绑定》一文中列举的内置绑定：

绑定类名称	传输	消息编码	消息版本	安全模式	可靠消息传送	事务流（默认情况下禁用）
BasicHttpBinding	HTTP	文本	SOAP 1.1	无	不支持	不支持
WSHttpBinding	HTTP	文本	SOAP 1.2 WS-Addressing 1.0	消息	禁用	WS-AtomicTransactions
WSDualHttpBinding	HTTP	文本	SOAP 1.2 WS-Addressing 1.0	消息	启用	WS-AtomicTransactions
WSFederationHttpBinding	HTTP	文本	SOAP 1.2 WS-Addressing 1.0	消息	禁用	WS-AtomicTransactions
NetTcpBinding	TCP	二进制	SOAP 1.2	传输	禁用	OleTransactions
NetPeerTcpBinding	P2P	二进制	SOAP 1.2	传输	不支持	不支持
NetNamedPipesBinding	命名管道	二进制	SOAP 1.2	传输	不支持	OleTransactions
NetMsmqBinding	MSMQ	二进制	SOAP 1.2	消息	不支持	不支持
MsmqIntegrationBinding	MSMQ	不支持（使用 WCF 之前的序列化格式）	不支持	传输	不支持	不支持
CustomBinding	您决定	您决定	您决定	您决定	您决定	您决定

每种绑定对应不同的传输协议、消息编码格式和版本以及安全、可靠性和事务模式。WCF也提供了扩展绑定的方式，例如通过CustomBinding或者定义派生与Binding的类。

WCF的契约包括服务契约、数据契约和消息契约（特别的，还包括了错误契约，用于异常的处理）。其中服务契约为面向服务应用程序的核心，通过它可以定义服务。数据契约则为服务所要传递的数据。由于服务的调用需要跨进程或机器进行通信，就需要服务数据必须能够被序列化和反序列化。虽然.NET本身提供了数据的序列化功能，但WCF的数据契约更加符合服务数据的定义习惯。至于消息契约，则可以将服务数据定义为消息，包括XML文本格式、MTOM（消息传输优化机制）格式和二进制格式。

绑定（Binding）、契约（Contract）与服务的地址（Address）组合在一起，则形成了终结点（Endpoint），如下图所示：

Address是Endpoint的网络地址，它标记了消息发送的目的地。Binding描述的是如何发送消息，例如消息发送的传输协议（如TCP，HTTP），安全（如SSL，SOAP消息安全）。Contract则描述的是消息所包含的内容，以及消息的组织和操作方式，例如是单向，双向还是请求/响应方式。

引入终结点可以说是WCF的一个伟大创举，通过它使得我们能够更加容易的发布和管理服务，尤其是发布和管理多个服务。每个服务必须至少拥有一个终结点，而客户端正是通过终结点知道服务的相关信息，例如地址、消息编码格式、传输协议以及服务的内容，然后在进行正确的调用。最特别的是，同一个服务可以定义多个终结点，每个终结点可以是不同的地址、不同的绑定方式，以便于满足多个客户端的不同需要。而对于服务的发布者而言，我们只需要管理终结点的配置，就可以完成对服务的管理，这也为服务的托管提供了便利。

5、WCF主要包含哪些内容？

Juval的《Programming WCF Services》一书基本已经涵盖了WCF技术的方方面面。概括来讲，主要包括绑定、服务契约、数据契约、消息传递、异常处理、实例模式、并发处理、事务处理、安全以及队列服务等。

绑定属于WCF基本的技术要素，是WCF进行通信处理的基础。了解绑定的相关知识，有助于开发WCF应用程序。因为在不同的业务需求下，可能对通信方式、协议、消息编码等多个方面会有不同的要求。在配制、发布和运行服务时，都需要对绑定进行操作。因而，我们必须掌握WCF内置绑定的相关属性，熟悉绑定元素的相关配置。此外，在一些高级应用上，我们还要掌握自定义绑定的方式，了解在自定义绑定时，添加绑定元素的方式与顺序，了解Binding基类的相关属性和方法。以及与绑定配置相关的类。

服务契约是WCF的主要处理对象，服务的定义和设置正是通过服务契约实现的。除了了解ServiceContract和OperationContract的基础应用之外，还需要比较WCF服务编程与普通的.NET编程之间的区别，例如服务的继承与多态是怎样实现的。最重要的是如何根据SOA的思想划分服务的边界，确定服务的粒度大小，这需要从系统的易用性、可扩展性、性能等多个方面进行权衡。

服务契约中关于操作的定义要受到很多约束，其中最重要的就是对数据的处理，这也是WCF引入数据契约的目的。由于WCF的特殊性，因而我们需要了解一些特殊数据类型的序列化方式，例如泛型类型、集合、DataSet等。

约束服务操作定义的还包括对异常的处理，WCF对异常有一套特殊的处理方式，可以根据实际的情况，确定异常消息是否需要进行通信，以及出现异常时，是否要求停止服务实例，或继续维持会话。

WCF为消息传递提供了非常大的灵活性。它提供了专门的Message类以及相关的读写器，例如XmlDictionaryReader和XmlDictionaryWriter等对消息进行读写，这其中包含了对消息版本、编码格式、消息标头和正文等的操作。同时，WCF还提供了消息与方法之间的映射。在提供系统的互操作性时，了解WCF的消息传递方式很有必要。

根据不同的需求，WCF将实例模式分为PerCall，Single和PerSession三种方式。通过设置服务行为的InstanceContextMode属性，来管理服务实例的生存周期，可以简化开发人员的工作。我们只需要了解这三种实例模式的特性即可。通常情况下，我建议服务采用PerCall模式，如果需要维持服务与客户端之间的会话，则可以采用PerSession模式。只有在对性能和可伸缩性没有太大要求的情况下，才可以采用Single模式。

关于事务处理、并发处理以及安全，主要都是通过相关的服务行为进行设置和管理。这些内容都是WCF高级应用所必需掌握的内容，尤其对于开发企业级应用系统而言。至于队列服务，主要是利用了消息队列，以实现系统可以脱机访问服务，并保持服务状态的同步。

6、WCF主用适用于哪些应用场景？

WCF本身就是微软为了应对SOA战略所推出的一套基于.NET Framework下的SDK。当我们在Windows平台下，基于.NET框架开发一套系统，同时要求这套系统需要与其它平台例如WebLogic、WebSphere或者JBoss进行交互时，就需要采用WCF技术了。这是因为WCF的互操作性所决定的。

目前来看，WCF在企业应用中还没有得到大量的应用，但随着开发者对.NET 3.x的深入了解，WCF会逐渐深入人心。由于WCF集成了.NET编程开发的习惯，对于.NET开发人员而言，就大大地降低了学习曲线，此外，WCF保留了对旧有技术包括Web Service、.NET Remoting、MSMQ、WSE的支持，同时对于旧有技术到WCF的迁移也提供了非常好的解决方案。因而，如果.NET人员若要应用SOA的解决方案，那么WCF无疑就是最佳选择。单以开发而论，利用WCF定义服务、公开服务以及运行服务，利用WF实现工作流的设计、运行与管理、利用WPF作为具有丰富表现的富客户端，或者通过AJAX+SilverLight开发调用WCF服务的客户端，以及通过CardSpace完成对服务安全的设置与管理，就足以实施一整套的SOA解决方案。同时，WCF还可以结合Biztalk以及Sharepoint，使得SDK能够搭载于应用服务器之上，更大程度地满足企业应用的需要。

除了实施SOA解决方案之外，WCF对于开发分布式系统而言，也是得天独厚的。当我们的应用系统需要在多个服务器上运行不同服务，以支撑大量的访问负荷、大数据量处理、数据挖掘等工作时，就可以利用WCF开发不同的服务，然后托管在不同的服务器上，此时，整个系统就可以有效地利用服务器资源，减轻系统负荷。

参考：
1、Juval Lowy著，张逸、徐宁译《WCF服务编程》
2、Aaron Skonnard，《WCF深度绑定》
3、Aaron Skonnard，《使用自定义行为扩展WCF》
4、Boris Lublinsky，《实现一个.NET Web Services服务注册中心》

本文链接

学习资源

2010-10-12T01:58:00Z

0）Robin's Space WCF从理论到实践系列文章索引

1) 官方主页：http://netfx3.com/content/WCFHome.aspx，它会公布WCF的最新消息和一些演示型应用。

2) http://wayfarer.cnblogs.com/ 博客园Bruce Zhang的Blog中有大量的WCF技术文章和对《Programming WCF Services》的翻译笔记

3) http://www.rainsts.net/

4) http://www.cnblogs.com/artech/ 他的《WCF之旅系列》阐述的也非常全面

本文链接

Wcf概述

2010-10-12T00:34:00Z

Wcf

概述
Windows Communication Foundation (WCF) 是由微软发展的一组数据通信的应用程序开发接口，它是.NET框架的一部分，由 .NET Framework 3.0 开始引入，与 Windows Presentation Foundation 及 Windows Workflow Foundation 并行为新一代 Windows 操作系统以及 WinFX 的三个重大应用程序开发类库。在 .NET Framework 2.0 以及前版本中，微软发展了 Web Service (SOAP with HTTP communication)，.NET Remoting (TCP/HTTP/Pipeline communication) 以及基础的 Winsock 等通信支持，由于各个通信方法的设计方法不同，而且彼此之间也有相互的重叠性（例如 .NET Remoting 可以开发 SOAP, HTTP 通信），对于开发人员来说，不同的选择会有不同的程序设计模型，而且必须要重新学习，让开发人员在用户有许多不便。同时，服务导向架构 (Service-Oriented Architecture) 也开始盛行于软件工业中，因此微软重新查看了这些通信方法，并设计了一个统一的程序开发模型，对于数据通信提供了最基本最有弹性的支持，这就是 Windows Communication Foundation。

概念
     什么是WCF？
根据微软官方的解释，WCF（之前的版本名为“Indigo”）是使用托管代码建立和运行面向服务（Service Oriented）应用程序的统一框架。它使得开发者能够建立一个跨平台的安全、可信赖、事务性的解决方案，且能与已有系统兼容协作。WCF是微软分布式应用程序开发的集大成者，它整合了.Net平台下所有的和分布式系统有关的技术，例如.Net Remoting、ASMX、WSE和MSMQ。以通信(Communiation)范围而论，它可以跨进程、跨机器、跨子网、企业网乃至于Internet；以宿主程序而论，可以以ASP.NET，EXE，WPF，Windows Forms，NT Service，COM+作为宿主(Host)。WCF可以支持的协议包括TCP，HTTP，跨进程以及自定义，安全模式则包括SAML，Kerberos，X509，用户/密码，自定义等多种标准与模式。也就是说，在WCF框架下，开发基于SOA的分布式系统变得容易了，微软将所有与此相关的技术要素都包含在内，掌握了WCF，就相当于掌握了叩开SOA大门的钥匙。
WCF是建立在.Net Framework 2.0基础之上的，正式的版本应该会作为Windows Vista的核心部分而Release。然而，这并不代表WCF只能运行在Windows Vista下。只要安装了WinFX Runtime Components，在Windows XP和Windows 2003操作系统下，仍然可以使用。Visual Studio 2005中并没有包含WCF，但是当安装好了WinFX Runtime Components后，我们就可以在Visual Studio 2005环境下开发和创建WCF的程序了。
目前最新的WCF版本是February 2006 CTP，下载页面是：http://www.microsoft.com/downloads/details.aspx?FamilyId=F51C4D96-9AEA-474F-86D3-172BFA3B828B&displaylang=en。使用WCF需要用到一些相关的工具，如SvcUtil.exe，所以还需要下载WinFX Runtime Components的SDK，其下载页面是：http://www.microsoft.com/downloads/details.aspx?FamilyId=9BE1FC7F-0542-47F1-88DD-61E3EF88C402&displaylang=en。安装SDK可以选择网络安装或本地安装。如果是本地安装，文件大小为1.1G左右，是ISO文件。安装了SDK后，在program files目录下，有microsoft SDK目录。
WCF是微软重点介绍的产品，因此也推出了专门的官方网站（http://windowscommunication.net），该网站有最新的WCF新闻发布，以及介绍WCF的技术文档和样例代码

WCF 由于集合了几乎由 .NET Framework 所提供的通信方法，因此学习曲线比较陡峭，开发人员必须要针对各个部份的内涵做深入的了解，才能够操控 WCF 来开发应用程序。

通信双方的沟通方式，由合约来订定。通信双方所遵循的通信方法，由协议绑定来订定。通信期间的安全性，由双方约定的安全性层次来订定。
合约（Contract）
WCF 的基本概念是以合约 (Contract) 来定义双方沟通的协议，合约必须要以接口的方式来体现，而实际的服务代码必须要由这些合约接口派生并实现。合约分成了四种：
数据合约 (Data Contract)，订定双方沟通时的数据格式。服务合约 (Service Contract)，订定服务的定义。营运合约 (Operation Contract)，订定服务提供的方法。消息合约 (Message Contract)，订定在通信期间改写消息内容的规范。一个 WCF 中的合约，就如同下列代码所示：

using System;
using System.ServiceModel;
namespace Microsoft.ServiceModel.Samples
{

[ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples")] // 服务合约
public interface ICalculator
{
  [OperationContract] // 营运合约
double Add(double n1, double n2);
  [OperationContract] // 营运合约
double Subtract(double n1, double n2);
  [OperationContract] // 营运合约
double Multiply(double n1, double n2);
  [OperationContract] // 营运合约
double Divide(double n1, double n2);
}

}

协议绑定 (Binding)
由于 WCF 支持了 HTTP，TCP，Named Pipe，MSMQ，Peer-To-Peer TCP 等协议，而 HTTP 又分为基本 HTTP 支持 (BasicHttpBinding) 以及 WS-HTTP 支持 (WsHttpBinding)，而 TCP 亦支持 NetTcpBinding，NetPeerTcpBinding 等通信方式，因此，双方必须要统一通信的协议，并且也要在编码以及格式上要有所一致。
一个设置通信协议绑定的示例如下：

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        
        <services>
            <service name=" CalculatorService" >
                <endpoint address="" binding="wsHttpBinding" bindingConfiguration="Binding1" contract="ICalculator" />
            </service>
        </services>
        
        <bindings>
            <wsHttpBinding>
                <binding name="Binding1"> </binding>
            </wsHttpBinding>
        </bindings>
    </system.serviceModel>
</configuration>

虽然 WCF 也可以使用 SOAP 做通信格式，但它和以往的 ASP.NET XML Web Services 不同，因此有部分技术文章中，会将 ASP.NET 的 XML Web Services 称为 ASMX Service。
WCF 的服务可以挂载于 Console Application，Windows Application，IIS (ASP.NET) Application，Windows Service 以及 Windows Activation Services 中，但大多都会挂在 Windows Service。
安全性层次
WCF 实现上已经支持了传输层次安全性 (Transport-level security) 以及消息层次安全性 (Message-level security) 两种。
传输层次安全性：在数据传输时期加密，例如 SSL。消息层次安全性：在数据处理时就加密，例如使用数字签章，散列或是使用金钥加密法等。

客户端
对于 WCF 的客户端来说，WCF 服务就像是一个 Web Service 一样，在 Visual Studio 2008 中，所有 WCF 服务的连接都是由客户端的 WCF Service Proxy 来运行，开发人员不用花费太多心思在通信上，而 WCF Service Proxy 在 Visual Studio 中被称为服务参考 (Service Reference)。
在 Visual Studio 中加入 WCF 的服务参考时，Visual Studio 会自动帮开发人员做掉一些必要工作（例如组态创建以及产生 Service Proxy 等），开发人员只需要在代码中取用 WCF Service Proxy 对象即可。

下载地址
目前最新的WCF版本是February 2006 CTP，下载页面是：http://www.microsoft.com/downloads/details.aspx?FamilyId=F51C4D96-9AEA-474F-86D3-172BFA3B828B&displaylang=en。使用WCF需要用到一些相关的工具，如SvcUtil.exe，所以还需要下载WinFX Runtime Components的SDK，其下载页面是：http://www.microsoft.com/downloads/details.aspx?FamilyId=9BE1FC7F-0542-47F1-88DD-61E3EF88C402&displaylang=en。安装SDK可以选择网络安装或本地安装。如果是本地安装，文件大小为1.1G左右，是ISO文件。安装了SDK后，在program files目录下，有microsoft SDK目录。
WCF是微软重点介绍的产品，因此也推出了专门的官方网站（http://windowscommunication.net），该网站有最新的WCF新闻发布，以及介绍WCF的技术文档和样例代码。

WCF的优势
在David Chappell所撰的《Introducing Windows Communication Foundation》一文中，用了一个活鲜鲜的例子，来说明WCF的优势所在。假定我们要为一家汽车租赁公司开发一个新的应用程序，用于租车预约服务。该租车预约服务会被多种应用程序访问，包括呼叫中心(Call Center)，基于J2EE的租车预约服务以及合作伙伴的应用程序（Partner Application），如图所示：
呼叫中心运行在Windows平台下，是在.Net Framework下开发的应用程序，用户为公司员工。由于该汽车租赁公司兼并了另外一家租赁公司，该公司原有的汽车预约服务应用程序是J2EE应用程序，运行在非Windows操作系统下。呼叫中心和已有的汽车预约应用程序都运行在Intranet环境下。合作伙伴的应用程序可能会运行在各种平台下，这些合作伙伴包括旅行社、航空公司等等，他们会通过Internet来访问汽车预约服务，实现对汽车的租用。
这样一个案例是一个典型的分布式应用系统。如果没有WCF，利用.Net现有的技术应该如何开发呢？
首先考虑呼叫中心，它和我们要开发的汽车预约服务一样，都是基于.Net Framework的应用程序。呼叫中心对于系统的性能要求较高，在这样的前提下，.Net Remoting是最佳的实现技术。它能够高性能的实现.Net与.Net之间的通信。
要实现与已有的J2EE汽车预约应用程序之间的通信，只有基于SOAP的Web Service可以实现此种目的，它保证了跨平台的通信；而合作伙伴由于是通过Internet来访问，利用ASP.Net Web Service，即ASMX，也是较为合理的选择，它保证了跨网络的通信。由于涉及到网络之间的通信，我们还要充分考虑通信的安全性，利用WSE（Web Service Enhancements）可以为ASMX提供安全的保证。
一个好的系统除了要保证访问和管理的安全，高性能，同时还要保证系统的可信赖性。因此，事务处理是企业应用必须考虑的因素，对于汽车预约服务而言，同样如此。在.Net中，Enterprise Service（COM+）提供了对事务的支持，其中还包括分布式事务（Distributed Transactions）。不过对于Enterprise Service而言，它仅支持有限的几种通信协议。
如果还要考虑到异步调用、脱机连接、断点连接等功能，我们还需要应用MSMQ（Microsoft Message Queuing），利用消息队列支持应用程序之间的消息传递。
如此看来，要建立一个好的汽车租赁预约服务系统，需要用到的.Net分布式技术，包括.Net Remoting、Web Service，COM+等五种技术，这既不利于开发者的开发，也加大了程序的维护难度和开发成本。正是因应于这样的缺陷，WCF才会在.Net 2.0中作为全新的分布式开发技术被微软强势推出，它整合了上述所属的分布式技术，成为了理想的分布式开发的解决之道。下图展示了WCF与之前的相关技术的比较：
从功能的角度来看，WCF完全可以看作是ASMX，.Net Remoting，Enterprise Service，WSE，MSMQ等技术的并集。（注：这种说法仅仅是从功能的角度。事实上WCF远非简单的并集这样简单，它是真正面向服务的产品，它已经改变了通常的开发模式。）因此，对于上述汽车预约服务系统的例子，利用WCF，就可以解决包括安全、可信赖、互操作、跨平台通信等等需求。开发者再不用去分别了解.Net Remoting，ASMX等各种技术了。
概括地说，WCF具有如下的优势：
1、统一性
前面已经叙述，WCF是对于ASMX，.Net Remoting，Enterprise Service，WSE，MSMQ等技术的整合。由于WCF完全是由托管代码编写，因此开发WCF的应用程序与开发其它的.Net应用程序没有太大的区别，我们仍然可以像创建面向对象的应用程序那样，利用WCF来创建面向服务的应用程序。

2、互操作性
由于WCF最基本的通信机制是SOAP，这就保证了系统之间的互操作性，即使是运行不同的上下文中。这种通信可以是基于.Net到.Net间的通信，如下图所示：
可以跨进程、跨机器甚至于跨平台的通信，只要支持标准的Web Service，例如J2EE应用服务器（如WebSphere，WebLogic）。应用程序可以运行在Windows操作系统下，也可以运行在其他的操作系统，如Sun Solaris，HP Unix，Linux等等。如下图所示：

3、安全与可信赖
WS-Security，WS-Trust和WS-SecureConversation均被添加到SOAP消息中，以用于用户认证，数据完整性验证，数据隐私等多种安全因素。
在SOAP的header中增加了WS-ReliableMessaging允许可信赖的端对端通信。而建立在WS-Coordination和WS-AtomicTransaction之上的基于SOAP格式交换的信息，则支持两阶段的事务提交（two-phase commit transactions）。
上述的多种WS-Policy在WCF中都给与了支持。对于Messaging而言，SOAP是Web Service的基本协议，它包含了消息头（header）和消息体(body)。在消息头中，定义了WS-Addressing用于定位SOAP消息的地址信息，同时还包含了MTOM（消息传输优化机制，Message Transmission Optimization Mechanism）。如图所示：

4、兼容性
WCF充分的考虑到了与旧有系统的兼容性。安装WCF并不会影响原有的技术如ASMX和.Net Remoting。即使对于WCF和ASMX而言，虽然两者都使用了SOAP，但基于WCF开发的应用程序，仍然可以直接与ASMX进行交互。

参考资料
1.MSDN .NET Framework Developer Center: WCF
2.MSDN Library: WCF Portal
3.http://dotnet.blog.51cto.com/272325/52076
本文中的示例均来自 MSDN Library: WCF Portal 中
本文链接

用Visual C#创建Windows服务程序

2010-09-07T06:42:00Z

用Visual C#创建Windows服务程序

一．Windows服务介绍：

Windows服务以前被称作NT服务，是一些运行在Windows NT、Windows 2000和Windows XP等操作系统下用户环境以外的程序。在以前，编写Windows服务程序需要程序员很强的C或C++功底。然而现在在Visual Studio.Net下，你可以运用C++或Visual C#或Visual Basic.Net很轻松的创建一个Windows服务程序。同样，你还可以运用其他任何与CLR相容的语言来创建Windows服务程序。本文就向大家介绍如何运用Visual C#来一步一步创建一个文件监视的Windows服务程序，然后介绍如何安装、测试和调试该Windows服务程序。

在介绍如何创建Windows服务程序以前，我先向大家介绍一些有关Windows服务的背景知识。一个Windows服务程序是在Windows操作系统下能完成特定功能的可执行的应用程序。Windows服务程序虽然是可执行的，但是它不像一般的可执行文件通过双击就能开始运行了，它必须有特定的启动方式。这些启动方式包括了自动启动和手动启动两种。对于自动启动的Windows服务程序，它们在Windows启动或是重启之后用户登录之前就开始执行了。只要你将相应的Windows服务程序注册到服务控制管理器（Service Control Manager）中，并将其启动类别设为自动启动就行了。而对于手动启动的Windows服务程序，你可以通过命令行工具的NET START 命令来启动它，或是通过控制面板中管理工具下的服务一项来启动相应的Windows服务程序（见图1）。同样，一个Windows服务程序也不能像一般的应用程序那样被终止。因为Windows服务程序一般是没有用户界面的，所以你也要通过命令行工具或是下面图中的工具来停止它，或是在系统关闭时使得Windows服务程序自动停止。因为Windows服务程序没有用户界面，所以基于用户界面的API函数对其是没有多大的意义。为了能使一个Windows服务程序能够正常并有效的在系统环境下工作，程序员必须实现一系列的方法来完成其服务功能。Windows服务程序的应用范围很广，典型的Windows服务程序包含了硬件控制、应用程序监视、系统级应用、诊断、报告、Web和文件系统服务等功能。

图1

二．创建Windows服务程序：

在介绍如何创建Windows服务程序以前，我先向大家介绍一下.Net框架下与Windows服务相关的命名空间和其中的类库。.Net框架大大地简化了Windows服务程序的创建和控制过程，这要归功于其命名空间中的功能强大的类库。和Windows服务程序相关的命名空间涉及到以下两个：System.ServiceProcess和System.Diagnostics。

要创建一个最基本的Windows服务程序，我们只需要运用.Net框架下的System.ServiceProcess命名空间以及其中的四个类：ServiceBase、ServiceInstaller、ServiceProcessInstaller以及ServiceController，其体系结构可见图2。

图2

其中ServiceBase类定义了一些可被其子类重载的函数，通过这些重载的函数，服务控制管理器就可以控制该Windows服务程序了。这些函数包括：OnStart（）、OnStop（）、OnPause（）以及OnContinue（）等四个。而且ServiceBase类的子类还可以重载OnCustomCommand（）函数来完成一些特定的操作。通过重载以上的一些函数，我们就完成了一个Windows服务程序的基本框架，这些函数的重载方法如下：

protected override void OnStart(string[] args)

{

}

protected override void OnStop()

{

}

protected override void OnPause()

{

}

protected override void OnContinue()

{

}

ServiceBase类还为我们提供了一些属性，而这些属性是任何Widnows服务程序所必须的。其中的ServiceName属性指定了Windows服务的名称，通过该名称系统就可以调用Windows服务了，同时其它应用程序也可以通过该名称来调用它的服务。而CanPauseAndContinue和CanStop属性顾名思义就是允许暂停并恢复和允许停止的意思。

要使得一个Windows服务程序能够正常运行，我们需要像创建一般应用程序那样为它创建一个程序的入口点。在Windows服务程序中，我们也是在Main（）函数中完成这个操作的。首先我们在Main（）函数中创建一个Windows服务的实例，该实例应该是ServiceBase类的某个子类的对象，然后我们调用由基类ServiceBase类定义的一个Run（）方法。然而Run（）方法并不就开始了Windows服务程序，我们必须通过前面提到的服务控制管理器调用特定的控制功能来完成Windows服务程序的启动，也就是要等到该对象的OnStart（）方法被调用时服务才真正开始运行。如果你想在一个Windows服务程序中同时启动多个服务，那么只要在Main（）函数中定义多个ServiceBae类的子类的实例对象就可以了，方法就是创建一个ServiceBase类的数组对象，使得其中的每个对象对应于某个我们已预先定义好的服务。

{

System.ServiceProcess.ServiceBase[] MyServices;

MyServices = new System.ServiceProcess.ServiceBase[] { new Service1(), new Service2() };

System.ServiceProcess.ServiceBase.Run(MyServices);

}

static void Main()

三．添加文件监视服务：

了解了Windows服务的基本体系结构和创建方法后，我们就可以试着往服务中添加一些实际的功能了。下面我将向大家介绍一个能监视本地文件系统的文件监视服务－FileMonitorService。该服务能根据预先设定的本地目录路径监视其中的文件包括子文件夹中的任何变化：文件创建、文件删除、文件改名、文件修改。同时，该服务还为每种变化创建了一个相对应的计数器，计数器的作用就是反映该种变化的频度。

首先，我们打开Visual Studio.Net，新建一个Visual C#的Windows服务的项目，如图3所示：

图3

在重载Windows服务的OnStart（）函数之前，我们先给其类添加一些计数器对象，这些计数器分别对应了文件的创建、删除、改名以及修改等变化。一旦指定目录中的文件发生以上的某种变化，与其相对应的计数器就会自动加1。所有的这些计数器都是定义为PerformanceCounter类型的变量的，该类是包含在System.Diagnostics命名空间中的。

private System.Diagnostics.PerformanceCounter fileCreateCounter;

private System.Diagnostics.PerformanceCounter fileDeleteCounter;

private System.Diagnostics.PerformanceCounter fileRenameCounter;

private System.Diagnostics.PerformanceCounter fileChangeCounter;

之后我们便在类的InitializeComponent（）方法中创建以上定义的各个计数器对象并确定其相关属性。同时我们将该Windows服务的名称设置为“FileMonitorService”，设定其即是允许暂停并恢复的又是允许停止的。

private void InitializeComponent()

{

this.components = new System.ComponentModel.Container();

this.fileChangeCounter = new System.Diagnostics.PerformanceCounter();

this.fileDeleteCounter = new System.Diagnostics.PerformanceCounter();

this.fileRenameCounter = new System.Diagnostics.PerformanceCounter();

this.fileCreateCounter = new System.Diagnostics.PerformanceCounter();

fileChangeCounter.CategoryName = "File Monitor Service";

fileDeleteCounter.CategoryName = "File Monitor Service";

fileRenameCounter.CategoryName = "File Monitor Service";

fileCreateCounter.CategoryName = "File Monitor Service";

fileChangeCounter.CounterName = "Files Changed";

fileDeleteCounter.CounterName = "Files Deleted";

fileRenameCounter.CounterName = "Files Renamed";

fileCreateCounter.CounterName = "Files Created";

this.ServiceName = "FileMonitorService";

this.CanPauseAndContinue = true;

this.CanStop = true;

servicePaused = false;

}

接着就是重载OnStart（）函数和OnStop（）函数，OnStart（）函数完成了一些必要的初始化工作。在.Net框架下，文件的监视功能可以由FileSystemWatcher类来完成，该类是包含在System.IO命名空间下的。该Windows服务所要完成的功能包括了监视文件的创建、删除、改名和修改等变化，而FileSystemWatcher类包含所有了对应于这些变化的处理函数。

protected override void OnStart(string[] args)

{

FileSystemWatcher curWatcher = new FileSystemWatcher();

curWatcher.BeginInit();

curWatcher.IncludeSubdirectories = true;

curWatcher.Path =

System.Configuration.ConfigurationSettings.AppSettings

　["FileMonitorDirectory"];

curWatcher.Changed += new FileSystemEventHandler(OnFileChanged);

curWatcher.Created += new FileSystemEventHandler(OnFileCreated);

curWatcher.Deleted += new FileSystemEventHandler(OnFileDeleted);

curWatcher.Renamed += new RenamedEventHandler(OnFileRenamed);

curWatcher.EnableRaisingEvents = true;

curWatcher.EndInit();

}

注意其中被监视的目录是存放在一个应用程序配置文件中的，该文件是一个XML类型的文件。这种做法的好处就是我们不必重新编译并发布该Windows服务而只要直接修改其配置文件就可以达到更改所要监视的目录的功能了。

当该Windows服务启动后，一旦被监视的目录中的文件发生某种变化，与其相对应的计数器的值便会相应的增加，方法很简单，只要调用计数器对象的IncrementBy（）即可。

private void OnFileChanged(Object source, FileSystemEventArgs e)

{

if( servicePaused == false )

{

fileChangeCounter.IncrementBy(1);

}

private void OnFileRenamed(Object source, RenamedEventArgs e)

{

if( servicePaused == false )

{

fileRenameCounter.IncrementBy(1);

}

private void OnFileCreated(Object source, FileSystemEventArgs e)

{

if( servicePaused == false )

{

fileCreateCounter.IncrementBy(1);

}

private void OnFileDeleted(Object source, FileSystemEventArgs e)

{

if( servicePaused == false )

{

fileDeleteCounter.IncrementBy(1);

}

OnStop（）函数即是停止Windows服务的，在该Windows服务中，服务一旦停止，所有的计数器的值都应归零，但是计数器并不提供一个Reset（）方法，所以我们只好将计数器中的值减去当前值来达到这个目的。

protected override void OnStop()

{

if( fileChangeCounter.RawValue != 0 )

{

fileChangeCounter.IncrementBy(-fileChangeCounter.RawValue);

}

if( fileDeleteCounter.RawValue != 0 )

{

fileDeleteCounter.IncrementBy(-fileDeleteCounter.RawValue);

}

if( fileRenameCounter.RawValue != 0 )

{

fileRenameCounter.IncrementBy(-fileRenameCounter.RawValue);

}

if( fileCreateCounter.RawValue != 0 )

{

fileCreateCounter.IncrementBy(-fileCreateCounter.RawValue);

}

同时，因为我们的Windows服务是允许暂停并恢复的，所以我们还得重载OnPause（）函数和OnContinue（）函数，方法很简单，只要设定前面定义的布尔值servicePaused即可。

protected override void OnPause()

{

servicePaused = true;

}

protected override void OnContinue()

{

servicePaused = false;

}

这样，该Windows服务的主体部分已经完成了，不过它并不有用，我们还必须为其添加安装文件。安装文件为Windows服务的正确安装做好了工作，它包括了一个Windows服务的安装类，该类是重System.Configuration.Install.Installer继承过来的。安装类中包括了Windows服务运行所需的帐号信息，用户名、密码信息以及Windows服务的名称，启动方式等信息。

[RunInstaller(true)]

public class Installer1 : System.Configuration.Install.Installer

{

/// <summary>

/// 必需的设计器变量。

/// </summary>

private System.ComponentModel.Container components = null;

private System.ServiceProcess.ServiceProcessInstaller spInstaller;

private System.ServiceProcess.ServiceInstaller sInstaller;

public Installer1()

{

// 该调用是设计器所必需的。

InitializeComponent();

// TODO: 在 InitComponent 调用后添加任何初始化

}

#region Component Designer generated code

/// <summary>

/// 设计器支持所需的方法 - 不要使用代码编辑器修改

/// 此方法的内容。

/// </summary>

private void InitializeComponent()

{

components = new System.ComponentModel.Container();

// 创建ServiceProcessInstaller对象和ServiceInstaller对象

this.spInstaller =

new System.ServiceProcess.ServiceProcessInstaller();

this.sInstaller = new System.ServiceProcess.ServiceInstaller();

// 设定ServiceProcessInstaller对象的帐号、用户名和密码等信息

this.spInstaller.Account =

System.ServiceProcess.ServiceAccount.LocalSystem;

this.spInstaller.Username = null;

this.spInstaller.Password = null;

// 设定服务名称

this.sInstaller.ServiceName = "FileMonitorService";

// 设定服务的启动方式

this.sInstaller.StartType =

System.ServiceProcess.ServiceStartMode.Automatic;

this.Installers.AddRange(

new System.Configuration.Install.Installer[]

{this.spInstaller, this.sInstaller });

}

#endregion

}

同样，因为该Windows服务中运用到了计数器对象，我们也要为其添加相应的安装文件，安装文件的内容和作用与前面的类似。限于篇幅，这里就不给出相应的代码了，有兴趣的读者可以参考文后附带的源代码文件。

到此为止，整个Windows服务已经构建完毕，不过Windows服务程序和一般的应用程序不同，它不能直接调试运行。如果你直接在IDE下试图调试运行之，就会报出如图4所示提示。

图4

根据其中提示，我们知道安装Windows服务需要用到一个名为InstallUtil.exe的命令行工具。而运用该工具安装Windows服务的方法是非常简单的，安装该Windows服务的命令如下：

installutil FileMonitorService.exe

而要卸载该Windows服务，你只要输入如下的命令即可：

installutil /u FileMonitorService.exe

Windows服务安装成功后，它便会出现在服务控制管理器中，如图5所示。

图5

这样，该文件监视的Windows服务就完成了，一旦我们对被监视的目录中的文件进行操作，相应的计数器就会运作，起到监视文件变化的作用。不过这个功能对于一般的用户而言没多大意义，然而你可以在此基础上添加新的功能，比如构建一个后台的文件处理系统，一旦被监视的目录中的文件发生某种变化，Windows服务便对其进行特定的操作，而最终用户就不必去关心后台处理程序是如何实现的了。

四．总结：

本文向大家介绍了Windows服务的一些基本概念和构建一般的Windows服务所需的方法，同时还向大家展示了一个具有文件监视功能的Windows服务程序。通过本文，读者应该能体会到构建Windows服务并不是想象中的那么复杂，这主要还得归功于.Net框架为我们所作的大量努力。同时，希望大家能在本文给出的实例的基础上构建更加完善和更加强大的Windows服务程序。最后希望本文对大家能有不少帮助。

（注：源代码文件为Source.rar ）

http://www.vchome.net/dotnet/dotnetdocs/dotnet38.htm

本文链接

VS2005没有源代码管理选项和菜单

2010-06-18T06:48:00Z

VS2005的菜单没有关于源代码菜单的选项，在工具－》选项里面的源代码插件管理也没有相关选择。正学来讲当我们装完VSS后在VS2005中应该会看到源代码菜单和相关的插件管理。

如果遇到这种情况可以通过运行下面的命令解决：

regsvr32 "C:\Program Files\Microsoft Visual SourceSafe\ssscc.dll"
regsvr32 "C:\Program Files\Microsoft Visual SourceSafe\ssapi.dll"
regsvr32 "C:\Program Files\Microsoft Visual SourceSafe\tdnamespaceextension.dll"
regsvr32 "C:\Program Files\Microsoft Visual SourceSafe\RemoteVssScc.DLL"

注意你VSS的安装路径，可作相应修改。

运行完上述几条命令后，再次运行VS2005，菜单已经正常出现，在工具－》选项的源代码管理中，也有VSS插件给我们选择了。

本文链接

RFID射频识别技术

2010-06-03T09:53:00Z

RFID是Radio Frequency Identification的缩写，即射频识别。

RFID是射频识别技术的英文(Radio Frequency Identification)的缩写，射频识别技术是20世纪90年代开始兴起的一种自动识别技术，射频识别技术是一项利用射频信号通过空间耦合(交变磁场或电磁场)实现无接触信息传递并通过所传递的信息达到识别目的的技术。

RFID 系统由三部分组成：

标签(Tag)：
由耦合元件及芯片组成，每个标签具有唯一的电子编码，附着在物体上标识目标对象；电子标签能够贮存有关物体的数据信息(约1k bits)。在自动识别管理系统中，每一个电子标签中保存着一个物体的属性、状态、编号等信息。电子标签通常安装在物体表面，具有一定的无金属遮挡的视角。

读写器(Reader)：
读取(有时还可以写入)标签信息的设备，可设计为手持式或固定式；其主要功能是：
* 查阅电子标签中当前贮存的数据信息；
* 向空白电子标签中写入欲贮存的数据信息；
* 修改（重新写入）电子标签中的数据信息。

天线(Antenna)：
在标签和读取器间传递射频信号。

工作原理：

　　当装有电子标签的物体在距离0~10米范围内接近读写器时，读写器受控发出微波查询信号，安装在物体表面的电子标签收到读写器的查询信号后，将此信号与标签中的数据信息合成一体反射回电子标签读出装置。反射回的微波合成信号，已携带有电子标签数据信息。读写器接收到电子标签反射回的微波合成信号后，经读写器内部微处理器处理后即可将电子标签贮存的识别代码等信息分离读取出来。

　工作原理图

RFID标签分类

RFID标签分为被动标签(Passive tags)和主动标签(Active tags)两种。
主动标签自身带有电池供电，读/写距离较远同时体积较大，与被动标签相比成本更高，也称为有源标签。
被动标签由阅读器产生的磁场中获得工作所需的能量，成本很低并具有很长的使用寿命，比主动标签更小也更轻，读写距离则较近，也称为无源标签。

有源RFID卡与无源RFID卡的性能比较：

有源 RFID卡	无源 RFID卡
内装电池	无源，利用无线波能量工作
在高温或低温下电池不能正常工作	在高温或低温下能正常工作
电池为一次性，无法更换。因此标签卡使用寿命受到卡使用情况的不同而差异很大，厂商理想指标为7~10年，但因每卡每天使用的次数及环境不同，实际工程中，有些卡只能用几个月，有些卡可以使用5年以上，系统的一致性比较差，无法控制。	系统一致性很好，无源卡的使用寿命保证10年以上，免维护。
卡的外型尺寸大，较厚，较重	外型小巧，轻，薄，安装方便，适用各种使用
无法做到标签防拆功能	容易做到标签防拆功能
无法做到“一车一卡一号”，容易进行卡之间的互换	容易做到做到“一车一卡一号”，为车量实现终身ID号标记及车量信息
成本较高	成本低
读写距离远10M	读写距离远10M
读写数据快	读写数据快

频率的划分：

目前有四种频率的标签在使用中比较常见。他们是按照他们的无线电频率划分：低频标签（125或134.2千赫），高频标签（13.56兆赫），超高频标签（868到956兆赫）以及微波标签（2.45GHz）。

主要国家UHF RFID频段：

国家和地区	频率	功率
中国	840～845MHz	2W ERP
中国	920～925MHz	2W ERP
北美	902～928MHz	4W EIRP
欧洲	865～868MHz	2W ERP
日本	952～954MHz	4W EIRP
韩国	910～914MHz	4W EIRP
澳大利亚	918～926MHz	4W EIRP
新西兰	864～868MHz	4W EIRP
印度	865～867MHz	4W ERP
新加坡	866～869MHz	0.5W ERP
新加坡	923～925MHz	2W ERP
香港	865～868MHz	2W ERP
香港	920～925MHz	4W EIRP
台湾	922～928MHz	1W ERP

EPC概念：

　　1999 年美国麻省理工学院MIT 成立AUTOID CENTER，提出EPC 概念。后在国际物品编码协会的主导下， EAN和UCC成立EPCglobal，管理全球EPC标准、开发并实施市场和通信、管理EPC系统。自此，EPC系统的研发力量在全球范围内得以整合，并进入了有计划的推广阶段。

产品电子代码（EPC）被认为是惟一识别所有物理对象的有效方式。这些对象包含贸易产品、产品包装和物流单元等体系。EPC 编码本身包含非常有限的信息，但它有对应的后台数据库作为支持，将EPC 编码对应的产品信息存储在数据库里，这些数据库又互相连接，与对象名称解析服务体系（ONS）等信息技术一起构成了一个“实物互联网”，因此EPC 是连通现实世界的桥梁。

EPC 的目标是为每一物理实体提供惟一标识，它是由一个版本号和另外三段数据（依次为域名管理者、对象分类、序列号）组成的一组数字。其中EPC 的版本号标识EPC 的长度或类型；域名管理者是描述与此EPC相关的生产厂商的信息，例如“可口可乐公司”；对象分类记录产品精确类型的信息，例如：“美国生产的330ml 罐装减肥可乐（可口可乐的一种新产品）”；序列号惟一标识货品，它会精确的指明所说的究竟是哪一罐330ml 罐装减肥可乐。EPC标识的实体对象不仅包括零售商品，也包括货运包装、物流单元、集装箱和组装件等。

EPC 系统是EAN?UCC系统的一个重要组成部分，EPC 编码与现行的EAN?UCC编码相兼容。EAN?UCC推出的这两种编码体系在编码结构设计、编码实现方式、应用目的和应用效应等诸多方面既存在联系又存在区别。当前，了解全球EPC的编码体系，并制定与国际接轨的国家标准是当务之急。

新型的产品电子标签在国外正由研究转向生产和应用，为了在我国推广该项技术，提高我国物流运作效率，现急需展开产品电子标签技术规范的研究与制定。包括如下方面：研究产品电子标签系统实施过程，制定“产品电子标签系统规范”，指导产品电子标签系统在物流配送过程中的应用。根据产品电子标签系统的实施过程，研究产品电子标签系统标准体系，给出标准体系框架，并制定产品电子标签系统相关标准，包括：产品电子标签编码体系；产品电子标签技术规范；产品电子标签系统读写器技术规范；产品电子标签系统网络管理软件；产品电子标签系统对象名称解析服务系统；产品电子标签系统实体标记语言。同时，EPC系统的管理与维护标准也急需制定，包括：建立EPC系统准入制度；建立EPC注册登记制度；建立EPC系统认可制度；建立EPC数据管理与维护制度；建立EPC系统安全体系，确立EPC系统一致性测试方法。

由于EPC为每一单品建立全球的、开放的标识标准，因此以EPC技术为主导的自动识别系统将能够使产品的生产、仓储、运输、销售、购买及消费的全过程发生根本性的变化，从而大大提高了全球供应链的性能。

EPC系统的推广和应用将带来供应链管理过程的根本性的革命。

UHF RFID应用注意事项

a) 协议选择

不同的协议标准有不同的特点，要根据应用需要和市场上的供应情况确定，目前6A、EPC C0、EPC C1的都已经淘汰了，可供选择的是6B、6C和EM。6B协议简单，目前应用以车辆和相对大型的货物管理为主，应用时间比较长，比较成熟，但可供选择的芯片厂家不多，目前国内只有NXP；6C协议比较复杂，灵活性大，应用范围广，较适宜多标签识别，是仓储、物流管理发展的方向；EM协议很有特色，它是TTF（Tag Talk First）方式，而6B、6C都是RTF（Reader Talk First）方式，EM协议很适合高速运动的目标识别。

b) 读写器选择

读写器主要作用就是读取标签的数据然后输出到后台处理器中。根据应用需求和成本要求，读写器有不同的类型和性能。从形式上看，有分体式（读写器和天线分开来，中间用馈线连接），一体式（读写器和天线做成一体化）和手持式；从性能上看，有带功能强大的操作系统的，有带简单嵌入式操作系统的，也有不带操作系统的，有高速的，有低速的，有接口丰富的，有接口简单的，有单天线接口的，有多天线接口的。根据具体应用要求选择不同的读写器。

注意事项：
1、由于馈线会产生损耗，影响读写距离，所以馈线尽可能短，而且馈线质量很重要；
2、多天线接口的读写器，各个天线之间一般都是分时工作的，所以天线数量会影响读取的速度；
3、手持读写器一般天线较小，方向性不强，所以不宜要求读取距离太远，否则很难确定被读目标的位置；
4、不同数据接口有不同的传输特性，要根据特性和环境选择不同的接口。

c) 天线选择

天线有不同的极化方式和增益大小，要根据应用环境要求选择。如果标签方向能够确定且比较一致，那就选择线极化的天线，如果标签方向不能确定，那就选择圆极化天线。天线的增益影响读写的距离，增益越大读写距离越远，但读写的范围越小。

注意事项：
i. 不是越远越好，要根据使用环境选择适当的增益，因为太远会读到不希望读到的标签，增加数据处理的难度；
ii. 安装时，天线的发射面应该和人保持一定的安全距离，视具体读写器输出功率和天线增益而定，一般50－100厘米以上。

d) 标签选择

标签是RFID应用系统的关键，它的选择和使用直接影响整个系统的性能。需要考虑几个方面的问题，首先是标签的安放位置，要考虑和读写器天线配合便于读取；第二是读写距离的要求，要设计不同的天线来满足距离要求；第三是封装形式，要考虑使用环境以及是否重复使用，还有成本要求，因为标签的数量通常比较大，对成本比较敏感。

注意事项：
i. 由于UHF频段的电磁波能够被水等液体吸收，也会被金属完全反射，所以标签的位置要尽量远离液体和金属，一般2厘米以上；
ii. 标签天线的形状和大小影响读写的距离，一般尺寸越小距离越短；
iii. 不同介质的介电常数不一样，所以要根据标签所附着的材料的介电常数设计天线，没有一种天线适合所有材料。
iv. 标签的天线有一定的方向性，所以在具体应用时一定要和读写器天线配合才能获得理想的读取效果；
v. 向标签写入数据比从标签读取数据的能量要求高得多，所以写入距离一般为读取距离的40－60％。

e) 实施的步骤

i. 详细了解应用需求，包括标签贴附的介质、位置，多标签之间的相对位置和中间的介质，同时读取的标签数量要求，读取区域的大小及周围的环境，读写标签数据量的大小，等等；
ii. 进行总体方案的初步设计，重点是读写点的位置和相应业务流程的配合；
iii. 选择读写器、天线、标签，有时需要设计标签，制作样品，编写测试软件；
iv. 由于射频信号是看不见摸不着的，很多情况并不能预先知道，所以有时需要搭建模拟测试环境，尽量和实际环境一模一样，对应用需求进行模拟试验，发现问题，找出解决方案；
v. 现场试验，经过模拟试验后，还需要到实际现场进行读写试验，有时还需要根据现场实际情况进行方案修改，直到满足要求为止；
vi. 进行实施方案的设计；
具体实施、试运行，必要时再改进。

本文链接

微软RFID开发平台BizTalk资料收集

2010-06-01T09:43:00Z

Microsoft BizTalk RFID 是一种开放平台，使行业供应商能够开发 RFID（射频标识）解决方案。这些行业供应商包括：系统集成商 (SI) 独立软件供应商 (ISV)独立硬件供应商 (IHV) 1.微软RFID开发平台及前景ppt文件下载2.BizTalk Server 2006系列课程 3.BizTalk Server 2009 评估版4.BizTalk Server 2009...

博客园_彭成东

Adventure Works示例数据库介绍

基于 SOA 的监测、诊断与预测系统架构

基于SOA的设备智能维护系统架构设计及实现

WCF基础知识问与答 （转载）

学习资源

Wcf概述

Wcf

参考资料1.MSDN .NET Framework Developer Center: WCF 2.MSDN Library: WCF Portal 3.http://dotnet.blog.51cto.com/272325/52076 本文中的示例均来自 MSDN Library: WCF Portal 中本文链接

用Visual C#创建Windows服务程序

VS2005没有源代码管理选项和菜单

RFID射频识别技术

微软RFID开发平台BizTalk资料收集

WCF基础知识问与答（转载）

参考资料
1.MSDN .NET Framework Developer Center: WCF
2.MSDN Library: WCF Portal
3.http://dotnet.blog.51cto.com/272325/52076
本文中的示例均来自 MSDN Library: WCF Portal 中
本文链接