WS-Eventing、WS-Transfer Web服务标准

传输（Transfer）
    WS-Transfer详细说明了对通过Web服务进行访问的数据实体进行管理所需的基本操作。要了解WS-Transfer需要介绍两个新术语：工厂（Factory）和资源（Resource）。工厂是能够从其XML表示形式创建资源的Web服务。WS-Transfer引入了用于创建、更新、检索和删除资源的操作。应当注意，对于资源状态维护，宿主服务器最多也只能做到尽力而为。当客户端获知服务器接受了创建或更新某一资源的请求时，它可以适当地预期资源目前在的确定位置，并具有确定了的表示形式，但这并不是一个保证――即使是在没有任何第三方的情况下。服务器可能会更改某一资源的表示形式，可能会彻底删除某一资源，也可能会恢复已经删除的某一资源。这种保证的缺乏与Web提供的松耦合模型一致。如果需要，服务可以提供非Web服务架构所必需的附加保证。

    WS-Transfer的创建、更新和删除操作扩展了WS-MetadataExchange中的只读操作功能。检索操作与WS-MetadataExchange中的Get操作完全相同。Create请求发送给工厂。然后，工厂创建被请求的资源并确定其初始表示形式。工厂被假定与所创建的资源不同。新资源被分配给一个在响应消息中返回的，由服务决定的端点引用。Put操作通过提供一种替换表示形式来更新资源。资源表示形式的一次性快照与WS-MetadataExchange中的Get操作一样，也可以通过WS-Transfer中的Get操作来检索。Delete操作成功后，资源将无法再通过端点引用来使用。这4个元数据管理操作构成了Web服务中状态管理的构建基础。

事件（Eventing）
    在由需要相互通信的服务构成的系统中，可能会使用异步消息传递。在很多情况下，由一个服务生成的信息也是其他服务所需要的。由于伸缩性差，轮询往往不是获得这种信息的有效方法；通过网络发送的不必要的消息太多了。相反，该架构需要一种当事件发生时发出显式通知的机制。更重要的要求是源服务和用户服务的绑定必须在运行时动态完成。为此，Web服务架构提供了一个轻量级事件协议。

    WS-Eventing详细说明了实现下面4个实体交互的机制：订户、订阅管理器、事件源和事件接收。这使某一Web服务在作为一个订户时能够登记它对另一个Web服务（事件源）所提供的特定事件的兴趣。这种注册叫做订阅。WS-Eventing定义了某一服务可以提供的支持订阅创建和管理的操作。当事件源判定有事件发生时，它就会将此信息提供给订阅管理器。订阅管理器然后可以将该事件传送给所有匹配的订阅，这类似于传统的发布/订阅事件通知系统中的发布主题。Web服务架构提供了主题定义、组织和发现方式的全面灵活性；它为在很多不同的应用场合中可能会用到的订阅提供了一个通用的管理基础架构。也可以订阅出租的资源，但最终都必须收回。用于收回资源的主要机制是各个订阅的到期时间。查询订阅状态同样也有一种机制，帮助订户管理其若干订阅事项（包括续订、通知和取消订阅的请求）的附加操作规范中也有详细说明。当然，任何服务都可以随时自由地终止订阅，这与所有Web服务的自主原则一致。订阅终止消息可供事件源通知订户订阅终止过早。

    虽然基于事件的异步消息的一般模式很常见，但不同的应用通常都要求使用不同的事件传送机制。例如，在某些情况下简单异步消息可能是最佳选择，但如果事件接收能够通过轮询控制消息流和消息到达时间，则其他情况可能会更适用。当接收无法从源头到达目的地时，如接收有防火墙阻拦的情况下，轮询也是必要的。WS-Eventing中所引入的传送模式概念就是用来支持这些要求的。传送模式被用作一个扩展点，以便为订户、事件接收和事件源建立定制的传送机制提供一种手段。下述管理规范利用了这种机制。

    事件代理可用于聚合或重新分配来自不同来源的通知，代理还可以用作独立的订阅管理器。这两个方法都得到了WS-Eventing的支持。代理在系统中可以扮演若干个重要角色。主题可以按特定的应用类来组织使用。代理可以充当通知聚集器，用于整合来自多个来源的事件信息。它们也可以充当过滤器，这比用于其自己通知的过滤器所接收的消息要多。这种灵活性是部署健壮而可伸缩的通知系统所必需的。

WS-Eventing for WCF: [url]http://www.codeproject.com/useritems/WSEventing.asp[/url]
WS-Transfer Service for Workflow ： [url]http://www.codeproject.com/useritems/WSTransferWorkflow.asp[/url]

自由、创新、研究、探索……