正向前一篇分析的，在全文检索、数据挖掘、推荐引擎的后台系统中，通常可以提供三种类型的服务：同步服务、异步服务、后台服务。对于同步服务可以采用Web Service、XML Over HTTP或Restful服务，我在项目中就采用了Jason over HTTP，主要考虑Javascript解析Json效率较高，但是还要看各人喜好。对于异步服务在实现上，如果选用Java做为编程语言，基本就需要选择JMS了。而后台服务主要是定时任务，可以采用新版JEE中的Timer服务，或直接使用Timer。
在JMS实现异步服务中，最简单的方法是采用消息驱动Bean来实现，但是JMS中有两种机制：一种是Queue，另一种是Topic，那么选哪种好呢？通常在需要松藕合系统中，由于业务逻辑非常复杂，需求集成多个系统及功能，而且系统及功能可能在运行时加入等原因，一般采用消息总线机制，如OpenESB。这种特性也是我的系统中所需要，但是引入重量级的ESB技术又是我所不愿意的，因此我选择了JMS Topic模式来实现消息驱动Bean。这样即使当系统上线后，要加入新功能，例如新用户注册时，需要将用户信用卡信息加入缓存中（原来只是将登录名密码加入到了缓存中），这时就可以动态部署一个新的消息驱动Bean，这样系统可以不进行任何修改加入新功能，实现类似消息总线机制。
为此，我在系统中建立了消息驱动Bean-MainMdb，用于监听jms/MainTopic这个Topic。
例如，当用户发布一条博客信息时，Web前端系统首先将该博客的信息存入数据库，然后会向jms/MainTopic发送一条消息，消息类别为博客添加，参数为博客编号。后台的消息驱动Bean收到该消息，在onMessage方法中，通过博客编号，找到博客的详细信息，然后将标题、标签、关键字、摘要、正文等文本信息建立全文检索索引，然后会计算文章分词后每个词在本篇博客中的出现频率以及与本博客的相关度（即TF/iDF，计算方法在本系列后续文章中会介绍到），建立术语向量空间，运行自动聚类算法，找出基于内容的相似博客，同时根据需要，可能还需要和用户进行自动聚类分析，找到可能喜欢这篇博客的用户。通常由于建立全文索引和进行基于内容的推荐引擎计算需要较长时间，如果采用同步服务，那么用户等待时间会比较长，用户体验不好，但是如果采用异步服务方式实现，可以立即向用户显示成功信息，耗时工作采用异步方式来完成。但是用户如果再进行下一步操作时，如进行全文检索，查看其他博客或其他用户等，由于已经过去了对系统来说足够长的时间，全文索引和基于内容的推荐运算已经完成，因此可以呈献出准实时的效果。
