【结构】
这种架构模型，是一种由 APP/ SERVICE / SESSION 组合而成的架构模型，一般缩写为 ASS。（这个缩写比较有意思~~）
APP 就是服务应用程序的一个代理，它接管应用程序的控制权（就是在MAIN或者WINMAIN里面直接进入一个APP的内部循环，直到程序结束才返回），并在内部进行初始化和结束的收尾工作，并管理所有的SERVICE。
SERVICE 就是服务，它负责管理一个服务，和它下属的所有SESSION(会话)，在TCP协议下，它就是一个监听器对象，在一个端口上提供服务。
SESSION 就是会话，它负责维持一个和外部呼叫者之间的会话。在TCP协议下，它就是一个连接对象，用来和一个外部的用户进行通信。
从整体上看，是APP管理着一群SERVICE，然后SERVICE管理着一群SESSION 的这样一种树状，金字塔状，食物链状的框架结构。
【工作方式】
当一个使用ASS架构的服务器应用程序启动的时候，首先进行APP的初始化，在这里面，用户（服务应用编写者）可以（需要）将这个服务器应用所用到的所有服务开启，并进行一些设定的读取，和对象的创建。
初始化完成之后，SERVICE都被启动起来之后，APP进入一个服务器心跳的循环里，并驱动在它管辖之下的所有SERVICE的心跳。
而此时，所有的SERVICE都在各自的服务上进行监听，当获得一个外部连入时，就创建一个SESSION，并管理起来。
而SESSION从连入开始的时候被创建，一直生存到外部连入结束为止。
【优点】
分级式的架构方式，易于管理，方便扩展，且相当灵活。
让本来杂乱无章的服务器应用，变的井井有条起来。
【历史】
这个架构最初源于我的一次服务器网络底层的重构。因为项目里面的一个服务器应用需要在两个端口上进行不同的服务监听，而之前的网络底层只能在一个应用里面创建一个监听，应用受到了一定的限制，于是我设计了最初的分级模型，一直发展到今天，SESSION从最初的CLIENTSHADOW到后来的CONNECTION，最终定为SESSION，这个历程也反映了我对“会话”这个概念的不断重新认识。而SERVICE则一直是叫做SERVICE，因为它的含义足够清晰。APP一直没有找到合适的词语，索性就用APP来称呼算了。然后就出现了这个有趣的ASS缩写。
【产品】
现在，我用这种模型构建了一套服务器引擎的组件，叫做“X Server Engine”。其实就是将APP, SERVICE, SESSION的主要部分和事件部分剥离开，互相使用C++的纯虚接口进行通信。把网络框架和网络底层封装在一个动态链接库里面，只导出框架接口，从而实现应用代码和底层代码的分离。通过一些简单的接口派生，就可以创建强大的服务器应用了。这套组件的代码，会在合适的时候公开出来，现在里面还是一团糟啊= =。这个组件是分为三个平台，WINNT( NT4.0以上IOCP支持)，LINUX(EPOLL支持)，FREEBSD(KQUEUE)，每个平台上使用效率最高的网络底层，而外部接口则是完全一致，基本实现一处编写，处处编译^_^。
【附图】
蓝色线表示客户端主动连接，通过Service的Port Listener在Service内建立起Session。
红色线表示Service内部的一个Session主动连接到外部的服务器。
但是在Service内部，所有已经建立连接的Session都进行相同的处理。
