关于用 HBI 实现 TOB 分布式访问的灵感

对于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客户端库.

评论

2 楼 歆渊 2007-01-18  

firebody 写道

比较有意思，感觉。
不过这个办法可行还是有很多必须跨越的障碍，一些质疑也需要提出来

太好了! 还是有人可以讨论能碰撞出更多思想火花 ;-)

firebody 写道

1） 这个思想是为了解决什么问题而提出？ （目的？ 需求？ ）

想到这里比较偶然, 是看到Robbin关于 RoR/FastCGI vs Java/J2EE部署 的帖子, 然后是 pojo 的   元数据、开放数据模型及动态系统 的帖子, 然后突然想起来的.
不过最终的结果是为TOB想出了一个适当的分布式方案, 呵呵.

firebody 写道

2） 能够在服务端无障碍的运行客户端的代码，服务器需要提供和客户端完全一致的环境，也就意味着客户不能在客户段编写依赖客户环境的代码。

这个其实不是这样的, 在HBI最初的帖子里我提到, 接合的软件组件之间应该是对等的, 不过在这边也扯过来容易造成困扰, 所以没多提.
延伸开说是这样的: 对象传递是基于XML的, 客户端还是必需要用DBMS native的编程语言去写打算发送过去的命令对象, 然后在服务器端执行的命令对象也可以回传给客户端命令对象, 而这些回传的命令对象就是要用客户端的native编程语言来写了. 要点是两边都有从XML流构建本地可执行对象的能力.

firebody 写道

3）安全的挑战，服务器段可以运行客户端的代码，这个倒置似乎比较可怕。 如何检查客户的代码是安全的？

这确实是个严峻的问题, Java的Sandbox模型会有助于在一定程度上的解决, 生产运行环境里, 可以要求远程代码必需签名, 同时也许设一个Sandbox, 禁止一些危险操作. 这个跟开放一个J2EE容器允许公众部署war的情况差不多, 不可能完美, 也就到一定程度的控制吧.

firebody 写道

4)  bootrap ？ 虽然过程已经很好的期望了，但是似乎对于命令的启动，很少看到这一段的分析，更主要的是从客户端的角度来看这个调用分布式组件的过程如何设计？ 似乎这点更可能发展成为一个规范框架。

嗯, 确实往通用面上考虑, 这个甚至比CORBA还要复杂一点, 考虑异构环境下的标准执行环境规范.
具体实现不同语言/平台的接口库也是很大的工作量.

firebody 写道

说了这么多，其实还是从作者的思路想到了一些优点：

1）  除了ClassLoader的装载，第一传递数据，回传结果外，别的客户端和服务器端的通讯似乎就可以避免了，这在 一个理论的程度上，似乎可以很好的提高分布式应用的效率，似乎从执行的角度来看，不能算是分布式了。

是的, 这样就只在网络上传输处理后的结果数据, 而不用传输可能是很大量的处理前原始数据, 可以有效的节省通信量而提高整体效率.

这个倒是有鼓励把 业务逻辑 的计算压力推到 数据库服务器端 的倾向, 不过SP的性能总是最高的, 如果 多核大内存 的硬件架构发展顺利, 大趋势应该还是契合的.

说起ClassLoader装载的问题, 我还有点迷茫, 如果像FTP协议那样命令和数据开两个网络通道, 感觉不太舒服, 网上下载东西只要有HTTP链接我从来不用FTP, 感觉比HTTP响应慢不少, 应该跟这种设计不无关系. 但是class数据和通信数据如果全在一个通道里传输, 觉得也够challenging的... 不知道大家有什么更好的思路.

firebody 写道

2）对于服务提供来说，除了外围层的开发，内部服务的实现基本不需要二次开发了，因为和客户在本地开发无甚区别。

我也觉得HBI最大的好处, 就是省去了先 定义, 再 实现, 最后一直 维护 类似WSDL这些接口的烦人工作, 应用自己的逻辑自己负责, 只依赖于服务器端的大环境, 不用再分离的设计 服务逻辑 和 客户端逻辑 了.

1 楼 firebody 2007-01-17  

比较有意思，感觉。
不过这个办法可行还是有很多必须跨越的障碍，一些质疑也需要提出来

1） 这个思想是为了解决什么问题而提出？ （目的？ 需求？ ）
2） 能够在服务端无障碍的运行客户端的代码，服务器需要提供和客户端完全一致的环境，也就意味着客户不能在
     客户段编写依赖客户环境的代码。


3）安全的挑战，服务器段可以运行客户端的代码，这个倒置似乎比较可怕。 如何检查客户的代码是安全的？

4)  bootrap ？ 虽然过程已经很好的期望了，但是似乎对于命令的启动，很少看到这一段的分析，更主要的是从客户端的角度来看这个调用分布式组件的过程如何设计？ 似乎这点更可能发展成为一个规范框架。



说了这么多，其实还是从作者的思路想到了一些优点：

1）  除了ClassLoader的装载，第一传递数据，回传结果外，别的客户端和服务器端的通讯似乎就可以避免了，这在 一个理论的程度上，似乎可以很好的提高分布式应用的效率，似乎从执行的角度来看，不能算是分布式了。

2）对于服务提供来说，除了外围层的开发，内部服务的实现基本不需要二次开发了，因为和客户在本地开发无甚区别。