本文研究阈值警告通知的示例，阈值警告通知向消费Web服务 (consuming Web service) 发出警告，告之系统正在接近承载多重SOA所能承担的最大负载。在本系列的第8部分，您将了解Web服务如何跨异构SOA来使用、产生和代理通知。Judith Myerson还涉足过Subscribe-Publish for Web services白皮书和WS-Notification产品的文档系列方面的工作。

　　引言

　　在本系列的第7部分，我说明了在处理文本格式的大型Web服务时XML二进制优化打包(XOP)规范为何要比XML解析器的效率更高。我还说明了在多面向服务的体系结构(SOA)中如何将它们转换为更为简化的二进制格式。

　　在本文中，我探讨了如何使用Web服务接收通知，如系统错误和阈值警告。我着重阐述了这些通知是如何影响异构SOA中彼此交互的Web服务和企业应用程序集成（Enterprise Application Integrations，EAI）的。我还探讨了使用XOP包作为一种简化通知的方式，并提供了将阈值警告作为通知主题的示例。
　
　　消息标准化

　　由于系统变得松耦合，为了对各种事件作出响应，更需要将Web服务接收消息的方式标准化。Web服务通知(WS-Notification)允许Web服务接收有关一个或多个主题的直接通知，从而满足了这一需要。如果某些Web需要与一些非Web服务的实体交互，WS-Notification可以为这些实体提供代理服务，将代理的通知分发到消费Web服务。实体可以是一个独立发布者，也可以是与另一个发布者通过接口交互的EAI应用程序。

　　WS-Notification有很多应用程序，例如系统或设备管理领域的应用程序或者商业应用程序（如电子交易）。WS-Notification是为了与Web Services Resource Framework(WSRF)协同使用而开发的，它提供针对特定主题创建的订阅服务。订阅列表中的主题应该与来自消费Web服务的通知请求中的主题相匹配。

　　如果基于XML的Web服务（如生产者、使用者、代理、订阅者）包含大量的大型文本文件，则XOP规范必须处理基于XML的Web服务。这些服务还应该通过业务流程规则进行优化——如果没有经过优化，则服务在使用WS-Notification规范时的效率就会很低。

　　WS-Notification探秘

　　WS-Notification文档系列包括：Publish-Subscribe Notification for Web services白皮书和三个标准化规范：

　　·WS-BaseNotification
　　·WS-BrokeredNotification
　　·WS-Topics

　　让我们来分别看一下每项内容：

　　·Publish-Subscribe Notification for Web services：此规范为WS-Notification文档系列设置目标和需求并包括安全注意事项。
　　·WS-BaseNotification：此规范展示基本功能，定义NotificationProducers、NotificationConsumers、通知和订阅。它描述了暂停订阅和恢复订阅以及对订阅时间进行控制的过程。（注：NotificationProducers是生产Web服务(producing Web service)或者通知的生产者。NotificationConsumers是消费Web服务或者通知的使用者。）
　　·WS-Topics：此规范允许在用户订阅NotificationProducer之后，将一个订阅与某个特定的主题或者多个主题关联。
　　·WS-BrokersNotification：此规范允许非Web服务实体创建一个发布者，此发布者会创建消息，并通过一个名为NotificationBroker的单独代理服务分发这些消息。

　　WS-Notification范例

　　让我们从另一个角度来看一下WS-Notification。图1展示的是由NotificationProducer、NotificationConsumer和NotificationBroker Web服务组成的三角形，我称之为WS-Notification范例。它构成了Web服务的发布-订阅通知(Publish-Subscribe Notification)的基础。

　　图1. WS-Notification范例
 
　　演练

　　正如您所看到的，此范例首先显示了订阅者正在订阅一个消费Web服务——面对人的服务或内部服务——以便接收通知，如系统错误(System Error)或者阈值警告(Threshold Warning)主题。生产Web服务负责维护订阅列表并在其中查找它们，以便与列表中的主题和通知请求中的主题相匹配。在需要更改时，您可以通过自动或者手动方式更改或删除订阅。

