
依据我们以往针对跨区域硬件控制的管理项目的开发经验(上大技防系统,二工大门禁系统),我做了两个图,一个是硬件及网络布局图,一个是程序基本原理流程图。
图一:硬件及网络布局图
图一:程序框架图
以上的网络和硬件架构只是为了更好的理解,通常在实施过程中web服务器,数据库服务器和通信及线程服务器,包括后面要和他们做的课表数据交互的xml服务器都可以合并到一台服务器上,web用户并发量不大的话,足够使用了,这样可大大控制成本。
这个方案的核心就在web管理和Socket通信分开,游工你们之前做的一套web管理平台应该是web程序(或者简单的说就是网页)直接和底下的中控进行Socket通信的,这也是你昨天跟我解释的为什么web程序要作为clientSocket的原因。其实这种方式是可选的之一,在5年前,我们打造上大安防系统的时候,客户的需求和你们现在是一摸一样的,既要能对终端的硬件(门禁控制器,摄像头)进行控制,同时又要很好的满足管理功能。我们当时做的第一个尝试就是通过web直接控制底下的硬件,也是走你们现在的方式。但测试下来问题太多,第一个问题就是架构的问题,管理程序作为clinet端去主动寻找底下的控制器,要知道底下的控制器的硬件处理能力是远远赶不上pc服务器的,同时短连接的socket既不能很好的维护连接也不能作状态信息的实时推送,这种方式的弊端在底下硬件控制器成倍增加后越发显现出来;第二就是web程序是基于IIS服务器的应用,他的优势在于众多的数据库管理系统的应用而并不是对硬件的控制同时对socket的支持没有类似vc等开发语言稳定和高效。所以最终我们采用了另外一个方案,就是web结合服务线程的模式,简单的说就是web用来管理基本的命令请求,但不直接和硬件进行通信,当web发送控制命令时是先给服务线程发去请求的,由用vc开发的服务线程再实时的和底层的控制终端进行通信,同样的道理,终端的状态信息也是先推送到服务线程,再由服务线程转发给web。而服务线程程序是一套用vc开发的服务器程序,这套程序服务作ServerSocket ,同时开辟多个服务线程负责完成web的请求和状态信息的推送,对于最终的用户来说他们通过web程序发出的命令对他们来说是透明的。而web和服务线程的实时信息交互是通过数据库做桥。
