面向构件的开发一直以来被奉为软件业的银弹，可就像无数冲锋的战士一样，无数优秀的团队都被银弹所伤，软件不像 硬件的工厂线，没有银弹。甚至于连复用都因为人的因素而无法有效的实施。
所以，当我谈面向构件的开发时，不要认为我在谈什么银弹，不存在银弹！这种方法只能适合某种场合，而不是放之四海而皆准的真理。
当初，早在01年的时候，我就被构件化开发的银弹打晕，当时的J2EE基础设施简直就是折磨，我认为甚至偏离了方向，EJB被当做构件来使用，无疑加大了难度，也无法实现什么装配，或者说简直是一场闹剧。普元的EOS是有其创新性的，但是我不认为其有多大的价值，原因在于其技术实现的标准与主流格格不入，谁都不会冒着被套牢的危险去搞那个私有化的东西。什么IoC，ORM在哪里都变了样子。普元如果不是Sun，不是IBM，所以我不看好。当然做为一个平台中间件供应商，搞些专有领域的东西还是有其存在价值的，就像金蝶、用友，浪潮等都有其专有的平台。
后来我也不断的寻求如何实现程序模块化、插件化开发的途径，不为了别的，为了程序的模块化，可扩展化，分工的清晰化来讲，这个是很值得的，我的目标就是实现一个Web上的Eclipse，初期看了OSGi，觉得短期内不可行，因为其在短期内不可能被Web或者J2EE领域所消化，吸纳，中间总是隔着一层皮。因为原来的Web标准根本没有考虑这个插件的东西。当然可能在3-5年内J2EE的标准化工作会把其吸纳、消化，并被大厂商所推动的。可是我现在就要用，怎么办？06年初的时候看到了JPF(http://jpf.sourceforge.net)，觉得其很适合被改造来做为Web插件平台的基础。经过一段时间的摸索，终于成功的与Spring等主流框架整合，基本上达到了Web上的Eclipse的目标。
关于OpenUAP框架的细节目前正在整理之中，也会在不久进行开源，我想肯定有其应用的价值，大家认为呢？
