Question

我们需要设计和描述分布式系统的接口，其中一部分将在.NET中实现（很可能是WCF）。除了特定于方法的属性之外，每个WS调用还需要接受/提供一些公共属性（例如，请求的认证令牌或分页参数，或响应的版本和错误信息）。将有数十到数百个不同的WS调用。我们还希望使用WIF或类似技术来理解SAML令牌和身份联合。

我的首选方法是（目前为止）使用XML结构，每个调用都有一些通用标头和一个变量主体，例如

<Request>
   <Header>
     <Paging>...</Paging>
     ...
   </Header>
   <Body method="GetInvoices">
     <!-- specific attributes for GetInvoices web method -->
   </Body>
</Request>

问题：

这是一个好方法还是你推荐另一个？
如何应用现有的.NET技术，以便尽可能简化/自动化处理这种格式，即
- 编写特定调用的接口并为正文部分生成服务/模式描述（类似于WCF从方法合同生成WSDL服务描述的方式）
- 在收到XML时解析XML，将其转换为使用正确参数的所需方法的调用（我不想最终得到的是一个带有大开关和100个案例的大方法......）

更新（1.7.2014）

我的问题提法可能有些模糊。我正在努力解决的真正问题是能够应用现成的.NET技术来生成服务（即定义服务契约并让VS生成WSDL服务描述等）但同时使消息格式足够灵活允许添加一些我打算单独处理的带外信息。

例如，我想在标题中包含身份验证数据（不确定是以哪种形式 - 可能是某些身份验证令牌或SAML）。然后我想拦截请求，然后在相应的Web方法中实际结束并拒绝它或根据认证数据设置一些上下文，以便web方法可以依赖于上下文。对于适用的Web方法中的分页或响应的成功/失败消息也是如此。

为了互操作性/通用性，我开始使用“纯粹的”XML方法，但现在我可以想象一个更好的解决方案是扩展这样的常见SOAP消息格式：

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <s:Header>
       <!-- out of band data -->
   </s:Header>
   <s:Body>
      <GetInvoices xmlns="http://tempuri.org/">
          <!-- arguments  of GetInvoices() -->
      </GetInvoices >
   </s:Body>
</s:Envelope>

那么问题是，这是否有意义以及它是否可以在WCF中实现（如何）？

Answer 1

我认为根据您的要求并根据您的方案说明Workflow Service 可以很好地匹配您现有的要求，特别是如果您不完全确定合同，合同即时实施。如果您处于项目的初始阶段并且不确定您的运营合同，此工具可以灵活地为您提供高水平的灵活性。此外，您可以组合WCF和WF以获得有状态服务，该服务可以与订阅该服务的客户进行交互。

Answer 2

System.ServiceModel中有一种机制，允许您定义包含具有多个子类的基类的服务数据协定。

此模型通过ServiceKnownType属性启用，并实现：

[DataContract]
public class MyBaseType
{
    ...
}

[DataContract]
public class MyDerivedType : MyBaseType
{
    ...
}

[ServiceKnownType(typeof(MyDerivedType))]
public class MyServiceImplementation : IMyServiceContract
{
    public MyBaseType GetADerivedType()
    {
        return new MyDerivedType();
    } 
}

然而，作为＆＃34;已知＆＃34;的数量类型增长（你说100＆＃39; s），这个列表变得庞大而且难以处理，添加新类型意味着你必须不断重新部署你的服务。

你可以实现一个解析器来处理这个问题（就像所描述的那样here），但它仍然需要一些时髦的IoC来实际在运行时加载所有可能的类型并注入它们以避免重新编译随着每次变化。

老实说，我认为这里的问题是你说你正试图定义一种＆＃34; SOA消息格式＆＃34;但这究竟是什么意思呢？

如果您计划在单个服务上公开300多种类型，那么对我来说，这表明服务是在错误的级别组成的 - 即您在运行时会有动态解析请求被解释为对某些数据的较低级别的CRUD操作。

这类似于将端点用作某种存储库，除非您完全脱离数据（例如通过互联网），否则我会直接转到数据库。

服务合同被称为合同的原因是，为了使用该服务，消费者必须同意实施满足其特定需求的特定接口，这些接口由服务表示。操作水平。

理想情况下，服务运营应该在业务能力层面进行组合。在您的示例中， GetInvoices（）并未真正向我解释正在提供业务的部分或需求。一个更好的例子是

GetInvoicesForApprovalByHR(SomeInvoiceSelector x)

或者即使获得发票的实际工作都包含在更高级别的电话中，例如

StartHRApprovalWorkflowForUser(User x)

此级别的示例可能完全超出您当前的范围，如果是这样，我很抱歉，但这里的重点是接口组合无疑是对分布式解决方案拥有成本的最大影响之一。

Answer 3

我决定使用标准的SOAP消息格式，将带外的位和部分添加到SOAP标头中。

对于实现，我使用WCF扩展机制，即自定义行为，消息检查器和元数据导出扩展。这样我就可以在代码中定义所有接口，使用自定义属性标记受影响的服务/操作契约，不仅利用现有的WCF技术生成WSDL，还可以根据我的特定需求更改WSDL生成，以便服务元数据包含所有添加的信息都用于生成服务代理客户端。

作为对此的概述文章，我推荐MSDN杂志文章"Extending WCF with Custom Behaviors"以及一些.NET代码示例如何做this文章（用例类似于我的分页示例）参数）。

SOA消息格式的最佳实践，在.NET中具有常见的+特定属性

3 个答案: