|
|
|
|
读了《程序员》第7期之读者来信
发布时间:2005-08-26 00:00:00 作者:cservice 出处:goComDevCenter 语言:中文 阅读次数:1126次 |
| 在来信中读者质疑了两点：
1、黄柳青博士关于构件化编程是否真的解决了接口脆弱性问题或接口脆弱性问题确实存
在否。
2、EOS中XML数据总线的存在形态及作用域。
读后觉得此读者是作了深度思考的，一语道中EOS核心模型及作用域问题。
本人认为如下：
1、接口脆弱性问题是确实存在的，不但存在同一进程空间、同一编程语言或平台中，特
别明显存在于不同
进程空间及异构平台上。对于数据结构的描述，我们一直没有找到有效的元类型描述方
法（业界一直在致力于meta相关的研究），
所以在目前所有编程语言或平台上我们除了在接口中传递primitive参数被认为是健壮的
之外，一些自定义
的数据类型可以被认为是脆弱的；要命的还不是类型问题，由于我们要保证参数类型的
健壮性势必在参数的数
量上无法做到统一，接口间参数个数的需求变得无法预知，也直接导致接口的脆弱性增
大；在异构平台中此
种冲突越发激烈，平台间因描述的语法及语义不同使接口变得基本上无法耦合，除了定
义非常有效的协议和
规范（本人一直惊叹于TCP/IP协议簇的伟大）。Primeton构件化编程的首要是接口的统
一性，大家可以看
到实际到语言级别的调用接口时EOS采用的参数只有一个，那就是一棵DOM树（其实构件
间的接口参数也只有一棵DOM树）；
其一保证了参数个数的健壮性，其二参数类型的健壮性也得到了保证。树是一种非常复
杂的描述结构，它适
用于任何线性和非线性的数据结构描述，可实现定位、排序、增加、删除、移动等许多
原子操作；而XML是
一个工业化的标准，业界对它的支持已达到非常成熟的地步。至于XML本身的好处就不在
这里详谈，大家将以上
分析和XML的优势一结合就不难得出EOS采用XML作为接口描述的原因。
2、关于XML总线问题；大凡一谈到总线就总会想到其流动性，就在想总线至少存在一个
发射源和接收源，甚至
形而上的认为就像一河流一样，具有河流一样的自治能力（河流的自治能力基本上由万
有引力在起作用）。这里可能
是Primeton在名词解释上没有做好工作。XML总线在EOS中实际上更像一个共享内存区，
不过这个共享内存
区是有组织的、有纪律的，也是一棵DOM树；不过在EOS中存在几个这种的共享内存区：
RequestContext、
BizContext...之所以这样我想可能是因为名字空间问题和生命周期维护问题；总线在E
OS要解决的问题实质
是要实现一个异步的数据交换空间，做到所有需要数据的构件都可以唯一确定到总线上
去取，至于取什么那是程
序员的约定，而不需要受制于基于调用-返回阻塞式的数据交换方式，将数据交换问题由
M的平方复杂度，变为M
的复杂度，并极大的实现了进程内解耦。
抛个砖，不在于引玉。
|
|
| 声明：本栏目转载文字、造型、样式、图形及程序如有来自网络，版权归原作者或首发媒体所有，欢迎任何个人访问或者转载，若有作者及出处有误，请来信说明，我们将及时更正。 |
|
