大音希声、大象无形

对你前两条的要求不是很理解。

1、为什么要自己控制POM和MANIFEST两个文件呢？为什么不把所有的配置信息都放到POM里面，从而生成MANIFEST而要违背DRY法则呢？

2、我觉得把OSGi工程当作普通java工程来开发也不是什么不可以的事情。

一般说来，我觉得使用maven来开发OSGi程序还是很方便的。

Felix的Bundle插件可以自动计算出你需要import的包。这一点有的时候确实有点儿烦人（比如说，我要在我的bundle里面embed一个hibernate的jar，hibernate所有依赖的东西——JTA、DBDrivers、....所有的支持全都加到import配置中去了，实际上我只是想要hibernate中的几个类而已），而且我没有看到什么办法可以解决，我的方式是对jar做自定制，排除掉所有不用的包。

新的SCA（目前已经是OASIS的规范了）标准的实现应该就是基于OSGi的吧？

好久没有看这个方面，都有点儿生疏了。呵呵。

最主要是根据自己的需要做好IT规划。
至于是否需要什么技术，要根据情况决定，不应跟采取跟风、什么流行就用什么的态度。

@BlueDavy

开发人员通常在开发的过程中都不会愿意去学习另外一种思路的东西（他们的项目经理更不愿意）。

由于Web组件还是视图组件，它还要包括视图组件的灵活性和用户友好性。最后还要保证它的重用性。

要是开发企业级应用，还要保证组件的质量。

这些纠结在一块儿就成了JSF标准。

Brooks说过“没有银弹”，所谓的合理的设计不过是在综合各种方面后作出的最终的妥协方案。

技术本身无所谓好坏，要看它使用的场景。

我也非常推崇简单化、敏捷化。但是，简单和敏捷不是教条，过于追求复杂是不对的。同样，过于追求简单也是不对的。

@BlueDavy

controller可以薄，但是薄到用一个Hashtable来注册Sevlet，太儿戏了吧？整个应用连一个基本的Servlet对象缓存池都没有，怎么实现高可靠性和高可用性？集群支持怎么实现？更不用提复杂的Session处理了。目前的情况，做一个简单的客户端还可以，复杂的应用肯定吃不住。

我承认，Equinox的Http项目还是一个新的东西，还会有一条路要走。但是，现在就贸然使用，肯定是不明智的。至少，如果IBM的WebSphere是全面采用OSGI技术的话，用WebSphere的Http Bundle可能还会有一些价值。

我没说OSGI不好，我说的是就目前的Equinox的Http项目的现状，根本不适合拿它开发企业应用。只能适用于比较小的应用，或者Demo之类的。

Ruby确实有慢的问题，但是Rails对服务端的处理也不是那么草率的。目前为止，Rails是公认的进行小型Web开发的最好工具。如果真是开发需要RCP的小应用，不妨试试Rails + WebService + RCP的方式。那样，开发效率也是很高的。

说不定，以后真有可能会出现OSGI Server。这也是一个产品线啊。

值得继续关注。

OSGI的环境就是一个非常经典的SOA环境，把思路限制在O/R Mapping身上就错了。

完全可以采用别的方式，我举两个：

1、采用ActiveRecord模式，中间需要一个从Domain Object到Active Record的数据迁移。
2、采用AOP的模式，在持久化操作时给Domain Object mixin持久化操作。

有趣的是OSGI只知道你是Service，根本不会管你到底是什么。那么，就可以让脚本语言出马啦。

如果再结合Annotation，可以实现脚本动态交织，能达到的效果是不可想象的。更有趣的是，这样在理论上并不会比Hibernate的动态解析HQL然后生成SQL效率低。而且，我个人觉得用MixIn的方式更面向对象。

我现在就有这样作的打算，我的初步想法是通过JRuby和OSGI把ActiveRecord这种模式以Service的方式实现，有想法的话可以跟我讨论。
Mail: guitarpoet@gmail.com

@BlueDavy

恰恰相反，Equinox的HttpService的源代码我看过了。那么简单的设计根本就不可能处理大型的应用。

就它目前的状态来看，基于Equinox来开发应用，还不如直接去用Rails开发。

Java EE的标准在短时间内是不可能被替换的，无论是从对现有投资的方面考虑还是从各大公司技术支持的方面（还有技术接受程度和技术人员培训的方面）考虑。

除非，Java EE应用服务器全部放弃JMX而使用OSGI或者至少有至少两种以上的成熟的OSGI的应用服务器出现。否则，我还是认为与Spring结合才是OSGI进入企业级应用开发的最好道路。

