SOA实现中的请求/响应模式

Use*_*rol 17 wcf soa

在一些类似企业的项目(.NET,WCF)中,我看到所有服务契约都接受一个Request参数并始终返回Response:

[DataContract]
public class CustomerRequest : RequestBase {
        [DataMember]
        public long Id { get; set; }
}

[DataContract]
public class CustomerResponse : ResponseBase {
        [DataMember]
        public CustomerInfo Customer { get; set; }
}
Run Code Online (Sandbox Code Playgroud)

其中RequestBase/ResponseBase包含像ErrorCode,Context等常见的东西.服务方法和代理的实体都包含在try/catch中,因此检查错误的唯一方法是查看ResponseBase.ErrorCode(枚举).

我想知道如何调用这种技术以及为什么它比传递所需的方法参数和使用标准的WCF上下文传递/故障机制更好?

CkH*_*CkH 28

您所谈论的模式基于Contract First开发.但是,在WCF中使用错误块模式并不是必需的,您仍然可以将faultexceptions返回给客户端,而不是使用Error Xml块.Error块已经使用了很长时间,因此很多人都习惯使用它.此外,其他平台开发人员(例如java)并不熟悉faultExceptions,即使它是行业标准.
http://docs.oasis-open.org/wsrf/wsrf-ws_base_faults-1.2-spec-os.pdf

请求/响应模式在SOA(面向服务的体系结构)中非常有价值,我建议使用它而不是创建接收参数并传回值或对象的方法.开始创建消息时,您将看到好处.如前所述,它们是从契约优先开发发展而来的,首先使用XSD创建消息并根据XSD生成类.此过程在经典Web服务中使用,以确保所有数据类型都在SOAP中正确序列化.随着WCF的出现,datacontractserializer更加智能,并且知道如何序列化以前不能正确序列化的类型(例如,ArrayLists,List等).

Request-Response模式的好处是:

  • 您可以从基础对象继承所有请求和响应,您可以在其中维护公共属性的一致性(例如,错误块).
  • Web服务本质上需要尽可能少的文档.这种模式就是这样.例如public BusScheduleResponse GetBusScheduleByDateRange(BusDateRangeRequest request); ,客户端将默认知道要传递什么以及他们返回的内容,以及在构建请求时,他们可以看到需要什么以及什么是可选的.假设此请求具有Carriers [Flag Enum](必需),StartDate(必需),EndDate(必需),PriceRange(可选),MinSeatsAvailable(Option)等属性...您明白了这一点.
  • 当用户收到响应时,它可以包含比通常的返回对象更多的数据.错误块,跟踪信息,无论如何,使用你的想象力.
    在BusScheduleResponse示例中,这可以返回多个运营商的多个公交车时刻表信息阵列.

希望这可以帮助.

一句谨慎.不要混淆,并认为我在谈论生成自己[MessageContract]的.您的请求和响应是DataContracts.我只是想确保我不会让你感到困惑.没有人应该在WCF中创建自己的MessageContracts,除非他们有充分的理由这样做.

  • 只是为了增加好处,这是我最喜欢的一个.*DataContracts比OperationContracts更容易修改(更容易版本).如果添加参数,则需要更改OperationContract,这对于旧消费者来说是一个重大变化.如果向DataContract添加属性,旧版本仍然可以工作(如果编码正确). (4认同)