endpoint WCF 终结点 宿主 WebAPI、WCFREST、WebService

WCF、WebAPI、WCFREST、WebService之间的区别.

在.net平台下,有大量的技术让你创建一个HTTP服务,像Web Service,WCF,现在又出了Web API。在.net平台下,你有很多的选择来构建一个HTTP Services。我分享一下我对Web Service、WCF以及Web API的看法。

  Web Service

  1、它是基于SOAP协议的,数据格式是XML

  2、只支持HTTP协议

  3、它不是开源的,但可以被任意一个了解XML的人使用

  4、它只能部署在IIS上

  WCF

  1、这个也是基于SOAP的,数据格式是XML

  2、这个是Web Service(ASMX)的进化版,可以支持各种各样的协议,像TCP,HTTP,HTTPS,Named Pipes, MSMQ.

  3、WCF的主要问题是,它配置起来特别的繁琐

  4、它不是开源的,但可以被任意一个了解XML的人使用

  5、它可以部署应用程序中或者IIS上或者Windows服务

  WCF Rest

  1、想使用WCF Rest service,你必须在WCF中使用webHttpBindings

  2、它分别用[WebGet]和[WebInvoke]属性,实现了HTTP的GET和POST动词

  3、要想使用其他的HTTP动词,你需要在IIS中做一些配置,使.svc文件可以接受这些动词的请求

  4、使用WebGet通过参数传输数据,也需要配置。而且必须指定UriTemplate

  5、它支持XML、JSON以及ATOM这些数据格式

  Web API

  1、这是一个简单的构建HTTP服务的新框架

  2、在.net平台上Web API 是一个开源的、理想的、构建REST-ful 服务的技术

  3、不像WCF REST Service.它可以使用HTTP的全部特点(比如URIs、request/response头,缓存,版本控制,多种内容格式)

  4、它也支持MVC的特征,像路由、控制器、action、filter、模型绑定、控制反转(IOC)或依赖注入(DI),单元测试。这些可以使程序更简单、更健壮

  5、它可以部署在应用程序和IIS上

  6、这是一个轻量级的框架,并且对限制带宽的设备,比如智能手机等支持的很好

  7、Response可以被Web API的MediaTypeFormatter转换成Json、XML 或者任何你想转换的格式。

  

  WCF和WEB API我该选择哪个?

  1、当你想创建一个支持消息、消息队列、双工通信的服务时,你应该选择WCF

  2、当你想创建一个服务,可以用更快速的传输通道时,像TCP、Named Pipes或者甚至是UDP(在WCF4.5中),在其他传输通道不可用的时候也可以支持HTTP。

  3、当你想创建一个基于HTTP的面向资源的服务并且可以使用HTTP的全部特征时(比如URIs、request/response头,缓存,版本控制,多种内容格式),你应该选择Web API

  4、当你想让你的服务用于浏览器、手机、iPhone和平板电脑时,你应该选择Web API

C# string 转换 endpoint 类型

string iStr ="192.168.0.1:1234";
System.Net.IPAddress IPadr=System.Net.IPAddress.Parse(iStr.Split(':')[0]);//先把string类型转换成IPAddress类型
System.Net.IPEndPoint EndPoint=new System.Net.IPEndPoint(IPadr,int.Parse(iStr.Split(':')[1]));//传递IPAddress和Port

EndPoint是一个抽象类,IPEndPoint继承自EndPoint。

WCF终结点——终结点地址(EndpointAddress)

 

终结点的地址的Uri属性作为终结点地址的唯一标示。

包括客户端终结点服务端终结点。

一、服务端终结点:

服务端的终结点通过宿主的添加方法暴露出来,从而成为可以调用的资源。

 

下面是将服务绑定到宿主的代码:

定义宿主时使用的是契约的实现类,也即服务类添加终结点到宿主的使用的是契约接口

1.1代码实现

代码实现往指定服务的宿主上添加终结点:

 

1.2配置实现

下面通过配置实现:

代码实现对应的配置如下:

 

 

1.3svc文件的配置

下面也给出svc文件中的配置:

由于svc文件被部署到了IIS上,所以对应的有端口,本身svc是一个文件,对应的也有路径,所以配置不用使用address字段

 

1.4获取宿主上的终结点

可以向一个宿主身上添加多个服务终结点,所以一个服务可以有多个终结点。每一个服务对应着一个宿主。当然可以获取所有的终结点。

宿主有个关于服务的描述属性,该属性包括了宿主的承载的所有服务终结点

1.5使用基地址+相对地址类添加契约终结点

当终结点比较多时,并且前面的部分相同时,可以通过基地址+相对地址类来添加终结点到宿主上面。

 

 

宿主这时也会根据使用的Binding类型的不同来区分请求的终结点。注意上面的一个是NetTcpBinding,一个是BasicHttpBinding。这就要求同一种绑定类型的基地址只能有一种,要不然会弄乱的。

