级别： 中级 Robert Chumbley, 软件开发人员, IBM
Jacob Eisinger, 软件开发人员, IBM
2009 年 10 月 26 日 WS-Notification 标准包 WS-BaseNotification、WS-Topics 和 WS-BrokeredNotification 可用作面向服务的体系结构 (Service Oriented Architecture) 的通用发布/订阅接口。
为了演示这些重要 WS-Notification 功能，开发了一个针对脱销业务情形的解决方案；本文将阐述用于此零售店配送网络场景的 SOAP 消息和代码片断。
事件分发
在面向服务的体系结构（Service Oriented Architecture，SOA）中，通常需要对情况进行监视。这种监视可能是从计算机管理角度出发，或者在更广泛的情况下，是为了随时了解现实世界的事件，如天气、金融事务、医疗保健等等。为了监视这些事件，客户端可以轮询状态更改或订阅状态更改。
在 REST 领域，此类监视通常是通过轮询 ATOM 或 RSS 等 Feed 来实现的。在此情况下，将配置客户端主动请求资源提供其最新状态。客户端轮询状态的频度越高，其获得的资源表示形式就可能越准确。但是，频繁的轮询在两端都需要带宽和资源来处理连接。因此在监视的时效性不太重要或网络和硬件资源充足的情况下，轮询是非常有用的。
在 SOAP 领域，轮询不太常用，因为客户端通常接收来自事件生产者的请求。使用这种对等风格，可以创建发布/订阅系统。在此系统中，客户端请求在事件发生时发送通知。这减少了事件发生与客户端处理事件之间的延迟。
WS-Notification 已被 OASIS 制定为标准，并且是用于解决异构复杂事件处理系统中的这种事件分发业务问题的唯一标准。它为使用者指定一个用于订阅、筛选通知和管理订阅的接口，并为发布者指定一个用于发送通知的接口。此外，它还描述了通知代理，用以实现系统扩展。有关 WS-Notification 工作组和规范的更多信息，请参阅参考资料。
为什么要使用 WS-Notification
WS-Notification 是支持多个实现进行协作的标准。有了此标准，更大的生产者和使用者群体可以进行互操作。WS-Notification 并不打算取代所有消息基础结构，如低延迟总线、行业标准或 JMS 等现有的基础结构。但是，WS-Notification 系统能够通过简单的适配器与这些系统集成。显然，WS-Notification 的关键价值是能够作为标准，支持与更多数量的供应商进行更强的互操作，从而降低实现成本。
WS-Eventing 规范和 WS-Notification 标准均适用于计算机管理场景。但是，WS-Notifications 的主要功能也允许将其用于通用发布/订阅 (pub/sub) 情形。本文将探索零售店配送场景以及 WS-Notification 的功能如何实现解决方案。
配送网络场景
为了演示这些 WS-Notification 功能，本文将应用事件分发来解决脱销（out-of-stock，OOS）情况下的典型零售和客户业务问题；当商店无法满足客户的订单时，就会出现 OOS 情况。显而易见，零售方会损失销售额，客户与零售商的关系也会受到损害。为了改善这种客户关系，此解决方案跟踪商店内的货架可用性，并根据业务驱动的阈值重新订购库存，从而减少 OOS 情况。
有关围绕 OOS 情况的更多业务上下文信息，请参阅参考资料部分。
在此场景中，存在四个角色：
图 1. 显示客户、商店、代理经销商和配送商角色交互的销售网络。
客户导致产生要求买入更多库存的通知。当客户从商店购买产品时，商店的库存就会减少。当库存降至某个阈值以下时，商店将向代理经销商发送订购更多库存的通知。然后代理经销商基于有效的订阅对通知进行筛选。最后，将把商店的需要通知给订阅该产品的配送商。
配送商向代理经销商订阅他们配送的产品。配送商可以暂停和恢复他们的订阅；在配送商恢复订阅之前，发送的任何库存通知将保存在代理经销商处。
此场景的技术实现考虑到了以下情况：
- 来自一家供应商的事件处理系统接收运行于另一家供应商系统上的应用程序产生的事件
- 来自一家供应商的事件处理系统向运行于另一家供应商系统上的应用程序分发事件
- 来自一家供应商的事件处理系统订阅来自另一家供应商系统的请求事件
此解决方案演示了可伸缩、高容量和高效率事件处理解决方案所需要的系列事件分发功能，以及如何利用独特的 WS-Notification 功能（尤其是 Brokered Notification 和 Topics）来分发和筛选事件。
主要 WS-Notification 功能演示
 |
