>Thin client, with pure HTML, is the trend.
我不同意，纯HTML不能做的事情太多了，如果你需要打印发票、和串口通信或者当客户电话打进来的时候自动读入客户数据显示在话务员的屏幕上，用HTML是不可能的。

>so I lock myself to J2EE
最好还是不要把自己lcok在任何平台上

>J2EE and .Net are both viable technologies. Whether
this is better than the other, is not a very meaningful
question at all.
同意，争论J2EE和.NET谁好就象讨论刀和剑究竟哪个更厉害一样没有意义。

基于Http的远程调用将激活fat client的活力，基于http的RPC比基于Http的Soap要快。所以在Java系统内，不必完全使用Web Services.

特别是J2ME，作为一个肥客户端，它和J2EE联系有两个方式，实时同步方式：基于Http的RPC；异步方式，作为JMS的客户端。后者对于信息交流类应用是首选，可见：
http://www.theserverside.com/home/thread.jsp?thread_id=20804&article_count=1

B/S结构是把业务逻辑放在服务器上。（多层结构）
C/S是把业务逻辑放在客户端。（两层结构）

因此当业务逻辑更改时B/S不必更新客户端，实际上因为和业务逻辑无关，因此所有的B/S程序都可以使用相同的客户端（Html浏览器）。
而C/S在更新业务逻辑甚至支持更新逻辑的实现途径的时候都必须更新客户端。

没想到一个B/S和C/S引起了这么多争论，其实只要能解决实际问题就行。

c/s和b/s争论历来已久，以前还有现在仍然有不少人停留在c/s阶段，c/s结构终将被b/s等多层系统替代。这是不争事实，可是我在其它地方看到有些人使用c/s概念来表达多层系统，甚至在自己的dephi系统中搞个web服务器，然后宣称自己是三层结构了。

另外说一点:刚从新浪上看到金蝶的官方消息,首先这里并没有提及要起诉的问题,另外注意"金蝶对产品线的调整是很正常的，但从未有过放弃.NET的想法"
这句话,其他的我也不想说什么了,用友放弃J2EE也很正常,他在J2EE上毕竟没有
金蝶那么强的实力,另外,J2EE 对整个软件行业都是很有益处的,能够带动整个产业链发展,其他的我也不想说了

http://tech.sina.com.cn/it/m/2003-08-10/1134219113.shtml
从未想过放弃.NET
　　对于目前有关媒体报道金蝶“放弃微软.NET”、“研发人才严重流失”，徐少春澄清说，金蝶对产品线的调整是很正常的，但从未有过放弃.NET的想法，在8月1日刚刚举行的微软中国2004财年合作伙伴大会上，金蝶刚刚被授予“微软ISV最佳合作伙伴”的称号。徐称，金蝶这两年的人才流动率不到5%，有时候觉得太稳定了反而需要适当的流动。

律师声明8月6日在金蝶的网站上就贴出来了，如果你不知道网站地址，我可以告诉你，www.kingdee.com。

－－－引文－－－－－－－－－
三、金蝶公司作为中国软件企业的优秀代表之一，一贯倡导健康、良好的市场秩序和传媒关系，坚决反对任何采取非法手段获取商业利益的行为。金蝶公司决意通过法律途径追究上述网站及作者的法律责任！
－－－－－－－－－－－－－

最后顺便说几句，学技术的最忌讳坐井观天，闭目塞听。Java教给你很多规范、模式、框架，是很好，但也很容易让一个人成为偏执狂，患上呓想症。看着书本就能“悟出”软件之道，认为传统架构都是垃圾，认为国内的老程序员都是笨蛋，这些都是症状。我曾经是这样，也见过许多类似的人，没有一个不是最后碰得头破血流的。所以真诚希望大家都能够虚心一点谈技术，经常看看java以外的东西，挽救“java程序员”在国内的形象。