下面是配置方式

 IIS来讲文件所在地点就是基地址:

 

1.6当一个服务同时实现了两个契约时,需要共享相同的地址,那么必须保证其绑定是同一个。方法是new一个绑定供两个终结点使用。

 

二、客户端终结点

客户端通过引用服务,最终生成了一个代理类:客户端服务代理类继承自ClientBase<TChannel>和TChannel,其中TChannel是和服务端等效的接口,不过名称是自动生成的,我们可以使用此代理类来操作数据;也可以通过ChannelFactory<TChannel>来创建代理类来操作数据。

下面看简单的看一下代理类的基类的部分构造方法和两个属性。下面的属性有个ChannelFactory<TChannel>,其实第一种方法的代理是通过ClientBase<TChannel>的属性创建的。
public abstract class ClientBase<TChannel>

{
        protected ClientBase();
        protected ClientBase(ServiceEndpoint endpoint);
        protected ClientBase(string endpointConfigurationName);
        protected ClientBase(Binding binding, EndpointAddress remoteAddress);
        protected ClientBase(string endpointConfigurationName, EndpointAddress remoteAddress);
        protected ClientBase(string endpointConfigurationName, string remoteAddress);

        protected TChannel Channel { get; }
        public ChannelFactory<TChannel> ChannelFactory { get; }
}

为什么客户端能调用服务端的方法类操作数据?

由构造函数来看主要是通过使用终结点来和服务端相对应,来让客户端能够找到服务端的对象。

下面给出客户端的终结点的第一种配置:

<system.serviceModel>
    <client>
      <endpoint name="myEndPoint"
                address="http://127.0.0.1/wcfservices/"
                binding="wsHttpBinding"
                contract="ServiceReference1.ICalculator">
      </endpoint>
    </client>
</system.serviceModel>
如果是使用上面的配置,那么就可以使用基类参数为endpointConfigurationName=myEndPoint的构造方法构造。

三、地址报头

每个终结点都含有一个Headers属性,客户端来说会被添加到请求消息的报头集合中,对于服务端来说,会提取响应的报头信息和本地终结点的地址报头来进行比较以选择出于请求消息相匹配的终结点。

地址报头的创建

AddressHeader CreateAddressHeader(string name, string ns, object value, XmlObjectSerializer serializer);

以下是服务端终结点的形状:

下面是如何使用地址报头的代码:

using (ChannelFactory<CalculatorService> channelFactory = new ChannelFactory<CalculatorService>("wsHttpBinding"))
          {
              CalculatorService calculator = channelFactory.CreateChannel();
              Uri uri = new Uri("http://127.0.0.1:3721/calculatorservice");
              AddressHeader header = AddressHeader.CreateAddressHeader("Licensed User", "http://www.artech.com", "UserType");
                  using (OperationContextScope operationContextScope=new OperationContextScope(calculator as IContextChannel))
              {
                  OperationContext.Current.OutgoingMessageHeaders.Add(header.ToMessageHeader());
                  double result = calculator.Divide(1, 2);
              }

}

如果AddressFilterMode为Any,报头可以不匹配。使用如下:

