Topic: OpenUAP的过去,现在与未来

  Print this page

1.OpenUAP的过去,现在与未来 Copy to clipboard
Posted by: juweiping
Posted on: 2008-08-05 10:47

1,起因——面向构件的系统设计
自01年开始,我都在寻找如何让系统以构件方式搭建,如何以构件的方式装配成一个应用系统,经过很多尝试都没有结果。后来看到了Eclipse,以及JPF,觉得在J2EE领域可以通过插件模式来实现模块化设计。因此,结合了多年年来在J2EE领域内的开发经验,又结合当前流行的Spring,Hibernate(JDBC ORM),FreeMarker(Velocity)等框架,开发了面向插件的系统平台。
2,优势——模块化与分工协作
在这个平台下,一切都是以插件存在的,除了底层的运行时以外,因此要求系统被切分成模块,这也就符合了模块化设计的思想,每个模块可以开发成单独的插件或者子插件。这些插件之间可以在运行时内协作。更多的模块可以被陆续接入系统,而且可以做到互不影响,插件之间可以组合出不同的产品。
3,成功——实践出真知
这个平台不是实验室里的小玩具,而是可以被大规模使用的应用平台,而且经受住了实践的考验,证明其是可以应用在大型商业软件之中,可以适应多种复杂部署环境。
4,挑战——大象与蚂蚁
复杂度意味着对开发人员要求较高,意味着一定的成本,复杂也意味着有些笨拙,每次开发都要按照一定的规范,打包成插件才能发布,不想PHP一类的开发,随手就改,马上见效,这其实已经不是这个平台的缺陷了,是Java这类编译型语言的固有问题,当然,Java也引入了Groovy,JRuby,JPython等动态语言,如何在平台中支持动态语言也是个挑战,但是绝对有可能实现。此外JSP这类语言对类的装载运行时的严格要求导致了,除非对Web容器进行底层改造,否则没办法在插件模式中顺畅的使用JSP做为视图层。当然这也不是OpenUAP自己的问题,OSGi框架也存在这样的问题,OSGi是在底层上运行于Tomcat等容器的底层。我不想在规范来临之前动这个。
5,未来——OSGi?
这个基于简单的JPF插件的应用平台是有其目的的,因为OSGi是个规范,遵守这个规范就会有很多想法被限制,被规范所制约,所以在当前是对JPF做了自己的改造,所以才会引入很多有用的特性,各有利弊吧,但是面对的问题就是各个框架的Hack,如何让她们支持插件的类加载路径也费了不少周折,这些问题其实也是OSGi同样面对的问题,在相当长的时间内,这个问题也不会消除。

轻与重,自由与规范,这些都是选择,没有绝对的优劣,只是在特定环境下的选择罢了!


   Powered by Jute Powerful Forum® Version Jute 1.5.6 Ent
Copyright © 2002-2021 Cjsdn Team. All Righits Reserved. 闽ICP备05005120号-1
客服电话 18559299278    客服信箱 714923@qq.com    客服QQ 714923