WCF ChannelFactory是否违反了SOA原则？

Question

共享一个包含wcf接口和数据契约的项目并通过ChannelFactory使用它们来使用服务是否违反了面向服务架构的原则？

我的架构师建议使用Add Service Reference生成代理更可取。

Answer 1

我猜这取决于一些东西:你的基础设施，安全策略，治理，等等。

我们设计WSDL(服务和消息约定)和XML (数据约定)，然后使用svcutil.exe*生成代理。在这一点上，我们有了代码，我们可以用来消费或建立服务。当然，我只是在谈论代码，output.config将在决定时使用适当的行为、绑定和端点进行修改。

一旦服务建立起来，它前面就有一个XML网关。在这一点上，我们可以开始使用“添加服务引用...”来测试服务。如果您只是想节省一些时间，并将预先生成的代理或WSDL不公开给其他人(因为它们位于不响应它们的XML网关的后面)，那么您所做的似乎没有问题。

否则，我希望消费者能够“添加服务引用...”并生成自己的客户端。

*基于Java的应用程序使用其他东西(WSDL2Java/ClientGen/内置IDE工具)。

Answer 2

共享预打包的服务接口和数据契约并不违反SOA原则，只要消费服务不会使用它。这正是使潜在客户能够针对现有的第三方服务加速开发，或针对尚未构建的服务开始开发的原因。以代码格式提供接口/数据契约将比仅通过文档描述这些内容更加明确(当然，如果客户端使用不同的编程语言，它们可能不会有用)。

但是，如果在共享包中提供了某种服务接口的预打包实现，并且需要使用此实现才能成功使用服务，则这将违反SOA原则，除非为所有类型的客户端编写了实现。虽然很实用，但这可能是一个好主意，这样客户端就可以针对传输选择、服务合同更改和服务版本控制等事情进行更松散的耦合。

我建议使用ChannelFactory (当然是从dotnet客户端)，无论是通过共享的预先打包的接口/数据契约项目或dll使用服务，还是生成自己的代理(通过“Add Service Reference”或“svcutil.exe”)。这将允许您针对服务接口进行编码，因此您的客户端将更加友好地使用诸如用于存根、测试等的依赖项注入等概念。

Answer 3

生成代理的两种方法都是有效的，这取决于您希望对代理拥有多大的控制权，以及您是否拥有代码的两端。第三种选择也存在，你可以手工制作你自己的代理。让我进一步解释一下：

在SOA中，我们传递消息，这是一种不同的范式，不同于传递指向堆/栈上的对象的指针，后者是面向对象世界中的规范。

因此，在SOA中，契约(您可以做什么)和消息(要操作的状态)很重要，并且需要与服务的使用者共享，以便他们都能就契约或“约定规则”达成一致。这里是SOA最基本的形式。

进入WS-*一组规范，用于向我们的服务调用添加更多功能(分布式事务、安全性等)但如果我们这样做，我们都需要就我们打算使用的交互类型的规则和风格达成一致，因此服务及其客户端需要准确地就如何实现这一点达成一致，以便需要共享。

约定定义和WS-*规范的组合被称为WSDL，这通常是在客户端和服务之间共享的内容，这与我们共享模式和约定而不是类的SOA租户是一致的，并且兼容性基于策略(WS-*)。

因此，如果使用通道工厂，则根据您拥有的接口定义和动态设置的配置生成代理；如果使用添加服务引用，则让IDE根据服务的WSDL生成代理类。

如果你手工制作代理，你就可以完全控制这是如何发生的，你可以跳到拦截链中，在客户端做一些事情来操纵调用。

这取决于你想做什么。