为什么选择SICS 3/6

5）AOP：支持基本的AOP

这里只好谦虚一点：因为SICS没有使用任何第三方工具（例如GCLIB之类），所以所有能提供的功能都受JAVA本身所提供的能力的限制。但是，对于一 般的应用而言，在SICS的编程模式下，其AOP支持足以解决常见的AOP应用的需求，包括：权限，日志，事务。当然，比较高的要求可能也是存在的，但是 我没遇到过--如果哪一天我接到一个项目提出了更高的要求以至于SICS目前提供的AOP能力无法实现并且切实属于AOP应用范畴，那么这样的能力肯定会 在这个项目期间被加入到SICS中。

6)AOP:原生会话支持,支持资源桌面

少不了也得扯虎皮做大旗:)

在SICS的编程体系中,其中心是资源和交换.所谓资源,就是由组件(系统成员)所提供的调用接口.组件间互相协作都是通过这个资源接口进行的.一个成员实现某些功能(接口),并将其作为资源统一向系统的资源交换机注册,然后其它的成员或者外部应用使用这个资源.

对于一个业务系统,其安全性和可靠性常常是一个重点.

(注: 安全性可以划分为很多层面,我们在这里仅讨论基本的权限认证方面的安全性,因为实际上这个才是业务逻辑真正关心的问题,也是程序员门的难题).

举一个企业级中心应用的例子,我所编写的企业应用服务交换平台为例.

在这个系统中,用户的登陆类型有以下几种:

1)基于浏览器登陆,直接登陆到交换平台的中心服务器,例如执行系统管理,查询共享服务目录树,直接调用其中的服务;

2)基于客户端的远程登陆,包括服务提供者端和服务调用者端,他们提供服务或者调用服务.

显然,这个时候权限控制非常重要(费话!),于是我们不得不建立类似这样的鉴权机制:

if(user.isAdmin()) then { 允许; } else { 不允许; }

大家可能立刻会想到:用会话可以解决这个问题!

但是,如何才能让会话贯彻这个系统?全部使用HTTP会话不可能,因为离开HTTP环境之后(例如客户端远程登陆),基本的HTTP会话就没用了!此外,在业务逻辑处理过程中,有时候会话可能也是没用的,例如在系统启动过程中的一些操作,因为会话根本就没建立!

这个不算复杂,因为实际上这个问题可以解决.所以,再来一个例子(可能需要一点专门性的知识才能明白),监控系统的,监控主机(DVR模式的):

监控主机通常要求操作员在本地登陆,操作界面根据登陆用户确定界面的表现类型,例如按钮是否可用等等;

同时,监控主体常常提供一个功能,即允许用户通过INTERNET在远程登陆,并且也允许获得一定的权限。在这样的本地/远程同时登陆的模式下，基本的会话机制完全失效！

“SICS源于工程实践”，这样的实践SICS肯定会经历到，于是SICS开始从系统的框架层着手，解决这个问题。（当然，肯定是解决了，否则我也不会在这里啰嗦了！）

其手法非常简单：

1）首先，SICS建立了这样的一个规则：所有的外部访问（线程）必须关联到一个会话，绝对不允许空会话（线程）进入应用内部；

2）其次，实际上，因为在系统启动时会话无法建立，所以SICS建立了第二个规则：仅允许元系统（即启动线程）不带会话，（当然，如果你愿意，也可用带会话。）换句话说：如果一个线程不带会话，那么就被认为是系统线程。

在这两个规则下，SICS使用AOP机制，建立了完整的分组会话和资源桌面，也就是解决了我们所讨论的问题！