EJB的一个主要的意图就是实现业务逻辑组件化（不管是实体Bean还是会话Bean），它的最大的优点就是对象生命周期容器管理和透明分布式调用。而OSGI就是实现组件化的一个非常好的实现，如果它能够融合Spring的对象生命周期管理的话，再结合WebService，我不觉得EJB还有存在的必要了。很明显EJB3中的实体Bean还是有一些作用的。但是，我个人觉得如果把O/R Mapping和ActiveRecord的方式融入到OSGI的Service中去，效果会更好（不但可以动态替换，还可以非侵入式拓展）。
当然，目前我也没太看出来怎样实现OSGI和Spring完美的结合。但是，如果它们能够实现结合，这肯定对EJB是一个非常大的打击。
呵呵，技术发展太慢或太快，受苦的都是底层技术人员。

OSGI和Spring结合以后，JavaEE还有多少生存空间呢？既然现在EJB容器都在采用OSGI技术，而OSGI的开发要比EJB简单一些。那么EJB作为一种标准还有多少价值呢？

看来，并没有什么短期内可预见的未来。

技术这样发展下去，未来将是混乱的，不光是在兼容性方面。

看来，企业级应用系统的开发远远没有达到成熟期，还有一段漫长的路要摸索啊。

哈哈

你并没有仔细的看我的评论。

在目前的OSGI R4标准里面，我提的几点问题好像并没有规范。

OSGi + Web Service确实是解决方案，但它不是标准。你也看过SCA的规范吧？它也使用Web Service，但是它把使用Web Service整合到规范中去了。规范本身是可以整合任何技术的。OSGI不是不支持远程Service调用，但是，说实话，我没在规范中看到具体的实现方式。

我可以负责任的说：在OSGI R4中“没有象Maven那样的透明化获取依赖的构件的‘标准’”（并不是说没有实现，而是说没有具体的标准）。

“标准里面的服务定义和发现功能太弱”不是我说的，是Eclipse的人说的。所以Eclipse才需要发明出自己的plugin.xml格式。Equinox也有自己的服务定义和发现方式。

OSGi作为一种技术确实是非常具有开创性的，正是这一点才如此吸引我。

但是，作为标准，尤其是实现SOA的架构的标准的话，尤其是跟SCA比，它还是有缺陷的。

我为什么要这么比？因为我觉得OSGI在基础上要比SCA扎实，你不觉得SCA的xml太多了吗？SCA还是静态部署的，而且对于依赖版本控制也束手无策。

我期待的是，OSGI的下一个版本能够成为一个比较完整的SOA标准，而不仅仅是一种动态加载的技术，呵呵。

在OSGI技术的使用上，我应该算是新手。所以，我希望能够跟你探讨在当前标准的基础上，怎么去在具体的工作中去使用它，获得它的优点，减少开发和维护的难度。呵呵。

OSGI的规范目前在SOA领域还不够完整，虽然OSGI能够解决工程依赖和版本控制黑洞，但是由于规范出发点不同，至少在两点上我认为还需要加强。

其一、标准里没有组件服务分布式调用
其二、标准里面的服务定义和发现功能太弱

所以，至少在目前的标准下，它不可能成为象SCA这种标准的SOA架构标准。

另外还有，它虽然有自己统一部署构件格式和相应的Repository，但是没有象Maven那样的透明化获取依赖的构件的标准。

说实话，我非常看好OSGI，它以一个非常完美的方式实现了模块化部署和构建的想法，如果能够在下一个版本里面把上述的缺陷处理掉的话，在SOA的重要性越来越强的背景下，有IBM和Eclipse的支持，它的前景是很令人乐观的。

目前来说，上述问题已经有人觉察到了，也分别实现了一些解决方案，但是，别忘了，它们都不是标准，在标准出台之前，要充分考虑这方面的投资。

至于怎么整合进现有的应用，我也正在考虑方案，可以讨论一下，呵呵。

@BlueDavy

项目经理的职责是跟你们公司的项目开发管理体制有关的。单纯的就这个定义而言，没有太多的可评价的东西。

一般说来，项目经理的职责是协调，尤其是在用户、销售部门、业务开发部门、技术支持部门之间对于项目的开发进行协调。

软件的质量问题，对于比较大的公司而言，是有专门的部门、专门的人员进行管理的，项目经理没有足够的发话权（一般说来，项目经理不宜兼顾QA，既是开发者，又是监督者，用户未必认可）。

是否是需求和开发分开来做（甚至是不同的人），还是采取XP的方式来做对于项目经理的要求是不同的。

团队协调不利肯定是项目经理的失职。但是，反过来想，也有可能是你们公司的开发规范和开发管理制度不够健全造成的。

