SOA 实现中的请求/响应模式 [英] Request/Response pattern in SOA implementation

问题描述

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

In some enterprise-like project (.NET, WCF) i saw that all service contracts accept a single Request parameter and always return Response:

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

[DataContract]
public class CustomerResponse : ResponseBase {
        [DataMember]
        public CustomerInfo Customer { get; set; }
}

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

where RequestBase/ResponseBase contain common stuff like ErrorCode, Context, etc. Bodies of both service methods and proxies are wrapped in try/catch, so the only way to check for errors is looking at ResponseBase.ErrorCode (which is enumeration).

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

I want to know how this technique is called and why it's better compared to passing what's needed as method parameters and using standard WCF context passing/faults mechanisms?

推荐答案

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

The pattern you are talking about is based on Contract First development. It is, however not necessary that you use the Error block pattern in WCF, you can still throw faultexceptions back to the client, instead of using the Error Xml block. The Error block has been used for a very long time and therefore, a lot of people are accustom to its use. Also, other platform developers (java for example) are not as familiar with faultExceptions, even though it is an industry standard.
http://docs.oasis-open.org/wsrf/wsrf-ws_base_faults-1.2-spec-os.pdf

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

The Request / Response pattern is very valuable in SOA (Service Oriented Architecture), and I would recommend using it rather than creating methods that take in parameters and pass back a value or object. You will see the benefits when you start creating your messages. As stated previously, they evolved from Contract First Development, where one would create the messages first using XSDs and generate your classes based on the XSDs. This process was used in classic web services to ensure all of your datatypes would serialize properly in SOAP. With the advent of WCF, the datacontractserializer is more intelligent and knows how to serialize types that would previously not serialize properly(e.g., ArrayLists, List, and so on).

请求-响应模式的好处是:

The benefits of Request-Response Pattern are:

• 您可以从基础对象继承您的所有请求和响应，您可以在其中维护公共属性(例如错误块)的一致性.
• Web 服务本质上应该需要尽可能少的文档.这种模式允许这样做.以像 public BusScheduleResponse GetBusScheduleByDateRange(BusDateRangeRequest request); 这样的方法为例，客户端会默认知道传入什么以及返回什么，并且在构建请求时，他们可以看到什么是必需的，什么是可选的.假设此请求具有 Carriers [Flag Enum](必需)、StartDate(Required)、EndDate(Required)、PriceRange(可选)、MinSeatsAvailable(Option)等属性……您明白了.
• 当用户收到响应时，它可以包含比通常的返回对象更多的数据.错误块，跟踪信息，不管怎样，发挥你的想象力.
  在 BusScheduleResponse 示例中，这可以返回多个运营商的巴士时刻表信息的多个数组.

• You can inherit all of your request and responses from base objects where you can maintain consistency for common properties (error block for example).
• Web Services should by nature require as little documentation as possible. This pattern allows just that. Take for instance a method like public BusScheduleResponse GetBusScheduleByDateRange(BusDateRangeRequest request); The client will know by default what to pass in and what they are getting back, as well, when they build the request, they can see what is required and what is optional. Say this request has properties like Carriers [Flag Enum] (Required), StartDate(Required), EndDate(Required), PriceRange (optional), MinSeatsAvailable(Option), etc... you get the point.
• When the user received the response, it can contain a lot more data than just the usual return object. Error block, Tracking information, whatever, use your imagination.
  In the BusScheduleResponse Example, This could return Multiple Arrays of bus schedule information for multiple Carriers.

希望这会有所帮助.

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

One word of caution. Don't get confused and think I am talking about generating your own [MessageContract]s. Your Requests and Responses are DataContracts. I just want to make sure I am not confusing you. No one should create their own MessageContracts in WCF, unless they have a really good reason to do so.

这篇关于SOA 实现中的请求/响应模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！