对于TOB的分布式访问支持, 原来总是从分布的TOB实例出发考虑方案, 思路一直不够成熟.
今天突然获得灵感, 其实完全可以通过最近总结的 HBI (Hosting Based Interfacing) 思路去实现. 原始想法在 http://www.iteye.com/topic/34848 提出讨论过, 表面上扯得比较远, 不过用在 TOB 的分布式访问上, 就可以得到这样的结果方案:
分布式的架构中, TOB 实例运行于一个专门的JVM中, 实现一个 TOB Host 服务器程序, 对它来说是以嵌入方式启动TOB实例, 自己实现线程池, 然后侦听网络端口, 从网络接受 客户端应用 通过网络, 以XML为载体 传递来的命令对象, 并执行这些对象, 对象本身通过应用编写的代码, 决定处理逻辑和结果内容等等.
为了能在 TOB Host 上执行应用定义的对象, 随应用程序开发的 命令对象类, 它们编译出来的bytecode代码要部署到 TOB Host 上, 这个过程可以和部署J2EE Web应用类似. 或者更理想的, 也可能在客户端鉴权认证以后, 每连接由客户端提供 ClassLoader 的数据源, 类似 URLClassLoader 通过 HTTP/FTP 的 URL 加载远程代码的方式, 这样很方便开发时重编译后动态替换代码.
另外持久模型类也会需要进行部署, TOB本身已经支持重新编译后的动态代码替换, 只需再实现一个代码更新的检测/通知机制.
这样一个分布式的 TOB 系统, 就是一个JVM跑数据库实例, 然后多个客户端应用, 各自或者相互依赖的开发好自己的 持久模型类 和 请求命令类, 部署到 TOB Host 上, 之后应用程序执行时不是像传统关系数据库那样发送SQL获得返回结果集, 而是发送 可执行的命令对象 到TOB数据库实例上执行, 然后获得自己写的这些命令对象代码的执行结果.
这个架构至少可以有以下好处:
1. 设计开发这些 命令对象类 时, 就是认为在访问一个嵌入的TOB实例, 因而其实就是访问/操作一张内存中的 持久对象图, 结构清晰明了, 逻辑不带杂质.
2. 超级性能. 因为是在数据库端执行, 性能指标和存储过程是一个层次的, 而且因为是用Java而不是用带各种局限的 PL/SQL 之类的专有编程语言, 仔细编码以后很有可能比SP性能更高.
3. Java的丰富类库, 灵活性和健壮性, 全盘保留.
其实思路朝这个方向想以后, 再看看 WoW 的架构, 完全可以认为是运行在广大浏览器里的Applet客户端应用, 通过互联网连接去访问服务器上的TOB数据库实例, 它各个部分的代码量统计结果, 完全支持这个观点.
美国那边的合作伙伴已经动手开始开发Flash版本的WoW浏览器端界面, 在这个方向上, 以后很有可能会衍生出TOB的Flash客户端库.