SICS的起源

在多年以前，因为一个偶然的机会，我参与了所在公司一个项目，并对这个项目中所使用的通讯报文的格式非常欣赏，认为这样的格式具有很好的通用性。后来在回到公司后，因为公司中的一个项目的需求，在这个项目的领导者的提议下，我使用这样的通讯报文格式建立了一个简单的 TCP/TP 的通用请求 / 处理程序。因为报文的高度适应性，这个程序有了一些基本的扩展性，可以称为一个非常小型的框架。

这个程序是用 JAVA 编写的，包括一个协议解释器，一个调用分配器，一个用户对象存储，一个功能容器，使用一个 Properties 文件作为配置管理。一共由 14 个类文件构成，总长度大约 3~4 千行。那个时候，它叫 DataRoad ，数据链路。

最初，这个小程序只是在那个项目中使用。在使用过程中，项目提出了一些更加高级的扩展需求，我就根据这些需求不断对功能容器部分进行增强，于是系统的体系结构迅速膨胀。到后来，已经明显的形成了这样的局面：原先作为程序主体的协议解释器已经变成了程序的一个分支功能。

一年之后，我参与了公司在外地的一个项目，这个项目使得这样的局面更加明显。于是，我在这个项目开始的阶段，用了近三周时间，重新编写了这个程序，以适应这样的一种应用格局：在一个系统范围内，必须能同时支持客户端调用和 WEB 的 HTTP 调用。那个时候， SERVLET 规范才是 1.1 版的， API 非常简单。所以，我也很容易的就为这个程序编写并建立了一个基本的 HTTP 服务，以支持 SERVLET 。同时，我还为这个程序配上了一个基本的管理界面，采用 SWING 编写的全图形界面。也就是在这个版本中， SICS 的基本编程思想被初步建立。我给这个版本程序命名为 NetCenter 。

在随后的两年里， NetCenter 作为一个可选的应用框架，在一些项目中被使用。但是自身的功能却几乎没有什么太大的变化。

后来， 2003 年 3 月，我离开了原先工作的公司。从此也没再管这个程序在原来的这个公司的发展或者保持的情况。

2005 年 5 月，我开始开发 SICS 的 第一个正式版本。那个时候，我已经是一个完完整整的无业游民：没有稳定工作，没有固定收入，基本上是靠接一些小项目挣钱维持生活。在承接和编写这些小项目 的日子了，为了能更快更好的完成项目，我也编写了一些小工具（这么说也许不恰当，因为有的工具实际上规模非常可观，例如 InfoBase ，程序长达 6 万多行）。一边做项目，一边做工具的日子是非常辛苦的，而且因为收入不稳定，日子更加艰难。

但是这却几乎是我的一段快乐时光：在这期间， SICS 的编程思想逐渐定型，我对应用系统的构成和协作机制的理解有了一个质的飞跃！

在所有的希望都落空的情况下，我开始编写自己的 SICS 的第一个正式版本，并寄希望于能通过这个程序为自己带来面包！

总的来说，我打字的速度是非常快的，再加上经历了那么多的项目的锻炼，经验和技术应该可以说是炉火纯青吧！所以程序很快得以编写完成（大约 3 个月）。程序版本被正式命名为 SICS/SysFrame 。

在这个版本中，我建立了完整的系统构成规范，运行控制规范，并且配备了两个基本的扩展服务： LightRpc— 轻型远程过程访问和对象调用服务； MiniHttp— 小型 WEB 访问服务。

但是，这个程序并没有如愿的为我带来面包，虽然我也设法联系了一些可能的买家，但是：想让国人为一个应用框架掏钱，那只能是梦想！

在无可奈何的情况下，因为一些原因，我到了一个朋友的公司，以他们的市场为原形，我开始编写监控系统。那是我第一次接触监控系统。因为市场时间的原因，我选择了使用 JAVA 作为监控系统的开发语言，以希望能够尽快的完成任务。还是一句话：为了面包，我努力工作！

但是，至少在当时的情况来看，我的这份努力因为这句话被否定了：没有人用 JAVA 开发监控系统，因为速度太慢！尽管我也一再解释： JAVA 只是用于界面和控制，底层运行的实际上依然是 C/C++ 。但是最后还是走路了事！

但是我还得生存啊！于是我又找了家公司，做市场技术支持！但是很显然我不是那块料！于是一个多月后，我又只有离开的份！怎一个“惨”字了得！

痛定之后，我开始重新规划自己的发展方向：做工具赚不来钱，那就做应用吧！做市场做不好，那就专心做技术 — 技术性应用！

我选择继续编写视频监控系统，依然用 JAVA ，时间已经是 2006 年了。

实际上，我们大家对监控行业有了解的人都知道，视频监控市场几乎已经做烂了：十几个镜头，加一个计算机主机，才 8~9 千大洋！至少低端市场，已经不值得我去努力了。于是，我把市场瞄准在高端大型复杂监控领域。

对于我个人来说，是不需要什么计划或者市场调查之类的琐事的，想到了就干！

于是一个复杂的应用体系开始象一个神话似的慢慢建立起来了！说它象神话，是我个人的感觉：以我 10 多年的编程经验，甚至在有了 SICS 这样的完全为工程应用为目标的框架的支持下，编写过程依然磕磕跘跘！

1）  因为我没有自己的硬件，只能选择和硬件厂商合作，所以框架必须能支持所有的硬件（至少在理论上要建立这样的支持接口）；

2）  因为要面向的是复杂应用领域，功能的扩展性可能包罗万象，所以必须建立一个稳定可靠而且非常灵活的功能性扩展机制；

3）  因为监控的应用和实施方式各种各样，系统必须能灵活适应所有这些已知的应用模式，所以其规模的伸缩性要求肯定也是一个关键。

这样的应用需求，导致了我对 SICS 系统框架本身的大幅度的修改！最终，在 2007 年 8 月， SICS 最终被再次彻底重写！

再往后，还有其它的一些项目，对 SICS 的功能的发展也有着重要的影响，包括促使 SICS 的核心层建立对 AOP 的直接支持

改动的细节，列出来可能得十几页，不列也罢，反正很大就是！几个关键点我需要提一下：

1）  MiniHttp 彻底抛弃了对所谓 SERVLET 规范的支持，轻装上阵了；

2）  LightRpc 实现了完整的远程回调和远程事件的直接支持；

3 ）建立了基本的 AOP 支持，建立了资源桌面的机制，建立了完整的分组会话支持。