请教关于构件化动态组合开发的思路．

这实际上是我之前提出的“组件彻底可配置化”，也就是说：应用系统的每个组件或者类都是通过配置实现装配运行，当然，这首先需要一个Ioc或者依赖注射DI容器，也就是类或组件之间实现最大松耦合分离。

只有具体类是可配置的，然后我们可以认为任意划分归类，划分子系统，今天将ABC三个类归为1号系统，明天我可能将AHJK三个类归为1号系统，不同系统协调工作也简单。

对于你这个案例，如果你的ABC这几个系统不是建立在DI模式上，那么就只能采取传统方式进行硬的弥补。

两个系统协调工作不外乎数据库共享和系统之间通讯，数据库共享不用说，是最简单，系统通讯一般用JMS，JMS是可以将两个系统实现最大程度的松耦合，当然，使用JMS不可能让几个系统天衣无缝运行一起，这到底属于弥补，而不是融合。

总之一句话：要实现你构件化动态组合，必须前提都是将这些构件最大松耦合，而Ioc/DI是目前主流选择。

从你这个案例，也可以看出，我们什么现在Ioc/DI轻量框架会成为主流，其最重要的核心就是实现了构件的彻底可配置，完全可定制，进而才有根据需要动态组合这样高境界设计事情发生。

首先感谢 banq 的热心回复.
我也是前几天开始接触JAVA,以前有关注过.但对于设计模式、IOC等这些概念还是有的.对于java实在比较陌生，最近一直有浏览这个网站，觉得e有很大的互动性,这也是为什么我在这边求教的原因.
昨天我有下载 jdon的框架下来看,包括PDF的参考文档.上面确实有很多的价值可以参考,暂时我还是要花时间把方向搞清楚,然后才决定如何使用或选择框架的问题.
或许目前面向构件设计系统的实例或者思想可能还不是很成熟，可能是我个人的能力原因。
我觉得界面控制和数据传输这方面感到很困惑。
比如上面提到的A要调用C的用户列表问题。
从业务方向来看A和C是存在一种关系，但系统方面应该保持独立(A不必知道C太多东西)，这就有个问题：
1、谁来控制如何显示界面？
2、如何实现数据传输（包括格式）？
3、如果要调用的模块不在如何响应（当作错误？）。

我感觉不大可能把每个模块的每个界面的URL都配置进去吧？
希望有经验的前人，给我帮助或者建议！谢谢。

全球领先的面向构件中间件提供商普元公司公布新消息，在继6月成为“服务构件架构”SCA国际构件标准组织中唯一的国内软件企业后，近日，又加入“服务数据对象”SDO国际构件标准组织，与IBM、BEA、Oracle、SAP等厂商协同，一起参与制定影响下一代企业数据编程的（Next-Generation Data Programming）架构与标准。
摘自：http://hi.baidu.com/%D2%F8%B5%AF/blog/item/3059b01b48b8e8198718bf51.html

上面这个引用，对这个贴子有什么作用呢？因为我需要开发的也是类似于此类系统框架．但我不知道国内是否还有更优秀的架构．
当然，我不知道有多少道友有使用或看过ＥＯＳ的代码或者构架思想．至少我看过它的＜EOS5.1程序员培训教程＞后并没有让我拍手叫好（也没有说他不好，毕竟我还没有做个更好的或发现更好的）．
这二天我主要也是在做这方面的学习，所以很希望大家给我帮助．

你是刚刚接触Java，对于构件组件发展趋势可能不是非常明了，下面说说我对目前构件发展方向的想法：

目前构架发展有两种发展方向：
1. 构件轻量化发展方向，以DI/ioc为标志的组件管理方式，以Spring/JdonFramework/Jboss Seam，这方面是从设计思想上入手，所以一般不容易被初学者认识到好处，不会被初学者认为它是自己想像中的那样，但这不是问题，仔细研究就可以。参考一篇文章：

轻量企业应用框架 JBoss Seam
Lightweight Java Enterprise Application Frameworks: JBoss Seam

http://java.sys-con.com/read/180347.htm

作者认为轻量框架是未来发展方向，轻量应用开发框架是过去几年来Java社区的最大变化，从Spring Hibernate这样先锋，到AOP元注释metadata annotation推广，，一直到EJB 3.0(Java EE 5.0)等轻量框架正成为主流.

轻量框架的共同点是POJO模型，并且通过Ioc/Dependency Injection (DI)来实现POJO之间解耦。

主流轻量框架主要区别是他们如何实现容器内服务的配对和实现依赖的。The major differences between lightweight frameworks are how they wire container services together and implement Dependency Injection

2.以工业厂商为主导的SOA,因为有工业厂商的市场部门的潜移默化的宣传和普及，很多人初学者觉得这就是我想要的，SOA是基于系统通讯JMS等基础上的更复杂架构，这种架构无疑适合大型规模。

我个人以为：对于我们普通用户来说，更易用，简单化，而不是在一个复杂层面上再封装复杂层面，一层层叠加上去，这样的技术会很好，但肯定不好用，一个EJB2.0就把程序员搞得抓狂，大呼轻量化，SOA至少在其发展初期不见的简单。

任何一个伟大的技术总是在最初不会易用的，因为大家的精力是如何把功能做好，把这个新东西发明出来，然后才考虑易用，从EJB2.0到3.0也是这样，想开去，，电的发明；火车发明都是这个基本原理。

