大家讨论得很好，首先回答楼上各位关于Jdon框架分布式问题，分布式不只是用EJB才能解决，可以使用分布式缓存，云计算这条路，我在 云计算成为现实 中介绍的兵马俑分布式内存技术就是可以直接和Jdon框架结合，兵马俑可以将ehcache直接进行分布式处理，而Jdon框架或Hibernate可以使用encache作为对象的活动空间，那么自然可以扩展到兵马俑这样分布式云计算平台了，这是一条针对性很强的路，我推荐。

我们其实一直期望有这样的架构路线，期初我们能够不用陷入复杂的大型架构之争，而是针对实际情况单机单机的一个个部署开发，当我们把这些点都开发部署完毕，然后通过少量的工作，就能够把他们联系起来，这个联系技术就是分布式缓存 JMS等技术。这就是可伸缩架构的真正含义。

所以，楼主这个项目看上去复杂，但是我们必须分而治之，只有一个原则：确保业务基本围绕内存对象中为中心编程，否则，围绕数据库这个单点盒子，到时规模庞大后，就很难打破这个BOX盒子，进行伸缩性扩展了。

第六点：客户的办公室分布在多个城市，需要高速响应用户的需求，抛开网络问题，需要在客户每个城市放上一台或多台服务器。 为什么会有这种需求，又不是静态网，感觉这个不好，要取消。

谢谢大家的讨论，在这里，项目还没有达到选型的级别，还在需求收集的阶段。现在还没有考虑到EJB等具体的问题。

>>to vcshcn 这种需求是没有经过我们做任何剪切，直接由客户提出的，要求在不同城市的办公室需要在网络断开的情况下，依然可以保持部分查询的功能可以使用。

>>to banq: 目前来说，只是需求有些特别，而业务并不是非常复杂。倒是考虑过根据功能先分割。

>>to IceQi 就目前来说，我也不知道完整的需求，因为现在，在调研阶段，在这里只是说明一个情况，然后和大家一起”联想“讨论一下。

现在，在调研过程中碰到的一个问题就是：如何满足客户对于速度的需求。因为通过网络，没有太好的办法避免网络条件。

考虑过数据库的问题，所以在尽量避免数据库中的任何业务逻辑，但无论如何，数据库只是一个大盒子，不能到处放。

断网情况下查询可用，就要把数据镜像到本地，但是必然要丢掉依赖这批数据所做的业务决定，不管这个决定是来自软件还是来自人工，都不能参考这部分不可靠的数据，关键性数据仍然要手工作业缓存，并且我依然推荐使用集中式缓存服务器。如果这种不可靠客户可以接受，到可以试试全文检索等东西，再用定时器计划镜像到本地或在本地计划从远程下载。

这让我想起了IBM最近推的JAZZ 汗自己一个囧rz

楼上的最后一个字念什么？怎么打进去的？

政府/国营企业项目吧 呵呵 都是这样的 大而全

不是我打击你，这种东西从工程技术上说最终都是失败的，当然从其它角度来说没准是成功的，比如大家都捞到了好处。

原因很简单，这种复杂度和难度不是你能控制的。

由于查询与更新操作比例2：1 所以你的服务器部署方式不可能象你说的那样，每个城市放一个镜象 把大量数据缓存到客户端更是不可想象的，要学会对某些不合理的客户需求说NO，或者影响客户去修改他的需求变的更合理一些 肯定是在某个地方部署了一个服务器集群，然后都跑这个地方来访问的 访问量那么大，应该存在企业或者政府自己的专用网络的吧，这种网络速度应该不是问题 JQUERY速度很慢，讨厌这个东西。有太多的JS框架可以来替代这个东西 WEB层框架只是做MVC的作用，用不用事件驱动的影响不是很大，使用JS都是可以来模拟实现的 架构的核心是你的业务模型，你并没有提到任何有意义的东西

to:nfxu 兄弟果然高手，没错，有复杂性的确是我无法控制的，而现在的问题是我们又必须面对这种复杂性，甚至是一些不合理的要求。这里，我有一个观点：也许这种复杂性是正确的。 现在项目还在谈的阶段，还没有到真正展开的阶段，因此现在碰到的问题在于，一切的需求都是空谈，因为有人提出来想要什么，我们就要记下来。

to:gougou3250 >>由于查询与更新操作比例2：1 >>所以你的服务器部署方式不可能象你说的那样，每个城市放一个镜象 用户提出了需求，我们思考的方式是，让用户在网络无法工作的情况下，也可以有部分查询或者OLAP的业务可以进行。

>>把大量数据缓存到客户端更是不可想象的，要学会对某些不合理的客户需求说NO，或者影响客户去修改他的需求变的更合理一些 >>肯定是在某个地方部署了一个服务器集群，然后都跑这个地方来访问的 目前项目没有进入真正的开发阶段，甚至只是在谈的阶段，因此现在只能是客户提出什么，我们就要先答应着什么，然后努力找解决方案。对于客户的“不合理需求”，要在后期再考虑是真的客户不合理，还是我们自以为是地认为不合理。

>>访问量那么大，应该存在企业或者政府自己的专用网络的吧，这种网络速度应该不是问题 >>JQUERY速度很慢，讨厌这个东西。有太多的JS框架可以来替代这个东西 没打算用UI的东西，只是用一些JQuery封装好的简单操作，比如get()，因此这个应该不成问题 关于网络，速度的确不成问题，但客户反复提出来的是：网络的不稳定性。

>>WEB层框架只是做MVC的作用，用不用事件驱动的影响不是很大，使用JS都是可以来模拟实现的 >>架构的核心是你的业务模型，你并没有提到任何有意义的东西 一个系统包含多个子系统，业务模型不是在这个阶段我就可以提出来的，更何况我需要在知道了所有业务后，大家一起去和这个客户的领域的专家去讨论。 WEB层的确是比较空的，主要是考虑到组件。

另外，现在年底了，找相关的负责人都不好找，估计一拖就是年初了。

说的太对了，感觉楼主是老虎吃天无处下口。 不管考虑用什么架构或技术，先说明你和你团队的能力，老板能给你哪些资源，你们准备花多少代价。这些都是项目能否（顺利）完成的前提