在面向服务的体系结构中构建事件驱动的应用程序，第 3 部分: 在SOA中构建WSN应用

本系列文章的第 1 部介绍了 WSN (WebService Notification) 和 WSRF (WebService Resource Properties Framework) 两个规范，第 2 部分将为大家展示一个基于 WSN 和 WSRF 的具体应用。在第 3 部分中，我们将对程序架构进行调整，在Notification Producer和Notification Consumer之间增加一个间接层：ESB，然后将我们之前实现的WSN应用迁移到ESB上，最后进行测试。

1．引言

本系列文章的第 1 部分中介绍了WSN(WebService Notification) 和WSRF(WebService Resource Properties Framework) 两个规范；第 2 部分中为大家展示一个基于WSN和WSRF的具体应用。在这个WSN应用中，Notification Producer和Notification Consumer之间是一种端到端的直接交互。在第 3 部分中，我们将对程序架构进行调整，在Notification Producer和Notification Consumer之间增加一个间接层：ESB，然后将我们之前实现的WSN应用迁移到ESB上，最后进行测试。

回页首

2. 在SOA中构建WSN应用

在第 2 部分我们实现的WSN应用中，Notification Producer和Notification Consumer之间是一种端到端的直接交互。在一个复杂的企业计算环境中，如果广泛采用这种直接的端到端的交互，那么随着企业内应用程序的增加和复杂度的提高，最终应用程序之间的关联会逐渐变的非常复杂，形成一个网状结构，这将带来非常昂贵的系统维护费用，同时也使得IT基础设施的重用变的困难重重。正如计算机领域的那句名言："有难以解决的问题，那么就增加一层"，要解决上面描述问题，我们需要对我们的程序架构进行调整，在Notification Producer和Notification Consumer 之间增加一个间接层：ESB。在这一部分，我们将首先在WebSphere Application Server V6上利用SiBus建立一个ESB，然后将我们之前实现的WSN应用迁移到ESB上，最后进行测试。目前已经有大量的文章和书籍介绍SOA，所以这里我们不再对SOA的基本概念进行详细介绍，如果您需要这方面的参考，请查阅本文最后所附的参考资料。

2.1 SOA中的WSN应用实例架构

图 1 是之前的WSN应用迁移到ESB上后的系统架构图：

这里大家可以看到Notification Producer和Notification Consumer之间的调用已不再直接把消息发给对方，而是将消息发送给ESB，然后通过ESB中的路由机制路由到目标服务，这样做的好处是：首先这样的结构将之前描述的复杂的网状结构的复杂性归纳到了ESB的服务选择和消息路由之上，大大降低了系统架构上的整体复杂性，这一点在有多个应用程序之间需要发布，订阅事件时体现的更为明显，其次，在这样的架构下，我们可以享受到服务替换，中介，监控等等ESB的基本特性，而且随着我们提升ESB的能力模型，我们还可以享受到ESB的一些如QoS这样的高级特性。

2.2 在WebSphere Application Server V6中构建ESB

要将我们的WSN应用迁移到ESB上，我们首先需要创建一个ESB，这里我们使用的应用服务器是WebSphere Application Server V6中，我们将使用该应用服务器的SiBus来创建我们的ESB，具体步骤如下：

登陆WebSphere Application Server的管理控制台，选择Service Integration'Buses，然后在右边的窗口中选择New，然后在General Properties下的Name属性处输入Demo作为我们的Bus（总线）的名字，最后直接点OK创建我们的总线，如图 2 所示：

在一个总线创建成功后，我们需要至少为它添加一个成员，对于每个添加到总线中的成员，该WebSphere实例上都会创建一个消息引擎。这里我们需要在总线列表中点击我们刚刚创建的总线Demo，然后选择Bus Members，接着选择ziqiangNode01:server1作为总线的成员（这里ziqiangNode01是本文试验环境的NodeName），其他都接受默认值，完成总线成员的添加，最后我们会看到总线成员列表中会列出我们新添加的成员：

