INI@HTTP通讯传输架构的介绍

介绍文章：什么是INI@HTTP通讯传输架构？
计算机世界网 文章:
http://www.ccw.com.cn/htm/center/net/02_4_9_17.asp (此链接因为服务错误而无法访问，所以自己另外上传了一份：http://szhaitao.blog.hexun.com/37197154_d.html)

不是有CORBA/COM+/DCOM...了吗？还要INI@HTTP...
0、不可否认，这些大公司、流行的东西，自然有它们的可取之处；
1、但是理论上说的很好的东西，具体实现起来才会发现有这样那样的问题和困难；
2、要利用好CORBA/COM+/DCOM...，你的公司、部门、团队必须有真正掌握它们的人，
而这样的人，不但工资高，更现实的问题也许是你根本找不到他们。
INI@HTTP架构就是确保：
你的公司、部门、团队可以立即动手，高效率地开发出
易于分发/配置、同时支持跨越Intranet/Internet的多层应用系统。

基本概念：

INI@HTTP通讯传输架构是一种新的应用架构，是我在对大量的Intranet、Internet应用的总结与比较之后得出的，并在此基础上衍生出一种新的应用模式：C/W应用模式（ThinClient/WebServer）。

INI@HTTP通讯传输架构，顾名思义，它是基于HTTP通讯协议之上的，以INI格式定义所传输的数据。（最近大为流行的SOAP，其核心就是基于HTTP通讯协议之上，以XML定义所传输的数据。INI与XML有异曲同工之处，只是更加简单直接，在编码、解码的实现上更是简单，大多数语言、工具均可以很轻易地实现。INI格式的具体介绍请参看后文）

C/W应用模式（ThinClient/WebServer），采用INI@HTTP通讯传输架构，以快速可视化开发工具构建应用前端，以高性能CGI（ISAPI@IIS或FastCGI@Apache）应用作为应用后端，通过INI@HTTP通讯传输架构连接应用前端与应用后端，使得应用前端彻底与数据库等原始对象隔离，成为真正意义上的瘦客户端，同时，由于HTTP协议的Intranet、Internet无差别特性以及各类防火墙对于HTTP协议的兼容性，使得C/W应用模式具有非常广阔的应用前景，一旦完成一个C/W应用，即使应用环境在Intranet和Internet之间切换，应用系统无须做任何改动，对网络系统也没有任何设置要求。

C/W与B/W（Browser/WebServer）有一定的同构之处，其实，C/W就是为弥补B/W的不足而产生的。B/W模式中，作为应用前端的是通用浏览器，它的优点是通用、无须安装，各种硬件操作系统平台下都有自己的浏览器。但是浏览器作为一个应用容器，目前—甚至是相当长远的时期内—在操作的便易性、灵活性方面，尚有相当的不足。尤其是在客户主导的国内的应用领域，实际用户对于操作方面的要求往往较多，使用浏览器将无法很好地满足实际用户额外的需求。鉴于此，以快速可视化开发工具构建瘦应用前端替代B/W中的浏览器，是一种现实有效的折衷、平衡。实际上，C/W用到的INI数据封装格式，其实完全也是可以被浏览器的Javascript语言所使用，也就是说，要从C/W转到B/W，应用后端基本可以不用修改，甚至C/W、B/W同时使用一个应用后端！

采用INI格式，而不是二进制的结构数据或XML，完全是效率与灵活性之间的一种折衷、平衡。二进制的结构数据，应该是没有任何浪费的最高效率的数据定义模式，但是它对于协议的双方的限制也是最严格的，一旦一方升级、另一方也必须完全是同样的版本，否则就极可能出现字节错位、双方均无法识别对方的数据；XML则是最灵活的数据定义模式，但是它需要大量的额外描述词，在空间上有相当的浪费，而且，它的编码、解码相当复杂，难以自己实现，只有利用开发语言各自提供的现成的编码、解码，不同开发语言的可能会导致些微的格式差别，即使如此，在编码、解码的时间开销上也有相当的浪费。

INI格式的思路则是取自Windows应用程序的配置文件xxxxx.ini，它非常简单，既吸收的XML的灵活性，又保持简单、高效。其典型的形式如下：

……

[类别1]

变量1=值1.1

变量2=值1.2

…

变量n=值1.n

[类别2]

变量1=值2.1

变量2=值2.2

…

变量m=值2.m

……

如上示例不难看出，只要指明类别、变量，即可得到对应的值。无论是生成还是扫描这样的数据定义块，都是非常简单、高效的。

技术准备：

1、 服务器端：ISAPI(IIS)或FastCGI(Apache)

2、 客户端：HTTP发送/接受接口

3、 服务器端、客户端：INI格式的编码/解码接口

4、 服务器端、客户端：数据的加密/解密和压缩/解压缩（如果必要）

5、 数据集的二进制获取、传送、恢复技术（当服务器采用Win2000/Delphi时）

关于数据记录集封装实现的一些讨论：

目前考虑到的，主要有3种模式：