　　接着，消费Web服务通过向生产Web服务注册实现了Notify消息交换。为了响应来自消费Web服务的一个或多个请求，信息的生产者查找与一个或者多个主题相关的订阅(Subscription)资源。

　　接着，生产者会根据列表的每个订阅中注册的兴趣来匹配消息和相关主题。如果生产Web服务确定了一个匹配项，它就会向与该订阅关联的消费Web服务发出一个通知。如果匹配不成功，它也会发出一个通知，告知请求中的主题为未知的主题。

　　代理Web服务

　　如果订阅了一个非Web服务实体，则生产Web服务会创建一个发布者，此发布者通过一个提供代理服务的单独代理Web服务将系统错误消息分发给这个实体。如果消费Web服务订阅的主题与代理Web服务发布的主题不同，您可以对其进行配置，使代理根据定义好的管理规则将消息路由至消费Web服务。

　　如果为消费Web服务准备的代理通知的格式不正确，则代理会接收到一个使用者警告。同样，如果代理发现来自发布者的传入消息的格式不正确而无法分发，它就会向生产Web服务发送一个警告，以便将该消息转发至消费Web服务。

　　异构SOA

　　来自不同SOA的多个Web服务可以为系统错误注册相同的信息。信息的制作者可以逐个地发送多个消息，也可以批量地将多个消息发送到异构SOA中每个注册Web服务。Web服务还可以（例如SOA编号1中的Web服务）向另一个Web服务（例如SOA编号2中的Web服务）注册，以便通过第三方来接收信息。

　　由于发送到Web服务的通知的数量非常大，因此信息的制作者可能会将WS-Notification的实现委托给一个或多个面向消息的中间件(MOM)提供者。可以建立一个NotificationProducer层次结构，每个层次都具有自己的跨SOA的MOM委托权限，并且在SOA的顶层有一个编排NotificationProducer。

　　阈值触发器

　　重叠的WSN范例会导致多SOA超载，从而使事情变得更为复杂。即使在使用XOP包对Web服务进行优化后，这种情况仍然会发生。为了减少超载的可能性，应设置可用来度量通知性能的阈值，并将其配置到用来通知阈值已接近最大限度的触发器警告通知。根据中断对三个标准化通知Web服务之间的双向通信的影响设置的阈值就是这样的一个例子。在WSN范例的Web服务中，两个方向的阈值可以不同。当阈值渐渐接近限定值时，代理Web服务向面向人的Web发送一个阈值警告通知。

　　也可以将通知阈值应用到以下类别：

　　·执行时间：此类别是Web服务可以执行请求或者发布通知的最长时间。
　　·访问时间：此类别是Web服务可以访问另一个Web服务或实体以发出请求或者发布通知的最长时间。
　　·Web请求：此类别是Web服务在相同时间可以接收和发送Web请求的最大数量。
　　·带宽量：此类别是总体带宽可以实现的最大带宽量，因为在网络空间中，不同的带宽可能会相互争用。
　　·通知负载：此类别是每个SOA可以处理的最大通知的数量。
　　·消息速率：此类别是在给定的时间内可以分发的消息的最大数量。

　　结束语

　　让Web服务能够接收和发送通知，要求人们提前作出计划，确定应该如何设计应用程序来避免在高峰时间出现超载。应该就阈值警告问题与系统管理员团队沟通，阈值警告用于警告Web服务，这些服务已接近发送和接收多个通知的最高级别。

　　您会发现，提前解决这些问题会使通知Web服务应用程序这一工作变得容易得多。可以使用WS-Notification文档系列来为跨SOA消费、生产和代理Web服务开发通知。管理员还会发现，这些问题的解决使管理和执行系统级通知变得更为容易。这样，管理员就可以确定使用多少应用程序来接收和发送通知而不会导致系统超载。