>>Actually I think Webservices is much much more than just make a java/C# class get published and be able to speak SOAP, the core value is about orchestration of B2B, EAI in an automated, manageable fashion

非常同意！

GLUE我也很看好，同时也希望Axis做的更好。

>>M$ may have implementation out quicker, but it take years for others sort out what’s about, by the time ISVs are ready to deploy their business on it, you know what, m$ outdated it. “热脸贴冷屁股",many ISVs had such kind of experience.

话虽如此，不过很多ISV们还是乐此不疲的。

我原来有一个同事一直做.net开发的，不过他很忙，常加班，也很久没有和他联系。.net比较容易学，何不花点时间自己看看呢。

希望可以和你多交流，E-mail:robbin_fan@yahoo.com.cn

>GLUE我也很看好，同时也希望Axis做的更好

Glue非常不错，和.Net的wsdl是兼容的，而axis至少去年还不行。
Glue的开发非常简单，可以把任何Java Bean发布成web services，而.net中又可以根据wsdl自动产生wsdl proxy classes，因此，开发中两种语言几乎没有障碍。

robin,你上次说的transaction,security,stateful的问题，其实都可以解决。在客户端只需要维护不同http连接中的cookie信息或者jsessionId，模拟browser的行为，这些问题都可以用web app的方式化解。

至于性能，据我们的开发体验（用VC7作客户端)，并不比rmi慢，但目前缺乏压力测试。

对了，上次你还提到了swt，当时太晚了，所以没有回。

我们去年用swt做过两个项目，一个是利用jface的类库，一个是做成eclipse的plugin形式，直接利用eclipse的workbence。

对swt的感觉是：
1. 反应速度很快
2. 缺乏可视化设计工具，写起来比较麻烦

但绝对比swing值得使用。如果有需要在linux或unix上运行的桌面程序，完全可以考虑用swt。

>robin,你上次说的transaction,security,stateful的问题，其实都可以解决。在客户端只需要维护不同http连接中的cookie信息或者jsessionId，模拟browser的行为，这些问题都可以用web app的方式化解。

哦，那么就是说Client使用HTTP协议和Servlet通讯对吧？但是会不会Client编程搞的比较麻烦？如果Client通过RMI调用EJB，编程还是很方便的，如果每次都是HTTP GET，POST请求，在构造POST数据，和取回Web Server的状态信息和内容都需要Client写代码实现，感觉好像很麻烦的样子呀。而且HTTP协议调用的效率比RMI恐怕要低很多了。

>而且HTTP协议调用的效率比RMI恐怕要低很多了

我没有详细测试过，但根据自己开发的RMI应用和WebServices应用的感觉来看，后者并不慢，甚至更快一点。

从理论上来说，我想可以这么分析，会影响速度的几个因素包括：
1. 底层协议的效率，都是TCP，这一点没有差别
2. 传输数据的overhead，HTTP的overhead比rmi要小，SOAP比RMI肯定会大。但考虑到我们的应用没有大数据传输，而且如果有，也可以用attachment来解决，所以这个因素相比网络环境来讲要小得多。
3. 网络环境，这一点也没有差别，都是影响各自性能的最主要的因素。
4. 服务器端的处理速度。目前RMI应用主要是利用J2EE服务器，一次RMI调用恐怕不仅远程数据传输这么简单，还需要安全、事务检查，传输数据clone等。WebServices的应用主要需要将XML解析成java对象，另外的处理和Web程序类似。这一点两者无法比较。
5. 客户端处理速度。RMI的客户端是Java,而我们的WebServices客户端是C++，无论从IO处理、数据解析还是内存占用上，后者都更占优势。

能详细说一下怎么用filter + LocalThread 的方法让hibernate使用JTA Transaction以支持分布式事务吗？
是不是这样？

1.在配置文件设置使用JTA Transaction
2.在filter里
if(request.getParameter("useTransaction").equals("true"))
{
Session s = sessionFactory.openSession();
request.setAttribute("HibernateSession",s);
Transaction tx = s.beginTransaction();
}
3.在Action里
try
{
account1.reduce(100);
account2.add(100);
Session s = (Session)request.getAttribute("HibernateSession");
Transaction tx = s.currentTransaction();
tx.commit();
}
catch(he)
{
Session s = (Session)request.getAttribute("HibernateSession");
Transaction tx = s.currentTransaction();
tx.rollback();
tx.close();
s.close();
}