>我觉得界面控制和数据传输这方面感到很困惑。
>比如上面提到的A要调用C的用户列表问题。
>从业务方向来看A和C是存在一种关系，但系统方面应该保持独立(A不必知道C太多东西)，这就有个问题：
>1、谁来控制如何显示界面？
>2、如何实现数据传输（包括格式）？
>3、如果要调用的模块不在如何响应（当作错误？）。
>我感觉不大可能把每个模块的每个界面的URL都配置进去吧？

当然不是界面URL配置进去，首先你要知道，URL是一个形式，真正功能不是在URL这个表面后的组件里实现，要抓住组件这个核心。

>从业务方向来看A和C是存在一种关系，但系统方面应该保持独立(A不必知道C太多东西)

你必须对这个有一个详细定义，存在关系，但要独立，是怎样的独立，我的理解是：C方面可以重用在其他系统，但这种重用是代码设计级别重用，不是运行阶段重用，这两个重用是有区别的，我在"快速适应需求变化的软件复用"中也提了，其实就是目前两个构件发展趋势的区别：代码设计级别重用是靠Ioc/DI模式实现；运行阶段重用有AOP和SOA，SOA是最高范围的构件重用。

所以，我理解A和C的独立是以A或C能够重用为标志，至于这个重用的级别有高有低，目前可以实战操作的是代码设计级别重用。如果是这样，其实我在JiveJdon3中已经做到。

A和C的关系，其实是业务系统和用户权限系统的关系，这个我已经做到完全分离，可以相对动态混合在一起运行，这个在首页最新文章"关于领域建模与角色权限问题 "：

http://www.jdon.com/jive/article.jsp?forum=46&thread=29177

具体实现可以参考JiveJdon3的源码：
http://www.jdon.com/jdonframework/jivejdon3/index.html

如果你追求更高A和C独立又依存，JMS是SOA基础，是目前成熟方案，SOA未来的成熟方案。

OK,我很感谢你花时间回我的贴子，这可能比较无形的感谢！
１、在我个人的理解上对于重用一般性来说是代码级的．
２、面向构件开发上，整个划分可能是二边的．
一个是原来的依职责按层划分（业务层，表现层，数据访问等）．
另外一个是现在从业务上来看构件划分是以业务应用作依据的．
比如一个用户构件就是一个独立功能，但它还有自己的层（表现，业务等）．
那么这就是我上面提的问题，可能我们把用户管理作为基础业务构件，默认于系统中实现，如果Ａ模块需要访问用户可能可以通过配置文件来实例化用户类，然后通过其公开的接口实现操作．但这回到我上面问的几个问题．如果我现在模块要显示用户列表，那么如果在代码上通过配置创建这个类并实施操作，那对于如何显示用户数据这个是问题。如果选择完如何回传数据呢？
2.1、当然，我假设这个如何显示还是给调用者来完成，那这样表面上没有依懒了，可明显地显示用户这个界面就不统一、重复了(有二个或N个)。
2.2、如果使用用户模块提供的界面来显示，那么就得知道它是哪个页面了。
可能这是我的困惑，可能是有点牛角尖了。请原谅我的无知.

>如果我现在模块要显示用户列表，那么如果在代码上通过配置创建这个类并实施操作，那对于如何显示用户数据这个是问题。如果选择完如何回传数据呢？
2.1、当然，我假设这个如何显示还是给调用者来完成，那这样表面上没有依懒了，可明显地显示用户这个界面就不统一、重复了(有二个或N个)。

2.2、如果使用用户模块提供的界面来显示，那么就得知道它是哪个页面了。

其实你这两个选择可以表达为这样一个问题：重用到哪个等级比较好？是构件类？还是界面Jsp?，你的2.1的意思是：关于用户模块的界面，每个调用户模块的系统自己完成用户界面；2.2的意思是：统一使用用户模块的界面。
这两者都可以做到，先谈谈2.2的意思，都使用用户模块的界面，实际你还是需要为不同的调用系统进行一些定制，这类似Web服务，不可能一个用户界面适合所有的调用它的系统，说白了：界面重用是不现实的，当然界面流程重用可以的，例如Spring搞了个Web Flow，其实jdon框架就是重用了CRUD流程。

还是回到我们主题：构件重用，我们目前有实际意义的是构件重用，这样，就采取你说的2.1方案，每个系统拥有自己的用户界面，用户界面后面的流程甚至功能都是一样的，但是你说这样的缺点是：可明显地显示用户这个界面就不统一、重复了。这你恐怕是从美工网页设计人员去考虑了，这是美工的事情，他负责如何方便统一这些实则一样，但是分布在不同系统中的界面，例如使用模板，当然，你也可以使用Tiles，但是无论如何，你说的缺点不是重要问题，关键是我们软件的构件重用了。

一个月过去了,对于此系统开发还是觉得有很大的困难.
同时也多了解了一些让我困扰的概念,如SOA，那SOA和面向构件化系统有什么关系？和Web Service呢？总的觉得SOA是像一个“共产主义社会”的概念！
我有个比较模糊的问题，就比如Web Service是提供服务来说，那如果是关系到数据库的内容，A开发商就不可能发布这种服务了，或者不能符合大众需求，就如passport功能。

我前面说过，SOA/web service是不断抬高，需要一定时间积累，不是短时间能够掌控；还有一个方向：不是向上抬高，而是分离打散，建议你研究Ioc/DI容器，试着用用，参考JiveJdon3.0这样源码，短时间应该有一定效果。