由于Web服务没有锁定某个特定的平台或者用户，所以在实现松耦合方面起了很大的作用。原则上来说，该项设计是诸多企业进行设置的最佳选择。下面我们要解决的一个重要问题，这个问题在松耦合架构方面需要一个特定服务：应用通告。

　　应用通告这个概念在Java JMS,Microsoft MSMQ和TIBCO Rendezvous这样的企业信息技术领域根深蒂固。迫于在不同的应用之间建立通讯渠道的压力，通信技术成为了IT企业领域的前沿科技。但是，在将多种应用混合和对比的过程当中也出现了许多问题，例如建立一个统一的通告机制解决设计中的固有问题。

　　Web服务的首要目标就是运用相似的原则桥接应用的差异，结果会把XML这个同样通告问题带到某个Web服务情况当中。Web服务中的重量问题不仅是因为在连接不同应用时所产生的不同的设计变量，还与应用和网络绑定的性质有关，这样就会产生如等待时间，网络故障，以及设计无效等问题。

　　在解决这些问题的过程中，改进过许多Web服务标准的OASIS公司创建了Web服务通告(WSN)。WSN的目的是为建立基于主题的发布/预定Web服务提供一个事件驱动的方式。如果你了解以前提到的企业通信技术，这条术语对你来说也许陌生，它包括以下几个部分：

　　·订户：一个将自己注册到特定事件/通告中以便得到更新的Web服务

　　·发行人：一个将通告信息发送给订户的Web服务。

　　·事件/通告：令发行人将通告信息传递给订户的真正报告表

　　·通告信息：依照事件/通告，将自己发送到订户手中的有效负荷传

　　WSN研究小组将原有的部分分解为更加具体的概念，这足以帮助我们理解WSN试图解决的Web服务模式。WSN事实上必须遵守三个规范：WS-Base Notification,WS-Brokered Notification和WS-Topics，但是在认识到这三个规范的复杂性之后，这些研究小组应该最小限度的考虑到负责WSN实施的终端用户。

　　既然我们已经为大家介绍了WSN的核心理念，现在我们再介绍一个WSN实例。在其它的专栏中，我们将依据Apache Software Foundation生产的开放源软件进行深入的探索。Pubscribe将为我们提供一个可以和Apache生产的Web服务栈一起使用的WSN实施。，例如主引擎使用的Axis。Apache的WSRF实施，用于WS-Coordination的Apache Kandula或者在其它项目/规范中用于WS-ReliableMessaging的Apache Sandesha。

　　在开始工作之前，我们应该认识到Apache的Pubscribe是与其WSRF（Web服务资源框架）实施紧密地整合在一起的。由于Web服务通告流程暗含这代表发布人进行数据检索维护某种状态的意思，但是我们要注意的是这并不表示每一个Web服务栈要求WSRF使用WSN.这是WSN设计师的独特选择。这种路由可能和其他的WSN实施不同。对此你可以阅读先前关于WSRF核心概念的专栏。我们的实施包含两种类型呼叫中心使用的Web服务。其中一个类型服务是用来传送外来信息的（发布人），其他的类型是用真正的有效负荷（通告信息）来处理请求的（订户）。该有效负荷包含了XML语言编码的片段。从业务层面来看，Web服务发布人可能代表一个机构的总部，订户可以被看做是机构的分部或者是离岸系统，它可以在先到先得的原则之上接收发布人的请求。

　　我们的应用中包含两种类型的Web服务，其中一种用于传送外来请求（发布人）另一种用有效负荷（通告信息）来处理这些请求（订户），该有效负荷中包含XML编码的片断，在业务层面，网络服务发布人代表机构的总部，而订户则代表分部或者离岸系统，并按照先到先得的原则来接收外来请求

　　在这种状态下，我们要先看一看总部将要发布的WSDL合同，这项合同需要经过每个订户的处理，表1.1展示了这个合同。

　　<?xml version="1.0"?>

　　<definitions name="SupportSystemResourceDefinition"
　　   targetNamespace="http://ws.apache.org/resource/example/filesystem"
　　  
　　  
　　  
　　  
　　  
　　   >

　　<!-- WSDL <import>, <types> and <message>
　　     sections omitted for brevity -->

　　   <portType name="SupportSystemPortType" 　　wsrp:ResourceProperties="tns:SupportSystemProperties">
　
　　     <!-- Resource operations -->
　　      <operation name="GetResourceProperty">
　　         <input name="GetResourcePropertyRequest" 　　message="wsrpw:GetResourcePropertyRequest"/>
　　         <output name="GetResourcePropertyResponse" 　　message="wsrpw:GetResourcePropertyResponse"/>
　　         <fault name="ResourceUnknownFault" 　　message="wsrpw:ResourceUnknownFault"/>
　　         <fault name="InvalidResourcePropertyQNameFault" 　　message="wsrpw:InvalidResourcePropertyQNameFault"/>
　　      </operation>

