我试图更好地理解 WCF 的调度过程,特别是对各种可扩展点的影响和影响。从底部列出的网页中,一旦通道堆栈将消息传递给调度程序,WCF 似乎将按规定的顺序执行以下操作。
- 消息检查器
- 操作选择器
- 消息格式
- 参数检查器
- 操作调用者。
我正在尝试找到一些选项来解决我遇到的问题,我正在考虑的一种方法是结合使用消息检查器、操作选择器、消息格式和操作调用程序。不幸的是,我的观察似乎表明执行顺序如下:
- 操作选择器
- 消息检查器
- 操作调用程序 (AllocateInputs())
- 消息格式
- 参数检查器
- 操作调用程序 (Invoke())
我可以理解在格式化消息之前调用自定义调用程序 AllocateInputs() 方法的细微差别,因为消息格式化部分本质上是将给定消息反序列化为一组方法参数,以传递给适当的操作和调用程序的 AllocateInputs( ) 方法指定需要多少个参数。
抛出我的部分是消息检查器和操作选择器之间的顺序反转。对我来说,当消息检查器对消息进行操作时首先运行它们听起来很合乎逻辑,而操作选择器确定消息的目标是哪个服务操作。
问题:
- 这是由于 WCF 的不同版本或发行版造成的吗?
- 这是因为 WCF 实际上并没有指定扩展点执行顺序吗?
参考页面:
扩展 WCF 以支持自定义数据格式- Zulfiqar 的博客
使用自定义行为扩展 WCF - MSDN 服务站 2007 年 12 月
消息流拦截点- Nicholas Allen 的 Indigo 博客
注意:我很抱歉没有提供链接,因为我仍然是菜鸟,所以不能提供多个链接。=)