4.在LocalThread里处理后事
if(request.getAttribute("HibernateSession")!= null)
{
Session s = (Session)request.getAttribute("HibernateSession");
Transaction tx = s.currentTransaction();
tx.rollback();
tx.close();
s.close();
}

还有怎样配置Hibernate使其在同一JVM中mapping for 2 database？

不要使用JTA事务，在Hibernate里面仍然使用JDBC Transaction。Filter+ ThreadLocal你可以参考这里:
http://www.javaresearch.org/article/showarticle.jsp?column=108&thread=5779
虽然是讲JDO的，但是道理一样，也详细介绍了Filter+ThreadLocal来关闭数据库连接。

Hibernate的JDBC Transaction不支持分布式事务。分布式事务要启动2PC（两阶段提交），控制比较复杂，需要在App Server中配置。

使用xml配置文件，文档中有说明！

一口气看完5页帖子，有一种观赏华山论剑的感觉，很难在其他论坛看到这样的高手过招，现在的论题已经不止局限于hibernate v.s. CMP了，^_^。在此也抛出一帖凑凑热闹。

1、目前我参与的项目与guty参与的项目架构类似，只不过客户端用PB，使用了XML作为数据载体，没有使用SOAP，毕竟SOAP的处理要比XML复杂一点，网络传输的overhead也要大一些，而且本身项目对于异构系统的互连要求不高，实际上现在很多真正在使用的系统都只用到XML而没有使用SOAP，不过即使是这样，对于涉及大数据量的业务调用，性能还是很大的问题，瓶颈不在网络传输，而在于服务器端对XML数据的解析和构建以及客户端对返回XML数据的处理，服务器端对XML数据处理的瓶颈我考虑不使用标准的XML Parser，自己构建XML Parser，而对于客户端处理XML数据的瓶颈暂时还没有方法解决，因为毕竟有那么多数据要在客户端显示。不过要对robbin说一点，使用HTTP调用Servlet这种方式非常方便，client端实现并不麻烦，而且client不局限于使用Java，我觉得反倒是使用RMI调用EJB可能还麻烦一些（个人意见）
2、最近我一直也在关注Hibernate，并且就像robbin建议的方式，准备在项目中抽取一些简单的模块试用一下Hibernate。目前的架构是Session Facade -> Java class -> DAO ，就是guty提出的性能优先的架构，因为性能是关注的重点，原来的DAO层是采用自己写SQL语句的方式，基本上没有脱离C/S模式＋RelationDB开发的框框，虽然有business layer，但实际上还是把很多business rule放到DAO这一层去了，快速完成了开发，可是随着需求不断地变更，后期维护越来越痛苦，所以一直在找一些容易切换的方式解决，看了一些Hibernate的资料，觉得可以一试。我想肯定还有很多人也希望了解多一些Hibernate的东东，希望guty和robbin两位多多指点，最好能开一个OR maping的专栏，呵呵。
3、SWT方面我也非常有兴趣，Eclipse是我现在使用的唯一的Java IDE，也看过一些使用SWT的应用程序，速度确实不错，不过缺乏可视化编辑环境着实麻烦，不想在client端花费太多的时间。

回到正题，我对EJB的了解不深，也没有实际使用的经验，学习过一阵子，确实觉得使用Entity Bean太过重量级，并且根据网上资料来看，其性能委实为人诟病。再加上目前的项目使用的数据表有200左右，还包括复杂的关联关系，看到前面的帖子，更加强了不使用Entity Bean的决心，呵呵。在各类JDO中浏览了一下，Hibernate的Open Source和比较丰富的资料有很大的吸引力，希望能在论坛上看到有更多的关于Hibernate的讨论。

看来，无论使用session bean + entity bean还是session bean + hibernate，有一点大的趋势是很明确的，entity bean和hibernate属于持久层，不要将过多逻辑放入持久层，这两种技术可以进一步明确阻止开发人员这种错误的决定。

我曾经接受过一个项目，开发人员将积分的数学运算做成DAO的方法，这就会造成层次不分，ah_cai说的可维护性差，甚至性能低等问题。

