就细节而言，要全部说清楚是颇费口舌的，但其中最关键的是多出了两个服务调用（Create和Terminate），此外就是一些信息头。这种设计并非多此一举。在以前的规范草案里，CreateSequence被设计为隐式调用，从而造成第一个消息的迷乱。而按照目前的设计，你一旦成功创建一个序列，就等于在消息传输两端签订了一个契约。在绝大多数实现中，即使没有显式发送TerminateSequence消息，序列也将会自动超时。当然，如果消息丢失，也会有对应流程予以处理，比如在本例中是重发。

　　那么，确认消息和普通消息到底有何不同？换句话说，用户可有哪些灵活选择？

　　首先，确认消息不必和普通消息使用同样的传输通道。RMS可以另行开启HTTP端口（当然也可以是别的端口）用于接收确认信息。这个接收端口的信息由AcksTo地址标明。若AcksTo地址和WS-A的ReplyTo地址相同，则RMD可以用与获得普通消息同样的方法，得到确认消息。

　　其次，RMD并非必须对它已接收到的全部消息作出确认。其实，如果在一百万消息中有一条被丢失，那么RMD可以仅对丢失的消息要求Nack。其意思相当于对RMS说，我只对这条丢失的消息感兴趣。第三，RMS可以主动要求确认。假如RMD配置为尽可能少确认（为减少网络流量），那么当RMS希望清理自己备份的已发出消息时，就可以通过增加AckRequested头，主动要求确认。随后，RMD将立即通过SequenceAcknowledgement响应RMS。

　　关闭序列

　　另外，我们增加了对序列的关闭操作。这样可以避免消息未被全部发送并由RMD成功接收前，RMS关闭序列。现在，RMS通过关闭操作可以告知RMD，“我不会再发送任何消息”。接着，RMD做最终确认。最后就可以关闭序列了。

　　请求/响应

　　至于对消息请求的响应，除了两个方向均有一个序列外，基本没有区别。这两个序列是彼此独立的，因此在其上传输的消息彼此没有联系。如果一定要说有的话，那就是你可以使用如下方法优化这两个序列的创建：在CreateSequence中请求返回序列（使用Offer）。

　　想象你是一个客户端，很显然，需要双向可靠连接。在这种情况下，客户端创建一个序列后，可提交给服务器并等待响应。这样一来，实际上是在一次消息交换中创建了两个序列。不过，这两个序列没有依赖关系，可以中止其中一个，再使用另一个。