在WebSphere Application Server V6的SiBus上，所有的消息都会被转换为SDO(Service Data Object)对象，因此我们需要一个用来存储SDO对象的子系统，另外SiBus还将把各种WSDL的定义存放在这个SDO存储子系统中，因此这里我们需要首先定义这个SDO存储子系统，在WebSphere Application Server安装的时候，会缺省安装CloudScape数据库，这里我们就将SDO存储子系统建立在CloudScape上，当然您也可以选择其他的数据库。创建SDO存储子系统的步骤非常简单，假定您将WebSphere安装到了<WAS_HOME>下，那么首先进入目录<WAS_HOME>/bin，然后执行下列命令：

wsadmin -f installSdoRepository.jacl -createDb ziqiangNode1 server1
            

如果命令执行成功，您最终会看到如下返回信息：

CWSJO0023I: SDO repository installation completed successfully.
            

同时在WebSphere的管理控制台，选择Applications'Enterprise Applications，您会看到有一个应用程序SDO_Repository被列出来。如图 5 所示：

为了使我们的总线能接收到客户端对WebService的调用请求，我们还需要配置endpoint listener。而为了使得我们的总线能调用其他的WebService，我们还需要配置一个Resource Adapter。首先我们先来配置Resource Adapter，在<WAS_HOME>/bin目录下，执行下面的命令：

wsadmin -f ..\util\sibwsInstall.jacl INSTALL_RA -installRoot
            "e:/WebSphere/AppServer" -nodeName ziqiangNode01
            

如果命令执行成功，您最终会看到下面的信息：

The resource adapter has started successfully : SIB_RA
            

同时，登录WebSphere的管理控制台，选择Resources'Resource Adapters，您会看到列表中有一个名为SIB_RA的Adapter：

接下来我们配置endpoint listener。我们知道具体传送SOAP消息的协议可能有多种（如HTTP，JMS），对于每一种具体的协议都有配置专门的endpoint listener，在本文中我们使用HTTP协议。对每一种具体的协议，两个endpoint listener会被创建，一个可以用来处理来自企业外部的请求，另一个可以用来处理来自企业内部的请求。首先执行下面的命令：

wsadmin -f ..\util\sibwsInstall.jacl INSTALL -installRoot "E:/WebSphere/AppServer" -serve
            me server1 -nodeName ziqiangNode01
            

如果该命令执行成功，您会看到下面的信息：

The application has started : sibws.ziqiangNode01.server1
            

接着执行下面的命令：

wsadmin -f ..\util\sibwsInstall.jacl INSTALL_HTTP -installRoot
            "E:/WebSphere/AppServer" -serverName server1 -nodeName  ziqiangNode01
            

如果该命令执行成功，您会看到下面的信息：

The application has started : sibwshttp1.ziqiangNode01.server1
            The application has started : sibwshttp2.ziqiangNode01.server1
            

同时在WebSphere的管理控制台，应用程序列表中，您会看到新安装了3个应用程序，它们是：sibws.ziqiangNode01.server1，sibwshttp1.ziqiangNode01.server1，sibwshttp2.ziqiangNode01.server1。 如图 7 所示：

在上述命令执行成功后，我们还需要登录WebSphere的管理控制台，选择Application Servers，然后在右边的窗口中点击server1，然后选择Endpoint Listeners，如图 14 所示：

选择New，在General Properties 下，输入SOAPHTTPChannel1作为名字，输入http://localhost:9080/wsgwsoaphttp1/作为URLRoot和WSDL Serving HTTP URL root的值，这里9082是本文试验环境所使用的端口，缺省情况下是9080。其他参数接受默认值

点击OK，我们会在endpoint listener列表中看到SOAPHTTPChannel1:

