是否共享一个包含 wcf 接口和数据合同的项目，并通过 ChannelFactory 使用这些来使用违反 SOA 原则的服务？
我的架构师建议最好使用添加服务参考生成代理。
问问题
797 次
4 回答
0
我们在我公司仔细考虑和采用的标准是，我们分发服务合同是两种方式。在交付给公司内部的团队时作为共享程序集，在提供给客户和其他第三方时作为 WSDL。这是我们在设计/流程审查期间与 Microsoft 讨论的标准，他们一致认为这是正确的方法。
于 2010-11-25T22:49:46.423 回答
0
两种生成代理的方法都是有效的，这取决于您希望对代理拥有多少控制权，以及您是否拥有代码的双方。第三种选择也存在，您可以手工制作自己的代理。让我进一步解释一下：
在 SOA 中，我们传递消息，这与传递指向堆/堆栈上的对象的指针是不同的范例，这是 OO 世界中的规范。
因此，在 SOA 中，合同（您可以做什么）和消息（要采取行动的状态）很重要，需要与服务的消费者共享，以便他们都可以就合同或此处的“参与规则”达成一致我们有最基本的 SOA 形式。
输入 WS-* 一组规范，用于向我们的服务调用（分布式事务、安全性等）添加更多功能，但如果我们这样做，我们都需要就我们打算进行的交互类型的规则和风格达成一致使用，因此服务及其客户需要就如何发生这种情况达成一致，因此需要共享。
合同定义和 WS-* 规范的组合称为 WSDL，这通常是客户端和服务之间共享的内容，这与我们共享模式和合同而不是类的 SOA 租户一致，并且基于兼容性关于政策 (WS-*)。
因此，如果您使用通道工厂，您将根据您拥有的接口定义和您即时设置的配置生成代理，如果您使用添加服务引用，您可以让 IDE 根据服务的 WSDL 生成代理类那么它就存在了。
如果您手工制作代理，您可以完全控制这种情况如何发生，您可以跳入拦截链并在客户端执行操作以操纵调用。
取决于你想做什么。
于 2010-11-03T08:33:22.660 回答
0
与数据契约共享预打包的服务接口并不违反 SOA 原则，只要不期望消费服务使用它。这正是使潜在客户能够针对现有的第 3 方服务加速开发，或针对尚未构建的服务开始开发的原因。以代码格式提供接口/数据合同将比仅通过文档描述这些东西更不模糊（当然，如果客户端使用不同的编程语言，它们可能没有用处）。
但是，如果在共享包中提供了某种服务接口的预打包实现，并且需要使用该实现来成功使用服务，那么这将违反 SOA 原则，除非为所有类型都编写了实现的客户。虽然务实，但这可能是一个好主意，因此客户端可以更松散地与诸如传输选择、服务合同更改和服务版本控制之类的事情耦合。
我建议使用 ChannelFactory（当然来自 dotnet 客户端），无论是通过共享的预打包接口/数据合同项目或 dll 使用服务，还是生成您自己的代理（通过“添加服务引用”或“svcutil.exe”） . 这将允许您针对服务接口进行编码，因此您的客户端将更加友好地使用依赖注入等概念进行存根、测试等。
于 2010-04-30T07:24:10.820 回答
0
我想这取决于一些事情：您的基础架构、安全策略、治理等。
我们设计了 WSDL（服务和消息契约）和 XML Schema（数据契约），然后使用 svcutil.exe* 生成代理。那时，我们有可以用来消费或支持服务的代码。当然，我只是在谈论代码，output.config 将根据决定的适当行为、绑定和端点进行修改。
一旦服务建立起来，它的前面就是一个 XML 网关。此时我们可以开始使用“添加服务参考...”来测试服务。如果您只是想节省一些时间并将您的预生成代理或您的 WSDL 不公开（因为它们位于不回显它们的 XML 网关后面）交给其他人，那么您正在做的似乎很好.
否则，我希望消费者能够“添加服务引用...”并生成他们自己的客户。
*基于 Java 的应用程序使用其他东西（WSDL2Java/ClientGen/内置 IDE 工具）。
于 2010-04-29T17:19:30.230 回答