Web Services中高效可靠消息机制的设计与实现
1.2 可靠SOAP消息机制
1.2.1 可靠性模型的建立
SOAP消息在HTTP协议传输过程中使用的是不可靠的无连接的传输方式。为了确保消息在机器之间的传递没有重复和丢失，采用了普遍使用的确认重传技术作为提供可靠性的基础。在SOAP消息头中加入消息标识符和确认机制部分，以确保消息的可靠传送。发送消息后，发送方缓存未确认的消息，如果在规定的超时时间片内，没有收到确认或反馈，则需要再次发送请求或处理结果。因此，对SOAP消息的传递需作以下完善：
(1)在消息传递过程中，增加惟一的消息序号标识符，并通过消息缓冲队列记录已经发送或响应的消息。若发生错误，能通过回溯查询消息队列以了解消息处理的进程。
(2)在SOAP消息头中增加支持可靠性传递的说明，并在SOAP通信逻辑中增加支持SOAP消息头封装和解析的处理模块。
可靠性模型的工作机制如图2所示。
1.2.2 可靠SOAP消息
可靠SOAP消息描述一个保证分布式系统之间在组件、系统及网络故障方面可靠传输的协议，定义了一个SOAP绑定支持 Web 服务的互操作性。按照该协议的规定，在SOAP消息头中增加了如表1所示的元素。
序列信息中的<Identifier>元素携带该SOAP消息发出时的信息，具有惟一性；<MessageNumber>是一个无符号长整型数，从1递增到上限再清零；<Uper>和<Lower>分别确认消息的上限和下限，便于对消息进行批量确认。
WS-Addressing定义了端点引用和消息信息头，使用消息传递系统来支持在包含各种处理节点的网络中以与传输无关的方式进行消息传输，而这些网络中的处理节点可以是端点管理器、防火墙和网关。按照该协议的规定，在SOAP消息头中增加了如表2所示的元素。
1.2.3 基于可靠SOAP的消息传递机制
在SOAP消息中加入WS-ReliableMessaging和WS-Addressing的定义，其SOAP消息和ACK响应示例如下所示。
SOAP消息：
<?xml version=″1.0″ encoding=″UTF-8″?>
……
<S：Header>
? <wsa：MessageID>
? http：//192.168.5.2/t/11112222-3333-4444-5555-666666666666
?< /wsa：MessageID>
?<wsa：To>http：//192.168.5.3/s/123</wsa：To>
? <wsa：ReplyTo>
<wsa：Address>http：//192.168.5.2/s/567</wsa：Address>
?</wsa：ReplyTo>
<wsrm：Sequence>
<wsu：Identifier>http：//192.168.5.2/RM/A</wsu：Identifier>
<wsrm：MessageNumber>5</wsrm：MessageNumber>
<wsrm：LastMessage/>
?<wsrm：Sequence>
</S：Header>
<S：Body>
? <!--Application Data-->
</S：Body>
</S：Envelope>
?ACK响应：
<?xml version=″1.0″ encoding=″UTF-8″?>
……
<S：Header>
<wsa：MessageID>
http：//192.168.5.3/t/aaaabbbb-cccc-dddd-eeee-ffffffffffff
< /wsa：MessageID>
<wsa：To>http：//192.168.5.2/s/567</wsa：To>
<wsa：ReplyTo>
<wsa：Address>http：//192.168.5.3/s/123</wsa：Address>
</wsa：ReplyTo>
??? <wsrm：SequenceAcknowledgment>
? <wsu：Identifier>http：//192.168.5.2/RM/A</wsu：Identifier>
<wsrm：AcknowledgmentRange Upper=″2″ Lower=″1″/>
<wsrm：AcknowledgmentRange Upper=″5″ Lower=″4″/>
?? <wsrm：SequenceAcknowledgment>
</S：Header>
<S：Body>
? <!--Application Data-->
</S：Body>
</S：Envelope>
图3为Agent之间基于可靠机制的SOAP消息传递。
(1)A向B发送了5条消息，其中第3条消息丢失，第5条是该组消息中的最后一条。
(2)B做消息头的解析，并判定是否缺少消息。当收到含有LastMessage标识的第5条消息时，反馈序列确认消息，其中序列号范围为1..2，4..5。
(3)A重新发送第3条消息，并通过<AckRequested>请求B反馈确认信息；B收到后，再次发送反馈序列确认信息，此时序列号范围为1..5。
上述消息在传递过程中均保留在各自Agent的持久队列中，待消息组被处理完毕或失效时删除。
1.3 高效消息传输机制
1.3.1 实时性模型的建立
实时性指系统或者系统执行任务的时间遵守某种时间约束特性，而不是在严格意义上达到同步效果。对于使用消息中间件的客户端组件而言，实时性指在单位时间内必须完成规定任务。因此，Manager/Agent框架使用实时机制来减小因为增加了可靠机制对系统性能造成的影响。
在实时服务提供者模型（Agent）中，大量采用了队列和线程池技术。队列完成对所有Web服务的缓冲，有效地防止服务器过载。同时，采用线程池技术提高服务提供者响应大量服务请求的性能。
本系统采用两个线程池：系统线程池和事件线程池。如图4所示，全局事件队列负责接收所有网络连接事件，它是Web服务事件的多路复用点。系统线程池包含持久运行的"后台"线程，其数目可配置。系统线程反复监视全局事件队列，经过事件解析和分配将事件插送到相关的分类事件队列中。
事件线程池包含处理所有类型事件的服务处理线程。实时模型中，事件线程池具有如下特点：
(1)线程分配、执行和空闲：事件线程池通常维持少量的工作线程。当分类事件队列有事件入队时，激活事件管理器的线程池调度器。线程调度器监视Web服务事件，如果存在该事件的活跃线程，则将该事件加入活跃线程的工作队列中等待执行；反之，则从线程池中选择一个空闲线程，并将事件赋予线程执行。处理完请求后线程成为空闲，返回到线程池中。
事件管理线程以单线程方式执行所有单个事件处理，没有主动线程切换，因此最小化了Web Services内部的线程上下文切换开销，提高了事件的执行效率。
(2)线程调度：线程调度器以后进先出LIFO（Last In First Out）的方式调度线程池中空闲线程，以期获得较好的线程局部性。
(3)线程池大小自适应调整：实时模型中，线程池通常只设置少量的线程，在系统负载增加时，线程池所有线程都用于事件处理，可动态调整线程池大小，为线程池分配更多的线程用于事件处理。在系统负载下降后，线程调度器每次使用空闲线程都检查线程池深度。如果线程池长期保持低深度，则减小线程池大小。
(4)服务区分：在全局事件管理器解析和分配过程中，根据定义的优先级别，将高优先级请求按事件排队规则的高优先权方式插入到事件队列中，保证它在该事件队列中能优先得到处理。
在Manager端提供了消息转发和服务发现的路由机制。该机制工作在线程池模式下，通过优先级选择的方式有效地提高各个服务请求转发的处理效率，同时也兼顾低级别请求的处理。对于客户的请求进行分级别处理，从而满足不同用户对于实时性的要求。基于级别和线程池方式的实时路由机制如下：
(1)当产生网络连接时，按注册时约定的优先级别高低，由择优线程决定是否创建该连接的接收线程、路由线程和发送线程组；线程池内的线程数量是有限的，并确保高优先级的网络连接得以执行。
(2)接收线程将消息放入相应的接收缓存队列中，路由线程从中获得消息，并分析出目的端地址参数连同消息体放入发送缓存队列中，交给相应的发送线程来转发。
(3)这种方式是以牺牲低优先级连接的响应时间为代价的，为防止高级别连接超负荷而彻底切断低级别连接，线程池中总是维持一对接收/发送线程，专为所有被择优线程拒绝创建独立线程的低级别连接服务。此时这些连接均视为同一级别。
在实时性模型中，通过在Agent端的服务调度中完成服务区分和服务资源的分配，提高了服务提供者的质量和效率。同时，在Manager端优化了消息路由机制，提供了高效的消息转发机制。
1.3.2 松耦合情况下实现高效可靠的通信模式
基于可靠SOAP通信的Manager/Agent框架的功能是：负责传递客户端应用之间的消息，并将其处理后的消息根据时效和策略要求予以反馈，提供发布/订阅、点对点、消息队列等同步/异步的通信模式。
图5所示的应用场景中，存在多个消息服务器Manager和消息客户端代理Agent。其中，Manager1和Manager2都是负责客户端Agent的注册管理、接收并转发消息；告警管理、资源管理组件等通过各自的Agent向Manager1注册并完成消息服务；计费管理组件和业务流引擎通过各自的Agent向Manager2注册并完成消息服务。
消息服务器Manager包括消息处理、系统管理、通信协议三部分。其中，消息处理部分包括接收/发送模块、队列缓冲区、队列管理、路由（向其他节点的Manager转发消息）排队转发等模块；系统管理部分包括系统监控、存储管理、日志管理、网络管理等模块；通信协议包括支持可靠机制的SOAP消息。
客户应用程序通过Agent注册、创建消息队列，并发送消息。Manager监听并接收消息，放入消息队列中，通过消息头分析模块来解析并处理消息，然后发送给其他应用程序。如果接收者不在该Manager节点下接受管理，则通过路由方式转发给其他Manager节点来处理。通常，组件无需知道对方信息即可通过Manager进行转发，这降低了系统耦合度。由于SOAP消息本身存在传递和处理速度的限制，为提升效率，应减少经Manager中转处理的延时，两个已知对方地址的组件可以直接通过各自的Agent建立连接并传递SOAP消息。
在实际应用过程中，Manager/Agent采用上述通信模式以提高可靠SOAP消息的处理和转发效率。对于点对点的连接方式，允许Agent之间直接通信，减少了Manager中转的延时；针对广播机制，通过Manager的发布/订阅模式中转消息，减少客户端Agent的处理负担。
2? 实验验证
一个分布式电信告警服务系统中，存在m个数据采集点，由各自的Agent（A1，A2……Am）上报给Manager，通过Manager的发布/订阅机制发送给上层各监控点。假设各数据采集点每秒上报k次数据，优先级为A1>A2>……>Am，Manager的线程池中维持n个线程组（n≤m）。测试条件为AMD900MHz，640MB内存，Agent和Manager分别运行在独立的机器上。
在可靠性方面，设定采集点每秒上报k=20个数据为一个消息组，第20个数据在SOAP消息中以Last Message标识，并请求上层接收者B反馈ACK以确认序列情况。以关闭某个节点来模拟网络故障情况，测试结果如图6(a)所示。?测试条件如下：t1时刻，关闭B；t2时刻，B服务恢复，Manage发来得到确认的消息；t3时刻，关闭Manager；t4时刻，Manager重启，向各节点重新请求数据服务。
根据上述测试可知，可靠SOAP协议确保了每条消息在任何时刻仅被接收一次，防止了重复交易或计费等危险。在有足够缓存条件的情况下，该Manager/Agent的可靠实时工作机制能够提供较好的处理效率和服务质量。
服务质量方面，测试中设定k=20，m=10，n=6。其中， A1～A5为高优先级事件，A6～A10则为低级别事件。测试结果如图6(b)所示，由此可看出每个Agent所获取的服务质量的变化。
在延时方面，选用ApacheSoapClient/Server和Manager/Agent做对比，后者采用上述的实时模型来提高处理效率。测试结果如图6(c)所示。从测试结果可知，优化后的Manager/Agent消息传递模型与优化前的Client/Server模型在性能上基本相近。因此，该实时模型在保证了可靠性的基础上，能够提供较高的处理效率和服务质量。
3? 总? 结
综上所述，Manager/Agent框架支持基于SOAP的可靠传递，并采用实时模型保证一定的处理效率。随着可靠性的处理复杂度的提高，单位延时也将不断加长，因此需要根据实际应用的情况来调整可靠性约束的策略，并加强消息传递和处理的实时机制。
参考文献
1?? Clabby J.Web Service Gotchas.North American Operations，Bloor Research，2002
2?? Tanenbaum A S.Computer Networks，Fourth Edition.Prentice Hall，USA，2002
3?? Banks A，Challenger J.HTTPR Specification.http：//www. ibm.com/.2002
4?? Reliable Message Delivery in a Web Services World：A
???? Proposed Architecture and Roadmap.white paper from?IBM and Microsoft Corporation，2003
5?? Bilorusets R，Bosworth A.Web Service Reliable Messaging? Protocol.http：//www.ibm.com/，2003
6?? Bosworth A，Box D，Christensen E et al.WS-Addressing. http：//www.ibm.com/.2003
