２、各个子系统的数据通信和控制？
如果在上面安装了Ａ、Ｃ等系统，那么Ａ和Ｃ的如何通信？
比如：我现在任务管理中想把任务分配给系统中的某个用户，那么必然要有个地方能让
我选择用户，一般我们假设为打开新窗口，那么A如何知道C模块用户列表的页面是哪个？
选择完后如何把选择的数据传回选择页面？
3、功能如何分布？
如果上面问题解决了，这个问题比较容易，就如上面的问题。
用户列表可能要屏蔽一些功能操作或者类似权限的问题，是放到C中还是A传递参数过去告知A该如何做？
只有具体类是可配置的，然后我们可以认为任意划分归类，划分子系统，今天将ABC三个类归为1号系统，明天我可能将AHJK三个类归为1号系统，不同系统协调工作也简单。
对于你这个案例，如果你的ABC这几个系统不是建立在DI模式上，那么就只能采取传统方式进行硬的弥补。
两个系统协调工作不外乎数据库共享和系统之间通讯，数据库共享不用说，是最简单，系统通讯一般用JMS，JMS是可以将两个系统实现最大程度的松耦合，当然，使用JMS不可能让几个系统天衣无缝运行一起，这到底属于弥补，而不是融合。
总之一句话：要实现你构件化动态组合，必须前提都是将这些构件最大松耦合，而Ioc/DI是目前主流选择。
从你这个案例，也可以看出，我们什么现在Ioc/DI轻量框架会成为主流，其最重要的核心就是实现了构件的彻底可配置，完全可定制，进而才有根据需要动态组合这样高境界设计事情发生。
我感觉不大可能把每个模块的每个界面的URL都配置进去吧？
希望有经验的前人，给我帮助或者建议！谢谢。
上面这个引用，对这个贴子有什么作用呢？因为我需要开发的也是类似于此类系统框架．但我不知道国内是否还有更优秀的架构．
当然，我不知道有多少道友有使用或看过ＥＯＳ的代码或者构架思想．至少我看过它的＜EOS5.1程序员培训教程＞后并没有让我拍手叫好（也没有说他不好，毕竟我还没有做个更好的或发现更好的）．
这二天我主要也是在做这方面的学习，所以很希望大家给我帮助．
目前构架发展有两种发展方向：
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也是这样，想开去，，电的发明；火车发明都是这个基本原理。
当然不是界面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未来的成熟方案。
2.2、如果使用用户模块提供的界面来显示，那么就得知道它是哪个页面了。
其实你这两个选择可以表达为这样一个问题：重用到哪个等级比较好？是构件类？还是界面Jsp?，你的2.1的意思是：关于用户模块的界面，每个调用户模块的系统自己完成用户界面；2.2的意思是：统一使用用户模块的界面。
这两者都可以做到，先谈谈2.2的意思，都使用用户模块的界面，实际你还是需要为不同的调用系统进行一些定制，这类似Web服务，不可能一个用户界面适合所有的调用它的系统，说白了：界面重用是不现实的，当然界面流程重用可以的，例如Spring搞了个Web Flow，其实jdon框架就是重用了CRUD流程。
还是回到我们主题：构件重用，我们目前有实际意义的是构件重用，这样，就采取你说的2.1方案，每个系统拥有自己的用户界面，用户界面后面的流程甚至功能都是一样的，但是你说这样的缺点是：可明显地显示用户这个界面就不统一、重复了。这你恐怕是从美工网页设计人员去考虑了，这是美工的事情，他负责如何方便统一这些实则一样，但是分布在不同系统中的界面，例如使用模板，当然，你也可以使用Tiles，但是无论如何，你说的缺点不是重要问题，关键是我们软件的构件重用了。