@BlueDavy

Hibernate的二级缓存机制最好还是不要用，因为一个项目不可能保证所有的数据库访问全部交由Hibernate进行处理，而越过Hibernate 访问数据库的方式很容易就造成了Hibernate的缓存数据不一致的问题。

另外对于Hibernate的内置缓存是不支持集群的，即使采用oscache这种支持集群的Cache，你也会发现，由于缓存本身实现的特殊性，服务器端压力的增加是很多的，也就是说，如果使用不当，对服务器端是压力的增大而不是减少。

而使用得当的必须是对Hibernate熟悉的并且对JavaEE技术和服务端技术非常了解的开发人员，对于业务开发人员而言，这种要求过高了。

如同HttpSession的实现也是争论不休一样，Hibernate二级缓存能够给你带来的优点不多，但是给你的系统带来的隐患却不少，我的建议是，尽量不要用。只有在非常需要的情况下慎用。

如果你有项目开发的经验，那么你就会明白，其实系统的更多的瓶颈是在于基本的编程错误的设计和技术的错误使用方式，对于二级缓存这种只是需求频率不足10%的需要考虑的问题，大可在系统出现致命的瓶颈问题时再考虑

至于你说的处理缓存和页面缓存，他们的最应该出现的地方应该是，耗费资源的几乎不发生改变对象的构建（比如一些图形、PDF或者需要通过脚本解析、远程服务调用而获得的Java对象），这些东西由于构造它们非常耗费服务器资源，而重复构造更是服务器资源的浪费，那么缓存它们是必不可少的

但是，别忘了，对于缓存而言，集群内部同步和内部对象失效和刷新机制也不是什么好玩的东西。想当然的认为使用它就会减轻系统的负担的想法是不负责任的。必须在压力测试的前提下进行试验。

所以，我认为：除了耗费资源的几乎不发生改变对象之外，其他所有的缓存（尤其是Hibernate的查询缓存）都应该经过试验后慎用，最好是不用，只在出现性能瓶颈的时候通过AOP的形式加入进去，我认为Spring框架就比较推荐这种方式

相辅相成吧，在我的观点是一半对一半。

每一项技术之所以存在都是有它存在的理由的。

但是，技术是为客户的业务服务的，软件是面向服务的，开发企业级应用软件必须要体现软件的价值，而企业级应用软件的价值不在于技术，而在于客户价值的提升。

我忘了是谁说的了，“如果一个软件公司的软件功能不是由营销部门确定而是由技术部门确定的话，真是一件可悲的事情”。

技术是基础，不是目的

既然是JavaScript RIA，客户端的JavaScript的重要性也要体会出来，估计楼主看过Rails的AJAX方案，也许那是个比较好的方案。

但是我还是比较看重直接进行客户端JavaScript编程，只要实现了JavaScript的完善的包和引入机制（很遗憾，标准的JavaScript里面没有），那么客户端的编程完全可以采用JavaScript编程的方式进行开发，说句实话，这样子学习曲线不会比自己发明一套框架陡，组件和可重用性也不会差而且工作量较低可测试性也比较高。

我非常赞同非侵入式的动态HTML页面开发，说句不好听的，模板式的动态HTML（比如JSP）根本不适合JavaScript RIA程序的开发，不但组件写起来非常复杂，而且使用起来也是非常复杂，还跟容器密切相关，增加调试和测试的难度。

希望楼主能够细致的讲解一下具体的设计方案，尤其是在非侵入式动态HTML页面开发、怎么与业务逻辑层无缝结合还有怎么进行良好的开发和配置方便的服务端页面流和页面导航上（这一点Tapestry做的就很不错）。

至于页面风格的变化，CSS就已经很强了，还可以通过SiteMesh进行框架的修饰，这个方面应该是比较成熟的了。

得看你针对的是什么样子的用户。他们是怎么用系统的。如果你是给一个大的企业或者政府机关作系统，还会跟它们的内部政治因素有关。这个方面不是界面漂亮、反应迅速、操作方便能解决的。

另外，还跟最终使用用户的素质有关，总体来说，功能完全、反应迅速、操作方便是最重要的部分，至于漂亮不漂亮关乎他们领导的心情和审美，跟底层使用者关系没太多的关系。

@mixlee
有趣，有趣，我真心的希望大家能够看完整篇文章再下结论。

另，文中所说是我个人的想法，难免会有不足之处，希望各位高手不吝赐教。毕竟展现层的开发和设计不是我的专长。呵呵，在此先谢谢了。

我有一个问题，如果是采用velocity的模板技术生成JavaScript的话，JavaScript的调试是不是会非常费事呢？