Soap is intended for system integration, therefore, it is
usually used between server and server, not client and
server. Maybe I should not say fat client is dead,
but it is not in the trend. Like Cobol which is still
the No. used language in the banking industry in North America,
so it is obviously not dead, but it is not in the trend.

>Thin client, with pure HTML, is the trend.
我不同意，纯HTML不能做的事情太多了，如果你需要打印发票、和串口通信或者当客户电话打进来的时候自动读入客户数据显示在话务员的屏幕上，用HTML是不可能的。
By HTML I meant HTML tags plus the MIME content it supports.
I am working in the North America banking industry.
We use JPEG to represent check images and PDF for statement.

The bottom line is that when the server is lauched, end
users can use it without doing ANY installation, a big save
for the service provider.

>so I lock myself to J2EE
最好还是不要把自己lcok在任何平台上

If you can work on both J2EE and .Net, that would be
great. However, an export with one platform is easier
to sell. Generally speaking, the more high level hierachy
you are in the organization (like CTO),
the more change you have
to have more overview stuff than detailed, in this case,
it makes sense to have grip on both platforms. Otherwise,
it is more feasible to focus one platform and move fast
upwards. But this is only my personal opinion.

Also you want to enjoy life.

>J2EE and .Net are both viable technologies. Whether
this is better than the other, is not a very meaningful
question at all.
同意，争论J2EE和.NET谁好就象讨论刀和剑究竟哪个更厉害一样没有意义。

These kind of big-questions are best leaved to big
market research companies such as gardner group, IDC.
For instance, Gardner group has been one of the first
to recognize and quite well predict middle-ware market
forming and growing at the beginning of 1990's.
Though they too make mistakes.

So far, Gardner group's 40% forJ2EE market share and another
for 40% for .Net has been well accepted, for quite a well.

vs.net没有提供or mapping, 但是可可以生成强类型化的DataSet，这点还是比较强的，m$的DS还提供各种事件处理，它的描述不但基于xml，而且基于schema, java的or mapping有多少做到这两点的呢？要命的是还能可视化设计DataSet...想不投诚都难啊

另外，中间层采用com+的问题，如果不用com+，写个j2ee类似的架构也不难。但是会失去com+兼容性，你想vb,vc，delphi里面也能调用.net的中间层，windows用户会很开心的

关于asp.net的控件。不知道大家作的网页由多特殊，真正要自己写的很少吧。而且毕竟.net刚开始，以后控件多了就好了。另外，自己写控件允许自行控制一些高级选项，比如缓存。在jsp里面很少有这种控制。控件的好处还很多，把常用的模块连页面带逻辑都封装到一个模块里面。以后重用的时候不要太爽啊。有些protalet的意思。

echo和asp.net类似。asp.net还提供数据绑定和可视化设计，这都是echo暂时没有的，开发效率自然也要高出很多。如果让我选择，还是觉得vs.net技高一筹。

看不到js的b/s开发有什么不好呢？我们写java不是也看不到C,汇编了吗？比如我们写日期选择的js控件，如果一个页面上放几个，很多页面上都要放，你会做无数的重复劳动，出错了更是一个头几个大。为什么不用控件呢？封装起来没什么不好。这是一种进步，怀念是有的，停滞不前就是愚蠢了。鄂温克人都走出森林了。

java也是有dataset的，其实这种概念在任何语言平台上都可以实现。早在几年前pb和delphi就都在用了。
但是dataset在java中的地位很低，不受重视。大家都在ejb，jdo，OR mapping上作文章。以我的观点，dataset才是最灵活，最实用的。
最新的java大会提出了类似的观点，看来今后dataset会逐渐浮现到java的台面上来的

>echo和asp.net类似。asp.net还提供数据绑定和可视化设计，这都是echo暂时没有的，
>开发效率自然也要高出很多。如果让我选择，还是觉得vs.net技高一筹。