其他 WS-Notification 功能
WS-Notification 还提供了其他对于事件分发非常有用的功能。
- 分发控制
- 订阅定义了应该发送给使用者的通知。
- 动态创建/销毁
- 在运行时对订阅进行管理，从而允许动态地添加或删除通知的新使用者。
- 时间期限
- 订阅的到期时间基于注册过程中提供的时间期限。可以指定无限时间期限，并且可以更新订阅。
- 按内容筛选
- 通知并不总是与所有使用者都相关。因此，使用者可以选择仅接收其内容与所提供的条件匹配的通知。
- 推送式发送
- 与使用者不断轮询通知不同，推送式通知是直接发送的。
|
|
WS-Notification 具有提高工作效率的可靠功能集。通过在体系结构中使用这些功能，可以实现公共软件组件的重用。其中部分重要功能包括推送/拉取通知、主题、暂停/恢复功能、代理可伸缩性和发布者注册。
注意：本文中的代码基于 WS-Notification Broker 的 WebSphere Application Server Version 7.0 实现。
WS-Notification 技术
WS-Notification 指定基于 SOAP 的消息，以便能够重用公共 SOAP 组件。此解决方案使用 JAX-WS 来实现 Web 服务接口，并重用 WS-Notification Broker 的 WebSphere Application Server (WAS) 7.0 实现。对于添加或查看引用参数等任务，将需要功能更强的 W3C 端点引用（endpoint reference，EPR）接口，因此还要在实现中使用 WAS 服务提供者接口（Service Provider Interface，SPI）。为了演示这些功能，下面将结合示例 SOAP 消息和 JAX-WS 代码进行阐述。
WAS WS-Notification Broker 也可以使用其他通知源。例如，WS-Eventing 是另一个允许订阅事件源的规范。在此特定场景中，开发了一个适配器来允许代理订阅 WS-Eventing 源，并将 WS-Eventing 事件转换为已注册的配送商可以使用的通知消息。WS-Eventing 事件生产者无需任何更改即可实现此支持。在处理 WS-Eventing 源时，虽然 WS-Notification 提供了比 WS-Eventing 更多的功能，但是只能传递与 WS-Eventing 兼容的事件通知。
代理
即使在最简单的发布/订阅环境中，连接和引导信息量也会增长得非常快。如果仅有 2 个发布者和 2 个使用者，并且每个使用者希望获得每个发布者的通知，则需要建立 4 个连接。显然，增加一个使用者后，您将需要 6 个连接；增加另一个发布者后，现在的总连接数为 9。
随着更多的配送商和使用者的添加，连接数量开始快速地增长；
m 个发布者和 n 个使用者所需的连接数量将为 m x n 个连接。为了简化此拓扑，WS-Notification 将在发布者和使用者之间充当中介的通知代理实现了标准化。其中，发布者和使用者彼此分离，只需向代理发送引导信息。因此，在具有 3 个发布者和 3 个使用者的简单场景中，所需的连接数量为 6：m + n。
图 2. 此图显示了未使用代理时需要 m x n 个连接的问题。
在零售场景中，发布者和使用者分离可以实现灵活的业务关系；无需影响当前商店及配送商的配置即可添加和删除配送商及商店。
主题
WS-Notification 提供了主题的概念，可对在消息内容之外具有共性的通知分组。这包括“与商店相关的所有通知”等常见主题，或者“与编号为 123 的商店相关的所有通知”等更细粒度的主题。主题还可以包括操作；例如，“所有销售操作”。简而言之，主题允许对通知分类，不是基于其内容，而是基于其他元数据。
主题允许使用者注册接收关于给定主题的通知而不是特定的消息。
按需发布者
在分离的代理环境中，发布者无法直接与使用者联系。因此，发布者无法知道它们产生的某个通知是否将被使用。而且，由于通知的产生和传输是要占用大量资源的任务，WS-Notification 提供了一种标准方法，以便代理传达是否应该发送通知。实现这些接口的发布者称为按需发布者。
发布者注册
按需发布者需要有某种方法来向代理描述它们能够产生什么通知。WS-Notification 实现了此发布者注册的标准化。在注册过程中，发布者通过使用主题指示它可以创建哪些通知。使用此信息，代理可以高效地传达使用者订阅了哪些通知，从而向按需发布者传达它应该创建哪些通知。
可暂停的订阅
在使用者方面，有时它们将无法接收或处理通知。例如，在计划的维护期间就是这样。在此情形下，使用者可以利用 WS-Notification 的暂停/恢复功能阻止将通知发送给使用者，直到使用者发出恢复命令为止。
清单 1. 用于暂停订阅的 JAX-WS 代码。
SubscribeResponse subscribeResponse = ...;
W3CEndpointReference subEPR = subscribeResponse.getSubscriptionReference();
SubscriptionManager port =
subEPR.getPort(SubscriptionManager.class, new AddressingFeature());
port.pauseSubscription(new PauseSubscription());
|
清单 2. 用于恢复订阅的 JAX-WS 代码。
SubscribeResponse subscribeResponse = ...;
W3CEndpointReference subEPR = subscribeResponse.getSubscriptionReference();
SubscriptionManager port =
subEPR.getPort(SubscriptionManager.class, new AddressingFeature());
port.resumeSubscription(new ResumeSubscription());
|
Notification Broker 对某个订阅操作的响应包含了对负责该订阅的 Subscription Manager 的端点引用。您可以通过对 Subscription Manager 调用这些操作来暂停和恢复订阅。
拉取式订阅
在安全的环境中，例如防火墙后面，使用推送式模型进行事件分发是最高效的。在此模式下，当事件发生时，可以快速地发送和处理通知。但是某些环境具有相关安全要求，禁止通知使用者直接接收事件。例如，当防火墙位于发布者与使用者之间时，就会发生这种情况。当配送商、商店和代理经销商在具有防火墙分隔的不同网络上时，就会发生这种情况。在此情况下，WS-Notification 指定了一种标准的拉模型交互；使用者不断向发布者轮询新的通知。发布者负责尽最大努力维护以前通知的缓存。当存储已满时，WS-Notification 指定可以丢弃第一个或最后一个消息。
为了实现此工作流，使用者请求代理创建一个拉取点。 然后，使用者发送一个订阅请求，其中含有相关主题，并将拉取点作为使用者引用。最后，使用者对拉取点轮询通知。
清单 3. 用于在代理中创建拉取点的 JAX-WS 代码。
NotificationBroker port = ...;
CreatePullPointResponse response = port.createPullPoint(new CreatePullPoint());
W3CEndpointReference pullPointEpr = response.getPullPoint();
|
清单 4. 用于轮询拉取点的 JAX-WS 代码。
NotificationBroker port = pullPointEpr.getPort(NotificationBroker.class,
new AddressingFeature());
GetMessagesResponse getMessageResponse = port.getMessages(new GetMessages());
|
可以看到，消息模式和 JAX-WS 代码是非常简单的。WS-Notification 指定发送一个空消息表示创建拉取点。若要检索通知，则调用 GetMessages 操作。WS-Notification 允许使用可选的 MaximumNumber 元素来指定要返回的最大通知数量。我们在此例中省略了 MaximumNumber 元素，因此应该返回存储在拉取点的所有通知。
WS-Notification 场景细节
此零售配送供应链场景中使用了 WS-Notification 来将通知从商店发送给代理经销商，以及从代理经销商发送给配送商。这是通过许多不同步骤完成的：
- 配送商向代理经销商注册他们希望配送的产品。
- 商店要么配置为向代理经销商发送通知，要么配置为向代理经销商将自身注册为发布者。
- 如果商店向代理经销商将自身注册为发布者，代理经销商将向商店请求通知。
- 商店将向代理经销商发送库存订购通知。
- 代理经销商将此库存订购通知转发给相关配送商。
从用户界面的角度看，存在两个界面：商店和配送商。商店负责让使用者能够进行产品购买。配送商界面允许用户管理他们能够对哪些产品重新进货，并且在配送通知到达时用于监视这些通知。有关该零售商店配送场景的图形视图，请参见图 3。
图 3. 从用户角度看零售商店配送场景，其中显示了用于商店和配送商的界面。
WS-Notification 配送商订阅请求
配送商订阅请求是配送商发送给代理经销商的消息，用于请求要发送的通知。其中包含配送商希望配送的产品的产品 ID。
清单 5. 用于配送通知发送的订阅请求的 SOAP 正文内容。
<wsnt:Subscribe xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2">
<wsnt:ConsumerReference>
<wsa:Address>
http://localhost/MegaDistributor/PushConsumerService
</wsa:Address>
</wsnt:ConsumerReference>
<wsnt:Filter>
<wsnt:TopicExpression
Dialect="http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple"
xmlns:product="http://www.ibm.com/xmlns/wsn/demo/product">
product:EAT84
</wsnt:TopicExpression>
</wsnt:Filter>
<wsnt:InitialTerminationTime>P0Y0M0DT1H0M0S</wsnt:InitialTerminationTime>
</wsnt:Subscribe>
|
在此订阅请求中，MegaDistributor 请求发送产品 ID 为 EAT84 的配送通知。
WS-Notification 库存配送消息
库存配送消息是商店与代理经销商和代理经销商与配送商之间发送的通知。该通知包含了产品代码和请求的数量。
清单 6. 用于请求配送更多产品的通知的 SOAP 正文内容。
<wsn:Notify xmlns:wsn="http://docs.oasis-open.org/wsn/b-2">
<wsn:NotificationMessage>
<wsn:Topic Dialect="http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple"
xmlns:product="http://www.ibm.com/xmlns/wsn/demo/product">product:ELE19</wsn:Topic>
<wsn:Message>
<d:quantity xmlns:d="http://www.ibm.com/xmlns/wsn/demo/distributor">6</d:quantity>
</wsn:Message>
</wsn:NotificationMessage>
</wsn:Notify>
|
在此通知消息中，产品 ID 与主题对应，请求的数量与消息内容对应。在此特定通知中，产品 ID 为 ELE19，请求配送的数量为 6。
总结
本文讨论了如何使用 WS-Notification 标准包 WS-BaseNotification、WS-Topics 和 WS-BrokeredNotification 作为面向服务的体系结构的通用发布/订阅接口。我们介绍了零售商店配送网络场景以帮助演示 WS-Notification 功能，并阐述了 WS-Notification 如何成为用于事件分发和处理的首选标准。
参考资料 学习
获得产品和技术
讨论
作者简介 | 
| | Rob Chumbley 是 IBM Software Group 的Emerging Software Standards 团队在策略领域的成员。他参加了 WS-I Basic Profile Work Group，并拥有许多 Web 服务技术和标准方面的经验。Rob 最喜欢的音乐类型是德克萨斯乡村音乐。
|
| 
| | Jacob Eisinger 是 IBM Software Group 的Emerging Software Standards 团队在策略领域的成员。Jacob 参与了 Extreme Blue 计划，并拥有 XML、Java 和 Web 服务方面的经验。 |
对本文的评价
| 
