对地观测传感网信息服务的模型与方法成果输出

应用层的异步是通过Web服务的异步调用实现的。异步调用是相对于Web服务以SOAP为典型的同步调用方式而言的。同步调用是指Web服务客户端向服务提供端发送服务请求后，其进程将挂起直到接收到服务提供方返回的请求结果，该返回结果包括函数结果返回、时间超时 (timeout) 或者其他中断等。异步调用是指在服务请求端发送服务请求后，无需堵塞进程等待服务器端返回结果，继续执行其他操作，等服务提供端返回结果后再行处理。异步交互可以避免与服务通信时的会话管理，但是必须维护调用状态信息。异步交互机制对于许多分布式异构执行环境里的应用非常有用: ①将计算与通信叠加以包容分布式系统里的长延时性; ②预测不能完全依靠调用结果的活动协调和执行; ③易于支持长时间运行事务的交互; ④考虑人机交互以便在控制层进行处理 (Giancarlo Tretola和Eugenio Zimeo，2007)。

根据不同的标准，Web服务的异步交互模式可包括不同类型。例如，根据WSDL定义的Web服务操作端点可以支持的四种基本传输类型 (单向、请求/响应、征求/响应、通知) 可以将Web服务异步模式分为单向和通知操作 (one-way and notification)、请求/答复操作 (request/response)、使用轮询的请求/答复操作、使用公布的请求/答复操作等4种模式 (Adams，2002)。Brambilla (2004) 讨论了W3C用例中的一些异步模式，并进一步对商业应用中经常用到的几种异步通信模式进行了研究，分析了3种消息确认模式与6种异步交互模型结合时可能出现的异步交互 (Brambilla等，2005)。

Web服务的异步性可以由客户端或服务器端进行处理 (Chinthaka，2008)。客户端异步需要在两个不同的线程中处理请求和响应消息。服务器端异步是为了避免处理请求长时间持续占用服务器资源。服务器端异步的理想选择通常是通知客户端服务器收到了消息，并在稍后通过一个不同的传输通道给响应的客户端发送请求响应。目前，许多文献都对客户端异步调用进行了研究。其中，一些学者研究了通过面向对象的RPC中间件实现远程异步调用的客户端模式 (Markus等，2008; Zdun等，2004)，而另一些学者则从消息中间件角度研究了消息队列、发布/订阅以及面向事件的技术等实现Web服务异步的中间件方法 (Doug等，2006)。综合以上分类法，根据交互流程的复杂程度可以将客户端异步调用模型分为基本异步调用模式和带确认的异步调用模式。

其中，客户端基本异步调用模式主要包括以下4种:

图8-1 单向调用模式图

图8-2 回调模式

图8-3 轮询模式

图8-4 发布/订阅模式

(1) 单向 (One-way) 调用模式，也称Fire-and-Forget模式 (见图8-1)。这种模式下，客户端向服务器端发出服务请求后继续执行，而不管服务器是否成功收到和处理该次请求，并且也不需要将服务器端的处理结果返回给客户端。单向调用模式的逻辑和实现虽然都十分简单，但是可靠性差，无法获得传输错误或远程服务器处理错误，无法确保请求消息是否送达服务器端或请求是否被成功处理。这种模式不适合应用在单个请求可靠性要求高的场景中。

(2) 回调模式 (Callback)，与单向调用模式不同，在回调模式下，服务器端需要向客户端返回结果消息。客户端向服务器发出请求后，继续与服务器并行计算。服务器端在完成客户端所请求的任务后，主动向客户端发送相关的结果消息，客户端在收到对应的响应消息后，对返回的结果进行相应的处理，当服务器完成客户所请求的任务后，主动向客户发送结果消息，客户在收到该响应结果消息后，再对返回结果进行相应的处理，如图8-2所示。其特点是: 由于响应结果消息的存在，若客户端收到响应结果，则可以确认该次服务请求被成功处理，从而使得回调模式比单向调用模式的可靠性要好; 同时，该模式下的客户端和服务器端之间可以并行计算，极大地提高了系统的处理能力和利用率。

(3) 轮询模式 (Polling)，轮询模式中，客户端主动查询某次服务请求的处理状态。如图8-3所示客户端向服务器发出请求后，与服务器并行计算，每隔一定时间，客户端主动向服务器查询该次请求的处理状态。若处理没有完成，则客户端立即返回去并发执行后续任务; 若请求已经处理完成，则取得其处理结果进行相应处理。该模式不但具有异步回调模式中的客户端和服务器端并行计算能力，同时，客户端还可以得知服务请求处理的状态 (是否完成)。由于客户端需要不断向服务器询问请求完成情况，因此该模式的效率方面不如回调模式好。