Hibernate的中文资料确实很少，大概因为Hibernate还比较新的缘故吧。不过对于技术人员来说，提高英语水平也很重要，所以花点时间认真去读英文资料，还可以同时训练阅读水平。

在TheServerSide上有一个hot thread，是JDO vs Hibernate的大讨论：
http://www.theserverside.com/discussion/thread.jsp?thread_id=19732
连LiDO JDO公司的CTO Eric Samson和Hibernate的作者Gavin King也发生了激烈的争论，耐心的看看还是很有意思的。由此也可以看出JDO和Hibernate走的方向不一样。

JDO提出全新的ORM模型，力求标准的统一，但目前还有些功能上的缺陷，特别是由于一些big name（IBM，BEA，Sun）从商业角度出发，对JDO不是那么热心，所以JDO的发展恐怕还会比较缓慢，但应该是一个大的方向，目前连JBOSS也开发了自己的JDO了，而OJB也计划全面支持JDO。

Hibernate的产生有点类似于PHP，完全为满足开发人员需要而诞生的，所以特别符合实际开发需要，实践效果非常好。单就ORM领域来说，肯定会有长久的生命力的。有个帖子说一个Fortune 100的公司的10亿美元以上的项目就是使用Hibernate，但没有说明是哪个公司。目前来说，JDO除了有些缺陷之外，也没有很好的OSS的产品（TJDO还很弱，JBossDO不能在JBoss外面使用），Hibernate似乎是首选了（个人意见）。

2003的 JavaWorld Editor Choice在Data Access Tool方面的入围产品有3个，分别是Hibernate1.2（当时Hibernate2.0final还没有出来），Toplink和CocoBase。也可以看出Hibernate目前受欢迎的程度。

Java的GUI编程一直是一个大问题，但我觉得问题的根源不在于Java本身，而是在于跨平台上。在不同的OS上，屏幕显示采用的方式各有不同，为了能够让同样的程序在不同的OS上表现出一样的外观，Java不得不引入布局管理器。

简单的来说，在Windows上用.net window forms可以很容易的使用像素定位法，像一个坐标一样，指定某控件的屏幕位置，和控件的长宽。所以完全可以做到“所见即所得”的编辑方式。

而Java不能这样做，在Windows上用像素定位好的界面拿到Unix上来，恐怕界面都跑不起来了。就算能跑起来，里面的控件位置和形状也肯定乱掉了。正因为如此，就不能使用绝对位置定位法，必须使用相对位置，所以就做不到“所见即所得”，因此一个控件的位置，控件的形状都很难很难精确和简单的确定下来，必须使用嵌套大量的布局来框住它。

这也是Java为了跨平台而做出的巨大牺牲，但现在看来，又似乎不是那么值得做如此大牺牲，毕竟绝大多数桌面OS都是Windows，还不如转为Windows做一个像素定位的图形库来，这样才能真正和.net window fomrs竞争。

各位老大，看你们的帖子真实太爽了，感觉降龙十八掌、六脉神剑、乾坤大挪移等等各种顶顶级的招式都用上了！看到你们的过招，真是小的们的福气啊！～～
本来不应该发在这里，但为了解决这个实际的问题，只能借助这篇帖子的火爆来吸引你们的眼球（对于普通的求助帖，你们一定不会留意的~~），guty、robbin等各位高人如果有时间，请你们百忙中帮我看看一下这个hibernate自定义映射的问题，先谢谢了！

http://www.jdon.com/jive/thread.jsp?forum=16&thread=8155

拜托了～：）

I found that hibernate and many DAO products load configurations from XML File, and it will cost too many times to finish it. So it is not glad experence to wait so long while debugging.

EJB load configurations while depolying, some better than hibernate i think.

To choose an new framework, IDE support is also a key point.
Hibernate has few GUI-tools, bad reverse engine.

Developing EJB app in JBuilder is a happy work now. In most not heavy load case, I think EJB is my better choice now :)

>
> 哦，那么就是说Client使用HTTP协议和Servlet通讯对吧？但?> 会不会

好像jakarta还是sourceforge有现成的java http client，应该可以利用，不要自己写了。

>>Hibernate has few GUI-tools, bad reverse engine.

用xdoclet已经很方便了