[ServiceBehavior(AddressFilterMode=AddressFilterMode.Any]
  public class CalculatorService:ICalculator

四、逻辑地址和物理地址

物理地址对于服务端来说是监听地址,对于客户端来说是真正发送的目标地址。

针对SOAP的消息交换来说,服务的逻辑地址是<To>报头的地址。

对于服务端来说物理地址和逻辑地址分离的表现在:用于监听地址和收到的消息TO报头的地址不一致。

在客户端表现逻辑地址和物理地址分离的表现:<To>的报头地址和消息真正发送目标地址不一致。

需要中介服务参与消息路由的通信就涉及物理地址和逻辑地址的分离。

对于服务消费者来说,消息发送的逻辑地址是针对服务的最终提供者的。

<endpoint address="http://127.0.0.1:5555/service1"
                 binding="basicHttpBinding"
                 contract="Artech.WcfServices.Service.Interface.ICalculator" />
       <!--2. BasicHttpBinding + ListenUriMode.Unique-->
       <!--6666加GUID-->
       <endpoint address="http://127.0.0.1:6666/service2"
                 binding="basicHttpBinding"
                 contract="Artech.WcfServices.Service.Interface.ICalculator"
                 listenUriMode="Unique" />
       <!--3. NetTcpBinding & ListenUriMode.Explicit-->
       <!--7777-->
       <endpoint address="net.tcp://127.0.0.1:7777/service3"
                 binding="netTcpBinding"
             contract="Artech.WcfServices.Service.Interface.ICalculator"/>
       <!--4. NetTcpBinding & ListenUriMode.Unique-->
       <!--会使用未占用的端口-->
       <endpoint address="net.tcp://127.0.0.1:8888/service4"
                 binding="netTcpBinding"
                 contract="Artech.WcfServices.Service.Interface.ICalculator"
                 listenUriMode="Unique" />
       <!--5. NetTcpBinding & ListenUriMode.Unique & Port Sharing-->
       <!--会使用原来的端口,后面加个GUID-->
       <endpoint address="net.tcp://127.0.0.1:9999/service5"
                 binding="netTcpBinding"
                 bindingConfiguration="PortSharingBinding"
                 contract="Artech.WcfServices.Service.Interface.ICalculator"
                 listenUriMode="Unique" />

上面的配置主要说明了监听地址和监听方式决定了最终的监听地址。

using (ServiceHost host = new ServiceHost(typeof(CalculatorService)))
            {
                host.Open();
                int i = 0;
                foreach (ChannelDispatcher channelDispatcher in host.ChannelDispatchers)
                {
                    Console.WriteLine("{0}: {1}", ++i, channelDispatcher.Listener.Uri);
                }
                Console.ReadKey();
            }

提供服务的主机,对应着一个或者多个分发器,每个分发器对应着一个或多个监听器。

wcf提供了4中类型的行为:1.服务行为、2契约行为、3终结点行为、4操作行为。行为是客户端或者服务端本地实现某个功能的一种方式,是一种单边的行为。

2和4被定义为特性。3只能通过配置,1可以声明和配置。1.服务行为,主要用于service behaviorConfiguration="" 。3.终结点行为主要用于终结点的endpoint endpointConfiguration=""

服务和终结点的行为配置如下:

 

终结点行为配置还可以如下:

<behaviors>
      <endpointBehaviors>
        <behavior name="aa" >
          <clientVia viaUri="http://127.0.0.1:55551/service1"/>
        </behavior>
      </endpointBehaviors>
    </behaviors>

上面的viaUri是代表的是物理地址,即消息真正发送的目的地址。

实现服务端逻辑地址和物理地址的分离的demo

 

 

客户端配置:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <bindings>
      <ws2007HttpBinding>
        <binding name="myBinding">
          <security mode="None"/>
        </binding>
      </ws2007HttpBinding>
    </bindings>
    <client>
      <endpoint name="calculatorservice"
             address="http://127.0.0.1:9999/calculatorservice"
             binding="ws2007HttpBinding"
             bindingConfiguration="myBinding"
             contract="Artech.WcfServices.Service.Interface.ICalculator"/>
    </client>
  </system.serviceModel>
</configuration>

服务端配置:

<system.serviceModel>
  <bindings>
    <ws2007HttpBinding>
      <binding name="myBinding">
        <security mode="None"/>
      </binding>
    </ws2007HttpBinding>
  </bindings>
  <services>
    <service name="Artech.WcfServices.Service.CalculatorService">
      <endpoint address="http://127.0.0.1:9999/calculatorservice"
                binding="ws2007HttpBinding"
                bindingConfiguration="myBinding"
                contract="Artech.WcfServices.Service.Interface.ICalculator"
                listenUri="http://127.0.0.1:8888/CalculatorService"
                listenUriMode="Explicit"/>
    </service>
  </services>
</system.serviceModel>

路由转发设置:监听9999,目的8888.To包含的是9999.

接下来是客户端逻辑地址和物理地址的分离的实例:

 

服务端

<system.serviceModel>
  <bindings>
    <ws2007HttpBinding>
      <binding name="myBinding">
        <security mode="None"/>
      </binding>
    </ws2007HttpBinding>
  </bindings>
  <services>
    <service name="Artech.WcfServices.Service.CalculatorService">
      <endpoint address="http://127.0.0.1:9999/calculatorservice"
                binding="ws2007HttpBinding"
                bindingConfiguration="myBinding"
                contract="Artech.WcfServices.Service.Interface.ICalculator"/>
    </service>
  </services>
</system.serviceModel>

客户端地址

<system.serviceModel>
  <behaviors>
    <endpointBehaviors>
      <behavior name="clientVia">
        <clientVia viaUri="http://127.0.0.1:8888/calculatorservice"/>
      </behavior>
    </endpointBehaviors>
  </behaviors>
  <bindings>
    <ws2007HttpBinding>
      <binding name="myBinding">
        <security mode="None"/>
      </binding>
    </ws2007HttpBinding>
  </bindings>
  <client>
    <endpoint name="calculatorservice"
           address="http://127.0.0.1:9999/calculatorservice"
           binding="ws2007HttpBinding"
           bindingConfiguration="myBinding"
           behaviorConfiguration="clientVia"
           contract="Artech.WcfServices.Service.Interface.ICalculator"/>
  </client>
</system.serviceModel>

路由转发从8888转到9999,双方的Address必须相同,为了让<To>内的地址相同。可以知道发送到哪里。

 

---

 

posted @ 2021-07-31 20:36  cao919  阅读(110)  评论(0编辑  收藏  举报