O3P 思考

我的思考:

一些词汇在本文中的含义:

EJB: SUN SPECIFICATION 规定的Enterprise Java Bean, 文中基本是指Entity Bean, 特别是CMP Bean.
AOP: JBoss4.0 开发过程中所使用的面向方面的编程思想. Aspect Oriented Programming.
O3P: 我正在考虑中的一种解决企业级组件编程的方法学. Object Osmosis Oriented Programming. 面向对象渗透的程序设计.

眼下开发企业级的应用成为不少软件生产企业的重要目标, 更是被开发工具提供商所看好. 这源于历史上众多
IT精英人才的不懈奋斗, 在信息系统方面所积累下的宝贵经验和软件财产, 譬如海量数据存储, 关系数据库技术,
高性能的计算机设备制造方法, 事务处理, 安全机制等等, 这些都是非常有用而且来之不易的财富.

而IT技术如此迅速的发展和丰富, 同时也极大的激发了市场对这些热门技术的需求, 但是随着对各种技术的
大规模融合, 同时让开发者看到的是对精力和资源需求的指数曲线增长(我还没有统计数据来证明这一点, 但是
经验证明, 如果不采取新的集成技术, 增加了各种热门技术支持的应用, 相对传统的没有这些需求的应用而言,
其开发成本绝不止是线性的增长). 而且在IT目前如火如荼的发展中随时可能会有新的或者表现更优秀的技术出现.

如何把这些有用的技术应用到日常的应用开发中来, 无形之中已经成为大多数应用开发者和开发工具提供商所考虑
和笃行的任务. 毫无疑问, 面向对象的程序设计方法(OOP)和组件技术的应用, 在过去的很多年里已经帮助我们这些
人取得了极大的成功, 产生了诸多稳定运行的企业级信息系统, 为人类社会带来了更多的机遇和成就. 但是近一段
时间来, 我发现很多IT先锋的企业和个人, 已经不知不觉中开始意识到在规模和复杂性积累到现行程度后, 传统的
程序设计方法所感到的不适. 他们也因此做出了, 并且也正在做着不懈的努力, 来寻找更积极的解决方案. 实际上
他们努力的开始远远早于我意识到这一点的时候.

目前企业级应用开发所面临的最大的困扰, 可能正是想去融合他人的先进技术的复杂性. 我们都知道, 譬如数据库技术,
开发它在当前规模下的复杂和困难程度足以使得只有专业的企业和团队才有能力做到优秀, 我们根本无法设想自己的
团队能够通吃应用的各个方面而且还能够有效的开发出好用的东西, 这里面可能同时有技术和成本的因素, 总之这是
不现实的. 而使用别人的技术, 在目前的条件下必然意味着需要对该技术有相当的了解(当然不是技术的实现细节, 而是
它的使用方式), 然后在我们的程序中加入调用语句, 由对方提供的功能库来实现完整的技术方案. 但是基于商业的原因,
同一种技术常常存在着不少不相上下的提供者, 或者在不同方面和场合各有专长. 而对于不同的提供者来说, 他们所提供
的功能库的调用方式(更规范的讲是Application Programming Interface-API应用编程接口)常常很不一致, 在不同供应商
的专有(Native)接口之间移植往往是异常繁琐的事情, 除非万不得已, 它甚至也许会导致你的产品最后以失败告终.
在这个问题的解决上, 要非常感谢大的厂商联盟, 以及在决定性领域拥有决定权力的企业, 他们制订了相对统一的规范,
使得不同的提供商所提供的技术解决方案, 能够用相当一致或者类似的接口进行调用, 比如ODBC, JDBC, JMS. 这就使
应用开发领域又向前迈进了相当大的一步, 同时也给不同供应商注入了开发更优秀技术的竞争动力.

但是我们的IT英雄们没有停滞于此, 他们还在向前迈着关键性的步伐. --既然我们有办法开发出统一的接口, 那为什么不能
让所有有用的接口联合起来组成一个更为统一的前端(Facade)? 而且我们应该有办法使得对这些接口的利用成为一种简单易行
的过程, 把应用核心逻辑的开发者从不得不熟悉各种复杂的相关技术的困扰中解脱出来. --答案是: 他们这样做了, 并且正在
不懈的努力. 在我了解的事实中, J2EE规范, EJB1.1, EJB2.0, EJB3.0, 以及JBoss AOP, 正是这些先锋力量的出色成就.

不管是J2EE服务器还是JBoss应用服务器, 都在做着这样一个有意义的任务: 使得重要的企业级应用特性, 能够简单的
使用在特定企业应用的核心逻辑之上. 在这个过程中, 也就诞生了 `组件服务' 的概念. 即把存储,事务,安全,连接这样
本身复杂但是极为有用的功能特性, 以服务的形式提供给应用核心逻辑组件, 使核心逻辑能够尽量少的被增加这些特性的
工作所干预, 而是能够更专注于自己的逻辑实现.

待续...

下集预告(也是我的提纲, 呵呵):

O3P: 传统的程序设计方法中对其他组件(对象)的使用是通过现在可以叫做Plain Invocation(简单调用)的方式来实现的,
而O3P的思想中应该允许其他组件/方面以更灵活的方式多渠道对被渗透组件进行干预(Intercept), 可以称之为: 渗入(Osmosis)
传统的组件调用方式本身也是一种渗入的实现, 但是, 其区别在于, 组件调用的过程需要被渗入方主动请求与渗入方的交互,
非常明显的, 被渗入方是通过实现渗入方的`使用逻辑'来达到这个目的的, 也就是说, 调用方包含了相当程度的被调用方的
逻辑实现. 而在O3P的思想方式中, 这一部分`使用逻辑', 是由被调用方主动`渗入'到调用方的逻辑内部的, 调用方在很清楚
自己被进行了什么样的处理的同时, 并没有过多的介入怎么样进行这个处理的逻辑, 这就是O3P与传统方法的区别...

AOP: 如果说传统的对象调用思想处在编程方法中的这个极端的话, 那么AOP的起点无疑非常接近另一个极端, 即完全排除调用关系...

EJB: 我认为EJB的实现方式介于两个极端之间, 因为它试图把组件服务定义为一个标准的集合, 而不是一个可以任意开发的平台...

渗透/合金: 一个组件通过渗透自己的特性到另一个组件从而融合为一种类似`合金'的新的组件, 这个组件可能具有原来两个
组件都没有的特性, 当然也可能综合原来组件的原有特性. 但是就像合金工业一样, 除了通过实验, 结果是很难准确估计的...

可以认为`合金'组件代表了比原本元素组件更高一个层次的逻辑...

可扩展语言: 一种语言变得可扩展的条件: 1. 可以自定义修饰符 2.提供各种情况下的上下文中对修饰符的解释接口.