最后为了让刚刚配置的endpoint listener关联到我们的总线 Demo,在endpoint listener列表中点击SOAPHTTPChannel1，然后点击Connection Properties，然后点击New，并选择我们的总线 Demo,最后点击OK完成配置：

同时选择Service Integration'Buses，然后在总线列表中点击Demo，然后选择Destinations，您会在列表中看到一个名为ziqiangNode01.server1.SOAPHTTPChannel1Reply的Destination。

好了，到现在为止，我们已经成功地安装了SDO存储子系统，为SiBus配置了Resource Adapter和Endpoint Listener，下面我们将把我们前面实现的WSN应用我们刚刚创建的总线上来。

2.3 将HRService和Directory Service迁移到ESB上来

在本文上一节所创建的总线在整个系统中所处的是一个中介的地位，它本身并不能提供我们需要的HRService和Directory Service，因此我们首先需要安装这两个服务，安装的方法非常简单：在WebSphere的管理控制台，选择Applications'Install New Application，选择本文所附的pubscribe_all_in_one.war，并使用pubscribe_all_in_one作为context root，点击Next，在后继的步骤中分别选择Generate Default Bindings以及Deploy Enterprise beans，其他的参数都接受缺省值，完成安装。

最后在application列表中我们会看到一个名为pubscribe_all_in_one_war的应用程序，刚刚安装完成，它的状态是停止的，我们需要将它启动。

由于pubscribe_all_in_one_war中有些类和WebSphere自带的类冲突，我们需要让WebSphere优先加载定义在pubscribe_all_in_one中的类，所以在应用程序列表中点击pubscribe_all_in_one_war，然后选择Web Modules，您会看到一个名为pubscribe_all_in_one.war的module，点击它，然后将class loader mode该为Parent Last，这一点非常重要，否则pubscribe_all_in_one在运行时刻会出现错误。

注意，由于我们的程序现在迁移到了WebSphere上，因此我们需要修改一下WEB-INF/classes/wsrf-config.xml中baseWebappUrl，请将字符串"http://$HOST_NAME$:8080/pubscribe_all_in_one" 中的8080替换为您的应用服务器所使用的端口，在本文的试验环境中使用的端口是9082，将"pubscribe_all_in_one"替换您所设置的Context Root.

在我们安装了HRService和Directory Service后，我们需要配置我们创建的总线使它承担起中介的角色。在WebSphere Application Server V6中，如果总线需要调用一个外部的Service，我们需要在总线上来创建一个Outbound Service，通过这个Outbound Service，总线内部的SOAP消息可以被发送到其他的WebService。简单来说，我们可以把Outbound Service看作是外部Service的映像。我们可以通过WebSphere的管理控制台完成Outbound Service的创建，对于每个外部Service WSDL文件中的Service元素，我们的总线上都会生成一个Service Destination，而对应WSDL文件中的每个Port，在总线上都会生成一个Port Destination，从总线发往外部Service的SOAP消息，从总线内的其他Destination路由到Service Destination，然后再通过Port Destination发送到外部的服务提供者。

在我们的例子中，我们需要通过总线把发送给HRService和Directory Service的SOPA消息通过总线路由到真正的服务提供者，也就是我们的pubscribe_all_in_one这个应用程序。我们首先来为HRService创建Outbound Service，在WebSphere的管理控制台中创建一个Outbound Service是一个简单的配置步骤：

• 选择Service Integration'Buses，点击我们的总线Demo，然后选择Outbound Service，点击New
• 在向导的第一步，选择WSDL 的Location Type为URL，然后输入http://localhost:9082/pubscribe_all_in_one/wsdl/hr.wsdl作为WSDL Location的值，这里需要注意的是，我们需要根据我们的运行环境修改hr.wsdl中soap:address元素的location属性.
  
  图15：创建Outbound Service第一步
  
  
  

