搜索引擎实现（精选十篇）
搜索引擎实现 篇1
因特网的出现, 彻底地改变了我们生活, 使我们地球真正成为一个地球村, 人和人之间的交流也从来没有如此的简单直接, 手机开始走入我们的千家万户, 成为了我们的生活必须品, 渐渐的尤其是在在中国, 手机用户的数量已经远远超过因特网的数量, 而且这个数目正在快速增加, 还有就是人们更换手机的周期要比更新电脑的周期短得多。所以未来无线互联网将会大大地改变我们的生活。但现有的移动搜索存在一些问题:
(1) 现有互联网的搜索模式到手机上来, 没有为手机这样的终端的特点量身定做一个搜索引擎。
(2) 目前的移动搜索引擎都是基于GSM网络, 也就是3G网络, 这种网络上的特点就是上网速度慢, 服务不够为用户考虑。
(3) 移动搜索里用户搜索的内容将会有区别于互联网搜索, 比如地图搜索、视频搜索、比价搜索等等。
(4) 移动搜索, 由于手机终端的屏幕小等问题, 所以要求返回结果的准确性和精确性, 用户是无法忍受你返回给他一大堆垃圾的。
(5) 移动搜索要求个性化, 因为可以根据手机号码等来作为区别每个个体, 同时广告也需要个性化和针对性。
2、系统相关技术
2.1 爬虫模块的设计与实现
在Web上出现的第一个实用站点之一——搜索引擎中, 爬虫 (AnswerSpider) 程序表现出了强大的功能。搜索引擎的作用是检索Web的内容。当你把几个关键字键入搜索引擎时, 它会提供符合搜索标准的Web链接。搜索引擎通过构造一个包含Web内容索引的大数据库来实现这一功能。
如果人工地去检索和分类整个Web将是一项巨大的工作。因而扫描Web站点、检索其内容这一工作始终是留给爬虫程序来做的。当爬虫程序扫描Web站点时, 它同时也查看当前站点所链接的其他网页。爬虫保留这些链接的列表, 当它完成当前站点的扫描时, 它将访问那些被链接的站点。由于在Web中广泛使用了超级链接, 我们可以设想这种方式进行下去, 一个爬虫程序最终可以访问整个Web的几乎所有可访问的网页。然而几乎每天都有新的站点接入, 而一个爬虫程序也不可能访问因特网的每一个站点。
2.2 索引模块的设计与实现
在整个搜索系统中, 爬虫模块实现对网页的链接的分析和对页面信息的处理, 并且把有用的信息保存为文件存入磁盘中。那么紧接着第二步就是索引模块对磁盘中的文件进行分析和建立索引文件。索引模块的好坏直接关系到整个搜索引擎的高效性和准确性。
Answer索引模块的运行机制, Answer索引模块从功能上可以分为三个部分。
(1) 从磁盘系统中读取AnswerSpider保存的有格式的文本文件。因为Lucene只能索引文本文件, 所以如果要索引其他类型的文件时, 必须对转换成文本。
(2) 分析正文数据使之更加适合被索引。分析数据时, 先将文本数据切分成一些大块或者语汇单元 (tokens) , 然后对它们执行一些可选的操作。在Answer索引中是使用CJKAnalyzer分析器对文本文件进行分析。
(3) 将分析过后的数据写入索引。对输入数据分析处理完之后, 就可以将结果写如到索引文件中。Lucene将输入数据以一种称为倒排索引的数据结构进行存储。在进行关键字快速查找时, 这种数据结构能够有效地利用磁盘空间。另外在这一部分中Answer还对没个网页进行了一次类似Google的PageRank的打分, 使索引评分更公平公正。
3、系统的设计与实现
3.1 搜索模块功能
搜索模块包括接受用户输入查询短语、检索、获得相应的匹配结果并显示给用户。此时我们已经有了索引网页库和倒排文件, 需要做的就是通过搜索模块实现索引数据与用户查询的互通。
在搜索模块中, Answer在调用Lucene类的基础上又增加了两个类ParseHits类和ReadHits类。
ReadHits类:ReadHits是一个读取由Hits类返回的结果的类, 在该类中会调用ParseHit类用于对结果集进行解析。ReadHits类是直接和用户界面打交道的类。
ParseHit类:ParseHit类是一个再一次把和用户输入短语与返回结果集合进行比较解析的类, 是为了使搜索结果更加准确而设置的一个类。例如会把查询短语和返回的结果中的网页的标题进行匹配, 如果和标题的相似度很接近则会把该结果的顺序提前。
3.2 搜索模块运行机制
Answer搜索模块的运行机制主要包含四个部分, 各个部分的任务分别如下:
(1) 在用户界面上提供给用户输入框, 用来接收用户输入的查询项。
(2) 调用QueryParser类对用户输入的查询项进行解析, 例如解析“A+B”短语等。
(3) 创建多个项对象, 使之能够在多个关键域中查询。在索引模块中, 我们对网页的URL, Tille等关键词使用Field.Keyword () 方法分别创建了索引, 这些结果将会搜索模块中被使用。例如:
Term t=new Term (“title”, ”杭州师范大学”) ;
Query query=new TermQuery (t) ;
Hits hits=searcher..search (query) ;
(4) 利用ReadHits类和ParseHit类对结果进行再一次的排序, 并且把结果返回在用户界面上, 返回结果和现在的搜索引擎一样, 每条结果显示网页标题和URL链接。
3.3 Answer搜索模块的界面设计
因为Answer是一个为手机等移动设备提供搜索服务的搜索引擎, 所以Answer的用户界面也是在移动设备的浏览器上运行的。由于上面的原因Answer的界面就选择了使用WML语言来编写。
3.4 用户界面和源代码
Answer提供给用户的操作界面, 是用标准WML语言+JSP技术编写的网页, 遗憾的是NOKIA Mobile Internet Toolkit对中文的支持很不好, 所以这里不得不选择了使用英文。它的源代码就和当初Google刚诞生时一样, 很简单, 只提供了一个输入框和Search按钮。关键源代码如下:
首页上的输入框接受用户的输入的查询词, 并且把关键词传递给后台, 后台会执行搜索, 并且把信息通过一个结果页面的形式返回给用户。在每个结果中会包含该网页的标题和URL链接。比如我们输入“Baidu”这个关键词, 会得到下面的结果页面 (页面中包含查询到的结果数和所用的时间) :
该JSP+Wap的网站主要运行在Web服务器上, 在Answer中使用的是Tomcat服务器, 运行的画需要开启Tomcat和Nokia Gateway Simulator, 通过Nokia Browser Simulator来运行。
4、结语
本系统能完成了移动搜索引擎的开发, 并通过Nokia Browser Simulator上模拟运行。在后续的工作, 将会实现各个模块协同工作, 并且增加Answer搜索图片、mp3、视频等等功能, 并且会使Answer专注于移动搜索服务。
参考文献
[1]李晓明, 闫宏飞, 王继民.搜索引擎——原理.技术与系统, 科学出版社, 2005.
[2]Otis Gospodnetic&Erik Hatcher Lucene in Action.中文版, 电子工业出版社, 2007.
ASP实现网站智能分词搜索 篇2
用ASP实现搜索引擎的功能是一件很方便的事，可是，如何实现类似3721的智能搜索呢？比如，当在搜索条件框内输入“中国人民”时，自动从中提取“中国”、“人民”等关键字并在数据库内进行搜索。看完本文后，你就可以发现，这个功能实现起来竟然是如此的简单。
第一步，我们要建立一个名为db_sample.mdb的数据库（本文以Access2000数据库为例），并在其中建立表T_Sample。表T_Sample包括如下字段：ID 自动编号
U_Name 文本
U_Info 备注
第二步，我们开始设计搜索页面Search.asp。该页面包括一个表单
（Frm_Search），表单内包括一个文本框和一个提交按钮。并将表单的method属性设为“get”，action属性设为“Search.asp“，即提交给网页自身。代码如下：
以下是代码片段：
＜!--Search.asp--＞
＜form name=”frm_Search“ method=”get“ action=”Search.asp“＞请输入关键字：
＜input type=”text“ name=”key“ size=”10“＞
＜input type=”submit“ value=”搜索“＞
＜/form＞
下面，就进入了实现智能搜索的关键部分。
首先，建立数据库连接。在Search.asp的开始处加入如下代码：
以下是代码片段：
＜%
Dim strProvider,CNN
strProvider=”Provider=Microsoft.Jet.OLEDB.4.0;Data Source=“strProvider=strProvider & Server.MapPath(”“)&
”datadb_Sample.mdb“ 假设数据库存放在主页根目录下的data目录下Set CNN = Server.CreateObject(”ADODB.connection“)
CNN.Open strProvider 打开数据库连接
%＞
接下来，判断 ASP页所接收到的数据，并在数据库中进行搜索。
以下是代码片段：
＜font color=”#FF0000“＞未找到任何结果！！＜/font＞
＜%
Else
%＞
搜索名称为“＜font color=”#FF0000“＞＜%= S_Key %＞＜/font＞”的项，共找到 ＜font color=”#FF0000“＞＜%= RST.RecordCount %＞＜/font＞ 项：＜p＞
＜%
While Not RST.EOF 遍历整个记录集，显示搜索到的信息并设置链接%＞
＜!--此处可设为你所需要的链接目标--＞
＜font style=”font: 12pt 宋体“＞＜a href=”info.asp?ID=＜%= RST(“ID”)%＞“ target=”_blank“＞＜%= RST(”U_Name“)%＞＜/a＞＜/font＞＜!--显示部分详细内容--＞
＜font style=”font: 9pt 宋体“＞＜%= Left(RST(”U_Info“),150)%＞＜/font＞＜p＞
＜%
RST.MoveNext
Wend
RST.Close
Set RST=Nothing
End If
End If
%＞
在上面的代码中，有一个自定义函数 AutoKey，该函数是实现智能搜索的核心所在。代码如下：
以下是代码片段：
＜%
Function AutoKey(strKey)
CONST lngSubKey=2
Dim lngLenKey, strNew1, strNew2, i, strSubKey
’检测字符串的合法性，若不合法则转到出错页。出错页你可以根据需要进行设定。
if InStr(strKey,”=“)＜＞0 or InStr(strKey,”`“)＜＞0 or InStr(strKey,”“)＜＞0 or InStr(strKey,” “)＜＞0 or InStr(strKey,” “)＜＞0 or
InStr(strKey,”“)＜＞0 or InStr(strKey,chr(34))＜＞0 or InStr(strKey,”“)＜＞0 or InStr(strKey,”,“)＜＞0 or InStr(strKey,”＜“)＜＞0 or InStr(strKey,”＞“)＜＞0 then
Response.Redirect ”error.htm“
End If
lngLenKey=Len(strKey)
Select Case lngLenKey
Case 0 若为空串，转到出错页
Response.Redirect ”error.htm“
Case 1 若长度为1，则不设任何值
strNew1=”“
strNew2=”“
’Case Else 若长度大于1，则从字符串首字符开始，循环取长度为2的子字符串作为查询条件
For i=1 To lngLenKey-(lngSubKey-1)
strSubKey=Mid(strKey,i,lngSubKey)
strNew1=strNew1 & ” or U_Name like %“ & strSubKey & ”%“
strNew2=strNew2 & ” or U_Info like %“ & strSubKey & ”%“
Next
End Select
’得到完整的SQL语句
AutoKey=”Select * from T_Sample where U_Name like %“ & strKey & ”% or U_Info like %“ & strKey & ”%" & strNew1 & strNew2
End Function
%＞
要实现智能搜索，其核心就是将搜索关键字进行自动分组。在此处，我们使用了循环取长度为2的子串的方法。为什么不将子串长度定为1、3、4或其他 呢？这是因为若子串长度小于2即为1时，会失去将关键字分组的功能，而若子串长度大于2，则会丢失一些词组。大家可以将 CONST lngSubKey=2改为其他数字试一试，孰优孰劣自见分晓。
最后，别忘了将数据连接关闭，以释放资源。
以下是代码片段：
＜%
CNN.Close
Set CNN=Nothing
%＞
搜索引擎实现 篇3
随着“互联网+”的兴起，依托互联网的航运业大数据浪潮涌动。相比干散货、油轮运输，处在全球货主、贸易商、船东及港口等海运贸易上下游交汇点上的班轮业，已成为航运大数据革命的第一个突破口。由于班次密、周转快，更有“大数据”生成与占有的深度资源，以及开展“大数据”研发和应用的优势：一是班轮联盟形成的“航线群”、“运力群”与货载流、资金流、信息流，无论体量、传速均远远超过了其他运输方式，建构“大数据”模式，从中发现和洞悉市场风云变幻，见事早则决策早、行动快。二是运用“大数据”，预测市场需求，精准投放运力，优化运力结构，锁定单箱成本，提升舱位利用率，有效应对运力过剩;三是让“大数据”作出不同航线、不同船型和联运服务的运费定价预测，向供应链业务整合要效益，管控风险，抑制运价“笋图”式的损害。
不可否认，集装箱班轮运输在航运大数据中居于先导优势，特别是在汹涌而来的大船潮中，一方面是船队规模、运力投入抑或航线网络均呈爆发性增长，每时每刻制造出庞大而纷繁的海量数据;但另一方面，在运营平台各异、数据标准不一、统计模式涣散的状态下，目前班轮业的海量数据被分割、流散在机构或企业的闭环内，并未构成“大数据”，因为“多数据”并不等于“大数据”。面对全球班轮运力和航线网络的快速增长，一方面，大部分班轮公司业务数据互相独立，信息孤岛和重复建设严重，“多数据”往往还成了垃圾信息，难以具有集约资源、精准决策的导向与价值;另一方面，政府部门、相关行业机构仅凭每周或者每月定期收集几张数据统计表格，且不论从全面翔实、可靠有效的数据收集和解析形成“大数据”，即便根据班轮企业报备的运价计算形成的航线运价指数，也并未与即期市场直接“挂钩”，难以让托运人在一个公共平台上“比价”下单。
面对班轮业的海量数据，迫切需要构建更快捷、更具洞察力的大平台实现运力规模、航线设置、港序版图、班轮船期等实时汇集、信息共享，从而满足业界的广泛需求。2015年，美国西海岸港口由于劳资矛盾造成历经数月的严重拥堵，仅5月份全球班轮船期变动就超过500万次。如果出口商无法取得及时更新的船期，导致订舱不准确、滞期费增加和错过集装箱交付截止期等，不仅付出了巨大的时间成本，同时由于班期失衡调整，造成交货延滞、服务信誉受损，物流成本大幅增加。
依托全球三十大主要承运人，占全球90%集装箱班轮近
5 000条航线与超过46 000对“港口配搭”的船期数据，构建起在线船期搜索平台，是近年来货讯通先后在班轮运输领域推出一系列数据产品的基础上的一个重大突破。据了解，“大船期”在线搜索平台，通过方法论创新，汇总整理从不同来源和渠道搜集的班轮船期信息，并运用数据编制，提供覆盖范围最广、信息更新最及时的船期，其主要智能功能包括：一是实时数据，进入大船期网站并注册免费账户，就可查找到不断更新的当前船期和船舶位置，为用户展示最及时更新的搜索结果;二是动态可视性，在船期搜索详情中插入地图并显示船舶的当前位置，可以让用户判断航程是否与预期一致，有助提升船运规划;三是个性化配置，搜索平台根据用户的最近搜索记录、收藏的船期和热门的港口配搭搜索作出推荐，节省搜索时间和优化搜索体验;四是强大分析，除了提供船期和实时的当前船舶位置数据，客户可查看到五大热门港口配搭下不同承运人的船期可靠性百分比与平均船期延迟偏差，从而有效评估准时货运的概率。
作为一家通过大数据提供强大的船运视野和绩效评估工具的全球船运管理软件方案供应商，货讯通首席商务总裁Lionel Louie先生表示：“能够结合大数据分析技术，为业内人士提供一个公共的船期搜索平台，整合不同来源的数据和利用先进的处理分析技术，帮助客户简化搜索流程，可以让发货人和物流服务供应商更快搜索到及时更新的船期数据，以及提供智能分析帮助他们提升船运规划。”
“大船期”以全新和免费的在线船期搜索，在同一视图中将船期与船舶、服务航线和货物运输信息联系起来，并让用户在获得最新的船期数据中，满足和实现互联网时代的个性化搜索体验。
FTP文件搜索引擎的实现(二) 篇4
1 总体架构
根据笔者的需求分析, 大体上用户需要两种形式的搜索, 一种为基于FTP文件名的搜索, 注意, 这里还须考虑FTP文件的路径上的搜索, 例如有的电子书, 其目录名可能是电子书的名字, 而目录内文件可能是Ch01.pdf Ch02.pdf…这类文字, 如果只搜索文件名必然无法命中所需的文件, 这也就是上一篇设计数据库时FileInfo表带有FilePath字段的原因。另一种需求是基于最新更新的搜索, 用户可能并没有明确的搜索意向, 但是想看看最近服务器上哪些文件被更新过, 因此系统实现了搜索最近N天更新的文件的功能。
虽然提供了两种不同的搜索形式, 但搜索后反馈给最终用户的结果页面是非常类似的, 其共同部分应该是一组符合搜索条件的文件的信息, 包括文件名、路径、文件大小、更新日期及所属的FTP站点名, 最后为了方便用户, 应该提供一个直接能打开或下载该文件的HTML链接。
基于以上分析, 本系统包含两个主要页面Default.aspx及Newest.aspx, 分别对应于基于文件名搜索和基于更新日期搜索, 两个页面共用一个User Control PagedDataList.ascx作为显示搜索结果的用户控件。程序界面如图1所示。
2 用户控件PagedDataList
顾名思义, 笔者在用户控件中使用了DataList来显示搜索得到的结果, 考虑到DataList本身不支持分页, 因此在用户控件中使用了PagedDataSource作为自定义分页的数据源中介, 同时嵌入了若干LinkButton来实现翻页效果, 其页面设计代码请参考所附带的源代码, 此处不再赘述。这里特别说明以下几个问题。
(1) 由于网页是无状态的, 每次用户提交页面到服务器后, 服务器都是返回一个全新的页面给用户, 因此如何记住翻页的页码就是一个关键, 另外, 如果用户发起一次新的搜索, 那么就必须重置翻页页码, 用户控件中关于此的核心代码如下:
请注意, 每次提交页面后, 用户控件的ds属性会被重置, 此时, pds变量会同时被重置, 但利用ViewState记录下了提交页面前的翻页页码, 因此得以实现翻页效果。而当用户进行了一次新的搜索后, 拥有用户控件的页面会调用ClearPageIndex函数来完成重置, 这样每次新搜索后, 第一次显示的都是搜索结果的第一页。
(2) 如何生成FTP文件的超链接。由于Microsoft的IE浏览器对于FTP路径中含中文字符支持不佳, 而大多数用户使用的却正是IE浏览器, 因此用户控件中对于此问题进行了特殊处理。IE默认使用GB2312编码来访问FTP服务器, 因此如果FTP文件路径上带有中文字符, 必须按照GB2312进行编码后才能作为超链接的地址返回给用户, Navigate控件默认按UTF编码, 因此笔者使用了label控件结合自定义函数来编码FTP文件的路径, 核心代码如下:
请注意, 上面代码中先使用了正则表达式来区分出FTP文件路径的各个部分, 对于除FTP站点信息外的其他部分利用自定义函数进行GB2312编码, 编码后传递给label控件并构造出标签, 由于IE不同版本对这一问题存在不同的Bug, 具体来说IE6无法直接点击标签, 必须使用另存为菜单, 而IE8点击标签后显示的文件名为乱码, 所以程序中使用嵌入Javascript脚本的方式来提示并帮助用户解决此问题。
基于文件名和基于更新日期这两个不同的搜索页面只是界面上有一些差别, 但都包含了上面提到的PagedDataList用户控件, 使用用户控件前, 必须在ASPX页面中加入Register指令如下:
然后, 在ASPX页面需要放入控件的位置, 如同声明一般ASPX控件一样, 声明如下内容:
轻量级工作流引擎的设计与实现 篇5
引
言1.1 轻量级工作流引擎的概念 轻量级的工作流引擎指的是从够用、灵活和低成本的设计原则出发，不追求工作流引擎的功能的完备和复杂，只是实现其中必不可少的功能和特征。在设计工作流引擎时主要考虑对其数据模型的定义和解释、活动之间的协调以及任务的分配和控制等功能提供支持，而不支持诸如提供内建（built-in）的应用开发工具、对应用资料的定义和完整性维护、完善的异常处理以及长事务控制等功能。轻量级工作流引擎的概念的提出，给开发工作流管理系统的开发人员开辟了一条新的道路。工作流管理技术本身就是一项抽象复杂的技术，它致力追求从企事业各种各样的业务中抽取出一个通用的模型，由这个模型去描述所有业务的一致性，以达到“放之四海皆可用”的程度。不过，要把众多的而又错综复杂的业务都集中在这个模型中，这是一件非常困难的工作，要经过一段漫长的摸索历程。而轻量级的概念让我们认识到可以从一般性的而又简单的业务入手，为企事业快速的开发出一个适应他们本身业务需求的而又带有可扩展性可移植性的信息管理系统，为他们提高工作效率，并保证在一段很长的时间内满足不断增加的业务需求。
1.2 工作流管理系统的分类及本文的侧重点
根据工作流过程本身的特点、系统建模的方式、所使用的底层支撑技术、以及工作流过程的执行方式等的不同而对工作流管理系统进行相应的分类。
1.2.1 面向文档的与面向过程的 前者的侧着点在于将电子形式的文件、图像等在有关的人员之间进行分发，以便能够得到不同人的处理与审阅。现有的文件管理与映像管理系统均属此类。在面向过程的WFMS中，工作流被描述成一序列执行环节。与各环节相应都有待处理的资料对象。各环节的资料对象可以按不同的方式分发到其它环节中去，如可以将资料对象的值作为控制条件、或者依此资料对象组装成其它的资料对象等。高端的WFMS一般都属此类系统。
1.2.2 结构化的与即席的结构化工作流指的是在实际工作过程中会反复重复、严格按照某个固定的步骤进行的业务过程。定义此种工作流所需要的各种类型的信息可以通过对业务过程进行详细的分析而得到，从而得到完整的过程定义并在以后的应用过程中反复使用。大量的办公程序，如公文处理、审批等都属此类。即席工作流则是针对那些重复性不是很强或没有重复性的工作流程的，关于这类流程执行所需的有关参数(如参加者等)事先无法确定，而必须推迟到过程实例运行时才能确定，同时在执行过程中间还可能会发生一些意外的情况。这种动态多变的特点在提供更高灵活性的同时，也为过程的建模与执行带来更多的复杂性。1.2.3 基于邮件和基于数据库
前者使用电子邮件来完成过程实例执行过程中消息的传递、资料的分发与事件的通知。低端的系统所使用的经常就是此种方法，它可以充分发挥电子邮件系统在广域环境下的资料分发功能，但整个系统将运行于一种松散耦合的模式下。在基于数据库的WFMS中，所有的资料都保存在某种类型的DBMS中，过程的执行实际上就是对这些资料的查询与处理。高端的大规模系统所使用的一般都是此种方法。
1.2.4 任务推动的与目标拉动的前者指的是从过程的开始逐步地一个环节一个环节的执行，当某个活动实例被处理完之后，后续的有关活动将被创建并被激活，由此直至整个工作流程的完成。这是目前大多数面向过程的WFMS所使用的执行方式。而在目标拉动的WFMS中，一个业务流程被看成是一个目标。过程实例执行时，该目标将被分解得到多个相互之间按一定约束条件的关联起来的可执行的多个环节，其中各环节还可以当成是子目标而进一步进行分解。在各环节均执行完毕之后，整个过程也就完成了。目标拉动是一种全新的执行方式，下一代的WFMS将具有此种特征。应该说明的是：上述分类只是从不同的角度入手的。一般来说，后面那些特点将给WFMS带来更好的灵活性，同时也将成为那些能够支持跨机构的大规模复杂工作流管理、面向关键任务的WFMS不可缺少的特征。1.2.5 本文的侧重点
本文的侧重点不在于完全实现其中一种工作流管理系统的所有功能，更不在于实现所有种类的工作流管理系统的全部功能，前文已经说过，这是一件非常困难的事情。那么我们的侧重点在哪里呢？就在于综合以上四种工作流管理系统的主要特点，是一个面向文件的，基于数据库的，由目标拉动的结构化的工作流管理系统，并且由此去设计和实现工作流管理系统的核心――工作流引擎。从一般性来说，目前大多数的企事业的业务都是事务申请，公文流转，各项通知等等，这些业务或者需要查看，或者需要审批，而这些业务的资料基本上是以文件的形式保存在计算机上，而其中一些格式化的资料是保存在数据库中，所以面向文件和面向数据库是轻量级工作流引擎的一个重要特征。业务的发起和结束是一项过程化的任务，任务又可以分解成一个一个环节任务，而任务是带有目的性的，由这个目的去拉动这个过程中的一个一个的环节任务，促使环节任务的推进，最终达到任务完成的目的。这些业务的过程化不是随机的，而是已经严格规定好的，只有遵循这些过程化的规则和流程环节才能完成整个业务。轻量级的工作流引擎就组合了以上这些，不追求工作流引擎的功能的完备和复杂，以满足一般性业务为目的，为企事业快速开发出适合他们业务的工作流管理系统。
第二章
工作流管理系统参考模型简介在阐述工作流引擎之前，我们来了解一下工作流技术的基本知识。早在几年前，为了建立工作流管理系统的相关标准，国际上成立了一个称为“工作流管理联盟”（简称WFMC）的国际组织。她提出了有关工作流管理系统的一些规范，定义了工作流管理系统的结构及其与应用、管理工具和其它工作流管理系统之间的应用编程接口，也就是工作流系统参考模型。
WFMC给出的工作流参考模型如下图：
接口2
接口3
接口4
接口1
接口5
过程定义工具
工作流API与交换格式
工作流执行服务
工作流机
（工作流引擎）
工作流 管理工具
其它工作流 执行服务
工作流机
工作流客户应用
工作流机直接调用 的应用
图2.1 工作流参考模型
从图中可以看出，参考模型包含了五类接口，分别是：
⑴ 接口1：过程定义输入输出接口，这是工作流服务与工作流建模之间的接口，该接口提供的功能包括通信建立，工作流模型操作和工作流模型对象操作。
⑵ 接口2：客户端函数接口，这是工作流服务与客户应用之间的接口，这是最主要的接口规范，它约定所有客户方应用与工作流服务之间的功能操作方式。包括通信建立，工作流定义操作（对过程模型定义操作），过程实例管理功能，过程状态管理功能，任务项列表/任务项处理功能，数据处理过程，过程监控功能，其它的管理功能，应用程序激活。
⑶ 接口3：激活应用程序接口，这是工作流引擎和直接调用的应用程序之间的接口，包括通信建立，活动管理功能，数据处理功能。
⑷ 接口4：工作流执行服务之间的互操作接口，这是工作流管理系统之间的互操作接口，包括连接的建立，对工作流模型和其中对象的操作，对过程实例的控制和状态描述，对活动的管理，对资料进行处理。
⑸ 接口5：系统管理与监控接口，这是工作流服务和工作流管理工具之间的接口，包括资源控制，角色管理，用户管理，过程实例的管理，状态管理，审核管理。
五个接口以及对应的API函数囊括了工作流管理系统的全部功能。一个完整的工作流管理系统就是以工作流引擎为中心，向外部部件（应用程序或其它工作流引擎）提供这五个接口，提供其实现的所有功能。
第三章
系统分析与设计在所有准备工作完成后，我们就开始进行系统设计和设计，构造一个轻量级的工作流引擎。轻量级的工作流引擎并不完全实现WFMC所提出的工作流模型包含的五个接口，特别是接口4，在分布式工作流管理系统才具有该接口。既然我们从轻量级的概念出发，我们就不再明显区分各个接口的界限以及其所具有的特定的功能，以够用、灵活和低成本的设计原则去设计出我们所理解的工作流引擎。我们运用了面向对象的方法，首先从众多的业务需求中抽取出工作流模型所包含的对象，再分析各个对象之间的逻辑关系，然后提出一个系统结构，再进行模块划分，数据库设计，最终完成类的设计。我们当中所用到的建模工具就是ROSE UML。
3.1 工作流模型的设计
对工作流模型的设计是工作流引擎设计的重要组成部分。
3.1.1 工作流模型的对象
企事业经营过程就是一项项业务的实现过程，我们从一般业务入手，并对这些业务进行详细的分析，研究，其结果就是得到一般性的业务对象，从而抽象成工作流模型对象。
3.1.1.1 从一个简单的业务实例看业务的需求
目前企事业的一项基本事务就是出差管理。它主要是对企事业的人员因为某种工作上的原因需要到别的地方出差进行的管理。我们可以列出出差的相关步骤：
⑴ 申请人需要出差，并且他（她）具有出差的权利；
⑵ 申请人填写出差表格，说明因何事出差，出差何处，申请出差金额，何时回来等等和出差相关的情况；
⑶ 申请人需要其它说明的话，可以将更具体的说明以文档的形式保存下来；
⑷ 申请人确认申请无误后提交申请，等待申请的结果；
⑸ 根据规定，该申请必须先让申请人的上一级审批，那么该申请就会以一项工作项的形式交给该级领导处理；
⑹ 处理该申请的领导对该申请进行处理，他（她）会先查看该申请所有的资料，包括出差申请表和与之相关的其它文档，然后对其进行审批，审批的结果是同意那么该次申请会交给再下一级领导处理；审批的结果不同意，该申请被打回，通知申请人申请不通过的结果。等所有需要审批的领导都审批通过了，该申请就成功完成，通知申请人申请通过的结果；
⑺
申请人得到申请的结果，如果审批通过则准备出差，如果审批不通过则根据审批结果对该申请进行修改，重新提交申请； ⑻ 申请事务结束。
这是一个简单的业务实例，对该实例进行分析我们可以得到该业务的一些对象：
⑴ 申请人：他（她）属于该企事业的某个部门的成员，并且具有启动该业务的权利； ⑵ 审批领导：他（她）也属于该企事业的某个部门的成员，并且具有对该业务进行处理的权利；
⑶ 出差表格：它是该业务规定的格式化资料，并且是必须的 ⑷ 出差具体说明：它是该业务附加的资料，可以不要的
⑸ 申请人已经填写好的出差表格：它是出差表格的实例化，代表一个具体的应用 ⑹ 审批同意和不同意：它们是对该业务的处理，遵循一定的业务规则 ⑺ 申请：这是一个过程，不是一个动作，需要时间和人的活动才能完成 ⑻ 审批：这是一个活动，是过程的一部分，并且可以向另外一个活动转化
⑼ 其它应用程序：申请人要填写出差具体说明时要调用相应的外部应用程序编辑该说明并以一定的格式保存下来，审批领导要查看出差具体说明时也要调用相应的外部应用程序打开该说明并以一定的格式显示出来。
从这些业务对象，再利用工作流技术，我们可以得到工作流模型的一些基本对象：
⑴ 用户：正如申请人，审批领导，他们就是工作流管理系统的用户，由他们去使用该系统的各种功能，并且直接参与业务活动，促使业务的完成。
⑵ 角色：有些人可以申请出差，有些人对出差申请可以审批，这两种不同的人可以作为两个不同的角色。角色是具有某种使用系统特定功能的权利的一个人员或多个人员的组合。⑶ 工作流应用资料：出差申请表格，出差具体说明，这些就是对应某个具体业务（这里是出差管理）的相关资料，根据这些业务资料我们可以对该业务进行处理。
⑷ 需激活的应用程序：在需要其它应用程序提供支持的时候，会去激活这些应用程序。⑸ 流程：整个出差申请的过程就是一个流程，它从整体去描述一个业务。
⑹ 环节：又称活动，它反映了业务流程的局部情况，通常业务流程是由一个一个的环节组成。
⑺ 流程实例：将该出差申请这个业务流程实例化，就得到一个流程实例。⑻ 环节实例：将流程的其中一个环节实例化，就得到一个环节实例。
⑼ 业务规则：业务的开始和结束需要一定的条件，在处理业务的过程中必须按照一定的规则，这些都是业务规则，只有严格遵循业务规则，业务才能完成。
3.1.1.2 工作流对象的具体分析和说明
通过一个具体的业务我们可以得到工作流模型的一些对象，那么我们再对其他一般性业务进行分析，研究，我们就会找到它们的共同点，并归纳出基于这些业务的公共的对象，这些公共的对象的组合，就是一个通用的模型，也就是工作流模型，这个模型能去描述每个业务，是我们追求轻量级工作流引擎的最终成果。
⑴ 用户：业务的执行者和参与者，对应于企事业的每一个雇员，是一个独立的、具有一定行为能力和一定技术能力的人的实体；
⑵ 角色：以技能为前提，能够完成某项功能的人员的总称；
⑶ 部门：对应于企事业的静态结构划分，由企事业的实际部门设置情况来决定，可以是传统的面向职能的，也可以是现在流行的面向过程与客户的；
⑷ 职位：以行政责任为前提，代表了管理上的等级关系；
⑸ 工作组：以执行某一任务为目标而动态组建的、跨部门划分的一种组织结构；
⑹ 流程：对应于一个业务过程，表示一个业务由发起、处理、结束的一个过程；
⑺ 流程实例：对应于一个业务流程具体应用，是业务流程实例化的表现形式；
⑻ 环节：对应于业务流程中一个单一的业务操作，是流程按照业务要求的细化；
⑼ 环节实例：对应于一个环节的具体应用，是环节实例化的表现形式；
⑽ 工作流定义主信息：描述一个工作流模型的主要信息，从整体来描述工作流模型；
⑾ 工作流附件信息：描述一个工作流模型所用到的附件信息，也就是工作流应用资料，或者叫业务资料。按照WFMC提出的工作流模型，这不是工作流模型所包含的对象，可是我们对其进行格式化，把它抽取成一个模型对象，用来规定了工作流模型在具体应用时所需业务资料的格式，我们把它分为两类：
●
表格类型：这是以表格的形式保存附件信息，可以用关系结构来定义附件信息，并保存在数据库中，每一条记录就是一个该附件的实例；
●
文档类型：只是以文件形式保存附件信息，可以是work文档，也可以是文本文件，它的实例化是就是一个一个带有对应某个业务应用标志的文件，保存在硬盘上 ⑿ 工作流实例信息：描述一个工作流模型实例化的信息，也作为启动一个工作流的信息，它记录该业务流程随着时间和人员的参与处理的不断变化，直到整个业务的结束；
⒀ 工作项信息：描述参与某个业务应用时被分配到的一项任务，这就体现了参与人员和系统交互的典型特征；
⒁ 业务规则：描述业务在运行的过程中必须要遵守的规定和原则，也是业务活动得以向另一个活动推进的规则。我们把它分为四类规则，分别是： ●
自动型：它主要描述一些只给参与人员查看业务信息的业务规则，例如通知、公文流转等等业务。该类业务不需要参与人员去审批或其它人为上的处理，只需要参与人员去查看其中的内容就足够，整个业务流程的完成是全自动的。●
与聚合：业务活动的完成是需要参与该活动的所有人员都进行人为处理，其中有一个人员没对其进行处理，整个活动只能停在原地，等待所有人员的处理，当最后一个参与人员执行了处理工作，它才能完成。●
或聚合：在参与某一业务活动的人员当中只要有一个对其进行处理，整个活动就可以完成。
●
投票聚合：统计参与该活动的参与人员的处理结果，当满足一定条件该活动才能完成。
⒂ 转换条件：描述流程、活动状态改变时需要的条件，用于业务运行过程中的约束。例如流程的完成必须等待所有活动的完成才能完成，活动的完成必须按照业务规则去完成等等； ⒃ 需激活的应用程序：工作流管理系统需要其它应用程序的支持，例如编辑和查看文本文件信息等等；
⒄ 日志信息：描述工作流中所有的状态改变、事件和控制流相关资料的变化，工作流实例和环节实例的启动、结束、挂起和激活等等信息都会记录下来，以便对其进行管理。3.1.2 对象之间的逻辑关系在找出工作流模型的对象后，我们就开始分析它们之间的业务逻辑关系。
3.1.2.1 对对象进行分类以及各个分类中对象之间的关系到此为止，我们有必要对工作流模型对象进行一下分类，根据工作流对象对工作流管理系统所起的作用我们可以分成以下几类： ⑴ 组织模型
组织模型描述了企事业的组织机构关系，包括的对象有用户，部门，职位，角色，工作组，它们的关系可以用下图表示：
设置
负责
组成 组成 资格
组成 部门
职位
用户
工作组
角色
图3.1 组织模型结构
从图中可以看到它们之间的关系，用户是基本的单位，部门是由用户组成，每个用户对应一个职位，负责该职位所要求的职能，用户凭着某种资格赋予一种角色，工作组也由用户组成，也可以由角色组成。这几个基本的对象以及其关系所构成的组织模型，已经可以满足轻量级工作流引擎对组织模型的需要了。⑵ 工作流定义模型
工作流定义模型描述了工作流模型的定义信息，包括工作流定义主信息，流程定义信息，环节定义信息，工作流附件信息，业务规则。它们之间的关系如下图：
图3.2 工作流定义模型结构
包含
包含
包含
包含
遵循
包含
工作流定义
附件信息
主信息
业务规则
环节
流程
包含
流程是包含若干环节的，而环节遵循一定的业务规则，再加上工作流主信息和附件信息，共同构成工作流定义模型。⑶ 工作流实例模型
工作流实例模型描述了工作流模型实例化时的信息，通过这些信息我们可以知道实例过程中的各种状态变化和最终的结果，因而得到一个业务具体应用的情况。它包括流程实例，环节实例，工作流实例信息，工作项信息和转换条件，它们之间的关系如下图：
记录
记录
细化
细化
影响
影响
影响
影响
记录
记录
转换条件
环节实例信息
流程实例信息
工作项信息
工作流实例信息
日志信息
日志信息
细化
图3.3 工作流实例模型结构
转换条件影响工作流实例，流程实例，环节实例和工作项的状态，并由转换条件去决定它们的状态转变，工作流实例信息à流程实例信息à环节实例信息à工作项信息，自上而下逐层细化，不但从全局了解业务运行情况，而且从局部了解业务运行的细节情况。而它们的状态改变都会记录在日志中，用以追踪工作流实例的运行情况。⑷ 外部支持模型
外部支持模型在本文只包括一个对象，就是需激活的外部应用程序，严格来说这不是工作流模型的一部分，可是提供接口去激活所需的外部应用程序为工作流管理系统提供支持是工作流模型的功能之一。有了这些外部应用程序的支持，我们的工作流管理系统的功能才变得更完善。
3.1.2.2 各个模型之间的逻辑关系
不但模型中各个对象有一定的逻辑关系，而且各个模型之间也有一定的逻辑关系，如下图所示：
调用
依赖
使用
使用角色和工作组
用户定义
工作流实例模型
外部支持模型
工作流定义模型
组织模型
图3.4 模型之间的关系
组织模型的用户定义工作流定义模型；工作流定义模型使用组织模型的角色和工作组，用来规定工作流模型的启动条件和任务分配条件，因为工作流模型的启动和任务的分配必须由一定的角色或工作组完成；工作流实例模型依赖工作流定义模型，同时使用组织模型的所有对象，并且调用外部支持模型为其提供支持。3.1.3 工作流实例，流程实例，环节实例和工作项的状态转换
工作流实例，流程实例，环节实例和工作项从不同的层次去描述业务运行过程的具体情况，不同级别的用户可以看到业务运行的不同方面，创建工作流实例的用户可以看到工作流实例信息以及其状态转换，参与该工作流实例的用户可以看到工作项信息以及其状态的改变，系统管理员可以看到所有信息以及其状态的转换。
⑴ 工作流实例状态图
创建
管理员
管理员
管理员
Running（运行）
Completed（结束）
正常情况
Suspended(挂起)
terminated(终止)
Initial（初始化）
图3.5 工作流实例状态图
提交
⑵ 流程实例状态图
管理员
管理员
管理员
Running（运行）
Completed（结束）
正常情况
Suspended(挂起)
terminated(终止)
图3.6 流程实例状态图
⑶ 环节实例状态图
处理中
接受
完成正常处理
没有完成异常处理
回退处理
提交给下一环节
图3.5 环节实例状态图
⑷ 工作项状态转换图
等待操作
完成 通过
没有完成 不通过
无操作，超时
操作下一工作项
回退处理
已查看
初始化
未审批
未查看
图3.5 工作项状态图
接受
3.1.4 任务分派任务分派是工作流引擎的一个重要功能。当环节实例产生时，就会以一定的准则把需要处理的工作当作一项任务项（工作项）分派给参与该环节实例的所有用户，而这些用户是同属一个角色或者工作组的。我们又把角色和工作组进行细化，可以得到以下准则： ⑴ 基于部门的：这就是说把任务分派到某个部门的所有人员，该部门的所有人员都参与了该项任务，因而会为该部门的所有人员都产生一个工作项；
⑵ 基于职位的：这就是说把任务分派到某个职位的所有人员，同属该职位的所有人员都被分配到一项工作项；
⑶ 基于部门职位的：这就是说把任务分派到某个部门的某个职位的所有人员，同属该部门的该职位的人员都被分配到一项工作项；
⑷ 基于所有人的：这就是说把任务分派到该企事业的所有人，该企事业的所有人都被分配到一项工作项；
⑸ 基于工作组的：这就是说把任务分派到该企事业的某个特定的工作组上，同属该组的所有人员都被分配到一项工作项。
基于部门的，基于职位的，基于部门职位的和基于所有人的这四种类型，其实是基于角色的细化，通过这些准则的分类，我们尽量做到系统与企事业有较强的适应性，以及使系统在任务分派时有较大的灵活性。3.1.5 转换条件的满足
工作流实例，流程实例，环节实例和工作项的状态转换有各自特定的条件，分别如下：
⑴ 工作流实例的转换条件
工作流实例从整体看业务运行过程，工作流实例被用户创建后就进行初始化并提交给工作流引擎，由工作流引擎去处理，此时实例处于运行状态；在运行过程中，它会根据流程实例的状态而不断进行本身的状态改变；当管理员由于某种原因要挂起它时，它就处于挂起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常结束；当它被正常处理完毕后，就正常结束。
⑵ 流程实例的转换条件
流程实例也从整体看业务的运行过程，流程实例在工作流实例初始化时就开始它的工作。在运行过程中，它会根据各个环节的完成程度来改变自己的状态，当所有环节实例都正常完成它就正常结束；管理员可能要挂起它使它处于挂起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常结束。
⑶ 环节实例的转换条件
环节实例从某个方面看业务的运行过程，环节实例在流程实例运行时就开始它的工作处于处理中状态。之后环节实例的状态由两方面决定，一是工作项的处理结果，一是业务规则的规定。
●
如果业务规则是自动型的，不管工作项的处理结果怎样，当系统把任务项分派（给特定用户）完毕后，该环节实例就正常完成处于正常结束状态；
●
如果业务规则是与聚合的，系统分派完任务项后，当所有参与人员都正常处理完该环节各自的工作项后，该环节才正常完成处于正常结束状态；在处理过程中，只要有一个工作项是非正常处理的，该环节就非正常完成处于非正常结束状态；在处理过程中，有工作项还未被处理并且没有一个工作项被非正常处理，那么环节实例仍然处于处理中状态；
●
如果业务规则是或聚合的，系统分派任务后，只要有一个工作项是正常处理的，该环节实例就正常完成处于正常结束状态；如果所有同属该环节实例的工作项都被非正常完成，那么该环节实例就处于非正常结束状态；
●
如果业务规则是投票聚合的，系统分派任务后，统计工作项的完成程度，当正常完成的工作项数量达到一定数量时，该环节实例就正常完成处于正常结束状态；当正常完成的工作项数量不达到规定的数量时，该环节就非正常完成处于非正常结束状态；当所有工作项还没处理并且正常完成的工作项还没达到规定数量时，该环节实例仍然处于处理中状态。
⑷ 工作项的转换条件
工作项从更细节的方面看业务运行过程，工作项的状态转换要看参与人员对各自的工作项的处理情况和业务规则的规定。我们把与聚合，或聚合和投票聚合这些要人工干预的规则统称为人工型规则。
●
如果业务规则是自动型，同属该规则的工作项的状态就只有正常处理后的正常结束状态，当然如果对该工作项还没被处理则处于处理中状态，可这不对环节实例等产生影响；
●
如果业务规则是人工型，就会有正常处理和非正常处理两种情况，正常处理该工作项则使到该工作项处于正常结束状态，非正常处理该工作项则使到该工作项处于非正常结束状态。
3.2 系统结构
本着基于轻量级工作流引擎的原则，我们已经对工作流模型进行了详细的分析和详细的设计，在这里我们就提出一个系统结构，如下图所示：
工作流定义器
工作流
解析器
实例调度中心
任务管理器
任务分派器
启动控制器
工作流定义数据
工作流实例 数据
日志 数据
工作流定义接口
工作流实例接口
组织定义
数据
组织定义接口
组织定义器
状态转换器
组织
管理器
图3.6 工作流引擎系统结构图
从图中可以知道，系统提供了三类接口：组织定义接口、工作流定义接口和工作流实例接口。这三类接口实现了工作流模型的接口一，接口二，接口三和接口五规定的主要功能；系统有一个实例调度中心，这是一个很重要的部件，它控制工作流实例的运行，通过工作流解析器对该工作流模型进行解析其含义，通过任务分派器按照一定的分派准则把任务项分派给参与该工作流实例的用户，通过任务管理器管理各个任务项的信息，通过启动控制器控制工作流的启动权利和启动信息，通过状态转换器控制工作流实例、流程实例、环节实例和工作项的状态转换；组织定义器定义企事业的组织结构；工作流定义器定义工作流模型信息，并通过组织管理器得到组织定义信息，为工作流模型提供组织支持。各个部件处理的相关信息都保存在数据库中。
3.3 系统模块的划分
根据功能实现的不同我们进行模块的划分如下：
⑴ 用户管理模块：对用户信息的管理，包括注册用户信息，注销用户信息，查询用户信息等功能；
⑵ 部门管理模块：对企事业部门结构信息的管理，包括增加部门信息，删除部门信息，查询部门信息等等功能；
⑶ 职位管理模块：对企事业职能信息的管理，包括增加职位信息，删除职位信息，查询职位信息等等功能；
⑷ 角色管理模块：对企事业某种技能信息的管理，包括新增角色信息，删除角色信息，查询角色信息等等功能；-
⑸ 工作流模型管理模块：对工作流定义模型信息的管理，包括定义新的工作流模型信息，删除旧的工作流模型信息，查询工作流模型信息；
⑹ 工作流实例管理模块：对工作流实例信息的管理，包括启动一个新的工作流实例，查询工作流实例信息，按照一定的业务规则生成新的环节实例信息，为用户分派工作项，管理工作项信息，按照一定的转换条件为工作流实例、环节实例转换状态等等功能；
⑺ 系统监控模块：为工作流实例，环节实例等的状态转换信息加入日志，挂起、激活工作流实例，强制结束工作流实例，为迟迟不对自己的工作项进行处理的用户发出提醒或警告信息，查看各个工作流实例的完成程度等等功能。
功能模块的划分，为系统的实现做好充分的准备。
3.4 数据库设计
基于轻量级的工作流引擎的特点之一就是把系统相关的资料，如工作流模型定义信息，工作流实例信息，组织模型定义信息等等，都以特定的实体形式保存在关系型数据库中。
⑴ 工作流定义主信息表（workflowTable）
静态定义工作流主要信息，包括该工作流的标识ID（可以定义为以”WORKFLOW_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作流名称，工作流描述，工作流类型（工作流的类型有自动型，人工型和混合型，自动型不需要人工参与，由工组流引擎自动执行，人工型需要人工参与，混合型包含了自动型和人工型），工作流创建日期，工作流创建者ID（即用户ID），工作流创建人名称（即用户名），工作流生命周期（每个工作流实例都有它的生命周期期限，在该期限内还没完成它的工作就直接死亡），目前该工作流实例数目（记录当前工作流实例数目），工作流启动者角色（指明该工作流可以由哪个角色发起，属于该角色的用户都可以启动该工作流模型对应的实例）。工作流重要信息还包括两方面，一是工作流附件，因为在工作流进行过程中，肯定会带有一些信息，这些信息对于出差申请来说就是出差申请表，对于公文流转来说就是以word文档形式的公文，对于通知来说可能就是以文本文档形式的通知书，等等；一是工作流流程描述，包括若干个环节（activity），这些环节有一定的顺序，表现工作流顺序执行的特征。把工作流附件和工作流流程描述从工作流定义分离出来，是基于工作流附件和工作流流程描述对于不同工作流有不同形式和数量的原因，有利于工作流附件和工作流流程描述的扩展。⑵ 工作流附件信息表（workflowAttachmentTable）
静态定义工作流所需要的附件，包括附件ID（可以定义为以”Attachment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作流ID（标识属于哪个工作流），附件类型（表或文件），附件名称（如果类型是表，则为该表的名称，如果是word文档，则为该文档名称，如果是文本文档，则为该文件名称），其它信息（如果类型为表格，该字段以一定的格式保存该附件表格的所有字段的各种信息，包括字段名称，字段数据类型，数据类型长度，字段描述）。⑶ 工作流流程描述表（workflowProcessTable）
静态定义工作流的流程，由若干环节（activity）组成，一个环节为一条记录，包括工作流ID（环节所属工作流ID），环节ID（可以定义为以”ACTIVITY_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），环节名称（即该环节名称），环节描述（对该环节的具体描述），参与者角色ID（将相同权限的用户作为一个集合，在数据库以同一个角色操作数据库特定操作，该项标识角色ID），环节任务分派规则，上一个环节ID（保存上一个环节的ID，由这项可以判断该环节是否整个流程的开始环节，或者该环节的任务没有完成（审批不通过，或没在其生命周期期限内完成）时作回滚处理的重要数据项，根据这个数据项可以回滚到上一个环节），下一个环节ID（保存下一环节的ID，由这项可以判断该环节是否整个流程的结束环节，或者该环节的任务完成了，根据这个数据项可以启动下一环节，继续向前推进）。
⑷ 工作流实例启动描述（workflowInstanceStartUpTable）动态定义工作流实例启动信息（其实这也是工作流实例信息表）启动者在产生一个工作流实例之前必须根据工作流的定义做好准备工作，这些准备工作的信息就填入该表中，然后交付给工作流引擎。该描述包括工作流ID（所属工作流ID），工组流实例ID（标识该工作流实例，可以定义为以”WORKFLOWINSTANCE_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作流实例描述，工作流实例创建时间，工作流实例创建者ID（启动者ID），工作流实例创建者名称，当前工作流状态（标识当前工作流实例的状态，启动者在创建后却没提交给工作流引擎前的状态为“initialized”初始化状态，之后的状态要视工作流类型而定），当前状态具体描述，当前操作者ID（当前工作流要被谁操作），当前操作者名称。工作流实例完成标志（标识该工作流实例的完成），工作流实例完成时间，当前工作流状态和当前操作者ID和当前工作流状态具体描述三项在工作流实例的运行过程中，可以动态追踪该工作流实例的运行，而这三项再加上工作流完成标志和工作流完成时间，可以知道该工作流实例的完成情况。
⑸ 工作流实例过程描述（workflowInstanceProcessingTable）以环节为单位动态描述工作流实例的处理过程，启动者创建工作流实例后，提交给工作流引擎后，工作流实例就根据工作流定义的流程进行运转了。包括工作流实例ID，工作流实例所对应环节（工作流流程就是由一系列的环节组成，按照预定义的流程一个环节过渡到另一个环节），当前该环节所处状态（这标识着该环节在处理过程中的状态，最终状态表示该环节的完成状态），当前操作者（对应的是角色），当前状态具体描述。⑹ 工作项描述（workItemTable）
动态描述已经参与该工作流实例处理的参与者（对应已处理环节的角色的每个用户）的工作情况。包括工作项ID（可以定义为以”WorkItem-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作项名字，工作项描述，工作流实例ID（该工作项所属的工作流实例），该环节任务分派规则（继承环节的任务分派规则，用于判断该环节任务完成方式），当前该工作项所处状态（根据不同的工作流类型有不同的状态，根据这些状态可以在参与者接口上显示不同的工作项列表），执行动作（记录执行者会对该工作项执行怎么样的动作，如果是申请事务则是审批通过或审批不通过），执行时间（记录该执行动作的时间），用户ID（标志该工作项是属于谁的。⑺
用户描述（UserTable）
该表描述所有用户的资料，包括用户ID（可以定义为以”User-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），用户名称，用户密码，用户所属部门，职位等等信息，级别是该用户的系统权限，包括普通职员，高级职员和系统管理员。⑻ 日志信息描述（LogTable）
描述用户的工作日志，便于对各种操作进行追踪。包括日志ID（可以定义为以”Log-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号）等等，其中有一项是相关工作项ID，这是当参与者对原始工作项进行执行操作动作时的工作项。⑼ 角色信息（RoleTable）
描述角色的信息，包括角色ID（可以定义为以”Role__xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），角色名称，部门名称，职位名称，角色描述。角色由部门和职位组成。
⑽ 部门信息（DepartmentTable）
描述部门的信息，包括部门ID（可以定义为以” Depatment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），部门名称，部门其它信息。
⑾ 职位信息（PositionTable）
描述职位的信息，包括职位ID（可以定义为以” Position_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），职位名称，职位其它信息。
除了以上这些主要表以外，还有一些我们是在定义工作流模型的时候才加入数据库的，如对应工作流附件类型为表的表格。为了减少网络流量和提高系统的运行速度，我们把一些有关联的数据库操作写成存储过程：
⑴ 删除工作流模型存储过程：删除一个工作流模型，必须删除它的工作流定义主信息，同时删除对应的附件信息，附件为表的表格，环节信息；
⑵ 创建附件类型为表的表格：定义附件信息时已经把该表格的字段信息保存在该附件信息的其它信息字段中，并且有一定的格式，那么我们从该字段中按照一定的格式还原表格的字段信息，并根据这些信息在数据库中创建该表格。
3.5 类的设计
用面向对象的方法和UML建模工具，再根据系统结构图，模块的划分和数据库的设计，我们把对象转化成类，进行类的设计。我们把整个系统的类分成三部分，一是实体类，二是业务类，三是接口类。
3.5.1 实体类的设计
工作流模型的对象就是一个一个的实体，实体类又分为数据库访问类和值对象类。数据库访问类是对存储在数据库的实体信息进行访问（插入，删除，更新，查询）的类，值对象类是在客户端和服务器端之间交换资料的实体信息类。
3.5.1.1 数据库访问类
⑴ 数据库连接类：该类是其它数据库访问类的父类，管理数据库的连接，负责从数据库连接池找可用的数据库连接给其它数据库访问类使用，使用完毕后负责放回连接池，类图如下图：
说明：属性只有一个connection，它代表数据库的一条连接，类型为Connection，方法有一个构造函数workflowDAO()和一个关闭连接的函数closeConnection()。WorkflowDAO()实现从数据库连接池找一个可用连接并赋值给属性connection，closeConnection()负责把连接放回数据库连接池。
⑵ 工作流定义主信息访问类：对应数据库的工作流定义主信息表，该类封装了对该表格记录的各种操作，就是插入或删除一条工作流定义主信息，查询特定工作流定义信息或者所有工作流定义信息，类图如下图：
说明：构造函数WFDefineMainInfoDAO()调用父类构造函数，从数据库连接池中找一个可用的数据库连接（其它数据库访问类也一样）。
⑶ 工作流流程信息访问类：对应工作流流程描述表，该类封装了对该表格记录的各种操作，流程是由若干环节组成，就是插入或删除一条环节信息，查询同属于一个流程的环节信息等等，类图如下图：
说明：findWorkflowFirlstActivityInfo()函数负责找该工作流模型的第一个环节的信息，findWorkflowNextActivityID()负责根据当前环节ID找下一环节的信息。
⑷ 工作流附件信息访问类：对应工作流附件信息表，该类封装了对该表格记录的各种操作，就是插入或删除一条工作流附件信息，查询同属于一个工作流模型的附件信息。类图如下：
⑸ 工作流附件类型为表的信息访问类：对应工作流附件类型为表格的信息表，该类封装了该表记录的各种操作，就是插入或查询一条工作流附件类型为表格的具体信息，类图如下：
⑹ 工作流实例启动信息访问类：对应工作流实例启动信息表，该类封装了该表记录的各种操作，就是插入或查询一条工作流启动信息，查询同属于一个用户的工作流实例启动信息，更新部分字段信息，类图如下：
说明：selectFinishedWorkflowInstanceStartUpInfoVO()负责查询特定用户启动的并且已经完成的工作流信息，selectNotFinishedWorkflowInstanceStartUpInfoVO()负责查询特定用户启动的并且还没有完成的工作流信息，updateWFInstFinishedFields()负责在工作流实例结束时更新特定的字段信息，updateWFInstProcessingFields()负责在工作流实例运行工程中更新特定的字段信息。
⑺ 工作流实例过程信息访问类：对应工作流实例过程信息表，该类封装了该表格记录的各种操作，每一条记录实际上是一个环节实例，就是插入、删除或查询一条环节实例信息，查询指定工作流实例的所有环节信息，更新部分信息字段，类图如下：
说明：SetWFInstProcessingCurrentPerformerNumField()负责更新已经处理该环节实例对应的工作项的参与该环节实例的用户数目，updateWFInstProcessingFields()负责在环节实例处理过程中更新特定的字段信息。
⑻ 工作项信息访问表：对应工作项表，该类封装了该表格记录的各种操作，就是插入或删除一条工作项信息，查询工作项信息，更新工作项信息，类图如下：
说明：selectFinishedWorkItemVO()负责查询特定用户已经处理完毕的工作项信息，selectNotYetFinishedWorkItemVO()负责查询还没有处理的工作项信息，updateWorkItemFields()负责更新工作项在处理过程中的特定字段信息，isPerformedInWorkItemByUser()负责判断该工作项是否已经处理完毕。
⑼ 用户信息访问表：对应用户信息表，该类封装了该表格记录的各种操作，就是插入、删除或查询一条用户信息，查询特定角色对应的用户信息，类图如下：
说明：selectCountRS()负责统计同属于一个角色的用户数目。
⑽ 角色信息访问类：对应角色信息表，该类封装了该表记录的各种操作，就是插入、删除或查询一条角色信息，查询所有角色信息，类图如下：
⑾ 部门信息访问类：对应部门信息表，该类封装了该表记录的各种操作，就是插入、删除或查询一条部门信息，查询所有部门信息，类图如下：
⑿ 职位信息访问类：对应职位信息表，该类封装了该表记录的各种操作，就是插入、删除或查询一条职位信息，查询所有职位信息，类图如下：
⒀ 日志信息访问类：对应日志信息表，该类封装了该表记录的各种操作，就是插入、删除一条日志信息，查询特定的日志信息，类图如下：
3.5.1.2 值对象类
值对象类其实是一种数据结构，用于客户机和服务器之间的数据交换，也用于对象实例的数据传递，它有若干属性，可是很少方法，实例化后就对应数据库表的一条记录。
⑴ 工作流定义主信息值对象类：可以保存工作流主信息表的一条记录信息，类图如下：
⑵ 工作流流程信息值对象类：可以保存工作流流程信息表的一条记录信息，类图如下：
⑶ 工作流附件信息值对象类：可以保存工作流附件信息表的一条记录信息，类图如下：
说明：SetOtherInfo()负责以一定格式把工作流附件类型为表的表格字段信息保存在OtherInfo中，GetOtherInfo()负责从OtherInfo中以一定的格式还原工作流附件为表的表格字段信息。
⑷ 工作流附件类型为表的信息值对象类：可以保存工作流附件类型为表的信息表的一条记录信息，类图如下：
说明：tableName就是工作流附件类型为表的表格名称，fieldValue就是对应该表的一条记录的各个字段值，用可变长数组Vector保存下来。
⑸ 工作流实例启动信息值对象类：可以保存工作流实例启动信息表的一条记录信息，类图如下：
⑹ 工作流实例过程信息值对象类：可以保存工作流实例过程信息表的一条记录信息，类图如下：
⑺ 工作项信息值对象类：可以保存工作项信息表的一条记录信息，类图如下：
⑻ 用户信息值对象类：可以保存用户信息表的一条记录信息，类图如下：
⑼ 角色信息值对象类：可以保存角色信息表的一条记录信息，类图如下：
⑽ 部门信息值对象类：可以保存部门信息表的一条记录信息，类图如下：
⑾ 职位信息值对象类：可以保存职位信息表的一条记录信息，类图如下：
⑿ 日志信息值对象类：可以保存日志信息表的一条记录信息，类图如下：
⒀ 信息集合值对象类：可以保存各种信息的一个集合，当需要返回多条记录信息的时候可以使用该类，类图如下：
说明：只有一个属性，是一个可变长数组，可以存放不定数量的记录信息。3.5.2 业务类的设计
业务类，其实就是边界类，它根据系统的需求按照一定的方式把各个实体类联系起来，以实现系统的各种功能。按照实现功能的不同我们可以分为用户管理类，角色管理类，部门管理类，职位管理类，工作流模型管理类，工作流实例管理类，系统监控管理类。
⑴ 用户管理类：负责用户的注册，注销，检测合法性，查找用户信息，类图如下：
⑵ 角色管理类：负责新增加角色，删除角色，查找角色信息，类图如下：
⑶ 部门管理类：负责新增加部门，删除部门，查找部门信息，类图如下：
⑷ 职位管理类：负责新增加职位，删除职位，查找部门信息，类图如下：
⑸ 工作流模型管理类：负责工作流模型的定义，解析，类图如下：
⑹ 工作流实例管理类：负责工作流实例的创建，维护各种实例的状态信息，分派任务给用户，用户处理工作项等等的工作，类图如下：
说明：uploadAttachmentToServer()负责把工作流附件类型为文档的文档上传到服务器特定目录下。
⑺系统监控管理类：是一个综合类，主要通过调用其它管理类的功能来实现本身的功能，就是查看工作流实例的过程状态，完成程度，根据一定的条件有必要控制实例的挂起，激活，结束，查看各个参与用户的工作情况，在出现工作误时、意外、异常等等情况时采取一定的措施保证整个实例的完成。而所有这些都保存在日志中。
3.5.3 接口类的设计
接口类是工作流引擎提供给外部应用的类，应用系统通过调用这些类，来实现一定的应用功能。我们在接口类的设计上，采取格式统一、隐藏系统复杂性、功能调用方便的原则，尽量为外部应用系统提供简洁、易懂的功能调用接口。因而我们把这些类都设计成只有一个业务类实例，一个ToDoWhat()方法的类，并且每一个业务类对应一个接口类。在这些接口类中，业务类实例作为它的一个数据成员，ToDoWhat()方法有两个参数，toDoCode（工作代码）和object（数据交换对象），工作代码表示要调用的功能的标识，数据交换对象表示功能调用要处理的数据（应用数据）。从本质上来说，就是根据不同的工作代码调用业务类实例的不同方法，对各种应用数据进行处理。
第四章
系统实现系统的实现主要包括关键问题的解决方案和一个工作流管理应用系统的实践。首先提出关键问题，然后给出解决方案，最后提出一个应用架构，利用J2EE技术和数据库技术实现一个基于轻量级工作流引擎的简单工作流管理应用系统。
4.1 关键问题的解决方案
在实现工作流引擎的时候，有一些关键问题，例如启动工作流实例，推动工作流实例的进程，类型为文档的附件的处理等等，都是要重点解决的。4.1.1 启动工作流实例
当根据各种业务需求创建了对应的工作流模型，根据结构组织情况创建了组织模型后，用户就可以创建工作流实例并启动它。用户把工作流实例的信息提交给工作流引擎，那么工作流引擎如何工作呢？工作流引擎其实做了一系列的工作，其处理过程如下：
⑴ 工作流引擎得到用户创建的工作流实例数据，记录在工作流实例启动信息表中；
⑵ 工作流引擎解析对应该工作流实例的工作流模型的含义，获得必要信息提供给工作流实例使用；
⑶ 工作流引擎根据这些必要信息找到工作流模型对应流程的第一个环节信息，并生成该工作流实例的第一个环节实例，记录在工作流实例过程描述表中；
⑷ 工作流引擎根据任务分派原则开始把任务项分派给参与该环节实例的所有用户；
⑸ 工作流引擎根据该环节定义的参与者角色，找出所有同属于该角色的所有用户，为各个用户都生成一个工作项，记录在工作项信息表中，工作项要继承该环节定义的业务规则，完成任务的分派；
⑹ 工作流引擎根据该环节定义的业务规则，如果该环节是自动型的，则为该环节的参与用户分派完任务后立刻就根据该环节信息去找下一个环节的信息，进行下一环节实例的处理；如果该环节不是自动型的，是需要人工参与处理的，则工作流引擎暂停该工作流实例的处理工作，等待参与用户处理的结果；
⑺ 启动工作流实例的工作结束。
4.1.2 推进工作流实例的进程
⑴ 如果上一环节定义的业务规则是自动型的，则立刻根据当前环节信息查找下一环节；
⑵ 如果上一环节定义的业务规则是不是自动型的，则等待参与用户对各自的工作项进行处理，当每一个用户处理完后，工作流引擎都要判断该环节实例是否结束，结束的条件是业务规则的规定和用户的处理结果。
①
如果业务规则是与聚合，当当前用户的处理结果是非正常处理的话，该环节实例就结束，并且该工作流实例也结束，通知其他还没处理的用户该环节已经结束，并记录在相应的数据库表中；当当前用户的处理结果是正常处理的话，则再判断是否所有参与的用户都处理完毕，如果是则结束该环节，通知其他用户该环节已经结束，并记录在相应的数据库表中，然后查找下一环节，如果不是则等待其他还没处理的用户的处理结果。
②
如果业务规则是或聚合，当当前用户的处理结果是正常处理的话，该环节的实例就结束，并且该工作流实例也结束，通知其他参与还没处理的用户该环节实例已经结束，记录在相应的数据库表中，然后查找下一环节；当当前用户的处理结果是非正常的话，则等待其他还没处理的用户的处理结果。
③
如果业务规则是投票聚合，当当前用的处理结果是正常处理的话，则使统计正常处理结果的计数器加一，然后判断该统计数量是否已经达到规定的数量，如果是则结束该环节实例，并通知其他还没处理的用户该环节实例已经结束，记录在数据库表中，然后查找下一环节；当当前用的处理结果是非正常处理的话，则不统计，等待其他还没处理的用户的处理结果。
⑶ 当前环节实例结束后，工作流引擎就找下一环节处理，如果没有下一环节，则结束该工作流实例，记录在数据库表中，如果还有环节，则同样生成环节实例，进行任务分派，等待环节实例的结束。工作流引擎就是这样推进工作流实例进程，从一个实例环节到下一个实例环节，直到工作流实例结束为止。
4.1.3 类型为文档的附件的处理
对于文档形式的附件，我们采用上传文件到服务器的方法，用户编辑好文档后，以规定的文件名上传到服务器中特定的目录中，当用户要查看该文档时，工作流引擎会根据该附件文档对应的信息得到其文件名，用户根据该文件名下载到本地中，同时调用外部应用程序如work2000、记事本打开给用户浏览其内容。
4.2 一个简单工作流管理系统的实现
现在，我们利用J2EE技术把工作流引擎开发出来，并基于该引擎做一个简单的应用系统，以证明系统设计的可行性。我们用Jbuilder9.0做开发工具，用MS SQLSERVER2000做数据库管理系统。4.2.1 系统应用框架
工作流实例管理器
工作流模型管理器
组织管理器
系统监控器
工作流引擎
应用服务器
数据库
Web界面
文档管理系统
图4.1 系统应用框架
4.2.2 J2EE相关技术的应用
J2EE为多层Web应用系统提供了容器平台，用J2EE技术把工作流管理系统开发成一个多层Web应用系统，是最合适不过了。
4.2.2.1 J2EE核心模式和类的实现
模式是特定问题的可重现的解决方案，使用模式有莫大的好处。模式可以权衡已经被证实的解决方案，为交流提供一个共同的词汇，约束解决方案的范围。J2EE核心模式是在J2EE平台上应用的模式，它在表示层，业务层，集成层都有特定的模式，为基于J2EE平台的开发提供很好的解决方案。对类的实现我们采用了J2EE核心模式，主要运用的核心模式是业务层的ValueObject（值对象）和集成层的DAO（DataAccessObject，数据访问对象）。
⑴ 值对象：基于多层应用架构的系统，客户端和服务器端往往有大量的数据交换，而且客户端调用的方法都是远程的，不是本地的，为了减轻网络负载，提高应用程序的性能，用值对象封装业务数据，在客户端和服务器端进行数据交换。因而我们把所有工作流对象都用值对象表示，像工作流定义主信息值对象类（WFDefineMainInfo）。在这些值对象中，所有属性和方法都是声明为公共的，并且很少方法，很多属性，这些属性就是对应的工作流对象的属性，也对应了数据库中表的某个字段。
⑵ 数据访问对象：基于关系数据库技术的系统，会对数据库进行频繁的访问，数据库表的众多，对某个表操作的方式的众多，如果不对这些表和表的操作方式进行必要的归类，只会造成模块聚合度的降低，代码混乱的后果。我们使用数据访问对象，来抽象和封装对数据库的访问，所有涉及到数据库访问的情况都使用数据访问对象去实现。工作流对象的所有数据都保存在数据库中，我们为每个对象数据的数据库操作都封装在数据访问对象中，像工作流定义主信息访问类（WFDefineMainInfoDAO）。4.2.2.2 JavaBean技术与类的实现
JavaBean是基于Java技术的软件构件模型，它是Java语言编写的可移植的不依赖于平台的软件构件模块。我们把系统所有的类都实现为一个一个的JavaBean，提高类的可重用性，有利于日后的功能扩展。另外，JavaBean应用到JSP中，可以为JSP应用带来更好的可伸缩性。
4.2.2.3 JBOSS应用服务器和工作流引擎的实现
应用服务器我们采用JBOSS，这是一个免费的产品，它提供数据库访问（JDBC）、命名机制（JNDI）服务等服务，支持数据库连接池、实例连接池，这些为我们的工作流引擎的实现提供了支持，给系统开发带来很大的方便。
⑴ 对数据库访问的支持：JBOSS通过对特定数据库管理系统的配置（XML文件），并实例化对数据库的若干连接，放进数据库连接池中，提供给系统使用。在JBOSS运行过程中，对这些数据库进行有效的管理，减轻了工作流引擎的工作负担。①
配置方法 mssql-ds.xml文件：
MSSQLDS/* 数据源名字 */
jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=WorkflowDB /* 连接URL，包括服务器
地址，数据库名称 */
com.microsoft.jdbc.sqlserver.SQLServerDriver /* sqlserver驱动 */
workflowUser /* 用户名称 */
123456 /* 用户密码 */
②
调用方法（使用JNDI机制）部分代码：
InitialContext ctx = new InitialContext();//初始化上下文
DataSource ds =(DataSource)ctx.lookup(“java:/MSSQLDS”);
//根据数据源名字查找已经配置好的数据源
Connection conn = ds.getConnection();
//调用该方法可以得到对数据库的一条连接，而这条连接已经被JBOSS初始化，实际上是从数据库连接池中找到一条可用的连接而已，然后通过该连接就可以对数据库进行各种操作，操作完毕后不用显式关闭，JBOSS会自动回收该连接，把该连接重新放入连接池中。
⑵ 对对象实例化的支持
当系统第一次生成某个对象实例时，JBOSS就对该实例进行管理，把该实例放入实例池中，并不释放它，当系统再次要生成该实例时，不再进行该对象的实例化，而是JBOSS从实例池中找到该实例并提供给系统使用，这明显提高系统运行速度。
⑶ 对线程的支持
当不同的用户登陆系统，并且对系统所有功能的使用，JBOSS会为每个用户分配一个线程去为他们工作，这些线程放入线程池中，JBOSS在运行过程中始终对这个线程池进行管理，提高系统的并发性能。
4.2.2.4 Jsp/Servlet技术和系统界面的实现
JSP技术可以方便的建立动态Web页面，提供一个友好的用户界面，并且很方便的调用JavaBean，完成复杂的业务功能；Servlet提供在Web进行请求和响应服务的功能，客户端对服务器提供的服务的所有请求和响应都通过Servlet实现。JSP最终解析为Servlet。
⑴ JSP调用JavaBean
下面是创建工作流定义主信息的JSP页面部分代码：
class=“wfsystem.interfacepack.client.workflowManager” /> „ <% WFDefineMainInfo wfDefinemaininfo =new WFDefineMainInfo(); „ // 填充工作流定义主信息值对象WFDefineMainInfo 实例 wfManager.ToDoWhat(0,(Object)wfDefinemaininfo);//调用接口类的方法，0对应创建工作流主信息的方法代码 %> ⑵ Servlet请求和响应服务 下面是请求得到表单信息（这些信息就是工作流定义主信息值对象的内容）部分代码： <% String workflowname = request.getParameter(“workflowname”); String workflowDesc = request.getParameter(“workflowDesc”); //request就是请求对象，调用其方法getParameter()可以得到表单的信息 „ //一个一个的得到信息 %> 下面是响应用户的部分代码： <% response.sendRedirect(“defineWorkflowModel-mainInfo.jsp”);// response就是响应对象，调用其方法sendRedirect()向用户发送一个页面重定向的应答。 %> 4.2.3 具体编码实现 接下来的工作就是编码工作，以Jbulider9.0作为开发工具，以VSS（Microsoft Visual SourceSafe6.0）作为版本控制工具，进行代码编写，进行单元测试，综合测试，最后得到一个基于轻量级工作流引擎的简单的工作流管理系统。 第五章 系统的不足 本文探讨的轻量级工作流引擎，尽管有很多的优点，可是它从够用、灵活和低成本的设计原则出发，不追求工作流引擎的功能的完备和复杂，所以存在着一些不足： ⑴ 不支持复杂业务：本文探讨的轻量级工作流引擎是从一般业务的需求设计工作流模型，我们只实现了活动的单分支，就是组成工作流流程的活动是一个活动只有一个后续活动，而复杂业务可能一个活动后面出现多分支，有多个后续活动，形成一个树型的结构。所以对复杂业务的不支持是本文探讨的工作流引擎的最大的不足。 ⑵ 不支持复杂的组织结构：本文探讨的工作流引擎只是以职能型的机构模型去描述组织结构，主要以部门和职位组成一个角色，任务分配也只是按照部门和职位的不同组合去分配，可是复杂的组织结构模型可以定义多重角色，临时工作组等等。 ⑶ 不支持提供内建（built-in）的应用开发工具，例如是可视化工作流建模工具，FORM设计工具，这些在本文探讨的工作流引擎都没有实现一定的接口。 ⑷ 在定义应用数据方面不支持所有数据类型和完整性维护，只支持字符型类型和进行一些简单的数据保存工作。 ⑸ 没有完善的异常处理功能。对异常的捕捉和处理并不完善，没能及时把错误信息显示给用户。 ⑹ 没有完善的事务控制功能。只实现了一些简单的事务控制，没有对复杂事务的控制。 第六章 总 结本文主要探讨了轻量级工作流引擎的设计与实现，首先我们要了解有关工作流技术的相关知识，然后说明开发轻量级工作流引擎的原因，再从企事业一般业务需求入手，抽象出工作流对象，分析其之间的逻辑关系，组成工作流模型，跟着提出一个系统结构，进行模块划分，数据库设计，类的设计，最后利用J2EE技术，用MS SQLSERVER2000作后台数据库，Jbuilder9.0作开发工具，VSS作版本控制，实现工作流引擎的开发，并基于该工作流引擎作一个简单的应用系统，最终实现为一个工作流管理系统。该管理系统的正常运行，充分体现了轻量级工作流引擎在企事业业务的开发过程中的价值。参考文献[1] 范玉顺著，《工作流管理技术基础》，清华大学出版社 [2] Deepak Alus等著，《J2EE核心模式》，机械工业出版社 [3] 王克红等著，《Java技术教程（中级篇）》，清华大学出版社 [4] Wendy Boggs等著，《UML With Rational Rose从入门到精通》，电子工业出版社 [5] Borland公司著，《Borland Jbuilder实用技术手册》，电子工业出版社 [6] 何清法等著，《基于关系结构的轻量级工作流引擎》，中国科学院计算技术研究所 [7] Joseph L.Weber著，《Java 2 编程详解》，电子工业出版社 本文来自CSDN博客，转载请 标 明 出 处http://blog.csdn.net/hjt79/archive/2004/08/15/75484.aspx 关键词 BOC 捕获 频谱 仿真搜索 正交 1 引言 由于GPS卫星发射的导航信号比较微弱，而且以固定的频率发射，因此很容易受到敌方的干扰。为了改善这种局面，1977年美国正式提出了“GPS导航战”（Navigation warfare）的概念[1-3]。但由于现行的军用和民用GPS信号的频谱是混叠使用的，所以美方对C/A码施放干扰信号也必然导致军用信号频谱的中央部分不能使用。为了改善GPS这种频谱结构的缺陷，美方经过大量的研究后，确定了最终方案：在现有L1和L2两个频段上附加新的军用信号，即M码。M码采用一种裂谱调制法，它把其大部分功率放在靠近分配给它的频带的边缘外，抗干扰能力主要来自不干涉C/A码或Y码接收机的强大的发射功率，而且M码信号的保密设计基于下一代密码技术和新的密钥结构，具有很高的保密性。实现M码分裂频谱调制方法有很多种，经过大量比较，确定了选用二进制偏移载波（BOC）调制技术，这是因为它不仅使M码信号的频谱能与现有信号的频谱很好的隔离，而且还有更好的性能。本文在介绍BOC调制技术的原理和分析其频谱结构的基础上，提出了基于并行码相位搜索的改进捕获算法，设计了正交IQ捕获算法，对两路并行捕获，捕获性能优于传统的捕获方法，仿真结果显示算法的正确性。 2 BOC调制信号的频谱与自相关特性 二进制偏置载波（BOC）调制，该调制提供两个相互独立的设计参数： （1）副载波频率fs，单位MHz； （2）扩频码速率fc，单位Mchip/s。 通过这两个参数，可以自由地将信号能量集中在所分配带宽的指定部分，以减少接收其他信号的干扰。 BOC调制信号通常被记作为BOC（fs，fc）或BOC（a，b），其中fs=af0，fc=bf0（a，b通常为正整数），基准频率f0=1.023MHz。 2.1 BOC调制信号的频谱特性 BOC（fs，fc）信号的归一化基带功率谱4-7：当n=2fs/fc为偶数时[4-7]， （1） 当n=2fs/fc为奇数时， （2） 采用BPSK调制方式，扩频码码率为fc的GPS C/A码信号的归一化基带功率谱为： （3） 图1所示为 BOC（1，1）信号和GPS C/A码信号的归一化基带功率谱，可以看出BOC（1，1）相对于 GPS C/A码信号，最大的一个特点就是具有中心分裂的功率谱，这将有助于降低它与GPS C/A码信号的干扰，并且由于它在高频段具有更多的能量，它比GPS C/A码信号拥有更大的Gabor带宽， 这也意味着它具有更佳的捕获性能。 2.2 BOC调制信号的自相关特性 BOC调制信号的自相关函数，可以通过对BOC调制信号的功率谱做逆傅立叶变换得到。理想情况下（接收机前端带宽无限宽）BOC（pn，n）信号的自相关函数为[8]： （4） 其中，p=1，2，3，…，k=■。 在（4）中令p=1，可得BOC（1，1）自相关函数RBOC （1，1）（τ）为： （5） 采用BPSK调制方式的GPS C/A码信号的自相关函数RCA（τ）为： 其中k=2τ/Tc，Tc=1/fc。图2所示为BOC（1，1）信号和GPS C/A码信号的自相关函数，可以看到BOC（1，1）的自相关函数相对于GPS C/A码信号而言，具有多个峰值，这也对接收机提出了更高的要求。通常将自相关函数正中间的峰值称为主峰，而其它的峰称为旁峰。 3 捕获算法的设计 经典的并行码相位搜索框图如图3所示[9-10]： 本地产生的副载波与本地产生的伪码相乘之后变换到频域取共轭，输入信号经过傅立叶变换后与经过傅立叶变换的BOC码相乘，输出结果经过傅立叶逆变换 转换为时域信号，傅立叶逆变换输出的模值表示输入信号与本地伪码的相关结果。改进后的并行码相位算法框图如图4所示： 改进捕获算法如下： （1）将接收到的中频信号取1ms的数据长度，记为x（n）； （2）本地载波取中频信号IF±10KHz范围，步长取500Hz，生成41个本地中频载波，并对生成的本地载波进行采样，记为li（n）（i=1，2，…，21）； （3）将x（n）和li（n）的转置点对点相乘，结果取FFT，记为Fi（k）； （4）产生本地副载波，相位分别为0°和90°，两路信号分别进行FFT变换到频域中，并取共轭。记为f1*（k）和f2*（k）； （5）Fi（k）分别与f1*（k）和f2*（k）点对点相乘，结果记为G1（k）和G2（k）； （6）产生本地的C/A码，并对其进行采样，记为Cs（n）（s为卫星编号）； （7）对Cs（n）进行FFT，变换到频域中，并取共轭，记为Cs（k）*； （8）将G1（k）和G2（k）分别与Cs（k）*点对点相乘，结果为Rs1（k）和Rs2（k）； （9）对Rs1（k）和Rs2（k）进行IFFT，变换到时域中，得到rs1（n）和rs2（n），得到其模平方rs1（n）2和rs2（n）2； （10）比较rs1（n）2和rs2（n）2的最大值，选择判决那个大就选择哪个，记为rsi（n）2，最大值对应的坐标即为C/A码的起始点和载波粗频。 4 仿真结果及分析 高斯信道信噪比为0dB时的捕获结果如图5所示，局部放大图如图6所示。由图可以看到有1个主峰和2个次峰，这和BOC（1，1）信号的自相关函数有三个峰值是相符的，由图BOC（14，2）捕获图可以看出，峰值位于码相位45094和频率25.542MHz处，图7为BOC（14，2）信道加高斯干扰0dB-34dB的仿真结果。 由图仿真结果可知，当干扰为-36dB时，捕获算法完全失效，主峰与副峰比值基本相同，捕获结果完全被信号淹没，在干扰为-35dB到-27dB时，捕获算法仍然有效，但效果较差，此算法在大于-27dB高斯信道干扰下完全可以捕获到信号的初始码相位和载波频率，为进一步跟踪提供了粗略值。 5 结束语 改进的捕获算法基于并行码相位搜索算法，针对收发端载波不同的问题，在产生本地副载波时分别产生I路和Q路两路信号，分别基于捕获算法，最后对捕获到的峰值进行比较，这样可以选择最优的捕获结果。 参 考 文 献 [1] 杨东凯，樊江滨，张波，张敏译. GNSS应用与方法. 电子工业出版社. 2011.09 p.16-22 [2] 杨力，基于BOC调制的导航信号同步接收关键技术研究. 南京理工大学.2009.12 [3] 楚横林，李春霞. BOC调制导航信号关键技术研究. 2010 Radio Engineering Vol.40 No.6 [4] 王智，耿相铭. Galileo卫星导航系统中的BOC调制与接收技术.上海航天.2007年第6期 [5] Peter Rinder， Nicolaj Betelsen， Design of a single frequency GPS software receiver. Aalborg University 2004. [6] D Akopian.Fast FFT based GPS satellite acquisition methods.IEE Proceedings Radar， Sonar and Navigation，2005，1 52（4）：277—286. [7] 杨俊，武奇生. GPS基本原理及其Matlab仿真. 西安：西安电子科技大学出版社. 2006：126-181页 [8] Julien O，Cannon M E，Lachapelle G，et al.A New Unambiguous BOC（n，n） Signal Tracking Technique [A].In：Europe Navigation Conference GNSS 2004[C].2004：17-19P [9] 刑兆栋. BOC 导航信号处理方法及卫星导航数据的传输. 北京航空航天大学. 2006：58-73页 [10] Kai Borre，Dennis M.AKos，Nicolaj Bertelsen Peter Rinder Soren Holdt Jensen，杨东凯，张飞舟，张波译. 软件定义的GPS和伽利略接收机. 国防工业出版社.2009.3 Based on Parallel Code Phase Search of BOC Signal Acquisition Algorithm of Design and Implementation Xin Fuguo1，Li Rongfang2 （1. Shaanxi Post and Telecommunication College department of communication，Xianyang 712000，China） （2. Shaanxi Post and Telecommunication College department of computer，Xianyang 712000，China） Abstract BOC modulation，as a navigation signal system ，has such better performances as multipath-resistant and anti-jamming ，it can realize spectrum separation under the condition of carrier frequency being shared .This paper first analyzes the characteristic of the frequency spectrum of BOC signal and the autocorrelation function ， put forward based on the concurrent code phase search of the algorithm， the design of orthogonal orthogonal IQ acquisition algorithm， the two road parallel acquisition， the simulation results show the correctness of the algorithm and the superiority. 近年来,随着无线通信技术的创新和手机的普及,移动上网渐渐成为发展趋势。为了满足用户随时随地查询衣食住行信息的需求,如何建立移动搜索引擎,成为移动网络应用的热点。移动上网受手机终端和传输带宽的限制,纯HTML文本只有少数智能机型可以支持,大多数手机只识别WAP 协议标记的语言,如WML 或XHTML。但是,网络信息主要以HTML语言表达,WAP的资源有限,单纯以爬取WAP页面作为信息来源的移动搜索引擎无法提供足够的信息。因此,如何能突破限制,使手机客户也能搜索到来源于HTML的海量信息,成为移动搜索的主要问题之一。 使用手机浏览HTML页面,一般的方法是加入一个WAP网关[1]。当手机发出浏览HTML网页的请求时,由网关首先读取该网页,并将其转化成相应的WML,再发送到手机。这种方式也是当前将通用搜索引擎扩展为移动搜索引擎的流行方式[2]。但是这种实时翻译的方式,显然对网关的性能和带宽要求较高。 本文介绍了一种利用HTML资源建立移动搜索引擎的方式。它通过集中对网络蜘蛛抓取的HTML网页进行翻译处理,生成WML语言的网页快照,满足手机用户的搜索需求。以该技术建立的移动搜索引擎,不需要实时翻译网关的支持,可以方便地扩展已有的搜索引擎系统。 1 移动搜索引擎设计框架 目前通用搜索引擎系统一般由搜索器、索引器、检索器、用户接口四个部分组成,不同搜索引擎的具体模块可能会有不同的变化和扩展[3]。移动搜索引擎就是在这四个基本模块的基础之上进行延伸,加入移动模块。它包括三个部分: • 翻译器,将蜘蛛抓取的HTML页转化为WML页; • WML网页快照库,保存转化后的WML页; • WAP接口,用手机访问的用户界面。 其中,翻译器是移动模块的核心,它直接决定了移动搜索引擎信息的质量。 如图1所示,移动搜索引擎的工作流程是:首先由搜索器开始,定期自动启动抓取互联网网站,将抓取到的网页存入网页库,并将网页上的所有超链接存入到URL列表中。索引器将己经抓取的网页文档进行分词处理,并按词在网页中出现的位置和频率计算权值,然后将分词结果存入索引库。在建立索引的同时,还要通过移动模块的翻译器,将HTML网页的主题信息进行翻译、过滤,再将主题信息转化成手机可以识别的WML页面,并存入WML的快照库中。当用户通过WAP接口查询信息时,检索器首先对用户输入的信息进行分词处理,并检索出所有包含检索词的记录,通过计算网页权重和相关性对查询记录进行排序,进行集合运算,最后提取各网页的摘要信息反馈给查询用户。但当用户点击条记录察看具体网页时,与互联网搜索引擎不同,系统不会直接链接互联网上的该网页,而是链接该网页相对应的WML网页快照。 2 翻译器模型及算法 从HTML到WML最直接的方法是根据一组规则将HTML源代码的标签进行处理转换成WML标签,并重新排版使其能够符合手机屏幕显示[4]。由于移动搜索引擎需要快速、直接、精炼地将查询信息返回给用户,然而蜘蛛抓取的网页中不仅存在部分无主题页,而且即使是有主题的页面通常也有大量与主题无关的信息,因此直接翻译并不适合。根据移动搜索的特点,翻译器需要包括网页过滤、主题信息过滤和翻译三个部分。 2.1 网页过滤 普通门户网站的页面性质主要包括表达某一主题的内容页和以链接为主的目录页。由于目录页一般没有主题,而且移动搜索返回的结果列表也可以代替目录功能,因此,首先将目录页面过滤,不予翻译。具体方法如下文介绍。 对整个页面的HTML进行遍历。把整个页面分割成相互独立的较大的内容块,只保留最大内容块。由于目录页通常是以链接文字的形式出现,<A>…</A>的比例占比较大,因此,系统通过链接文字和非链接文字数量的比例作判断: • 如果非链接文字总计大于300个字符,且链接数量少于10,则判断不是目录页。 • 如果非链接文字总计大于200个字符,且非链接文字总计大于链接文字总计,则判断不是目录页。 • 如果连续的非锚文字长度大于150个字符,则判断不是目录页。 对于不符合这三个条件之一的页面,系统将其作为目录页过滤。由于搜索引擎返回的搜索结果需要和翻译后的WML页面一一对应,因此,被过滤掉的网页,也将不会被包含在索引中。 2.2 基于DOM的主题块过滤 内容页常常也包含导航条、版权信息、广告等大量主题无关的信息。手机受屏幕大小的限制,这些信息会使手机上显示的内容比较混乱,可读性差。 由于蜘蛛抓取的信息来源广泛,因此选择不依赖于信息源的STU-DOM的树模型[5],对网页的主题相关部分进行提取。 将网页的<table>、<tr>、<div>和<tbody>等标签结点作为分块结点。对于一个块的取舍用局部相关度和上下文相关度来衡量。局部相关度由块内链接和内容决定,其计算公式可以表达为: 其中,ContentLength 和LinkCount分别表示块内的文字数和链接数,STUCij表示STUi的第j个子块。 上下文相关度由块内链接和父块内容决定,其计算公式可以表达为: 其中,STUPi表示STUi的父结点。 通常局部相关度阈值是2,而上下文相关度的阈值是70。对于面向不同领域的搜索引擎,也可以根据本领域门户网站页面的特点调整阈值。 2.3 HTML2WML 将HTML块转化成WML文件,主要参考了Sébastien Aperghis Tramoni在SourceForge开源项目Html2Wml的设计方式[6],建立HTML标签与WML标签转化的对应关系。它的核心是一个强大的规则库,用来存储HTML 标记和转换规则的信息。规则库由标记名库、属性名库、标记与属性表、特殊符号表、信息剪裁规则和处理函数库几个部分组成: • 标记名库里存储了所有已知控制标记名; • 属性名库存储了所有可能的属性名; • 标记与属性表存储了标记与属性之间的对应关系; • 特殊符号表存储了语法中一些特殊符号; • 信息剪裁规则保存了进行信息剪裁时的相应规则; • 处理函数库保存了供规则调用的处理函数。 当HTML块转化时,首先使用信息剪裁规则,去除WML无法处理的元素,如<style>、<front>、<script>等标签,然后,将HTML转换为手机可读的WML。对于内容转换规则,主要包括图片转换、编码转换和特殊字符处理等;对于版面排版规则,主要是针对TABLE 和FRAMESET 等标记作一些重排处理,将HTML 文档中的TABLE 按列切分成多个表格。由于WAP不支持多帧,所以对于FRAMESET 中的多帧页面,可用<A>来链接每个FRAME。转换处理算法如下:因为HTML 的标签分为配对标签(标签必须成对出现,如<table>、<tr>、<td>等)和非配对标签(如<p>、<br>、<h>等),所以这里引入栈的处理方式,将所有的HTML 标签分为两类后,配对标签必须进行出入栈操作。 3 WAP接口设计 WAP接口是以手机为载体的人机交互查询界面。它使用WML或XHTML语言设计,界面与普通搜索引擎相类似,作用是输入用户查询,显示查询结果,提供用户相关性反馈机制,主要的目的是方便用户使用搜索引擎,高效率、多方式地从搜索引擎中得到有效、及时的信息。它包括以下三个部分: • 用户查询界面 由于受手机屏幕尺寸大小的限制,它非常简单,具体的实现内容只有一个可以输入词句的输入框和相应的查询按钮。 • 查询结果列表界面 该界面返回用户提交后的查询结果。当WAP接口接受用户的查询请求后,首先对用户输入的搜索关键词进行切词,然后从索引文件中查找包含切分出的每个词的文档并对这些文档集进行汇总,得到最终的结果集。系统采用TF-IDF评分函数计算文档的得分,并按得分高低进行排序,并把处理后的结果返回给用户。但是由于手机屏幕小,浏览器也不易表达复杂的表格和绚丽特效,因此在WAP上的内容要尽量简练;在搜索结果的列表页上,要缩短摘要的篇幅,同时每页的条目数尽可能不超过十条。 • 详细信息展示界面 该界面由列表页转入,显示用户所查询的详细信息。在互联网搜索引擎中,获取详细信息一般会跳转到搜索器抓取的原页面,但是WAP上的详细信息展示界面不会直接链接互联网上的该网页,而是链接WML快照库中翻译器翻译的该页面相对应的WML网页快照。 4 系统实现 根据本文描述的设计方法,开发了生活服务领域移动搜索引擎www.zhaocha.mobi。它是在原有的互联网搜索引擎www.zhaocha.com.cn[7]的基础上改进,并加入移动模块建立起来的。 该搜索引擎利用翻译器将蜘蛛下载的网页清洗过滤,只保留包含网页主题的主题块,并翻译成WML语言。它使用Lucene技术建立索引,并用转化后WML网页地址代替原网页的URL编入索引中,中文分词采用基于词典的正向最大匹配分词算法[8]和双字哈希索引词典机制[9]。 目前系统开通了餐饮、娱乐和黄页三个领域的移动搜索引擎,覆盖全国37个主要城市。如图2所示,用户可以通过手机随时随地地访问自己所在城市的相关生活服务信息,带来极大的方便。 与传统的WEB上的搜索引擎相比,移动搜索引擎的优势如表1所示。简而言之,移动搜索可以满足随时随地的高度目标化、专业化搜索请求,其优势在于不受时空限制,且针对性强,对特定范围的网络信息的覆盖率相对较高,具有可靠的技术和信息资源保障,有明确的检索目标定位。 5 结 语 本文从移动搜索的现状出发,提出一种扩展当前互联网搜索引擎,支持移动搜索需求的方法。该方法在当前搜索引擎的框架上加入移动模块,对网络蜘蛛抓取的HTML网页进行集中翻译,使其成为手机可以识别的WML格式,并保存到快照库中。手机用户通过WAP接口根据搜索结果提供的链接访问WML网页库中相关网页。利用这种方法,已经成功地开发了覆盖全国37个城市的餐饮、娱乐和黄页的移动搜索引擎。 摘要：针对移动搜索引擎的现状,在现有互联网搜索引擎的框架上加入移动模块,提出一种利用HTML资源建立移动搜索引擎的方式。该方式通过集中处理网络蜘蛛抓取的HTML网页,将其翻译成WML形式的网页快照,满足用户的移动搜索需求。在实际应用中,使用该方式成功地建立了一个面向生活服务领域的移动搜索引擎,覆盖全国近四十个城市的餐饮、娱乐和黄页信息。 关键词：移动搜索,搜索引擎,WAP,WML 参考文献 [1]陈嘉玫.WAP闸道器上的HTML过滤器之设计[D].台湾:国立中山大学资讯管理研究所,2001. [2]陈明,孙丽丽.基于WAP的移动搜索模型[J].计算机工程,2008,3(34):205-209. [3]王志江.面向领域的垂直搜索系统研究与实现[D].大连:大连理工大学系统工程研究所,2008. [4]Issa A A,Qutaishat M A.Dynamic Multiplatform HTML to WML Mo-bile Converter[C]//Proceedings of the World Congress on Engineering 2008Vol I.London,2008:816-821. [5]王琦,唐世渭.基于DOM的网页主题信息自动提取[J].计算机研究与发展,2004,41(10):1786-1792. [6]Tramoni S A.Html2Wml[EB/OL].http://htmlwml.sourceforge.net/index.html.en. [7]汲业,陈燕,杨健,等.生活服务领域垂直搜索引擎的设计与实现[J].计算机工程,2010,36(24):24-26. [8]刘迁,贾惠波.中文信息处理中自动分词技术的研究与展望[J].计算机工程与应用,2006(3):175-177. 网络搜索引擎 (Web Search Engine) , 是伴随着互联网的发展而出现的人们上网必不可少的简单方便而又实用的入门工具, 没有搜索引擎就像冲浪的时候没有冲浪板, 面对滔天海水, 只能望洋兴叹, 没有搜索引擎面对浩如烟海的网上信息我们将无从下手, 找不到我们希望得到的信息。网络搜索引擎是对网络上网页的一种检索系统, 有的提供分类和关键词检索途径, 有的仅提供关键词检索途径。它根据检索规则和从其它信息服务器上得到数据并对数据进行加工处理, 自动建立索引, 通过用户界面为用户提供查询检索服务, 能够对互联网上的资源进行分类提供人们感兴趣的话题以供查询, 并返回能够让用户满意的结果。 在此我们将通过java语言和htmlparser开源工具包及微软的SQL Server数据库来构建一个简单的搜索引擎。这只是对搜索引擎的工作原理和概念的一种简单的实现和验证。本文将介绍如何构造出一个网络搜索引擎的关键部分———网络爬虫。 2 网络搜索引擎的组织结构 网络搜索引擎主要由网络爬虫、索引器、检索器和用户接口四大主要部分组成。 网络爬虫:又被称为网络蜘蛛, 网络机器人, 是一种按照一定的规则, 自动的抓取万维网信息的程序或者脚本。从一个或若干初始网页的URL开始, 获得初始网页上的URL, 在抓取网页的过程中, 不断从当前页面上抽取新的URL放入队列, 直到满足系统的一定停止条件为止。 索引器:功能是理解网络爬虫所搜索到的信息, 从中抽取出索引项, 用于表示文档以及生成文档库的索引表。对数据库中的网页内容进行分析, 提取网页信息, 依据一定的相关度算法进行大量复杂计算, 得到每一个网页及超链中每一个关键词的相关度, 然后用这些相关信息建立网页索引数据库。 检索器:根据用户输入的查询请求, 在索引数据库中快速检索文档, 进行相关度评价, 对将要输出的结果排序, 并按用户的查询需求合理返回让用户满意的信息。 用户接口:提供图形用户接口, 接纳用户查询、显示查询结果、提供个性化查询项, 使用户的查询请求可以直观、栩栩如生地表现出来。 搜索引擎的实现需要完成三个部分的功能, 抓取网页、处理网页、提供查询服务。 抓取网页:完整意义上的网络搜索引擎都具有自己独立的网络爬虫程序。网络爬虫沿着网页中的超链接不停地抓取网页。从抓取的网页中解析出指向其他网页的超链接, 网站基本上都是建立在超链接的基础之上的。所以从理论上来说, 从一个经常用到的网站主页出发, 就可以抓取到网络上所有的网页, 被抓取的网页被称之为网页快照。 处理网页:搜索引擎抓到网页后, 需要对网页进行大量的处理工作, 然后把处理好的网页送往数据库中, 以便检索器在数据库中进行检索。其中包括提取关键词, 建立索引文件数据库、对重复网页网页的处理、中文分词的处理、判断网页类型、解析得出超链接、计算网页的页面排名等。 提供查询服务:用户使用关键词进行检索时, 提供图形化易于理解和操作的用户接口, 以便用户进行检索, 检索器从索引数据库中进行检索, 得出和用户的查询请求相匹配的查询结果, 并返回网页的一个页面快照, 方便用户进行网页和查询结果的挑选。 搜索引擎是对不对互联网进行直接搜索, 通过对已抓取的网页数据库建立的索引库进行搜索, 使得返回的结果快速而又高效高质量, 索引和页面排名在搜索引擎中中扮演了最为重要的角色, 页面排名和索引算法的效率直接影响搜索引擎的效率, 是评测搜索引擎准确性和性能的重要因素。 搜索引擎的收集HTML、XML、Newsgroup文章、FTP文件、word文档、图片、MP3和视频等。为了提高信息发现和更新的速度, 搜索器的实现常常采用分布式、并行计算技术, 同时搜索引擎的数据库每隔一段时间进行更新。 3 系统设计 系统主要包括分四个部分: (1) 网络爬虫:搜索引擎的基础, 负责抓取索引数据源。 (2) 索引数据库:对网络爬虫抓取到的网页建立索引, 生成索引数据库, 供查询用。 (3) 全文索引:利用SQL Server 2008方便地实现全文索引。 (4) 搜索模块:用户的查询字符串传递给服务器, 服务器通过在索引数据库中进行搜索, 然后将得到结果集返回给用户 网络爬虫生成了一个URL待处理表, 并把这个链表交给控制器进行处理。处理过程中, 首先是页面的解析, 从而筛选出需要的内容。对筛选出的内容分词、过滤之后, 再由索引器对其建立索引数据库, 从而形成了一个索引库。 4 系统实现 接下来从总体和细节两个方面对网络搜索引擎进行描述, 并对其中的一些重要部分进行了详细的说明, 主要包括对实现网络爬虫的流程、索引数据库、全文索引的方面。 4.1 网络爬虫的实现 网络爬虫的工作流程如图2所示。 (1) 初始化URL等待表 默认情况下用http://www.baidu.com这个URL初始化URL队列, 当点击开始抓取网页时会把这URL个放入URL等待处理表中。调用函数urlisok () 对输入的字符串进行处理, 若是可以连接的URL, 则返回这个URL的名称。判断输入的URL是否有效。若是不为空, 则有效, 为空则不能访问的URL。函数insert_1 () 访问数据库zhy_data, 把URL放入表URL等待表中。提醒重新输入一个URL。上面的这些函数和过程通过函数process_url () 调用实现初始化URL等待表。实现这个过程的流程如图3所示。 (2) 判断是否满足结束条件 查询表urlpool。若结果集的首行为空, 或取得指定数量的网页, 则结束程序。查询表的时侯, 得到一个URL, 同时在urlpool表中删除此URL对应的行。在解析此URL指向的网页中的新URL的同时, 同时把此URL指向的网页进行处理, 放入供查询用的数据表中。利用一个while () 循环执行此过程, 直到满足结束循环的条件为止, judge () 函数用于判断表urlpool是否为空, 若为空返回false, 否则返回true。max为已得到的用于建立索引的网页的数量。表头URL出表, rs.next () 使游标能够在访问表urlpool得到的结果集中移动, rs_1.get String (1) 获得URL。 delete_1 (str_url) 函数删除在urlwaiting中的str_url指代的URL。实现是否满足结束条件的处理过程如图4所示。 (3) 下载URL指向的网页 调用htmlparser包中的类Parser实例化一个对象parser, parser.set URL (str_url) 用于设置parser访问的URL, parser.get Encoding () 用于获取str_url代表的URL指向的网页所用的编码。 (4) 抽取网页中的URL 建立一个锚过滤filter用于过滤网页的节点。Parser类的方法extract All Nodes That Match () 。用于解析过滤得出上一步中parser对象中的网页中的URL。过滤后得到得到想要的节点。得到网页中的猫节点, 并转换成字符串表示。Found_url.urlisok (link.get Link () ) 判断得到的URL是不是一个可用的URL, 若URL可用, 则把代表此URL的字符串返回给字符串string, 若此URL不可用, 则返回null。 (5) 新URL插入URL队列 函数waiting () 用于判断表urlwaiting中是否有string代表的URL, 有返回true, 无则返回false。如果flag_2为真, 则调用函数update_2 () 用于更新表urlwaiting中string代表的URL。Insert_2用于把string代表的URL插入URL等待表中, newfirst代表此URL的优先级, newpoint代表指向此URL的链接数。流程如图5所示。 4.2 索引数据库的实现 索引数据库的实现流程如图6所示。 sta_1.execute Query (query_1) 用于从表urlwaiting中取出url进行处理。利用for循环实现对网页数量的控制, i表示要取的网页数不超过100个, re_1.next () 表示表urlwaiting中是否还有URL可用, 下面几段所涉及的函数和表达式都包含在这个for循环里面。rs_1.get Int (2) 用于获得优先级, rs_1.get String (1) 用于获得URL函数delete_1 () 用于删除表urlwaiting中包含指定URL的行。update_1 () 用来更新urlprocessed表中str_url所代表的URL, 函数insert_3 () 用于向表urlpool中插入数据, got_title () 用于获得网页的标题, text () 用于获得网页的内容, insert_1 () 实现把URL及网页内容插入表urlprocessed, processing () 用来判断urlprocessed表中是已有str_url所代表的URL, 有返回true, 没有返回false SQL Server 2008提供了全文索引的功能, 在数据库中建立全文索引的过程比较简单, 只需要按照相应的提示即可完成操作。全文索引也可以直接利用java代码实现, 在数据表urlprocessed中全文目录catalog_1上建立全文索引。 4.3 搜索的实现 搜索的功能是基于JSP的技术和tomcat服务器的技术上实现的, 用户通过index.jsp页面提交form表单, Indexservlet类获得用户的查询请求, 然后开始处理用户的查询请求。根据查询合不合法, 找没找到查询结果返回用户不同的页面。其处理过程如图7所示。 查询的处理用到了两个比较重要的类: (1) Indexservlet类 Indexservlet用于处理用户的查询请求, 根据判断用户的查询请求是否合法, 由此返回给用户不同的处理界面。Indexservlet中包含对用户查询的各种处理, 包括滤掉那些对查询没有帮助的字符, 对于较长的查询请求进行截断。 (2) Test1类 调取result.jsp, 实际上result.jsp调用了类Test1的一个实例。如果这个索引数据库中查找到匹配的结果, 那么就对结果进行排序, 处理后返回给用户正常的查询结果界面。如果没有找到任何结果, 那么就返回给用户notfind.jsp。 get_result () 函数用于在索引数据库中进行全文索引, 搜索包含str代表的字符串的URL, 搜索的同时对结果进行排名。 5 结语 本系统的实现使用了htmlparser和数据库结合使用的方式, 本系统还存在着在对搜索引擎的数据结构和数据库进行优化处理, 从而让数据库中可以准确而高效的存储网页文档和检索用户索引的信息、采用更合理的数据库更新机制等方面可以进行进一步研究和探讨。 摘要：网络搜索引擎是指自动地从网络搜集信息, 经过处理后提供给用户查询的系统。设计了一个网络自动搜索引擎, 给出了系统的设计框架和各组成模块之间的关系, 从系统代码实现的角度详细说明了实现思路和方案, 并基于htmlparser开源工具包和SQL Server 2008数据库实现了该网络搜索系统。 关键词：网络搜索引擎,网络爬虫,全文索引,htmlparser 参考文献 [1]张艳琼.基于Web Service的工业控制系统研究[J].微计算机信息, 2008, 08 (3) :58-63. [2]陈会果.数据挖掘技术浅析[J].科技创业月刊, 2010, 23 (11) :167-168. [3]熊筱晶.R语言在PubMed数据库文献检索方面的应用[J].医学信息:上旬刊, 2009, 22 (1) :42-45. [4]欧荣.PubMed, ISI-Medline, Google Scholar检索性能对比测评[J].医学信息学杂志, 2009, 30 (12) :37-40. [5]何蛟, 崔雷, 侯跃芳.面向主题词/副主题词的PubMed数据挖掘软件[J].中华医学图书情报杂志, 2005, 14 (1) :49-51. [6]许丹, 朱斐.从PubMed数据库中挖掘生物医学中的十大热点话题[J].计算机与现代化, 2013, 1 (209) :192-195 [7]车敦仁.周立柱.王令赤.面向对象数据库系统的体系结构[J], 软件学报, 1995年10期, 599-606 [8]潘定;沈钧毅.数据仓库中实时元数据管理的研究[J], 计算机工程, 2000年05期, 29-31 用过多个CQA站点中搜索引擎的用户会发现,同一个问题,各CQA站点的搜索引擎返回的搜索结果不尽相同,有的甚至有很大差异。已有学者对google、百度等中外通用搜索引擎搜索结果的重合率进行了研究,得出重合率很低的结论[7,8],这为元搜索引擎的发展提供了依据。我们对百度知道、搜搜问问、雅虎知识堂、爱问知识人等4个主要中文CQA站点搜索引擎检索结果重合情况进行了研究,同样得出重合率很低的结论[9],因此,针对CQA站点的元搜索引擎是有必要的。我们设计并实现了一个针对CQA站点的元搜索引擎,具有的功能有:可以按句子或关键字检索;如果有匹配的结果直接显示其内容,否则显示最相关的前10个结果。该文介绍了实现该系统的关键技术,并通过实验对该系统的有效性做了验证。 1 元搜索引擎的工作原理 元搜索引擎可以看作建立在搜索引擎之上的搜索引擎,它相当于一个搜索代理,用户提交查询后,元搜索引擎根据预置的规则,将查询发送到其它搜索引擎上,将各搜索引擎返回的结果汇集处理、排序后呈现给用户,用户得到的是处理过的来自多个搜索引擎的搜索结果。 如图1所示,元搜索引擎的工作过程如下:1)接收用户的查询请求q;2)将q的字符格式转换成各搜索引擎要求的格式;3)将转换后的查询qi发送到这些搜索引擎i,并接收搜索结果集Ri,i=1..n;4)处理搜索结果集Ri,如转换格式、消重、排序等,得到最终结果集R;5)将R做为查询q的结果输出给用户。 2 关键技术及实现 由上面工作过程可知,一个CQA元搜索引擎应具有的功能包括:接收用户提交的查询请求;转发查询请求;接收搜索结果;汇总处理搜索结果并输出给查询用户。其中的关键技术在结果的处理上,具体可分为信息提取、分词和相关度排序三部分。下面详细介绍其具体实现方法及程序代码。 2.1 信息提取 各搜索引擎的检索结果是以网页的形式返回的,网页信息的抽取方法可分为4类:基于网页结构的方法、基于模板的方法、基于可视化分块的方法和基于规则表达式的方法。由于网页内容、形式各不相同,上述各方法均不具有通用性,不能精确抽取网页信息。针对搜索引擎返回结果这一特殊情景,返回结果页面形式固定、格式规范,可用正则表达式进行快速、精确抽取。页面内容分三各层次:结果列表、结果、结果中主题,该文的元搜索引擎只考虑结果主题,需要用正则表达式精确抽取主题。 结果列表、结果、主题具有包含关系,要取得主题,需要依次进行结果列表、结果、主题提取,对每个搜索引擎返回的结果,根据其页面特征,设计了三个正则表达式,分别抽取结果列表、结果、主题,正则表达式存为配置文件,当页面形式改变时重新设计正则表达式,无需改程序代码。 配置文件格式: 抽取信息的Perl语言程序代码(去除了字符集转换、异常处理代码)如下,字符变量$wholestr中保存的是抓取的整个网页内容,提取的主题项及对应的链接分别保存在字符数组$result[]和$url[]中。 2.2 分词 实用性较好的分词方法有基于词典的方法和基于统计的方法。因为CQA站点的搜索查询中常会有新词、简称、缩写、商品名称、型号等内容,这些都是词典里少有的,基于词典的方法不适合本应用。我们采用的是基于统计的N_gram方法,这里N选2。2_gram的基本方法是以2个字为单位重叠组词,如字符串“3G手机上网速度快吗”会切分为“3G手、手机、机上、上网、网速、速度、度快、快吗”。 分词函数代码如下,substr函数用于切词,哈希表$atoken中保存的是被切字符串中的词项及出现频数。 2.3 相关度排序 搜索结果的相关度排序方法有多种,根据CQA搜索引擎的特点,返回结果的第一页是与查询相关度最高的,我们只取第一页的内容进行排序。我们的排序方法是:在返回结果中搜索是否有与查询完全匹配的标题项,如果有则直接将标题对应的答案内容取回作为查询结果发送给用户;否则对结果按余弦相似度排序,将前10个结果返回给用户。算法描述如下: 其中t为词项数量,wi,j为rj中第i个词项的权重。wi,j计算公式为: ni,j为第i个词项的在rj中出现的频数,ni为第i个词项在所有元素中出现的频数,N为所有词项频数之和。 由于Perl语言具有强大的模式匹配及文本内容处理能力,Redhat Linux系统都带有Perl语言开发环境,无需额外安装,我们在Redhat Linux 9.0下用Perl语言实现了该系统。Web界面部分用PHP语言编写,用于从文本输入框中接收用户的查询请求,验证安全后再传递给后台的Perl程序。一个有匹配结果的查询如图2所示,没有匹配结果的查询如图3所示。 3 实验及结果 为了验证该元搜索引擎的效果,我们从网上随机选取了500个查询进行试验,方法如下。 将“吗、呢、啥、哪里、哪些、哪个、哪儿、哪去、哪样、咋样、怎样、如何、何时、时候、几点、哪天、哪年、哪个月、什么、谁、谁知道、谁有、谁是、谁说、谁清楚、谁明白、睡去、多少、为什么、为何”等中文常用疑问词作为关键词依次向google提交查询,将google返回结果的前20页保存下来,用正则表达式将这些网页中结果标题提取出来,人工对消重后剩余的5300多条逐项检查,去除了其中的不良信息和陈述句、删除各句子首尾的栏目名、作者名、网站名等无用文字,再次消重,从剩余的4000个标题中随机选取500个作为查询问句。将这500条问句依次向元搜索引擎提交,元搜索引擎将查询同时提交给百度知道(用zhidao表示)、腾讯搜搜问问(用soso表示)、雅虎知识堂(用yahoo表示)、新浪爱问(用iask表示),将它们返回结果的第一页分别保存下来,并提取结果标题,如果查询问句与某结果标题相同,则认为有一个匹配结果,该结果所属的搜索引擎匹配计数器加1。最终结果列于表1、表2。 该文中定义搜索引擎的查准率precision为有匹配结果的查询数与全部查询数的比值;根据上节的排序算法,元搜索引擎的查准率precision为: 其中n为CQA站点搜索引擎的个数,Qi为第i个搜索引擎中有匹配结果的查询集合,Q为全部查询的集合。 表1中,zhidao、soso、yahoo、iask列依次为百度知道、腾讯搜搜问问、雅虎知识堂、新浪爱问四个单一CQA站点搜索引擎的匹配数和查准率,Mzsy为搜索zhidao、soso、yahoo的元搜索引擎的匹配数和查准率、Mzsi为搜索zhidao、soso、iask的元搜索引擎的匹配数和查准率,以此类推,Mzsyi是搜索zhidao、soso、yahoo、iask的元搜索引擎的匹配数和查准率。表2是zhidao、soso、yahoo、iask任意两个组合的元搜索引擎的结果。从表1、表2中可以看出,元搜索引擎的查准率明显好于单一CQA搜索引擎,使用的CQA搜索引擎数量越多,查准率越高。 4 结束语 该文详细介绍了CQA元搜索引擎的工作原理和实现方法,实验表明元搜索引擎提高了查准率,元搜索引擎使用的CQA站点越多,查准率越高。针对CQA站点的元搜索引擎可以提高使用者的查询效率、缩短检索问题的时间,同时也能提高各CQA站点知识库的利用率。 摘要：基于社区的问答是近几年出现并流行的一种有效的信息搜寻网络应用。文章介绍了针对这种社区的元搜索引擎的工作原理,信息提取、分词、相关度排序等关键技术的实现方法,实验结果表明元搜索引擎提高了查准率。 关键词：搜索引擎,元搜索引擎,基于社区的问答 参考文献 [1]搜搜问问网[EB/OL].[2009-10-06].http://wenwen.soso.com. [2]JEON J,CROFT W B,LEE J H.Finding Semantically Similar Questions Based on Their Answers[C]//Salvador,Brazil:Proceedings of the28th annual international ACM SIGIR conference on Research and development in information retrieval,ACM,2005:617-618. [3]AGICHTEIN E,CASTILLO C,DONATO D,et al.Finding High-quality Content in Social Media[C]//Palo Alto,California,USA:Proceedings of the international conference on Web search and web data mining,CM,2008:183-194. [4]BIAN J,LIU Y D,AGICHTEIN E,et al.Finding the Right Facts in the Crowd:factoid question answering over social medie[C]//Proceeding of the17th international conference on World Wide Web.2008,Beijing,China:ACM,2008:467-476. [5]LIU Y D,BIAN J,AGICHTEIN E.Predicting Information Seeker Satisfaction in Community Question Answering[C]//Proceedings of the31st annual international ACM SIGIR conference on Research and development in information retrieval,2008.Singapore,Singapore:ACM,2008:483-490. [6]樊佳怡.图书馆虚拟参考咨询与互动问答咨询的比较与启示[J].图书馆研究与工作,2007(4):37-40. [7]SPINK A,JANSEN B J,BLAKELY C,et al.A Study of Results Overlap and Uniqueness among Major Web Xearch Engine[J].Information Processing and Management,2006,42(5):1379-1391. [8]王益明,刘菲.中文搜索引擎搜索结果重合率研究报告2007[R/OL].[2009-04-03].http://www.searchlab.com.cn/thesis.php. 随着因特网的迅猛发展, Web信息的增加, 用户要在信息海洋里查找信息, 就像大海捞针一样, 由此互联网搜索引擎应运而生。搜索引擎服务能成为最受欢迎的服务是因为它帮助用户在浩瀚的互联网快速的查找信息。搜索引擎提供导航服务己经成为互联网上非常重要的网络服务。 (二) Lucene内容介绍 1. Lucene技术分析 Apache Lucene是一个开放源程序的搜索引擎, 利用它可以轻易的为Java软件加入全文搜索功能。Lucene的最主要工作是替文件的每一个字作索引, 与传统的逐字比较相比, 索引让搜索的效率大大提高, Lucene提供一组解读、过滤、分析文件, 编排和使用索引的API, 它的优点除了高效和简单外, 使用者可以随时根据自己需要自订功能。 2. Lucene软件包的分析 Lucene软件包的发布形式是一个JAR文件, 下面我们分析一下这个JAR文件里面的主要的JAVA包。 org.apache.lucene.Document (文档结构包) :这个包提供了一些为封装要索引的文档所需要的类, 主要负责字段的管理, 比如Document, Field。 org.apache.lucene.Analysis (语言分析包) :这个包主要功能是对文档进行分词。 org.apache.lucene.Index (索引管理包) :这个包提供了一些类来协助创建索引以及对创建好的索引进行更新。 org.apache.lucene.Search (检索包) :这个包提供了对在建立好的索引上进行搜索所需要的类。 org.apache.lucene.queryParser (查询分析包) :实现查询关键词间的运算。 org.apache.lucene.Store (存储包) :进行底层的I/O操作。 org.apache.lueene.Util (工具包) :是一些公用使用类。 Lucene的模块结构图如图1所示: (三) 搜索引擎系统设计 1. 搜索引擎系统结构图 系统要在网页上通过网络爬虫将预先想检索的网站的信息抓取下来, 保存在网页数据, 接口建立索引库, 再然后用户在输入检索命令后, 系统可以读取索引, 返回相关的信息而展现结果。系统的总体结构如图2所示。 2. 网页抓取 网页的抓取是基于Heritrix来实现的。Heritrix可以从http://crawler.archive.org/downloads.html上进行下载。Heritrix是一个开源代码的多线程网络爬虫程序, 为了提高信息发现和更新的速度, 网络爬虫通常都采用分布式和并行计算技术。网络爬虫的任务是要尽可能多、尽可能快地搜集各种类型的新信息, 由于网上的信息更新速度很快, 网络爬虫还需要定期更新已经搜集过的旧信息, 以避免死链接和无效链接。Heritrix底层的核心代码采用Java语言编写, 最大的特色就是其强大的可扩展性。Heritrix默认的组件已经完成了爬虫线程调度和监控程序, 完全可胜任普通爬虫的抓取和分析任务, 除此之外, 它允许开发人员任意地选择和扩展其内部自带的各个组件并提供了丰富的API接口, 以方便系统开发人员进行二次开发, 实现特定的抓取逻辑。 在下载完Heritrix的完整开发包后, 解压到本地的一个目录下, 其中, Heritrix所用到的工具类库都存在lib目录下, heritrix.1.14.3.jar是Heritrix的Jar包。另外, 在Heritrix目录下有一个conf目录, 其中包含了一个很重要的文件:heritrix.properties, 其中配置了大量与Heritrix运行相关的参数, 这些参数主要配置了Heritrix运行时的一些默认工具类, WebUI的登陆名和密码。设置完登陆名和密码后, 就可运行Heritrix了。如图3为正确运行后, Heritrix的后台对服务器的8088端口进行了监听, 访问http://localhost:8088, 就可以打开Heritrix的WebUI。 想要更有效更快速的抓取网页内容, 就必须采用多线程。Heritrix中提供了一个标准线程池Toepool, 它用于管理所有的抓取线程。ToePool和ToeThread都位于org.archive.crawler.framework包中。 当有某个任务在抓取时, 可能希望人为的去除符合某种条件的URL链接, 使得其内容不会保存到本地。比如希望只对网页文件进行抓取, 除去相关的下载链接, 比如, 要去除所有的扩展名为.zip、.exe、.rar、.pdf和.doc的链接, 使得其内容不会保存到本地。可以通过FrontierScheduler, 并重写内部的schedule方法来达到需要。实现如下: 3. 建立索引 Lucene提供了非常简单的建立索引的方法, 只要能将要索引的文件转化成文本格式, Lucene就能为这些文档建立索引, 建立索引的过程可以通过三个步骤来实现。 第一步:将不同的数据源组织成一个Document类型的对象。 第二步:对要建立索引的数据对象进行分析。 第三步:按照Lucene的索引格式将数据写入索引文件。 Lucene的索引机制如图4示: 使用Lucene实现索引过程的算法如下: 4. 搜索的实现 Lucene的检索接口主要由QueryParser、IndexSearcher、Hits这3个类构成, QueryParser是查询解析器, 负责解析用户提交的查询关键字, 在新建一个解析器时需要指定要解析的域和使用什么语言分析器, 这里使用的语言分析器必须与索引库建立时使用的解析器相同, 否则查询结果不正确。Lucene的检索过程如图5示。 IndexSeareher是索引搜索器, 在实例化IndexSearcher时需要指定索引库所在的目录, IndexSearcher有一个search方法执行索引的检索, 这个方法接受Query作为参数, 返回Hits, Hists是一系列排好序的查询结果的集合, 集合的元素是Document。通过Document的get方法可以得到与这个文档对应网页的信息, 比如:网页标题, URL等。检索过程的算法如下所示: 5. 中文分析器 Lucene提供的中文分词器, 功能又太弱了, 所以迫切需要开发自己的中文分词器, 而开发适用的分词器是一项很有挑战的工作。由于Lucene提供了很好的扩展机制, 所以目前网上有大量的中文分词库, 都已经很成熟了, 可以直接拿来使用。 本文中分词器使用了基于Lucene的JE-Analysis-1.5.3中文分词组件。该组件免费安装使用传播, 无限制商业应用, 但暂不开源。其分词效率达到每秒30万字 (第一次分词需要1～2秒加载词典) 。 JE Analysis基本特点有: (1) 支持英文、数字、中文 (简体) 混合分词。 (2) 超过22万词的词库整理。 (3) 实现正向最大匹配算法。 (4) 支持分词粒度控制。 JE分析器还提供了很多功能, 例如它提供了设定分词粒度的参数, 即可以设定正向最大匹配的字数, 例如: 这段代码表示正向最大匹配到4个字时, 就不再尝试第5个字与前4个字是否能组成新词。例外, JE分词还提供了API, 可以添加新词, 例如: 其中的addWord方法可以像词库添加单个的词, 而addDictionary方法则可以从Reader中读取新词。 (四) 结束语 本文是对Lucene全文检索技术的一个初步探索, 具体在Lucene API基础上实现了一个小型的搜索引擎系统, 包括网络爬虫、索引器, 检索器、中文分析器等。系统基于Apache Lucene开源项目上进行设计开发。在开发该系统的过程中, 采用改进和扩展Apache Lucene的思想来指导开发, 有效的重用了系统的部分代码。这种软件开发思想符合软件工程中软件重用的思想。 摘要：随着因特网的迅猛发展, 搜索引擎提供导航服务己经成为互联网上非常重要的网络服务。利用Lucene开源全文本搜索技术框架建立全文检索系统, 设计实现了索引器、检索器、中文分析器等模块, 完成了一个基于Lucene的搜索引擎的应用, 改进后的基于Lucene的全文检索系统能更好地支持中文及更准确地提供给用户所需要的信息。 关键词：搜索引擎,网络爬虫,Lucene,Heritrix 参考文献 [1]钟凯磊.Lucene论述——构建自己的搜索引擎[J].大众商务 (投资版) , 2009, (30) :95-98. [2]郎小伟, 王申康.基于Lucene全文检索系统研究与开发[J].计算机工程, 2006, 32 (4) :94-99. [3]刘迁, 贾惠波.中文信息处理中自动分词技术的研究与展望[J].计算机工程与应用, 2006 (3) .搜索引擎实现 篇6
一种移动搜索引擎设计与实现 篇7
一个网络搜索引擎的设计与实现 篇8
搜索引擎实现 篇9
搜索引擎实现 篇10