日志对许多应用程序来说是都是一个重要的组成部分，至少存在两种类型的日志： 一般信息的和 关键业务的。

一般信息日志主要用来跟踪应用程序的步骤和操作。根据日志信息的用途，它对应用程序的操作有着不同的影响。例如，如果日志记录只是用来进行统计分析，少数几次失败的日志操作将是可以接受的。然而，如果日志是用来审计，那么遗失日志记录将是不可接受的，这就要用到第二种类型的日志：关键业务日志。

在这种情形下，根据业务的相关程度，日志的输出将影响到系统的其它部分，换句话说，其它应用程序将读取关键业务日志并应用到它们的商业逻辑中。这种类型的日志将像其它的一些业务操作一样被谨慎处理。这类日志的一个例子就是金融系统的日志，那些记录财务事务信息的日志可用来进行兴趣统计、税费计算或仅仅是用来满足法律要求，如可跟踪性。

不幸的是，在目前系统在，一些重要的日志消息，（可能是一般信息日志或关键业务日志），很少被认真处理。原因在与日志操作经常被当作一种辅助操作，日志资源被当作一种只写的设备，只满足快速和廉价即可。

基于日志的自身内在特性，Web 服务是实现日志的很好的选择。因为对业务关键日志敏感的企业同样会对一个企业范围内所有应用程序都能够使用的日志服务感兴趣，并且Web服务还提供了日志记录及其生命周期的集中管理能力。

在本文中，我们将提出一种企业范围的日志 Web 服务架构，它重点解决分布式系统 2 个关键设计方面： 可靠性和容错性和 事务语义支持的日志。

日志的容错性和可靠性
在本节我们将基于 WS-Reliability 标准讨论与日志有关的 Web 服务可靠性问题，并提出一个可靠的日志 Web 服务架构方案。

可靠日志的需求
在讨论技术细节之前，我们首先定义可靠性以及日志 Web 服务需要实现的可靠性需求

从一个用户的角度出发，可靠性经常是一种需求，下面两段引文对什么是可靠性给出了很好的定义：

• 根据文献 分布式系统－概念和设计（请参阅 参考资料），一个计算机系统的可靠性是对系统的行为偏离它最初的设计行为（即根据正确行为的定义）的可能性大小的度量，它包括在没有任何个别的错误操作的前提下发生的系统中止。可通过设计系统来发现系统偏离（或错误）并从中恢复来提高系统可靠性。
• 可靠性的第二个定义源于文献 分布式系统－原理和示例（请参阅 参考资料） ，它指系统在不发生故障的前提下连续运行。一个高可靠系统是指系统在无故障前提下一个相当长的时间周期内可以最大可能的持续不间断工作。.

这两个定义从根本上说明，你希望建立的日志 Web 服务是在一个相对较长的时间范围内可以不间断工作，且具有发现故障并从中恢复的能力。

记住上面的定义，则不难确定一个可靠日志 Web 服务的可靠性需求。下面的列表描述了一个可靠日志 Web 服务所必须实现的需求：

• 实现可靠的消息传递：未来的设计技术方案必须保证提交到日志 Web 服务日志消息能够传递到服务器端且被处理。
• 除去重复消息：日志 Web 服务除了必须保证消息被提交外，还要确保即使一条消息被提交多次，在服务器端也只处理一次。
• 确保消息次序：协议和设计技术方案必须保证提交到 Web 服务的日志消息按照它们的发送时的次序在服务器端处理。
• 日志客户端和 Web 服务容错性：日志客户端和 Web 服务需要能够发现错误并能够从错误中恢复。

这意味着，要实现一个可靠日志 Web 服务，未来的技术方案必须保证消息传递到服务器端并按照正确的顺序处理一次（且仅处理一次）。另外，方案必须保证提交的日志信息必须是可持续化的，即使服务器或客户端崩溃等特殊时刻。

高层架构
在详细讨论之前，我们还必须明确几个定义。在本节，我们为日志 Web 服务提出了高层架构，研究架构体系内的组件，并定义整节中使用的通用术语。

图 1 显示了组成日志方案的高层组件，并定义了日志客户端与 Web 服务进行交互的两个场景。

图 1: 日志场景

图 1的上半部分显示了最基本的场景。 这里，日志客户端与日志 Web 服务直接进行交互。

图 1 下半部分显示如下场景： 日志客户端并不直接与日志 Web 服务进行交互，日志信息被传递到一系列称为跳转的中间服务。不管是日志客户端的直接通信组件还是日志 Web 服务来作为跳转，都需要保持透明。

本文将不对跳转进行单独讨论，但从架构的观点来看，如果与日志客户端交互，那么它就像一个日志 Web 服务，如果与日志 Web 服务交互，那么就是一个日志客户端。

在上一节我们研究了主要组件－日志客户端和日志 Web 服务。在本节我们将从架构的角度对日志 Web 服务进行详细研究。

图 2: 基本日志服务架构

图 2 中的高层视图并没有给出太多的技术细节，只是用来说明组成日志 Web 服务的 2 个主要组件。

简单地，日志 Web 服务从总体上可以分为 2 部分：

• 日志客户端：组件封装了一个可靠日志客户端，应用程序通过提供的 API 可以使用它。组件可以从应用程序中接收日志信息并通过可靠的方式提交到日志服务器。在本文中这一组件通常被称作 客户端或 日志客户端.
• 日志服务器：此组件是应用程序的核心部分，它为日志客户端提供了一个进行可靠日志的 Web 服务。日志服务器接收日志信息并采用可靠的方式进行处理，在本文中这一组件通常被称作 服务器或 日志服务器.

应用程序是 图 2 中的第 3 个组件. 应用程序并不属于日志 Web 服务，由于它使用 Web 服务，因此它在本文上下文中也很重要。

在整篇文章中，这一组件被称为 商业应用程序.

WS-Reliability 标准
作为讨论的基础，我们对 WS-Reliability（请参阅 参考资料）进行概述，并讨论了它的关键元素和机制。 然而，你会发现， WS-Reliability 标准很好地覆盖了协议层上关于可靠性的问题，但并没有涉及到应用层上的可靠性问题，而这些问题正是本文中着重讨论的，以此来弥补协议层与应用层之间的差距。

WS-Reliability 标准的目标
WS-Reliability 标准的目的在于通过定义客户机服务器之间的通信机制，使得 Web 服务满足如下要求：

• 提供可靠消息传递（ 至少一次语义）
• 除去重复消息（ 至多一次语义）
• 确保消息次序

WS-Reliability 定义的消息关键元素
WS-Reliability 提出了一种基于消息/确认（message/acknowledgment）模型的可靠性解决方案。这意味着每个消息发送者在发送一条消息后都会等待从服务器返回的一条回应消息－确认。

图 3: WS-Reliability 中的日志消息/确认模型

图 3显示了 WS-Reliability 规范中定义的一个消息场景。这里我们使用消息来取代 日志消息。 WS-Reliability 并不是特定日志消息而是适用于通用消息。但从我们的角度重发，我们只考虑日志应用程序。