• 点击Next，在向导的第二步，选择服务{http://ibm.com/wsn/hr}HRService

  
  
  图16：创建Outbound Service第二步
  
  
  

• 点击Next，在向导的第三步，选择Port hr

  
  
  图17：创建Outbound Service第三步
  
  
  

• 点击Next，在向导的第四步，输入HRService作为Outbound Service的名字

  
  
  图18：创建Outbound Service第四步
  
  
  

• 点击Next，在向导的第五步，选择ziqiangNode01:server1作为总线的成员，最后点击Finish完成Outbound Service的创建。

  
  
  图19：创建Outbound Service第五步
  
  
  

• 对于Directory Service也可以类似地创建，这里不再赘述。最后我们在Outbound Service的列表中可以看到我们所创建的服务。

  
  
  图20：Outbound Service列表
  
  
  

• 同时我们可以在总线的Destination列表中看到新创建了一个Service Destination和一个Port Destination

  
  
  图21：总线的Destination列表
  
  
  

由于总线现在充当了一个中间人的角色，因此对HRService和Directory Service的调用，SOAP消息都不是直接发送给这两个服务的，而是发送给我们的总线，然后再由总线转发出去。为了使得总线能接收SOAP消息，我们需要在总线上创建一个Queue Destination以及一个Inbound Service代表要调用的服务。在Inbound Service创建完成后，我们可以将其发布，将portType，bindings以及endpoint 地址等信息提供给服务调用者。我们首先为HRService创建一个Queue Destination：

• 首先在WebSphere的管理控制台，选择Service Integration'Bus，选择我们的总线Demo，然后选择Destinations，点击New，选择Queue作为Destination的类型：

  
  
  图22：创建Queue Destination
  
  
  

• 点击Next，在向导的第一步，输入HRInboundDest作为标识符：

  
  
  图23：创建Queue Destination第一步
  
  
  

• 点击Next，在向导的第二步，选择总线成员ziqiangNode01:server1

  
  
  图24：创建Queue Destination第二步
  
  
  
• 最后完成Queue Destination的创建

接下来我们需要为HRService创建Inbound Service：

• 首先选择Service Integration'Bus，选择我们的总线Demo，然后选择Inbound Service，点击New，在向导的第一步选择URL作为WSDL Location Type，输入http://localhost:9082/pubscribe_all_in_one/wsdl/hr.wsdl作为WSDL Location的值：

  
  
  图25：创建Inbound Service第一步
  
  
  

• 点击Next，选择{http://ibm.com/wsn/hr}HRService

  
  
  图26：创建Inbound Service第二步
  
  
  

• 点击Next，输入HRInboundDestInboundService作为Inbound Service的名字，选择ziqiangNode01:server1:SOAPHTTPChannel1作为Endpoint Listener。这里我们选择的listener，如果您还记得的话是在介绍创建ESB时在WebSphere的管理控制台中创建的。

  
  
  图27：创建Inbound Service第三步
  
  
  

• 点击Next，由于这里我们不使用UDDI，所以直接点击Finish完成创建对于Directory Service，我们可以用同样的方法为其创建Inbound Service，这里不再赘述，最后我们可以在Inbound Service的列表中看到我们创建的服务：

  
  
  图28：Inbound Service的列表
  
  
  

现在，为了让我们的总线充当中介的角色，并让它能正确的路由SOAP消息，我们还需要最后为我们的总线配置消息路由，对于HRService，我们需要把HRService的Inbound Service对应的Queue Destination上接收的SOAP消息路由到HRService对应的Outbound Service的Service Destination上，而这个Service Destination则会将SOAP消息自动路由到相应的Port Destination上，最后消息被转发到HRService。具体的配置步骤如下：

选择Service Integration'Buses，点击我们的总线Demo，选择Destinations，选择HRService的Inbound Service对应的Queue Destination "HRInboundDest"，在Default forward routing path下输入：Demo:http://ibm.com/wsn/hr:HRService，这里的格式是<Bus Name>：Destination Name.

对于Directory Service的路由配置，请读者作为练习配置。

2.4 在SOA的环境中测试我们的WSN应用

现在我们的WSN应用已经完全迁移到SOA的环境来了。在介绍如何使用Apache的Pubscribe创建WSN应用时我们讲到，为了避免硬编码，我们把Notification Producer和Notification Consumer的Endpoint Reference分别写在了<app_name>/epr/directory.txt和<app_name/epr/hr.txt中，现在，由于我们的总线充当了中介的角色，SOAP消息都是发送给总线，然后再由总线转发的，因此这两个文件也需要做相应的修改，具体的修改值，我们可以通过发布Inbound Service，然后从获取的WSDL文件中得到：

• 在WebSphere的管理控制台，点击Service Integration'Buses，选择Demo，选择Inbound Services，选择HRInboundDestInboundService，选择Publish WSDL files to zip file：

  
  
  图30：发布Inbound Service
  
  
  

• 将HRInboundDestInboundService.zip保存在本地

  
  
  图31：保存Inbound Service到本地
  
  
  
• 打开zip文件中的Demo.HRInboundDestInboundServiceService.wsdl，用soap:address元素的location属性的值作为hr.txt文件中Address元素的值

对于Directory Service，我们可以类似地修改directory.txt。

下面我们开始正式的测试：

通过浏览器访问http://localhost:9082/pubscribe_all_in_one/hr.jsp，您可以看到如下界面：

访问http://localhost:9082/pubscribe_all_in_one/directory.jsp，您可以看到如下界面：

在Directory Service的界面中，点击SUBSCRIBE，您会看到一条消息说订阅成功，点击return按钮，然后您将在如下界面中接收消息：

在HR Service的界面中，点击Trigger Notification，您将看到：

回到Directory Service的界面，点击Get Last Notification，你将看到：

这里我们看到，将我们的WSN应用迁移到SOA的环境中之前和之后，对于用户来说是感觉不到变化的；通过之前我们的配置步骤我们也可以看到，对于Service的客户端或者说是调用者，依然不需要修改代码，重新部署；而对于服务的提供者来说，也一样不需要修改代码。通过简单的配置我们就可以享受到ESB的服务选择，消息路由，中介服务等基本特性，而且随着ESB能力的提升，我们还可以进一步享受QoS等高级特性，同时却基本不必对原有系统进行改动，这也就是我们要将WSN应用迁移到SOA环境中来的重要原因。

在迁移WSN应用到SOA环境之前，我们为读者详细解释了在整个应用的运行过程中所发送和接受的消息，现在您依然可以观察这些SOAP消息。同时您还可以利用总线的Mediation特性编写一个简单的Mediator来记录流经每个Destination的SOAP消息，进而观察SOAP消息是如何路由的。由于本文的主要目的是介绍在SOA环境中构建WSN应用程序，因此如何编写Mediator就不再这里讲述了。如果您感兴趣，可以参考本文后面的参考资料。

回页首

3．总结

在本系列文章（三部分）中，我们首先为大家简单的介绍了WSN规范，在WSN应用中的关键角色Notification Producer，Notification Consumer。 接着介绍了WS-Resource的基本特性并结合实例介绍了访问模式。在有了WSN和WSRF的基础后，我们为大家介绍了一个WSN应用的具体例子，接着我们采用Apache对于WSN和WSRF的实现Pubscribe，遵循其开发步骤实现了这个WSN应用，并对应用中的消息进行了详细解释以帮助大家进一步理解WSN和WSRF，最后我们将这个WSN应用迁移到了SOA环境中，详细描述了具体的迁移方法以及将其迁移到SOA环境的好处。在文章中我们涉及了较多的配置步骤，但是熟能生巧，相信随着您实践的增加，您会发现这些配置其实并不复杂，而它却能使您的系统架构更加灵活、标准和健壮。

回页首

下载