Web服务搜索与执行引擎(四)——基于(三)的系统架构设计

上一总结文档Web服务搜索与执行引擎(三)——系统设计方案 可以说是系统的一种物理结构，基于这样的结构，我们是这样设计接下来的系统架构。

1 系统功能图

系统功能结构图如图1所示。

使用者管理功能：服务使用者需要注册到本系统才能真正使用一个服务，并且，服务使用者可以查看其消费记录等信息，系统需要对服务使用者的相关数据进行管理。

提供者管理：提供者需要注册本系统才能进行发布服务等操作，系统需要对服务提供者信息进行管理和维护。

服务发布功能：服务提供者输入一些服务相关数据，如服务各部分的描述，服务的WSDL位置等信息即可将其服务发布至本系统。

服务搜索功能：服务的使用者可以对其想要的服务进行搜索，本系统搜索所有服务发布者的服务信息，找到合适的，返回给使用者。

服务执行功能：服务的使用者对其搜索到的服务进行操作，只需在网页中输入一些信息，即可调用远程异构平台服务，这同时也是使用者和系统的最终目标。

服务管理：服务提供者可以对其发布的服务进行管理，如修改服务数据，删除所提供的服务，查看此服务的消费记录等。

图1 系统功能结构图

2 系统架构

本系统采用J2EE WEB技术来实现，使用传统的MVC模式跟DAO模式的分层架构来组织整个系统。

上学期刚刚接触这个项目时，初衷是打算使用几种流行的开源框架来架构整个系统，如使用Struts来设计显示层，使用Spring来设计核心业务层，使用原生的JDBC (由于对Hibernate只是简单了解，所以当时也没打算使用它)再加上索引数据库引擎Lucene来设计持久层的，以前的团队项目并没有使用Struts+Spring结合的，只是用Spring做过小的案例，而Struts还算用它做过团队项目，然而经过一个愉快的寒假后并没有在这两种开源项目的结合上做好充分准备，所以开学回来后，只剩下一个月就得提交作品了，但是还没有使用这两种开源框架设计好整个系统的架构，最终决定，还是使用之前自己在架构团队项目时一直使用的方法：传统MVC+标准DAO。

即自己使用MVC模式来设计表现层，使用DAO模式来设持久层，而核心业务层就使用Javabean，我想这样的搭配还有一个原因就是，设计出来的系统必须具有可扩展性，前些日子团队在编程时，很好的体现了架构的重要性，首先我们的系统在客户表现端的多样性，即系统支持JSP页面的客户端及支持J2ME手机客户端，而这两种客户端在编程时在代码上必须避免重复编程，必须重用已有代码，所以在表现层上必须具有扩展性即使用MVC模式设计出来的表现层，应该在系统添加另外一种客户端表现方式时不会影响到系统的核心代码，即很好地体现了面向对象设计的基石“开—闭”原则：一个软件实体应当对扩展开放，对修改关闭。另外还有一点就是，本系统的持久层比较特殊，因为使用到了两种数据库存储策略，即Lucene索引引擎+MySql数据库，所以在持久层的设计时，我还是按以前项目中一直使用的方法：使用标准DAO模式来设计持久层，可以看看SeConfig.xml配置文件：

<?xml version="1.0"?>
<config>
<daos>
<dao id="serviceDAOLucence"
type="com.swc.se.dao.lucene.ServiceDAOLucence" />
<dao id="operationDAO"
type="com.swc.se.dao.jdbc.OperationDAOJDBC" />
<dao id="serviceDAOJDBC"
type="com.swc.se.dao.jdbc.ServiceDAOJDBC" />

<dao id="cosumingHistoryDAO"
type="com.swc.se.dao.jdbc.CosumingHistoryDAO" />

<dao id="providerDAO"
type="com.swc.se.dao.jdbc.ProviderDAOJDBC" />

<dao id="consumerDAO"
type="com.swc.se.dao.jdbc.ConsumerDAOJDBC" />
<dao id="detectDAO"
type="com.swc.se.dao.jdbc.DetectDAOJDBC" />
<dao id="parameterDAO"
type="com.swc.se.dao.jdbc.ParameterDAOJDBC" />
</daos>
</config>

对应ServiceDAO，两种实现方式：Mysql+Lucene,这个接口隐藏了持久化操作的细节，而最终的实现细节是使用何种存储策略，就是由系统运行时来确认，如果说系统以后想要更换另外一种存储策略或者增加存储方式，就可以在这个配置文件中增加说明。我想这也是面向对象另外一个设计原则，依赖倒转原则：要依赖于抽象，不要依赖于具体。即针对接口编程，不要针对实现编程。
这也是开源框架Spring的IOC框架所体现的。详细的说明请见我的那篇blog:一次愉快的“DAO模式之旅”(三）

最终的系统架构如下：

View(V)

使用JSP作为用户通过WEB与系统交互的接口，并使用J2ME开发移动客户端，使得用户可以通过移动设备执行网上操作。

Controller(C)

控制器使用JAVA Servlet技术，com.swc.se.controller接收来自于浏览器的HTTP请求,com.swc.se.controller.mobile接收来自于手机的HTTP请求，并根据请求调用相应的逻辑，并将结果返回给用户客户端。

图2 系统实现架构图

Model(M)

系统逻辑层由所有的处理逻辑组成，即com.swc.se.model包，它包括数据库操作模块，服务解析模块，搜索模块等构成。MVC模式的Model调用DAO模式中的DAO对象，所以这一层的业务对象只应该关注业务逻辑，不应该关心数据存取的细节。数据访问对象必须实现特定的持久化策略。如，基于JDBC跟Lucene的持久化逻辑，这样就抽出来了下面的DAO层，

DAO

作为数据源层，而之上的Model层与之通讯而已，如果将那些实现了数据访问操作的所有细节都放入高层Model的话，系统的结构在一定层次上来说就变得有些混乱。低级别的数据访问逻辑与高级别的业务逻辑分离，用一个DAO接口隐藏持久化操作的细节，这样使用的最终目的就是让业务对象无需知道底层的持久化技术知识，这是标准 j2ee 设计模式之一，也是我们在架构整个系统时所遵从的原则之一。

DB

数据库，用于存储所有Web服务提供者发布的Web服务的有关信息，如服务操作的中文描述，输入/输出参数的中文描述等。

Lucene

索引库，用于存储所有Web服务的主要信息，描述文档WSDL的URL及服务名等。

服务会话层

com.swc.se.util包存放的主要是用来:解析WEB服务描述文档WSDL的Transform，利用SAAJ技术构建SOAP消息的的Invoke类等

图3系统部分核心类类图

远程异构平台所发布的服务，是用户需求的最终执行部分。

3 系统部分核心类

系统中的部分核心类及其关系如图3所示。

4 典型业务时序图

如图4展示了用户搜索到某个确定服务并对其调用执行的时序图。

图4 系统典型业务时序图