从一个 WCF 服务调用另一个 WCF 服务时要考虑的事项
我们正在将一组 WSE 服务迁移到 WCF 平台。
新的 WCF 服务通过安全的 HTTP 进行调用。 (https)
我想从一个 WCF 服务调用另一个 WCF 服务的操作契约。这两个服务大多托管在同一个 IIS 中，但它们也可以位于单独的 IIS 服务器上。
- 在这种情况下我需要处理一些事情（我目前显然不知道）吗？
- 这种情况下有什么特殊的调用机制吗？
- 同步调用和异步调用时的调用机制是否会发生变化？
- 您能否建议某种在这种情况下可用的绑定类型？
We are migrating set of WSE services to WCF platform.
The new WCF services are called over secured HTTP. (https)
I want to invoke an operation contract of one WCF service from another. Both the services are mostly hosted in the same IIS, but they can be on separate IIS server.
- Do I need to take care of some things (which i obviously do not know at present) in this scenario?
- Is there any special calling mechanism in this case?
- Does calling mechanism change when call is synchronous and when it is asynchronous?
- Can you suggest some type of binding which is readily available in this case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
1.) 如果服务位于同一个盒子上，请使用命名管道来相互通信，除非您有任何令人信服的理由不这样做。虽然 WCF 本身并不关心您正在做什么，只要地址、绑定和契约都匹配（看看我在那里做了什么？），但 .NET 在建立网络连接时会关心您正在做什么。使用的越少越好。 （请参阅http://msdn.microsoft.com/en-us/library/fb6y0fyc .aspx 了解更多详细信息）
2.) 如#1 中所述，如果他们在同一台机器上进行通信，请使用命名管道，除非有充分的理由不这样做。
3.) 您能否更详细地说明您的意思或您打算做什么？其中很多内容都是为您构建的，因此假设您熟悉实现异步方法和使用异步回调，简短的答案是肯定的，它与同步调用操作不同，但这是可以预料的。或者你的意思是IsOneWay = true？如果是这种情况，调用机制是相同的，但可能存在许多其他问题（例如故障）
4.) 同一框上的命名管道，否则为 BasicHttp（除非您需要 WS 的任何附加功能）。
1.) If the services are on the same box, use named pipes, unless you have any compelling reason not to, to communicate with each other. While WCF proper doesn't care about what you're doing as long as the address, binding and contract all match up (see what I did there?), .NET will when it comes to making network connections. The fewer you use, the better. (see http://msdn.microsoft.com/en-us/library/fb6y0fyc.aspx for more details)
2.) As stated in #1, if they're talking on the same box, use named pipes unless there's a good reason not to.
3.) Can you provide a little more detail on what you mean by this or what you're planning on doing? A lot of this is built out for you, so assuming you're familiar with implementing async methods and using async callbacks, the short answer is yes, it's different than calling an operation synchronously, but that's to be expected. Or do you mean IsOneWay = true? If that's the case, the calling mechanism is the same but there can be a number of other gotchas (e.g. faults)
4.) Named Pipes on the same box, BasicHttp otherwise (unless you need any of the additional features from WS).
在这种情况下，您要么不能使用 Windows 身份验证（如果您正在使用它），要么必须在域上设置一些特殊的委托内容才能使其正常工作。 Windows 身份验证不会在不同服务器之间“跳跃”。 这里有一些相关信息，有很多关于主题。
如果它们位于同一服务器上或者您没有使用 Windows 身份验证，那么这应该不是问题。
应该没关系，服务端都是一样的。我会说，如果客户端调用 X 并且 X 调用 Y，X 可能也会同步调用 Y，因为无论如何，在 Y 完成之前它都无法返回到客户端。 （如果 X 调用 Y 和 Z，那么 X 进行异步调用可能更有意义。）
如果您以前使用过 WSE，那么 BasicHttpBinding 将是最接近您所做的事情，并且其输出内容看起来非常熟悉。这也是最容易使用的一种。
In this case, you either can't use Windows authentication (if you were using it) or you have to set up some special delegates stuff on the domain to make it work. Windows Authentication won't "hop" between different servers. Here's some info on that, there's a lot of reading out there on the subject.
If they stay on the same server or you're not using Windows authentication, then it shouldn't be a problem.
Shouldn't matter, it's all the same on the service end. I will say that if the client calls X and X calls Y, X might as well call Y synchronously because it can't return to the client until Y is done anyway. (If X calls Y and Z, then X making async calls may make more sense.)
If you were using WSE before, then BasicHttpBinding is going to be the one closest to what you were doing and will look pretty familiar in what it outputs. It's also the simplest one to work with.
不应该仅仅因为一个 WCF 服务方法调用另一个 WCF 服务就需要任何特殊的东西。 WCF 服务并不“关心”哪些其他应用程序类型正在调用其方法，只要它们使用正确的服务协定、数据协定、端点和绑定设置即可。
只需确保两个服务方法都能及时返回，并且不会导致执行长时间阻塞。
There shouldn't be anything special needed just because a WCF service method calls another WCF service. A WCF service doesn't "care" what other application types are calling its methods so long as they use the correct service contract, data contract, endpoint, and binding settings.
Just make sure that both service methods return promptly, and don't cause execution to block for long periods of time.