WCF为REST服务的寄宿提供了一个新的ServiceHost，即WebServiceHost。WebServiceHost是ServiceHost的子类，而WebServiceHostFactory是对应的ServiceHostFactory，在基于IIS/WAS寄宿中被使用。由于对REST服务绝大部分功能的支持都是通过WebHttpBehavior这么一个终结点行为实现的，所以WebServiceHost的核心功能就是将该终结点行为应用到寄宿服务的所有终结点。除此之外，WebServiceHost还具有
REST服务采用面向资源的架构，而资源通过URI进行标识和定位，所以URI在REST中具有重要的地位。对于WCF来说，服务调用请求的URI映射为某个具体的操作，所以服务端需要解决的是如何根据请求URI选择出对应的操作。如果采用SOAP，操作的选择是根据消息的<Action>报头来实现的，那么REST服务又采用怎样的操作选择机制呢？ 目录 一、URI模板 二、UriTemplate 三、UriTemplateTable 四、WebHttpDispatchOper
相较 WCF、WebService 使用 SOAP、WSDL、WS-* 而言，几乎所有的语言和网络平台都支持 HTTP 请求。我们无需去实现复杂的客户端代理，无需使用复杂的数据通讯方式既可以将我们的服务暴露给任何需要的人，无论他使用 VB、Ruby、JavaScript，甚至是 HTML FORM，或者直接在浏览器地址栏输入。 WCF 3.5 引入了 WebGetAttribute、WebInvokeAttribute、UriTemplate 来增加对 REST 的支持，这使得我们用很简单的方式就可以实现
多年之前，我写了一篇通过WCF扩展实现上下文信息从客户端自动传递到服务端的文章，其实现机制很简单：将上下文信息存放到SOAP Header进行传递。那么对于非SOAP消息的RESTful服务就不使用了。为了解决非SOAP消息的RESTful服务这个问题，我们可以将存放上下文信息的地方从SOAP Header替换成HTTP Header。这篇为你消息讲述具体的实现[源代码从这里下载]。 目录 一、 Ambient Context 二、ApplicationContext
不论是我们采用SOAP还是REST架构风格，运行时框架体系依然不曾改变，终结点也仍旧是通信的核心。在Web HTTP编程模型中，我们采用基于WebHttpBinding绑定的终结点。绑定是一组相关绑定元素的有序组合，绑定的特性与能力决定于它包含的绑定元素，在这里我们通过分析绑定元素的方式来剖析WebHttpBinding绑定与其它绑定有何不同。采用HTTP/HTTPS通信协议的WebHttpBinding具有一些与WSHttpBinding/WS2007HttpBinding相同的属性，在这里我们只关心如下
最后一章将进行WCF扩展和新特性的学习，这部分内容有一定深度，有一个基本的了解即可，当需要自定义一个完整的SOA框架时，可以再进行细致的学习和实践。 服务端架构体系的构建主要包含接下来的几个要素：服
原创地址：http://www.cnblogs.com/jfzhu/p/4044813.html
You can expose the service in two different endpoints. the SOAP one can use the binding that support SOAP e.g. basicHttpBinding, the RESTful one can use the webHttpBinding. I assume your REST service will be in JSON, in that case, you need to configure the
JSONP（JSON with Padding）可以看成是JSON的一种“使用模式”，用以解决“跨域访问”的问题，这篇简单的文章给出一个简单的例子用于模拟如何通过jQuery以JSONP的访问调用一个WCF REST服务。[源代码从这里下载] 在这个例子中，我们将定义一个用于返回所有员工信息的服务，下面是用于表示员工信息的Employee的类型和契约接口。契约接口IEmployees的GetAll操作用以返回所有员工列表，我们指定了Uri模板并将回复消息格式设置为JSON。 1: using Syst
之前介绍了基于SOAP的Web服务，接下来将介绍基于REST的轻量级的Web服务。 REST(Representational State Transfer)与技术无关，代表一种软件架构风格，可以成
一直在为安卓和苹果写服务，刚开始的时候全用的Get请求用url传所有的参数，由于url长度的限制大的数据量 无法传到服务器，提交图片什么的就更不用说了，后来用的POST请求，记录一下，做了一个很简单的小例子： c#源代码提供大家下载 10Solution4.rar ios代码 IOSHttpPostDemo.rar 开始做吧！ 1建一个空工程Solution4，添加一个类库WcfSerDemo引入 System.ServiceModel 和System.ServiceModel.Web两个类库 建一个接
2022年4月28日，我们达到了一个重要的里程碑，并发布了CoreWCF的1.0.0版本。对Matt Connew (微软WCF团队成员)来说，这是5年前即 2017年1月开始的漫长旅程的结束。Matt Connew 用3 周的时间来构建一个基于 .NET Core 的 WCF 服务实现的POC 基本原型。在3周结束时，Matt Connew 有了一个可以工作的玩具，可以使用BasicHttpBinding托管服务。然后，Matt Connew 的原型作为概念证明坐在那里收集灰尘，同时决定如何处理它。.NET团队在2019年的Build 大会上 已经决定了不在继续在.NET Core中支持WCF，这也是微软官宣的事情，我想大家都记忆尤新，没有资源将这个玩具开发为具有与 WCF 功能奇偶校验的完整产品，但是有许多客户 无法在不对其WCF服务进行完全重写的情况下迁移到 .NET Core。 Matt Connew最终决定 将花一些时间打磨一下的原型实现，包括添加NetTcp支持，并将代码捐赠给开源社区，托管到.NET基金会，看看这是否社区将围绕它构建的东西，以便在Microsoft之外生存下去。
可以说WebHttpBinding和WebHttpBehavior是整个Web HTTP编程模型最为核心的两个类型，前者主要解决消息编码问题，而余下的工作基本上落在了终结点行为WebHttpBehavior上。WebHttpBehavior属性HelpEnabled和AutomaticFormatSelectionEnabled是“帮助页面”与“自动消息格式选择”这两个特性的总开关。[“自动消息格式(JSON/XML)选择”源代码从这里下载] 1: public class WebHttpBehavi
其中<service>节点中的name属性,是实现了服务契约的类型名,类型名必须是完整的,要包括名称空间 <endpoint>节点的address属性为空,说明使用基地址. behaviorConfiguration属性与behavior节点的name属性相匹配 binding属性说明WCF服务使用什么协议,这里是HTTP协议 contract属性是描述契约的接口名称,也必须是完整的.如果没有接口直接写实现契约的类型名也可以(我这里就是这样).
WCF寄宿方式是一种非常灵活的操作，可以在IIS服务、Windows服务、Winform程序、控制台程序中进行寄宿，从而实现WCF服务的运行，为调用者方便、高效提供服务调用。本文分别对这几种方式进行详细介绍并开发例子进行说明，以求大家对WCF寄宿的方式进行全面的认识和了解。 1、 WCF服务的IIS服务寄宿 我在我前面几篇WCF开发框架的介绍文章中，介绍过了WCF常用的一种寄宿方式，IIS服务寄宿。这种寄宿方式是最为方便的方式，而且由于服务只需要IIS运行就能自动运行起来，因此广为使用。 创建这种方式IIS
如果你安装了 VS 2010 的 Silverlight 4 开发工具，会发现一项重量级的安装项目，WCF RIA Services，用于Silverlight数据访问服务，比WCF和ADO.NET Data Service和Web服务都要简单. 在一个三层架构的应用程序中，中间层介于表示层和数据层之间，你所写的业务逻辑和数据验证都将在中间层出现。创建拥有良好用户体验的RIA应用，你需要客户端和服务端有着相同的业务规则，因此在客户端和服务端保证同步的中间层变得至关重要。WCF RIA Services可以让
REST并非是标准而是一种再互联网环境下开发提供服务的方法规范。REST 遵循 web 应用程序的体系结构风格,用户通过类似于选择翻页链接去往下一页的方式访问web应用程序。REST基于唯一URI标识的资源。 只要服务遵从定义的标准或特性，我们可以将这个服务称为 rest。REST 并不与任何特定的平台联系在一起, 当前在Web上使用 HTTP 完成的。 REST基础特征 客户端 关注点分离是将用户界面与数据存储分离的原则。这使得程序的用户界面能够移植到其他的平台,并通过简化服务器组件来提高可伸缩性。 无状
webhttpbinding是REST风格的绑定，您只需点击一个URL，然后从Web服务中获取大量XML或JSON。
今天介绍WCF 4.0的另外两个新特性：标准终结点（Standard Endpoint）和无(.SVC)文件服务激活（File-Less Activation）。前者实现了针对典型通信场景对终结点的定制，后者让你在进行IIS/WAS的服务寄宿中无须定义.svc文件。 一、标准终结点 我们知道，绑定的本质就是一系列相关绑定元素的有序集合，而系统绑定就是基于若干典型的通信场景对相关绑定元素的整合。WCF通过系统绑定对绑定元素进行了定制，那么能否在终结点级别对组成该终结点的ABC（地址、绑定和契约）也进行相应的定
微软在WCF 3.5中就通过提供基于Web HTTP的编程模式使我们很容易地创建基于REST的服务，WCF 4.0中对此进行了较大的改进。为了让读者对REST在WCF中的应用有一个大致的了解，我们先来进行一个简单的实例演示。 [源代码从这里下载] 一、定义服务契约 在这个实例中，我们创建一个简单的服务来管理员工的基本信息。至于实例程序的结构，我们依然采用熟悉的包含三个项目（Service.Interface、Service和Client）的解决方案。如下所示的是定义在Service.Interface中用于
SharePoint 2013为开发者提供了丰富的REST API，方便了我们在客户端操作List中的数据。当然我们也可以在SharePoint 2013中创建自定义的REST Service，比如通过REST Service去操作数据库。本篇博客将介绍怎样在SharePoint 2013创建WCF REST Service。 SharePoint 中 创建WCF Service 因为无法在SharePoint 2013 Project中添加WCF Service Template，所以预先创建一个WCF
WCF的承载既可以通过编码实现,也能够通过配置实现.而且使用配置,更有利于日后的维护和扩展。我们经常会碰到这样的一个场景：需要把WCF的配置信息放在一个单独的文件中，这种情况经常出现在需要为自己开发的服务配置，需要采用独立的配置文件，而不是只能放到app.config/web.config中。.NET提供了一种机制是通过ConfigSource。例如在asp.net的在站点的默认 Web.Config 文件中使用： <appSettings configSource="customAppSetting.co
整个WCF框架由两个基本的层次构成，即服务模型层和信道层。对信道层的扩展主要通过针对绑定的扩展实现，具体来说就是自定义绑定元素，以及相关的信道管理器（信道监听器和信道工厂）、信道来改变对消息的处理和传输方式。 而对于服务模式型层的扩展则主要体现服务端和客户端运行时框架的定制，进而让WCF按照我们希望的方式进行运作。由于整个运行时框架由一系列的可扩展组件构成，并且大部分运行时属性也可以改写，所以针对服务模型层的扩展具体体现在：根据具体的需要定义相应的组件，并以某种情形将这些自定义的组件应用到运行时框架相应的地
服务通过 ServiceHost 进行寄宿。可以添加终结以暴露可被调用寻址和调用的资源。
任何一个程序都需要运行于一个确定的进程中，进程是一个容器，其中包含程序实例运行所需的资源。同理，一个WCF服务的监听与执行同样需要通过一个进程来承载。我们将为WCF服务创建或指定一个进程的方式称为服务寄宿（Service Hosting）。服务寄宿的本质通过某种方式，创建或者指定一个进程用以监听服务的请求和执行服务操作，为服务提供一个运行环境。 服务寄宿的方式大体分两种：一种是为一组WCF服务创建一个托管的应用程序，通过手工启动程序的方式对服务进行寄宿，所有的托管的应用程序均可作为WCF服务的宿主，比如C
关于如何解决分布式系统中的跨时区问题，上一篇详细介绍了解决方案的实现原理，在这一篇中我们通过一个完整的例子来对这个问题进行深入探讨。尽管《原理篇》中介绍了那么多，解决方案的本质就是：在进行服务调用过程中将客户端的时区信息作为上下文传入服务端，并以此作为时间转换的依据。我们首先定一个具体的类型来定义包含时区信息的上下文类型，我们将这个类型起名为ApplicationContext。 一、通过CallContext实现ApplicationContext 在《通过WCF扩展实现Context信息的传递》一文中，
元数据的导出就是实现从ServiceEndpoint对象向MetadataSet对象转换的过程，在WCF元数据框架体系中，元数据的导出工作由MetadataExporter实现。MetadataExporter是一个抽象类型，定义了导出元数据的基本行为。WCF定义一个具体的MetadataExporter：WsdlExporter，将基于某个终结点的元数据导出生成基于WSDL的MetadataSet。我们先来认识MetadataExporter和MetadataSet。 一、MetadataExporte
对WCF的可靠会话编程有一定了解的人应该知道，我们可以使用 DeliveryRequirementsAttribute 可以指示WCF确认绑定提供服务或客户端实现所需的功能。如果在从应用程序配置文件加载服务说明或在代码中以编程方式生成服务说明时检测到 DeliveryRequirementsAttribute 属性，则 WCF 会验证所配置的绑定，并支持该属性指定的所有功能。例如，您的服务可能要求绑定支持队列。使用 DeliveryRequirementsAttribute 可以让WCF 确认是否满足下列要
在WCF中，每个终结点都包含两个不同的地址——逻辑地址和物理地址。逻辑地址就是终结点Address属性表示的地址。至于物理地址，对于消息发送放来讲，就是消息被真正发送的目的地址；而对于消息的接收放来讲，就是监听器真正监听的地址。 一、服务端的物理地址 在默认的情况下，终结点的逻辑地址和物理地址是同一个URI。换句话说，终结的逻辑地址是必须的，如何物理地址没有指定的，默认使用逻辑地址作为物理地址。对于消息接收方的终结点来讲，物理地址就是监听地址，通过ServiceEndpoint的ListenUri表示：
在上篇中，我详细介绍了如何通过自定义ClientMessageInspector和ErrorHandler，实现WCF与微软企业库中的Exception Handling Application Block（EHAB）之间的集成。这个方案的基本思路就是：当异常从服务端抛出，利用EHAB针对某个配置好的异常处理策略进行处理；然后将处理有的异常通过ServiceExceptionDetail对象进行封装，最后序列化置于Fault消息，最终被返回给客户端；客户端接收到该Fault消息后，提取并创建ServiceE
从 .NET 3.5 开始 WCF 已经支持用 WebHttpBinding 构建 RESTful Web 服务，基于 WCF 框架的 RESTful Web 服务还是建立在 WCF Message 栈上，还是基于RPC风格的，因为 REST 的工作原理有所不同，它不需要依赖 SOAP 协议，因此 WCF 消息管道对于它经过了特殊的消息优化。但 REST 集成在 WCF 消息管道上还是不理想，所以微软重新开始构造基于Http 协议特点的RESTful的Web API, 从2010年10月份开始把代码放在co
在上一篇文章中，我们通过自定义InstanceProvider实现了WCF和微软Enterprise Library Unity Application Block的集成， 今天我们已相同的方式实现WCF与Enterprise Library的另一个Application Block的集成：Policy Injection Application Block (PIAB)。
随着Aspire发布preview5的发布,Microsoft.Extensions.ServiceDiscovery随之更新,
昨天有人在微博上问我如下一个问题： 老蒋，客户端调用wcf的一个接口函数时，有没有什么办法可以先弹出一个确认框，确认后再执行调用。因为这个接口函数再很多地方都执行了调用，所以我想在某个入口进行统一地
从 Visual Studio 2005 开始有个非常好用的功能, 就是在 debug 的时候, 可以用Visualizer 很方便的查看某些类型的参数, 比如说 Text Visualizer, XML Visualizer, HTML Visualizer 等等, VS2008还针对了 IEnumerable 类型对象也提供了查看的能力. WCF Visualizers 可以查看WCF的各种对象,是WCF开发的必备工具之一,WCF Visualizers 主要提供下列Visualizers: 1. M
在这之前，我写过深入介绍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前一个版本，在新的版本中（EnterLib V4.1与Unity 1.2）中，MS通过Unity对PIAB进行了重新设计与实现，所以我们很有必要重拾着这个话题，谈谈对于新的EnterLib和Unity，如何将PIAB和Unity集成到WCF之中。（Source Code从这里下载）
在前面的学习中我们可以了解到，执行器的任务执行都是在触发器触发下执行的。对于触发器如何路由、具体的调度策略等等我们后面再进行学习，本章的重点是来看一看执行器是如何被调用以及执行任务的。
RESTful Wcf是一种基于Http协议的服务架构风格, RESTful 的服务通常是架构层面上的考虑。 因为它天生就具有很好的跨平台跨语言的集成能力，几乎所有的语言和网络平台都支持 HTTP 请求，无需去实现复杂的客户端代理，无需使用复杂的数据通讯方式既可以将我们的服务暴露给任何需要的人，无论他使用 VB、Ruby、JavaScript，甚至是 HTML FORM，或者直接在浏览器地址栏输入
我们有两种典型的WCF调用方式：通过SvcUtil.exe（或者添加Web引用）导入发布的服务元数据生成服务代理相关的代码和配置；通过ChannelFactory<TChannel>创建服务代理对象。在这篇文章中，我们采用一种独特的方式进行服务的调用。从本质上讲，我们只要能够创建于服务端相匹配的终结点，就能够实现正常的服务调用。在WCF客户端元数据架构体系中，利用MetadataExchangeClient可以获取服务的元数据，而利用MetadataImporter将获取的元数据导入成ServiceEndp
本文提出了一种检测WCF服务是否在线的方法，通过使用一个假的contract接口以及一个用于创建调用通道的工厂，避免了在配置文件中添加endpoint信息和真正的contract接口文件。该方法可以快速地检测服务是否在线，同时避免了繁琐的配置和复制文件等工作。
在采用TLS/SSL实现Transport安全的情况下，客户端对服务证书实施认证。但是在默认情况下，这种认证仅仅是确保服务证书的合法性（通过数字签名确保证书确实是由申明的CA颁发）和可信任性（证书或者CA证书存储于相应的可信赖存储区）。而WCF提供服务证书并不限于此，客户端对服务认证的模式应该是这样的：服务端预先知道了服务的身份，在进行服务调用之前，服务端需要提供相应的凭证用以辅助客户端确认调用的服务具有预先确定的身份。对于这样的服务认证模式，具有两个重要的概念，即服务凭证和服务身份。 目录：
在《WCF技术剖析（卷1）》的最后一章，我给出了一个具体的应用WCF的分布式应用实例，我把这个实例命名为PetShop。在这个例子中，我利用WCF的扩展实现了一些设计、架构模式，比如AOP、IoC等。看过本书的读者，一定还记得我还通过WCF扩展实现了于微软企业库（Enterprise Library）异常处理应用块（Exception Handling Application Block：EHAB）的集成。当时由于缺乏相应的背景知识，不可能介绍具体的实现，现在我们可以详细来讲述这是如何实现的。 （Sourc
松耦合、高内聚是我们进行设计的永恒的目标，如何实现这样的目标呢？我们有很多实现的方式和方法，不管这些方式和方法在表现形式上有什么不同，他们的思想都可以表示为：根据稳定性进行关注点的分离或者分解，交互双方依赖于一个稳定的契约，而降低对对方非稳定性因素的依赖。从抽象和稳定性的关系来讲，抽象的程度和稳定程度成正相关关系。由此才有了我们面向抽象编程的说法，所以“只有依赖于不变，才能应万变”。 然后，对于面向对象的思想来讲，我们的功能通过一个个具体的对象来承载。对象是具体的，不是抽象的；创建对象是必然的；对象的创建从
任务的绑定的执行器，任务触发调度时将会自动发现注册成功的执行器, 实现任务自动发现功能; 另一方面也可以方便的进行任务分组。每个任务必须绑定一个执行器, 可在 "执行器管理" 进行设置;
WCF的服务端架构体系又可以成为服务寄宿端架构体系。我们知道，对于一个基于某种类型的服务进行寄宿只需要使用到一个唯一的对象，那就是ServiceHost。甚至在某种语境下，我们所说的服务实际上就是指的对应的ServiceHost对象。整个服务寄宿过程包括两个阶段，即服务描述的创建和服务端运行框架的建立。而第一个阶段创建的服务描述是为了第二个阶段对服务端运行时框架建立服务的，所以我们有必要在对服务描述进行简单的介绍。 目录： 一、从服务描述（Service Description）谈起
Jenkins Pipline执行过程，需要实时获取持续集成-静态代码扫描的结果，以确定扫描结果是否符合既定的要求。通过在SonarQube中设定与Jenkins的WebHook，即可解决这个问题。
Windows® Communication Foundation (WCF) 提供了许多扩展点，供开发人员自定义运行时行为,从而实现服务调度和客户代理调用。您可以通过编写能以声明方式应用到服务中的自定义行为来使用这些扩展点。本月将为您介绍这一流程的工作原理。 WCF 可扩展性 在上期专栏中，我重点介绍了 WCF 绑定概念，您可以为 WCF 服务上的各个终结点指定绑定。绑定控制该终结点的消息传递详细信息（发生在网络上的情况）。这是 WCF 建立一个能够在字节流（网络上的消息）和 WCF 消息间转换的通道堆栈
若确保上述self-host server能运行，需要用管理员权限开一个powershell，运行：
关于AutoPWN-Suite AutoPWN-Suite是一款功能强大的自动化漏洞扫描和利用工具，在该工具的帮助下，广大研究人员可以轻松通过自动化的方式扫描和利用目标系统中潜在的安全漏洞。 功能介绍 1、实现了完全自动化（使用-y选项开启）； 2、无需用户输入即可检测全范围网络IP； 3、基于版本的漏洞检测； 4、Web应用漏洞测试； 5、支持从终端获取跟漏洞相关的信息； 6、自动下载与漏洞相关的漏洞利用代码； 7、提供了在网络中制造噪声的噪声模块； 8、提供绕过/规避功能； 9、根据权限自动决定
客户端调用WCF服务的方式不外乎有两种：其一、通过代码生成工具（比如SvcUtil.exe）导入服务的元数据生成服务代理相关的类型；其二、通过ChannelFactory<TChannel>创建服务代理对象。对于前者，生成的服务代理是一个继承自ClientBase<TChannel>的类型。对于这样一个服务代理对象，其内部本质上还是借助于ChannelFactory<TChannel>创建真正用于进行服务调用的代理对象。对于WCF客户端应用编程接口来说，ChannelFactory<TChannel>是一个
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
