我怎么就觉得rails适合做大型应用

1. REST
SOA可以在网上搜得到大量文章，就REST这个通信部份，我就说一下：
通常的项目中用不到，但当项目较大时，会遇到.Net和java的通信，老版本j2ee平台和新架构（比方spring，只是比方）的通信，这里老的项目支持某一种或两种协议，这时，你要调取别人的服务就得用别人能懂的协议，虽然，REST不错，但你这里无法对老的系统全改为REST，代价大，风险大。也许你会说，针对每种协议写一个Adapt就可以啊。是的，是一种方法。SOA（有很多轻量级open source的SOA，不一定非要用钱去买）对你说，你不用写了，我帮你写好了。

2. 太多太多的东西
一是指各种component，像我们平时用的各种apache library，各种j2ee中提及到的服务（像tx, mail, jms等等）。rails在这一部份很缺少，虽然他的component在不断增长，但相比java，太少。
二是指解决方案，方案这东西，不能保证你快，但他能保证你的安全，性能。上一个项目是用XXX+XXX+XXX解决，它支持XXX并发，在XXX内响应。rails在这一部份很缺少，你得在定方案前做各种检验。
三是指兼容性与集成性，全新的东西是好办事，但你不能让企业把它运行得好好的东西全部重新开发吧。那么怎么集成，如何平滑的升级，这里又是一堆要做的东西。rails在这一部份也没怎么见过。

3. 轮子
关从技术角度，.Net还真是这样。但从商业角度，从兼容性等方面来看，那就不是了。

4. 开发速度
的确，j2ee的方式是慢，看上去java比不上rails，但是，这个问题要看架构师如何设计你的架构，如何利用或改装现有组件。思想是相通的，rails代表的是思想，而这种思想在java上实现是一样可以做到的。

5. 欧美项目
我知道瑞士银行的一个核心项目也在用SSH（非门户之类，涉及到具体投资、资金方面），这句话好像有点抬杠，我主要是说，在面对新兴的技术，其实是有各种选择。rails最大的问题是优势不明显（从架构的角度），底气（component,项目证明等）又不足，所以现在不是它用于做大型应用的时候。

你说这个很有讨论的价值

1 我知道SOA可以在网上搜得到大量文章，但我却不知道在ava中如何SOA，我的看法和"readonly"一样，只见SOA嗡嗡嗡，当然你可以举实际的例子来反驳

2 tx, mail, jms 在ror中是有的，数量不多是事实，属于最小实用主义，个人认为不见得就差，当然你得充分理解最小实用主义。

3 方案 “上一个项目是用XXX+XXX+XXX解决，它支持XXX并发，在XXX内响应，rails在这一部份很缺少，你得在定方案前做各种检验”，这个我不好说，但 TW应该有大量的一手经验

4 轮子，虽然JE做.net的比较少，但这样说微软有点不厚道了吧：）

5 架构，对REST的拥抱是个很积极的举措，至于你说的那个是遗留项目，我在主题贴已经强调了这个是rails的弱势，java刚出道时，去兼容老系统比这种情况更加那个什么

6 另外，我说rails适合做大型应用，并不是说java就不适合，rails能做，java基本都可以做，这是事实，我承认。或许我们可以从开发效率以及后期维护再以及对rest的原生态支持上探讨下