(4) 发布/订阅模式 (Publish/Subscribe)，本质上属于一种异步回调模式，但与普通异步回调模式最大的不同在于: 回调模式是一种点对点的消息模式，而发布订阅模式是一种多对多模式。在该模式中，接收服务器结果消息的客户端不一定只包括初始发出请求的客户端，而且这样的客户端可以同时有多个，如图8-4所示。该模式实际上属于一种组合调用模式，但由于其实际应用中使用普遍，因此也与前面几种调用模式一起讨论。其典型应用场景如: 在一个火灾预警系统中，用户可以向服务器发出一个报警事件的订阅申请，该申请中指明一旦该系统的火灾预警事件发生，则将给指定的所有用户发布该预警事件信息; 系统中各订阅用户收到该报预警事件信息后，可做相应的应急处理。(https://www.xing528.com)

以上的4种简单的客户端异步调用模式均可以避免客户端的进程阻塞。但在实际使用中由于应用环境的复杂性，客户端必须面对网络环境的不可靠性。因此，对于客户端而言，可靠性是实现异步调用时的经常性需求。首先，请求消息必须确保能从Web服务客户端被提交到Web服务提供端并且能被处理; 其次，提交到Web服务的消息必须确保按发送时的次序在服务器端处理; 此外，客户端和Web服务还应该具有一定的容错性，能发现错误并能从错误中恢复。因此，在实际应用中，常常将确认机制引入到简单异步调用模式中，形成带确认的异步调用模式，该模式主要包括以下几种。

图8-5 与服务器同步的确认模式

图8-6 带确认的回调模式

图8-7 待确认的轮询模式

图8-8 带确认的发布/订阅模式

(1) 服务器同步的确认模式 (Sync with Server)。该模式是单向异步模式与同步调用模式之间的中间模式。一方面，它与单向异步模式类似，都不要求服务器端返回请求处理结果，另一方面，它与同步调用模式也有类似之处，要求服务器接收到客户端请求后立即发送一个接收确认消息给客户端，如图8-5所示。该模式确保了请求消息的成功发送，具有较好的可靠性，且同时具有单向异步调用的简单性。

(2) 带确认的回调模式 (Callback with ACK)。与回调模式类似，其不同之处在于:服务器收到客户端请求后，立即返回一个确认消息给客户端，该消息仅表明服务器收到客户端发出的请求，但服务器还未真正执行其请求任务，如图8-6所示。其特点是: 相对于普通异步回调模式，由于该模式中客户端发出的每个请求，客户端都会收到一个确认消息，因此具有良好的可靠性。这种可靠性要求在某些应用场景中是必须达到的，如动态电子商务环境下，合作伙伴之间的重要的电子订单，在业务上就强制要求必须确认对方已经收到发出的某个订单申请。

(3) 带确认的轮询模式。与带确认的回调模式和回调模式之间的区别一样，带确认的轮询模式和轮询模式的不同之处在于: 服务器在收到客户端请求后，也立即返回一个确认消息，以表示该服务请求已经收到，如图8-7所示。相比较于普通轮询模式，该模式具有进一步的可靠性; 此外，客户端在发出每一个请求后，都需要等待服务器端返回一个确认消息。因此，该模式的使用效率较差。

(4) 带确认的发布/订阅模式。与发布/订阅模式类似，不同之处仅在于: 服务器在客户端请求消息后，需要立即返回一个确认消息给客户端，如图8-8所示。与前面带确认的调用模式一样，该模式在可靠性上较好，但在效率方面却有一定的损失。由于在 (带确认的) 发布/订阅模式中，订阅消息的客户端、服务器和接收发布消息的客户端之间的交互较复杂，而且涉及接收发布消息的客户端的唯一地址标识、订阅消息的格式标准化等问题，通常把这两种模式归类为异步通信模式中较高层次的消息事件服务来实现; 而把较简单的单向、服务器同步的确认、(带确认的) 回调和 (带确认的) 轮询模式归类为异步消息调用队列模式。

以上模式中，回调模式是工业协议中受到最广泛支持的异步调用模式，因为它可以将客户端从客户端代理服务器与服务器端之间因使用轮询导致的繁重网络流量中解放出来。工业界使用的回调模式的实现一般采用了两个Web协议: WS-Callback以及WS-Address-ing。在OGC中，目前提供的各种Web数据和处理服务 (WCS、WFS、WMS、WPS等)并不支持回调机制，但其消息通信服务WNS的two-way communication方式中也可提供了一个可实现回调服务地址的Callback URL元素来接收返回的响应消息 (OGC，2007a)。