　　      <operation name="SetResourceProperties">
　　         <input name="SetResourcePropertiesRequest" 　　message="wsrpw:SetResourcePropertiesRequest"/>
　　         <output name="SetResourcePropertiesResponse" 　　message="wsrpw:SetResourcePropertiesResponse"/>
　　         <fault name="ResourceUnknownFault" 　　message="wsrpw:ResourceUnknownFault"/>
　　         <fault name="InvalidResourcePropertyQNameFault" 　　message="wsrpw:InvalidResourcePropertyQNameFault"/>
　　      </operation>

　　     <!-- Other Resource operations omitted for brevity -->

　　     <!-- Notification operations -->

　　      <operation name="Subscribe">
　　         <input message="wsntw:SubscribeRequest" />
　　         <output message="wsntw:SubscribeResponse" />
　　         <fault name="ResourceUnknownFault" 　　message="wsntw:ResourceUnknownFault" />
　　         <fault name="SubscribeCreationFailedFault" 　　message="wsntw:SubscribeCreationFailedFault" />
　　         <fault name="TopicPathDialectUnknownFault" 　　message="wsntw:TopicPathDialectUnknownFault" />
　　      </operation>
     
　　      <operation name="GetCurrentMessage">
　　         <input message="wsntw:GetCurrentMessageRequest" />
　　         <output message="wsntw:GetCurrentMessageResponse" />
　　         <fault name="ResourceUnknownFault" 　　message="wsntw:ResourceUnknownFault" />
　　         <fault name="InvalidTopicExpressionFault" 　　message="wsntw:InvalidTopicExpressionFault" />
　　         <fault name="TopicNotSupportedFault" 　　message="wsntw:TopicNotSupportedFault" />
　　         <fault name="NoCurrentMessageOnTopicFault" 　　message="wsntw:NoCurrentMessageOnTopicFault" />
　　      </operation>
     
　　     <!-- Other Resource operations omitted for brevity -->

　　   </portType>
 
　　   <binding name="SupportSystemSoapHttpBinding" 　　type="tns:SupportSystemPortType">

　　      <soap:binding style="document" 　　transport="http://schemas.xmlsoap.org/soap/http"/>

　　       <!-- Binding for notification operation(s) -->

　　      <operation name="Subscribe">
　　         <soap:operation style="document"/>
　　         <input>
　　            <soap:body use="literal"/>
　　         </input>
　　         <output>
　　            <soap:body use="literal"/>
　　         </output>
　　         <fault name="ResourceUnknownFault">
　　            <soap:fault name="ResourceUnknownFault" use="literal"/>
 　　        </fault>
 　　        <fault name="SubscribeCreationFailedFault">
 　　           <soap:fault name="SubscribeCreationFailedFault" use="literal"/>
 　　        </fault>
　　         <fault name="TopicPathDialectUnknownFault">
　　            <soap:fault name="TopicPathDialectUnknownFault" use="literal"/>
　　         </fault>        
　　      </operation>           

　　       <!-- Other bindings for operations omitted from brevity -->

　　   </binding>

　　   <!-- Service name declaration -->
　　   <service name="SupportSystemService">
　　      <port name="filesystem" binding="tns:SupportSystemSoapHttpBinding">
　　         <soap:address 　location="http://www.hqsupportsystem.com/pubscribe/services/pcsupport"/>
　　      </port>
　　   </service>

　　</definitions>

　　在表的最顶端，你会看到Web服务通告的命名空间。接下来你会看到两个和通告事件相关的操作：预定和获取现有信息，用户Web服务呼叫这两种方法以便通告发布人它想要了解事件，并且获得最新信息。在WSDL合同的各处你会找到WSRF语句以及同WSDL合同相关的典型操作和捆绑。，但是我们只能描述和通告中主题相关的片段。

　　由于文章篇幅的限制，我们就不再展示WSDL背后的Web服务，发布人以及相应的订户Web服务了。但是必须要确保与Web服务相对应的生命周期重点关注上述在WSDL提到的两个方法，并保证Pubscribe提供的API建立的这两种方法的逻辑完全建立起来。

　　现在我们可以对WSN做总结了。 现在你应该能够同Web服务一样并入到相同的松耦合架构之中了。有了应用通告的支持，业务就需要更长时间的需要基于事件通告的存活过程。