echo我没有用过，vs.net的ds可视化设计我用过几次，的确很好，简单的拖拉就生成了一个ds，有点类似CMP。但是我查了好多的地方都没有发现对于关联表的dataset如何实现增删改的功能。后来在清华的大厚本书上找到了类似BMP的方法，因此我还是觉得不如自己写sql实现起来更方便。
说道可视化设计，我们做的系统中的报表几乎都是关联很多表，而且外连接，子查询和union都是常有，真让dataSet的可视化设计实现起来恐怕就要叫娘了。而且sql写起来其实也是很轻松很惬意的事情。
如果有一个很好的构架，那么写一个sql就是一个报表，几分钟一个报表，多么潇洒得意呀，其实在我们的系统里就有一个自由报表，用户需要某个数据，而我有不能访问后台时，我就写一个sql，放到自由报表的查询条件里去，一个我想要报表就出现了。

>另外，中间层采用com+的问题，如果不用com+，写个j2ee类似的架构也不难。但是会失去com+兼容性，你想vb,vc，
>delphi里面也能调用.net的中间层，windows用户会很开心的

更多的时候我们的客户关心的还是系统在unix系统上的兼容性。

>看不到js的b/s开发有什么不好呢？我们写java不是也看不到C,汇编了吗？比如我们写日期选择的js控件，
>如果一个页面上放几个，很多页面上都要放，你会做无数的重复劳动，出错了更是一个头几个大。为什么不用控件呢？
>封装起来没什么不好。这是一种进步，怀念是有的，停滞不前就是愚蠢了。鄂温克人都走出森林了。

控件我很欣赏，但是标准一点说：控件是一种代码重用的方法，和.net与j2ee无关，微软在asp.net平台上实现了控件来提高代码重用的效率，而j2ee上也早就有标签库可以实现你要得功能。不过我还是苯的，至今还没有研究过标签库，但是我自己用〈%include……%〉也同样实现了控件的效果，我的日期控件就是这样实现的，同样也是封装起来的，不用重复输入。

其实微软是在asp.net平台上又构筑了一个平台，就象hirbnate，提供了便利的同时也限制了自由，当做到大型或复杂的应用的时候就会发现这个平台限制太死。其实就是这么公平，有便利就有限制，如果你不想做饭就不要挑剔别人作的不好吃。

我个人认为没有完全实用的构架，不同类型的应用软件需要不同特长的构架。其实j2ee是给了我们最大的自由性，你可以根据自己产品的特点设计一套贴身的框架出来，然后你的开发就会事１％功１０００％。一般作一个行业一段时间后都会积累很多工具和经验出来，再有一个资深的java程序员把这些工具整合起来作成一个框架。就会超过asp.net的开发效率，为什么说超过呢，因为它更贴身更合用。这就是j2ee的项目里需要一个系统架构师的原因。这也是我更喜欢j2ee的理由。

asp.net实际上是把这个系统构架师的工作给作了，因此你不需要再去整理构架，因此上手感觉很好。而j2ee如果没有系统构架师的工作就会很难应用。就象你饿了，给你馒头呢，你可以吃饱。但是给你面粉呢你就可以作出来自己特别喜欢的面食。是要馒头还是面粉就看你的老婆（给你做饭的人）在不在家或者水平如何了。那如果你的口味很随便，就吃馒头省事了。

其实微软也不是吃素的，他也考虑了很多的应用的，但是顾及的越多就越没有特长，asp.net上手是很快，但是真正的高层开发就会觉得蹩手蹩脚。因此不能说asp.net比j2ee好，也不能说j2ee就好过asp.net，他们有各自的市场，有各自的人群。

不过有一点可以肯定，在一个出色的系统构架师手里，j2ee绝对不输过asp.net。

是啊，因为不受重视，所以才做的不好，呵呵
如果受到重视的话，至少会有很多开源的产品起来。

个人观点，在ds的设计上，我觉得pb是做的最好的。
它的dataset中包含的数据获取，持久化，事件激发（包括自定义事件），数据格式化输出，数据验证，数据完整性关联等等。缺点就是它是个两层的，有些功能还是不容易移植到三层中来。