- 可靠性会话: 端到端(多个点到点系统组成)的可靠性,基于消息,基于WS-*,可以跨平台.
- 在信道层创建可靠性会话,由两端的缓冲区进行可靠性管理(对消息进行排序后才发给服务器端,接收到消息后回发ACK.)跟TCP类似.当消息投递不成功时,会尝试重发(Meg2)可靠性消息实现了WS—RM,WS—RX的标准.
- WS-RM消息过程: 创建序列号(标示消息在传递时的位置).由消息的发送方发送.只有头一次发送时.应答序列号创建成功. 由服务器的服务信道发送.实际传输中,对消息序列号的应答.ACK,由服务进行发送.其中,ACK在Http回应中返回,或者在TCP中以单独的消息返回.以下是调用阻塞时的情况.
- 而当是One_way时一次操作的ACK只有被客户端代理接收到后,才会进行下一次操作请求.所以客户端其实是发送后要确保这一件事情的.对发送后不管的一点点修改.
- WS-RM Policy断言: 可以包含在WSDL中,代理自动生成,可以不修改.对ACK进行设置.
- 配置: 1) 对于大量数据的传递,如果使用流传输,则不能使用可靠性消息,无法创建大尺寸的缓冲区.2) 由客户端代理信道进行重试,不影响客户端逻辑,只有当所有的重试都失败,才会给客户端一个失败的消息.否则客户端不知道有重试着一个动作.3) SessionID通常是一个GUID(128位16进制字符串{01-05-ef-ab-…..})通过随机算法生成,以实现很好的并行性.可以同时给多个客户端分配SessionID且不重复.但是对于数据的查找会带来一些麻烦.4)会话超时: 由ReceiveTimeout和当是可靠性会话时的inactivityTimeout两者的最小者决定,但是如果是应用程序会话,使用前者,并且也推荐使用前者,因为它是通用的.5)异常处理: 异常本身不安全,其可能包含与安全有关的信息.其可能含有.NET中特有的类型.不能互操作.把异常包装成错误.然后发给客户端.
- 什么时候使用: 服务有网络连接风险的;One-way;保证消息Order;在跨平台实现可靠性.
- 问题: 投递失败的问题只会被传递到信道层,无法传输到客户端进行分析,所以无法知道那个消息失败了;会带来与会话创建销毁带来的开销;异常导致信道错误;容易超时.