其实这跟软件的发展历史是有很大的关系的，随着企业级应用系统的复杂度不断的提高，人们在探索软件的可重用性和提高开发效率的道路上又一次飞跃。
面向对象的开发模式解决的是企业应用复杂度到软件系统的转化的问题，而基于构件的开发我觉得就是人们解决可重用性上的一次飞跃。
它使得应用和技术的分离走入了我们的视野，从而发展出了容器和组件这两个相辅相成的软件概念。
可以说容器来解决技术问题，而组件来解决应用问题，这是一个好的设计思想，两者分离，两者独立发展，而两者又不可分割。
=============================================================基于构件的开发确确实实给解决可重用性带来了。。飞跃。，。也给开发者提出了新的要求。在系统的可扩展性方面，也是种有效的尝试。在设计容器组件系统结构时，为了利于系统的可扩展性组件开发，容器的设计成了核心也是难点。我感觉，为了使系统具有一定的可扩展性，这比设计组件的可重用性更具难度。类比J2EE，在J2EE服务器容器下，开发者完成一个个EJB的设计，对于可重用性方面，它无疑拥有了很好的容器支持，如何设计EJB自身的应用逻辑使其具备应用独立性和功能完整性成了关键。然而，对于一个实际应用，往往需要多个组件（或EJB）共同协调完成，这也带来了组件间如何处理耦合连接问题。
有点偏题了，不知所云。呵呵。
面向对象的开发模式解决的是企业应用复杂度到软件系统的转化的问题，而基于构件的开发我觉得就是人们解决可重用性上的一次飞跃。
它使得应用和技术的分离走入了我们的视野，从而发展出了容器和组件这两个相辅相成的软件概念。
可以说容器来解决技术问题，而组件来解决应用问题，这是一个好的设计思想，两者分离，两者独立发展，而两者又不可分割。
=============================================================基于构件的开发确确实实给解决可重用性带来了。。飞跃。，。也给开发者提出了新的要求。在系统的可扩展性方面，也是种有效的尝试。在设计容器组件系统结构时，为了利于系统的可扩展性组件开发，容器的设计成了核心也是难点。我感觉，为了使系统具有一定的可扩展性，这比设计组件的可重用性更具难度。类比J2EE，在J2EE服务器容器下，开发者完成一个个EJB的设计，对于可重用性方面，它无疑拥有了很好的容器支持，如何设计EJB自身的应用逻辑使其具备应用独立性和功能完整性成了关键。然而，对于一个实际应用，往往需要多个组件（或EJB）共同协调完成，这也带来了组件间如何处理耦合连接问题。
有点偏题了，不知所云。呵呵。
而在探索发展技术可重用性的道路上也产生了很多分支，同时也走了不少的弯路，组件体系结构的出现是一个亮点，但它不是银弹，我们还有很多很多的问题要解决，其中一部分问题不是技术本身的问题，还有很多非技术因素。
技术基础设施的搭建是容器体系的核心，但没有标准的支持，我想这种技术也无从发展，标准怎么来？
是要靠所有与这种技术相关的人来共同制定和维护的，sun想自己来统一这个标准，我觉得它的想法很好，同时也有了很好的市场竞争，我但个人觉得标准应该是开发的，应当由所有与其有关系的人来制定，这样的标准才是最符合大众要求的，不然的话就是只能想ejb那样，让人又爱又恨！