对OpenMiner进行了一系列手术

         OpenMiner已经成为了sourceforge的approval项目。与此同时，我们也开始紧张地对OpenMiner进行了一系列的外科手术。我现在做的主要是服务器部分的裁剪，尽量把OpenMiner的核心做得更加简单，更加具有扩展性。而OpenMiner现在还没有可视化的客户端，另外一个同学grand现在也开始加紧赶制OpenMiner的客户端，我们的客户端打算仿造Yale。

首先的第一个手术就是减掉阑尾。  之前在给教务处做决策系统的时候，为了赶进度， OpenMiner 过于依赖了 Oracle 数据库，各种数据集的提取，以及挖掘模型的存取，都是基于 Oracle 的 JDBC 来访问的。而 Oracle 的 JDBC 特别是在处理 BLOB 数据块的时候，又和标准的 JDBC 不兼容，于是搞得代码很不具备通用性。现在的 OpenMiner ，不仅是需要对 ORACLE 的很好支持，同时还要能够对各个方面的数据集进行很好的访问，当然，训练数据集都是只读，也就是 OLAP 。作为一个数据分析，我希望设计处理的服务程序不仅能够从数据库中提取数据，还希望能够从各种文件格式 (excel, xml, 等 ) ，以及远程的 Socket 输入流来获取训练数据集。减掉了旧的 Oracle 处理模块后，需要新增加的就是一个比较齐全的输入数据抽象层了。采用设计模式中的抽象工厂 Abstract Factory 的方式来实现。这样，对于数据挖掘的算法模块来说，就只有一个 InputDataSet 输入数据集的接口，训练数据就只能从这里面来提取，根本不用去理会这个 InputDataSet 是一个什么样的数据来源和怎么样创建的。于是乎，文件数据，数据库数据， Socket 流输入数据，就能很好地统一到 InputDataSet 接口下了。

其次，关于使用挖掘模型的接口函数，统统从 Miner 类删除。因为如何使用一个挖掘完成的模型，是根据应用程序 Application 来决定的。如果 OpenMiner 来做，并不见得做得能用，而且，使用一个模型的方法千变万化， OpenMiner 做起来也麻烦，于是，最好的办法就是，不做，统统删除！

最后，我考虑将挖掘模型的存储访问管理，放在客户端来进行。原因很简单， OpenMiner 就只做 Data Mining 的工作，不做 Data Mining 以外的任何工作。这里所谓的客户端，并不一定就是用户实用的客户端，也可能是应用系统，只是从 OpenMiner 服务提供者来说的客户端的意思。如何管理挖掘模型 Model 这个问题，本身并不能轻率，因为现实企业应用系统中，可能挖掘模型数量成百上千，如此庞大的挖掘结果模型，一般的文件系统并不见得高效，而应该放在数据库的，针对各种数据库的访问，那么就成了一个问题。同时，挖掘模型也可能存在安全性的问题。要让 OpenMiner 去这样复杂的一项工作，很难做得好。既然做不好，最好的办法就是，不做，统统删除。

做了这些过后， OpenMiner 的核心服务器的手术基本上可以算完成了。剩下的就是客户端的事情了。我们现在的这个客户端功能很大，把以前本该是服务器做的模型管理的工作都移交到了客户端来做，于是 grand 现在也忙起来。关于客户端的开发，我推荐使用 NetBeans 5.5RC1 来开发。因为 Eclipse 的 VE 插件做得太老火了，经常出问题，而且又慢又兼容性也不好（ 3.1 和 3.2 的 VE 都不兼容）。而 NetBeans 本身就自带了可视化的界面开发功能，速度和稳定性都比 Eclipse 那种外部插件的好。虽然 Eclipse 一度成为 IDE 的典范，但是 SUN 的新秀 NetBeans 也有它不错的有点。随便说一下， NetBeans 也是免费开源的，可以随便下载。