1	[table1] ;以“;”开头的行为说明信息，实际不会出现 FieldCount=5 ;数据集table1的字段数为5 ;以下描述了该数据集各字段的属性 F1.name=id F1.type=Int F1.size=4 F2.name=title F2.type=String F2.size=50 …… F5.name=note F5.type=String F5.size=200 RecordCount=320 ;数据集table1的记录数为320 ;以下为该数据集各字段的属性 1.1=2345 ;第1条记录的第1个字段的值 1.2=关于市场业务的通知 ;第1条记录的第2个字段的值 … 1.5=一周内落实 ;第1条记录的第5个字段的值 2.1=2346 ;第2条记录的第1个字段的值 2.2=开展促销活动的效益回报 ;第2条记录的第2个字段的值 … 2.5=送各部门负责人 ;第2条记录的第5个字段的值 …… …… 320.1=2701 ;第320的第1字段的值 320.2=关于市场业务的通知 ;第320的第2个字段的值 … 320.5=一周内落实 ;第320的第5字段的值
2	[table1] ;将1中的INI格式数据压缩、加密，以BASE64编码，得到一个大文本行 Data=大文本行 ;对方收到后，先解码、解密、解压缩，得到1中的INI格式数据， ;再进行访问
3	[table1] ;将Borland TDataSet格式的数据压缩、加密，以BASE64编码， ;得到一个大文本行 Data=大文本行 ;对方收到后，先解码、解密、解压缩，得到Borland TDataSet格式的数据， ;再进行访问

说明：

模式2、3，在效率上相对模式1有较大的提高；

模式3的跨平台能力有相当的限制：必须保证客户端与服务器端均为Borland Delphi/C++Bulder/Kylix一族的开发工具。如果两端或任何一端采用或可能移植到Java语言/环境时，本模式不适宜。

因此，数据集封装实现模式的选择，其实是一个非常具体的任务，必须在项目需求相对明确的前提下，才可以进行。

安全性的实现：

由于HTTP协议的上下文无关特性，任何B/W或C/W模式的应用，都离不开如何“以上下文无关的协议实现上下文有关的逻辑”的问题。如：正常的应用流程是“先用户登录，合法用户才可以进行内容访问操作”，而HTTP协议的上下文无关，使得用户登录与内容访问操作不存在必然的关系，即非法用户只要知道了内容访问操作的URL，也可以绕开用户登录而直接进入内容访问操作，这显然是一个很严重的安全漏洞！

笨拙的解决办法是：要求内容访问操作也附加用户合法性验证的信息，但是每次操作都附加用户合法性验证的信息，一则数据冗余，二则增加了不安全因素。

幸亏B/W模式的应用有了一个巧妙的通用解决措施：通过一次有效的SessionID。服务器维护一个“合法登录用户信息—随机码”的对照表，对于经过用户登录被验证为合法的用户，服务器生成一个随机码（可以是纯数字，也可以是字符串，只要足够长度以致非法用户难以伪造冒认），并将此随机码与该用户信息一起存入“合法登录用户信息—随机码”的对照表，同时将此随机码发给前端（浏览器），以后前端（浏览器）的内容访问操作必须附加这个随机码（而不是原本的用户合法性验证的信息）以供服务器验证，没有随机码或随机码不存在于“合法登录用户信息—随机码”对照表的请求被视为无效请求。“合法登录用户信息—随机码”对照表的内容，在对应用户显式退出或超过指定时间没有操作请求后，自动被服务器删除。

这样，即使某个有效的随机码被非法用户截获，那么这个非法用户也只能盗用一段时间，下一次就仍然会拒之门外。

这个解决措施在C/W模式上也是一样的。

新架构的优、缺点分析：

优点：

实现了业务逻辑的后移（相对于C/S模式）

保证了客户端是一个瘦客户端（相对于C/S模式）

保证了客户端的易操作性与功能强大的兼得（相对于B/W模式）

保证了客户端在物理上与生产环境隔离（相对于C/S模式）

保证了客户端在物理上与办公数据库隔离（相对于C/S模式）

当应用从Intranet搬移到Internet时，整套应用可以无需任何改动（相对于C/S模式）

缺点：

如果是简单的数据库应用，客户端的开发较难做到“摆放几个数据库相关控件就完成”，而需要相当的编码实现（相对于C/S模式）（如果是复杂的应用，C/W模式与C/S模式在开发客户端的工作量是相当的，而且远少于B/W模式为实现前端显示、操作而需要的工作量）

服务器端开发的工作量较大（相对于C/S模式）（与B/W模式在开发服务器端的工作量是相当的）

应用实例：电子商务公司 新版OA系统的架构

新版OA系统的架构即考虑采用上面介绍的INI@HTTP架构，现将OA系统的原有架构与新架构作一简要的图示比较：

例子需要iis才能让应用服务器（isapi）跑起来
只好简单介绍一下大致开发、运行方式：
1、简易模式（应用服务器就是一个通用的数据库网关，一次性开发、甚至无须开发，无限使用；sql/开发主要在client）
client直接发出sql，应用服务器只负责执行sql，返回查询到的记录集（如果需要返回的话）

2、正规模式（sql不会在client出现）
应用服务器就是一个项目专用的后台（需要与业务功能相应的开发工作量），client只负责发出：操作id+相应参数
应用服务器负责对操作id+相应参数组合为正确的sql并提交执行，返回查询到的记录集（如果需要返回的话）。操作id+相应参数 组合为 正确的sql，就是应用服务器所需要的开发工作，因项目业务不同而不同。

当然，应用服务器对于client提交的sql或操作id，都存在一个权限认证的工作，这个不专门说了。

client把返回的记录集转存到Tclientdataset/TkbmMemTable这样的内存表，再用于显示；用户需要修改哪些记录时，由client收集相应的参数，直接生成SQL（简易模式）或找出对应的操作id+相应参数（正规模式），后面就是应用服务器的事情了。