由于系统变得松耦合,为了对各种事件作出响应,更需要将 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 文档系列包括:Publish-Subscribe Notification for Web services 白皮书和三个标准化规范:
让我们来分别看一下每项内容:
让我们从另一个角度来看一下 WS-Notification。图 1 展示的是由 NotificationProducer、NotificationConsumer 和 NotificationBroker Web 服务组成的三角形,我称之为 WS-Notification 范例。它构成了 Web 服务的发布-订阅通知 (Publish-Subscribe Notification) 的基础。
正如您所看到的,此范例首先显示了订阅者正在订阅一个消费 Web 服务——面对人的服务或内部服务——以便接收通知,如系统错误 (System Error) 或者阈值警告 (Threshold Warning) 主题。生产 Web 服务负责维护订阅列表并在其中查找它们,以便与列表中的主题和通知请求中的主题相匹配。在需要更改时,您可以通过自动或者手动方式更改或删除订阅。
接着,消费 Web 服务通过向生产 Web 服务注册实现了 Notify 消息交换。为了响应来自消费 Web 服务的一个或多个请求,信息的生产者查找与一个或者多个主题相关的订阅 (Subscription) 资源。
接着,生产者会根据列表的每个订阅中注册的兴趣来匹配消息和相关主题。如果生产 Web 服务确定了一个匹配项,它就会向与该订阅关联的消费 Web 服务发出一个通知。如果匹配不成功,它也会发出一个通知,告知请求中的主题为未知的主题。
如果订阅了一个非 Web 服务实体,则生产 Web 服务会创建一个发布者,此发布者通过一个提供代理服务的单独代理 Web 服务将系统错误消息分发给这个实体。如果消费 Web 服务订阅的主题与代理 Web 服务发布的主题不同,您可以对其进行配置,使代理根据定义好的管理规则将消息路由至消费 Web 服务。
如果为消费 Web 服务准备的代理通知的格式不正确,则代理会接收到一个使用者警告。同样,如果代理发现来自发布者的传入消息的格式不正确而无法分发,它就会向生产 Web 服务发送一个警告,以便将该消息转发至消费 Web 服务。
来自不同 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 服务应用程序这一工作变得容易得多。可以使用 WS-Notification 文档系列来为跨 SOA 消费、生产和代理 Web 服务开发通知。管理员还会发现,这些问题的解决使管理和执行系统级通知变得更为容易。这样,管理员就可以确定使用多少应用程序来接收和发送通知而不会导致系统超载。
==============================================================
使用 XML: 提供更友好的 RSS 和 Atom 提要RSS 和 Atom 新手的明智选择 http://www-128.ibm.com/developerworks/cn/xml/x-wxxm37.html |
级别: 初级 Benoît Marchal ([email protected]), 顾问, Pineapplesoft 2006 年 11 月 27 日 Web 站点上的 RSS 和 Atom 提要如同雨后春笋般涌现。它们之所以如此流行,原因就在于为忠诚的访问者提供了一种简单的机制,帮助他们注册站点、获得更新通知。但对于用户来说,它们并非总是非常简单,特别是那些使用较旧的浏览器的用户更是如此。在这篇文章中,Benoît 介绍了一种技术,帮助 Web 站点的访问者阅读和理解 RSS 和 Atom 提要。 RSS 和 Atom 提要提供了一种极其有效的解决方案,使访问者可以订阅您的站点,并在新项目可用时得到通知。它们的流行程度与日俱增,原因在于访问者越来越多地关注自己的隐私、警惕垃圾邮件。Atom 和 RSS 使访问者能够获得您的站点的最新信息,并且无需提供任何私人数据。 RSS 在 blog 中非常流行,但它并非局限于 blog:所有站点都能够从建立起忠实的客户关系中受益。 Web 站点管理员所面临的挑战之一就是 RSS 和 Atom 依然属于新兴事物,知道它们的人并不多,了解其用法并安装了恰当的软件的人更是少之又少。 这一挑战特别困难之处就在于您必须在 Web 站点上放置一个 RSS 或 Atom 文件的链接,以便访问者订阅,但若单击此链接,许多访问者都会看到 XML 代码,看起来显然不是非常友好。 Web 连锁(Web syndication)正处于过渡阶段。它已经体现出自己的优势,值得在您的 Web 站点中构建 RSS,但依然有许多用户尚未完成恰当的配备,无法订阅 RSS 提要。Apple Safari 是第一个带有内置 RSS 支持的主流浏览器(2005 年)。Firefox(v 1.5)、Internet Explorer(v 7)和 Opera(v 9)很快跟进。 到了明年这个时候,所有主流浏览器都将提供极好的 RSS 支持。可能还要再过一两年,大多数用户才会升级完成,在那之前,您无法放心地假设所有访问者都使用支持 RSS 的浏览器。 在此期间,您可提供一种几乎能与所有浏览器正常配合的替代性选择。 情况究竟怎样?RSS 或 Atom 提要是一种 XML 文档。用户单击它时,浏览器下载文档,并试图将其作为 XML 显示,也就是原始代码。更糟糕的是,某些版本的 Internet Explorer 将显示安全警告。 这种情况并不轻松。从技术上来说,RSS 提要应具有 在实践中,很少有访问者具有恰当的配置,他们很可能会看到晦涩的错误消息。因此,大多数 Web 站点都使用 更糟糕的是,由于配置错误,某些站点将 XML 文档作为 为缓解问题,最新的浏览器会嗅探(sniff) 传入的 XML 文件,以恰当地对其加以分类。简单地说,嗅探就表示它们将读取开头的一些字节,查找 RSS 或 Atom 标记。但这同样也要求访问者使用的是一种支持 RSS 的浏览器。 幸运的是,存在一种较好的解决方案:XSLT 样式表。如果浏览器将提要作为 XML 文档处理,它将使用样式表来呈现明确的页面。另一方面,如果浏览器识别出 RSS 和 Atom 提要,则将忽略样式表。瞧!这简直是世界上最美好的事情! 清单 1 是与一个样式表关联的 RSS 文档(摘自我个人播客的提要)。请注意,第二行是一条 清单 1. RSS 摘录
清单 2 是样式表。如果您熟悉 XSLT,那么在几分钟内就可以编写出一个类似的样式表……但要注意下一小节中介绍的一个特殊问题。如果您了解 XSLT,可直接跳到 下一小节 处。如果还不熟悉 XSLT,请继续阅读,我将简要介绍在本系列其余部分中处理 RSS 所必需的知识。 清单 2. XSLT 样式表
请注意,样式表是一个 XML 文档(正像 RSS 或 Atom 流一样),它使用一个名称空间(就像 Atom 元素或 RSS 扩展)。通常,对于 XML 文档,您必须谨慎处理语法。特别是要保证开始标记( 样式表包含 XSLT 语句以控制呈现(在 如果您希望修改 清单 2 以便适应您的站点布局,可以编辑 您将需要用到的四条 XSLT 指令是
例如,要复制提要标题,路径是 要从一个属性中复制数据,可用
属性中的花括号(只用在属性中)从 RSS 或 Atom 提要中提取信息,就像 最后但并非最不重要的一条指令就是 这里只介绍了一些 XSLT 的粗浅内容,但如果您能擅加利用复制粘贴操作和 清单 2,就可以将其调整为适合您的站点的布局。关于 XSLT 的完整教程,请参见 参考资料 部分。 如果您的样式表未能如愿地工作,请按照以下几方面进行检查:
绝大多数提要编辑器都允许您插入所需的 如果 Firefox 支持 XSLT 中的
使用 对于这种行为是否符合标准,Firefox 社区中一直存在争论。但这确实是个问题,您需要找到一种解决方案。 幸运的是,Sean M. Burke 提出了一段 JavaScript 代码,可以巧妙地回避这种限制。Burke 先生非常友善,公开了自己的代码,任何人都可以在任何项目中使用这些代码。方便起见,我在 参考资料 中给出了这段脚本的链接。 为使该脚本正常工作,您的样式表必须插入 最后,您必须在加载 HTML 文档时调用脚本( 在 RSS 或 Atom 提要中列出项目只是开始。毕竟,Web 站点中已经随处都有内容,而提要的设计目的在于促进订阅,而不是复制内容。 大多数向 RSS 或 Atom 提要附加了 XSLT 样式表的 Web 站点管理员都会提供指导信息,说明如何安装一个新的聚合器然后订阅其提要。 虽然这听起来像是正确合理的作法,但根据我的经验,看到此类页面的访问者未必会去安装聚合器。在病毒和木马程序肆虐的网络上,网民们会对安装软件的要求充满猜疑。 因此,许多站点都包含将访问者定位到在线聚合器(如 Google Reader 或 Yahoo!)的指令。这似乎是个好办法,但我对这种做法的效率持保留态度。除非访问者已订阅了许多提要,否则他们注册一个新服务的可能性不会比安装一个新软件高。假设他们确实注册了,那么他们记得去访问在线聚合器的机会有多大?我的想法是:如果访问者必须将某个站点加入书签,那么我宁愿那是我的站点, 从个人角度来说,我提供了一种选择,利用 RSS 到电子邮件的服务之一通过电子邮件进行订阅。您可放心地假设,所有访问者都有一个电子邮件地址。我编写了详细的指导说明,列出了选项,并包含了一个非常醒目的电子邮件订阅表单。我发现,在我个人播客网站中,五分之一的访问者宁愿通过电子邮件订阅,而不是 RSS。 RSS 和 Atom 可能是较好的技术解决方案,但什么也比不上一项熟悉的服务,而对于许多访问者来说,电子邮件就是一种最熟悉的服务。 为了避免重复编写订阅指导说明(如果使用多份指导说明,将来有可能出现不一致的风险),我使用了 清单 3 中的样式表。它比 清单 2 中的要简单,实现了 HTML 重定向,将访问者定位到我的站点内的一个页面。 清单 3. 最简单的解决方案?重定向!
访问者单击 RSS 提要时,如果其浏览器不能识别 RSS,则将发生重定向操作! 这篇文章介绍了如何为 RSS 或 Atom 提要打造一张友好的 “面孔”。在它们被广泛认识之前,将本文介绍的内容作为一项安全措施去实现是个好主意。 |