我觉得采用AJAX的系统前端JavaScript的调试也是一个很重要的部分，如果采用模板生成JavaScript，那么调试JavaScript是不是会很费事呢？怎么解决这个问题呢？

目前我最推荐的方式是采用HTML模板技术（比如Tapestry），直接就可以在web容器外进行JavaScript调试

作学问切忌浮躁。楼主的想法是好的。只是行文中带了一些浮躁，看起来有点像牢骚。呵呵，若是能让看客幡然醒悟倒也是未必不是好文。

另，虽然没有看过你们的开源框架，对你们的奉献精神表示尊敬。

@fisher

其实我们的想法相似，只是表达方式上有所不同，呵呵。

很高兴能跟你讨论问题，软件工程作为一门学科，现在离真正的成熟期还远，在一定的时间内，概念的争论是免不了的。

我觉得，在这种条件下，要想真正意义上的进行企业级应用开发，必须脚踏实地的采用注重实效的方法。

而且软件开发还是要以人（客户、开发人员）为本的，不管采用什么概念、技术和实现方法。

很多人都喜欢拿企业级应用类比汽车产业，其实可比性没有想象中那么高，软件开发毕竟是一个概念上的东西，与现实中的物质相比，它跟人的思想和人分析问题解决问题的方法更近一些。

古希腊的时候，人就开始对自身的概念和思维的逻辑进行探讨，但是直到现在，还是没有什么有突破意义的结果。

软件开发更接近于哲学，这就是为什么编程高手一般都非常喜欢古典哲学。

其实，技术哲学也是哲学的一种啊。

计算机科学的发展，最后应该是跟人类的哲学的发展相互依存的。

马克思说的真他妈有道理。

不过你并没有真正的把Java的Proxy的概念用出来。
首先Broker不应该是Artist。
Broker只应该是InvocationHandler，Artist代理是Proxy的newProxyInstance方法自动构造出来的，Broker自己去找Artist（当然也可以采用IOC让Artist自己去找Broker），通过InvocationHandler的invoke方法截获Show方法，找适应的Artist去处理。
这个例子需要改进一下。

有趣，通俗易懂，符合面向对象的概念啊，哈哈哈

还好啦，我觉着用Maven2管理项目还是可以尝试的。Java的最大缺点就是Lisence千奇百怪，如果SUN的Lisence能够再“友善”一点、Maven2再成熟点，我想Maven2还是下一代的Java开发项目管理工具的。

@fisher

软件开发必须以人为本，但是所谓的“团队特色”是一个伪命题，团队中的人总会流失（升迁、跳槽、借调），总会有新的人加入，这是业内的常识。如果针对团队作出良好设计的人或是一个对各种技术十分精通的人被别的公司高薪翘走了，怎么办？

合格的软件公司都要有一定的应急机制，这也是对软件质量保证的手段之一。这样就不会因为某一个开发人员跳槽而造成手足无措的情况。

怎样才能 达到这一点？那就是有效的分层，有效的把损失局限在某一个范围内，就算是临时拿新人顶，他也可以迅速的接替流失人员的位置。

当然，Brooks说过：“无论怎样，项目肯定会延期”。但是要要尽最大可能的把损失降到最小。

太多的软件工程书不顾现实的情况了，完美的人是不存在的，技术全才一般是不愿意只做技术的（这个东西真是有趣啊），我们得面对现实。

分层开发的最重要的特征是层与层之间的松耦合。松耦合所带来的结果是，各层之间都可以有自己的基础模块，可以实现本层内部的重用，在底层发生变化的时候（变化协议、变化技术、甚至变化介质），上面的层是可以花费很小的成本进行适应的（比如操作系统和应用程序层）。

商业开发必须考虑开放成本，而有效的重用是降低成本的方法之一。

模块化开发，估计每家做企业级应用的公司都必然会采用这个方式。拿用电系统来说，客户服务模块和电费管理模块业务差距非常大，非业务专精人员，很难在短时间内写出高效和高质量的代码（光是业内常识就有的学的，而且各处业务还都不大相同）。

fanta的话是有问题的，对于不成熟的团队，如果没有成熟的技术框架进行支持和有能力的项目负责人进行管理的话，生产的软件产品质量和工期就没有办法得到有效的保证。

实际工作中不完全遵照低耦合的分层设计其最主要的原因就是现实情况要比理论要复杂一些，如果放在以前的话，真是不太可能。但是目前来看我觉得还是有希望的，在接下来的几天里，我就把我现在正在使用的技术设计方案贴上来。这样也可以对这一种方式是否真的合乎生产实践和能对软件开发成本的降低起作用进行一下探讨。