Web服务搜索与执行引擎——系统设计方案 及系统架构设计

系统总体结构如图3.1所示，主要分为用户接口层、核心业务层以及基础服务层。



[align=center]图3.1 系统总体架构图[/align]
3.1 用户接口层
用户接口层是用户进入Cactus Web服务搜索与执行引擎的入口。本层采用了两种用户接入方式：第一种是基于Internet网络的Http访问，用户通过浏览器进入本系统，由浏览器用户代理实现；第二种是基于GPRS网络的手机用户访问，使用户通过手机进入该系统，由手机用户代理实现。
3.2 核心业务层
核心业务层是Cactus Web服务搜索与执行引擎的核心层次，实现了系统中的主要业务功能，包括：Web服务发布、Web服务解析、Web服务执行、Lucene搜索以及服务资源库。
3.2.1 Web服务发布
Web服务发布的功能是帮助用户提供者将其Web服务及相关描述注册到本系统的服务资源库中。具体地，服务提供者通过输入Web服务的名字、描述以及WSDL的URL等服务基本信息，系统将根据WSDL解析出Web服务的内部操作和相关参数动态构建中文描述录入向导，协助服务提供者实现对Web服务的使用信息的描述，并存入服务资源库中。服务提供者对Web服务的使用描述将为服务使用者提供关于如何使用该服务的详细信息，从而方便了普通用户对Web服务的使用。
3.2.2 Web服务搜索
为了提高Web服务的搜索质量与效率，我们使用了索引数据库引擎Lucene建立索引，并按照倒排文件的格式存放。用户输入搜索条件，索引引擎将通过索引数据库进行检索，把符合查询要求的数据按照用户需求进行分级排列，并返回给用户。
3.2.3 Web服务解析
Web服务解析对Web服务WSDL的解析，是系统的核心业务之一，可用于服务执行和发布过程中。系统使用IBM WSDL4J技术来进行对WSDL文档的解析，以读取服务相关信息，从而了解服务的内部结构。
3.2.4 Web服务执行
Web服务执行是实现对异构平台Web服务统一调用的核心。在用户输入服务执行所需参数并执行服务调用时，系统动态构建服务调用SOAP消息，并将其发送给Web服务核心执行组件。服务执行结束后，系统接收服务执行结果SOAP消息，对其解析，并按照用户期待的格式对结果进行重新组织。
3.2.5服务资源库
服务资源库主要用于存放提供者录入的Web服务调用相关语义信息，包括服务操作的描述和各操作的输入/输出参数等的相关描述。
3.3 基础服务层
基础服务层主要提供了对异构平台Web服务生成的支撑技术，包括Java、.Net和PHP等平台上如何开发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模式之旅”(三）http://blog.csdn.net/lin_bei/archive/2006/08/11/1051018.aspx
最终的系统架构如下：
View(V)
使用JSP作为用户通过WEB与系统交互的接口，并使用J2ME开发移动客户端，使得用户可以通过移动设备执行网上操作。
Controller(C)
控制器使用JAVA Servlet技术，com.swc.se.controller接收来自于浏览器的HTTP请求,com.swc.se.controller.mobile接收来自于手机的HTTP请求，并根据请求调用相应的逻辑，并将结果返回给用户客户端。



[align=center]图2 系统实现架构图[/align]
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展示了用户搜索到某个确定服务并对其调用执行的时序图。



[align=center] 图4 系统典型业务时序图[/align]
[align=center][/align]
[align=center]未完[/align]