前言：
seam :  以前在项目开发的过程中，你需要引入很多框架（比如：hibernate, jsf , 工作流引擎….) ,  JBOSS说，你们自己做整合，不专业，我来帮你们做了这个工作吧，我来整合，肯定比你们自己整合要好。于此，JBOSS招兵买马，把hibernate的核心团队，JSF规范制定核心团队，EJB3规范制定核心团队等等，都找来当咨询顾问，共讨整合之事，如此诞生了一个新宝宝,取名为SEAM

使用Seam已经有1个多月的时间了，对Seam有一些简单的了解，谈谈我对Seam的一点感想吧。Seam的目标就是把各种优秀的开源系统，J2EE规范，都通过seam这个框架整合起来，从而简化开发工作，提高开发效率。我想这是seam的目标。

seam亮点：

1  JSF和EJB3.0规范实现与整合是亮点之一。

seam实现了SUN公司JSF规范做了不错的工作，在开发JSF应用时，简化了一些JSF。 Seam框架试图简化JSF的开发比如JSF的异常处理，XML配置，JSF组件的调用等等，在开发的时候让JSF和后端的业务逻辑组件(business service bean)达到紧凑，易用的效果。

2 Seam 很有意思的组件管理

我没有去看seam的源代码，但是从seam的介绍文档里有一些简要的介绍，如果有说得不对的地方，仅为交流。
Seam有2种方式来管理组件，一种为了跟JSF，JSP, servlet 等接口，seam 在web.xml 里添加了一个SeamListener，把JSF所需要的组件实例缓存到ServletContext或者HttpSession中，当请求完成或者Session失效时销毁组件实例.

另一种方式是Seam业务组件，这个组件的生命周期管理，类似EJB3规范里规定的方式,Seam业务组件的生命周期管理是否就是EJB3组件规范的实现，还是有自己的管理方式，这些方面的问题，将在以后再去深入了解。
总之，有了对组件的生命周期管理，您不需要去关心事务，并发，同步等问题。我一直都觉得EJB3的组件生命周期管理，比Spring的实现要舒服很多(Spring的组件生命周期管理，还要实现Spring 的InitializingBean,DisposableBean 这2个类,EJB3的组件就是一个很干净的POJO)。

3 Hibernate，Seam中集成的经典JPA

EJB3的JPA规范，作为EJB3的重要组成部分，Seam中对此规范的实现，整合了Hibernate3. 在使用的过程中，好像针对Hibernate3做了一些优化,让您在开发过程中，使用hibernate3更加简单一些了。

EJB2的持久化方案，在过去的几年，被hibernate3之前的版本彻底打败，EJB3开始, 这2家冤家对头，居然走到了一起。在ejb3的JPA规范发布不久，Hibernate就开始支持这一规范, 以前的相互指责，现在变成相互吹捧。

(题外话：其实我在做项目的过程中是很不喜欢hibernate的，不是因为他能提高效率的话，早就抛弃它了。我更喜欢ibatis一些，都是手工写的SQL代码做成映射关系，效率提高很多，可惜他现在对ejb3规范还不支持。虽然开发的时候会多写一点代码，那可是值得的)

Seam真的是王者归来，我见未必。让我们跳出SEAM看seam。

不要看seam的介绍文档说得多好听，好比一个人自己说自己多厉害一样，没用，还是要人家去评价才行。 在你使用seam之前，请仔细评估自己的需求，是否需要使用他。

1，你的项目是否需要使用EJB？

SEAM 在文档里有说明，SEAM也可以开发类似struts+spring+hibernate一样的轻量级架构的系统，但是那是胡说八道。我可以负责任的告诉 你，seam是一个很重的架构，他大多数的技术体系都是偏重于EJB，用他开发SSH类似的系统，只会误事误工。

2, JSF是否适合你的项目？

JSF 是SUN公司主推的一种表示层解决方案。可惜生不逢时，用JSF做企业应用，有Flex,Silverlight等技术比他强。 用JSF做WEB网页方向的应用，JSF更是滑稽可笑。也许有人说，JSF跟Seam有什么关系？但是我告诉你,seam核心目标之一就是整合JSF做表 示层开发，是他整合目标的重要组成部分。如果你打算应用seam，那么表示层的开发就一定绕不过JSF这一关。尽管seam说，他不用JSF也可以，但是 不用JSF，用什么！！ 没有其它好的选择了。

3,开发效率低

呵呵，seam说我的开发效率很高嘛，但那是他自己说的嘛，seam开发环境只能在Jboss里运行才有良好的表现，Jboss在开发,调试,部署还是非常麻烦，和tomcat比效率低很多。

4,学习成本

seam引入了很多相关的其它框架包，假设你有良好的JAVA基础，一个未使用过seam的开发团队，熟悉seam起码也要3周以上的时间，这是我见过的学习成本最高的框架,他整合的框架很多，技术面很广.

5，大型系统的解决方案，seam还是无法提供

一个大型的系统，核心的关键点是：负载均衡，集中缓存处理，并行计算， 分布式存取等， seam面对这些问题，一样显得力不从心，这些问题还是需要架构师自己动手解决。而且seam中有一个web beans的技术(我在想，他使用这个是否考虑到整合JSF才这么做呢！)，给负载均衡, session的处理还不及其它框架灵活。

Seam是否是归来的王者？ 让我们拭目以待！

文章内容只是个人之见，肤浅之处，意在交流。

注意，你要把上面的 the-remote-host-name 改成你的。部署完成后，确认在jboss的JndiViewer里能不能看到 java:/RemoteJMSProvider 。然后再MDB类上加上：

providerAdapterJNDI属性使这个MDB从刚才部署好的JMS provider那里读取消息。

现在要实现一个高可用的消息驱动bean，监听远程机器上的消息topic/a。如果只在集群中的一个节点上部署这个MDB，一旦这个节点不可用，消息处理就停止了。为了提高可用性，可以在每个节点上部署这个MDB，但这时同一个消息会被每个MDB收到和处理，这不是我们想要的，因为同一个消息应该只被一个 MDB处理。这个时候只要让这个MDB对barrier依赖，再把它部署在所有节点上，那么就只有主节点上的MDB会运行，并且当主节点完蛋时，其他节点变成主节点时，那个节点上的MDB会自动运行。这样我们就实现了高可用单例消息驱动bean服务。

要让mbean对barrier依赖，只要在它的部署文件里填上一行，例如:

对于war,jar,ear，可以在jboss.xml里添加，具体见jboss文档。对于ejb3，加上下面的annotation就好了：

这种时候就是使用ear的时候，位于同一个ear里ejb jar的classloader是war的classloader的父classloader。这样，只需要部署一份接口类，war也能访问到它，因为子classloader能访问父classloader载入的类。

会话与JPA的entityManager的关系。一个entityManager与hibernate的session相当。JPA里定义的entityManager一级缓存的刷新方式只有两种：Auto和commit。seam发明了第三种方式，Manual。Auto意味着，当执行到select语句时，entityManger会自动执行一下flush()方法，commit会在事务提交时flush()；而Manual则是由你自己来手动控制flush()。每次开始一个会话的时候，seam都会为你开启一个entityManager，这个entityManger会一直打开，直到conversation结束。这是seam的作者Gavin最骄傲的地方了。能让hibernate的session持续在一个会话之内，可以在会话期内的几次服务器与客户端的几次交往中避免LazyInitializationException，最大程度的发挥hibernate延迟载入的能力。其实Gavin最初要把服务端做成这样有状态的，就是因为他认为与orm协作的最佳方式，就是让服务端有状态。

长会话的结束。默认的情况下，当遇到<end-conversation />或@End时，会话并不会立刻结束，而是会在下个页面生成之后才结束，这是为了避免生成页面时无法取到前一个页面POST时处理的结果。但是有的时候，我们确实需要在POST之后，下个页面生成之前就结束掉。这时需要用@End(beforeRedirect=true),或
<end-conversation before-redirect=”true” />。

会话的维持。我们都知道session是靠一个叫JSESSIONID的cookie或者请里的参数来维持的。类似的会话也是通过这么一个特殊的请求参数来控制的，默认为cid。观查cid的变化，能帮助我们查看conversation的变化。

为什么要发明会话呢？？这得从seam的作者Gavin说起。这个牛人发明了杰出的ORM框架hibernate，但是却发现现在的web开发方式并没有正确的使用它。和
hibernate搭档最多的当属spring了。在结合spring使用hibernate的时候，我们很难把握得好hibernate session的范围，如果太窄，那么在这个范围之外对持久对象的调用很容易产生LazyInitializationException。所以后来OpenSessionInView的方式很流行。但这还是不能完全解决问题。OpenSessionInView把session的范围扩大到了对一个http request的处理过程之中，而不能处理跨页面的情况。如果把hibernate session扩大到 http session范围内，这显然会让session太长，引发其它问题。所以Gavin觉得需要一种能够跨越页面，并且又不会像http session那样太长的Scope，于是conversation就诞生了。在开发中，尤其是以提交表单方式为主的企业开发中，常常需要用几个页面来配合完成一个用例，这几个页面内的数据往往耦合性强，需要被放到同一个上下文中，而这个上下文用conversation来做也是很自然的。对于Gmail这样的应用，conversation没什么意义。

Conversation是个好东西，但是一定要小心的使用。一来它存在着性能问题 ，二来用的太多，不小心控制conversation的开始和结束，就会导致conversation的混乱，那个时候会导致一些奇怪的问题。

为了能够观查到seam内部的运作情况，我把org.jboss的log设成debug级别的，现在点一下页面，一个post->redirect->get，在使用page scope时会产生 1 万多行日志，而conversation scope时居然会产生 近 3 万条日志！光从这个日志的数目就可以看到 conversation 在背后不只是做了一点点工作呀！再仔细对比两者的日志，会发现，conversation scope里会多出许多处理事件的日志：instantiating Seam component: org.jboss.seam.core.events 。这句日志在conversation时出现了 3630次，而 page scope时只出现了 1464次。conversation的日志里多出了大量如下日志：

2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.preRemoveVariable.supplierSearchAction.supplierName
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.postRemoveVariable.supplierSearchAction.supplierName
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.preRemoveVariable.supplierSearchAction.employee
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.postRemoveVariable.supplierSearchAction.employee
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.preRemoveVariable.supplierSearchAction.state
2008-06-24 14:23:32,592 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events
2008-06-24 14:23:32,593 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events
2008-06-24 14:23:32,593 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events
2008-06-24 14:23:32,593 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events
2008-06-24 14:23:32,593 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events
2008-06-24 14:23:32,593 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events
2008-06-24 14:23:32,593 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.postRemoveVariable.supplierSearchAction.state

从日志中可以看出seam 处理了大量的 org.jboss.seam.preRemoveVariable 和 org.jboss.seam.postRemoveVariable 事件，类似的事件还有 org.jboss.seam.preSetVariable 和 org.jboss.seam.postSetVariable。Seam疯狂地为conversation scope里的组件里的property 都产生了一遍这些事件。更可怕的是，并不是处理一遍，而是会处理很多遍，在我的这个测试的例子中，它处理了47遍！ 这一算，1 action * 30 properties * 2 events * N times * M event listners，不是一个小数目呀，在我这个没有event observer的例子中，N = 47, 会有 1 * 30 * 2 * 47 * 1 = 2847 次操作！通过日志还可以看出 把 supplierSearchAction的所有的properties走一遍事件，要花掉 208ms, 那么 47 次这样的操作，需要 47 * 208 = 9682ms ！ 9秒多的时间，绝对不是一下小数目，改成page scope后快，就快在这里。(208 / 30) * 47 = 326ms，每个bean的property, 在这个例子中消耗掉了 0.3秒时间，好昂贵呀。幸好我们公司的服务器比较牛，能够把这个差距的绝对值缩到很小，但是，这无疑是一种对CPU的浪费。

这样看来，conversation是不能乱用的，不能随便把个组件就置成conversation scope的，能把逻辑用page scope, event scope, stateless scope搞定，就尽量不要用conversation。如果有多个页面交互等操作，适合于用conversation的，那也要尽量减少 conversation scope内组件的 properties, 把 conversation 内的组件做成功能明确单一的最好。

其实，我的项目中把 supplierSearchAction放在conversation scope里就是不必要的，因为search动作都是在一个页面内完成的，用 page scope就足够了。不仅如此，还把页面上的很多输入框等通过绑定，直接绑定到conversation scope的组件上。以后再用seam的时候，一定要小心使用conversation scope了。也期待着seam的新版本能把conversation scope的组件性能提高！

为了优化jboss的性能，对jboss服务器做了如下改动。

1. 设置jvm 参数
   
2. 安装jboss-native
3. 降低jboss输出日志的等级
4. 起用了jboss内的tomcat对传输数据的压缩功能
5. 使用ehcache做hibernate的二级缓存

下面就以上的各改动做详细说明，为了表述方便<jboss>代表jboss的安装目录：

设置 jvm 参数

编辑<jboss>/bin/run.conf,  在文件的底部找到对参数JAVA_OPTS进行设置的地方。这个参数会最后传到jvm里。其中

1. -Xms512m 代表jvm最少用 512m内存
2. -Xmx1024m 代表jvm最多使用 1024m内存

修改这个两参数，给jvm分配适当的内存，一般为服务器的3/4内存量，推荐至少使用4G内存。
另外添加两个参数 -XX:+UseParallelGC -XX:+UseParallelOldGC 这两个让服务并行回收内存空间。修改完成后，大致为 JAVA_OPTS = “-Xms4096m -Xmx8192m -XX:+UseParallelGC -XX:+UseParallelOldGC -Dsum…….

安装jbossNative

jboss的web container使用的 apache tomcat (http://www.apache.org)。 apache tomcat 有一个扩展包，使tomcat可以通过 java native interface 使用 apache portable runtime (APR)，而APR则是大名顶顶的apache httpd 网络服务器的运行时环境。用了这个扩展之后，就使得tomcat可以借助于apache httpd的力量，性能得以提升，尤其是处理静态文件时效率更高。Jboss native，实际上就是tomcat的这个native的扩展，只不过被jboss又添进了一些为了和jboss更好协作而加进去的东西。
要安装jboss native, 按以下步骤进行

1. 请到jboss的网站上下载，地址是 http://www.jboss.org/jbossweb/downloads/jboss-native/?action=a&windowstate=maximized, 依据服务器环境选择合适的版本。 目前我们用的版本是JBoss Native 2.0.4 Linux x86 。
2. 解压下载后的压缩包到某个目录，比如 jbossNative目录
3. 将jbossNative/bin/META-INF/bin/linux2/x86/openssl 复制到<jboss>/bin
4. 在<jboss>/bin目录里建一个文件夹，名为 native
5. 把jbossNative/bin/META-INF/lib/linux2/x86/ 目录下所有内容复制到上一步建好的<jboss>/bin/native目录下

降低jboss输出日志的等级

打开 <jboss>/server/default/conf/jboss-log4j.xml ，这是一个log4j的配置文件。log4j的详细配置说明请参看  http://logging.apache.org/log4j/1.2/index.html  。日志输出的太多，会导致服务器性能降低，所以减少不必要的日志输出。方法大体如下：

1. 找到 name=”org.jboss” 的category 元素，设置里面的priority元素为 <priority value=”INFO” />
2. 建一个新的category，内容为 <category name=”javax.faces”><priority value=”INFO” /></category>

log4j 还能够将不同的日志输入到不同的地方，为了以后维护方便，应该将不同 category的日志输入到不同的文件里。详细方法参看上面的网站里的说明。

起用了jboss内的tomcat对传输数据的压缩功能

合同管理里用了大量的javascript css等，为了减少传输时间，可以起用压缩功能。方法是：

1. 打开<jboss>/server/default/deploy/jboss-web.deployer/server.xml
2. 找到 protocol=”HTTP/1.1″的 Connector元素，添加属性 URIEncoding=”utf-8″ compression=”on” compressionMinSize=”2048″ noCompressionUserAgents=”gozilla, traviata” compressableMimeType=”text/html,text/xml,text/javascript, text/css, text/plain,application/xhtml+xml,application/x-javascript,application/javascript,text/xhtml”

添加完后类似于：
<Connector port=”8080″ address=”${jboss.bind.address}”   
maxThreads=”250″ maxHttpHeaderSize=”8192″
emptySessionPath=”true” protocol=”HTTP/1.1″
enableLookups=”false” redirectPort=”8443″ acceptCount=”100″
connectionTimeout=”20000″ disableUploadTimeout=”true” URIEncoding=”utf-8″ compression=”on” compressionMinSize=”2048″ noCompressionUserAgents=”gozilla, traviata” compressableMimeType=”text/html,text/xml,text/javascript, text/css, text/plain,application/xhtml+xml,application/x-javascript,application/javascript,text/xhtml”/>

使用ehcache做hibernate的二级缓存

起用二级缓存，可以大大提高hibernate的运行效率。

1. 到http://ehcache.sourceforge.net/ 网站下载 ehcache-1.4.1.tgz
2. 解压到某个目录，例如ehcache目录
3. 复制 ehcache/ehcache-1.4.1/ehcache-1.4.1.jar, ehcache/ehcache-1.4.1/lib/backport-util-concurrent-3.0.jar和 ehcache/ehcache-1.4.1/lib/jsr107cache-1.0.jar到 <jboss>/server/default/lib目录

10:28:57,000 WARN  [ServiceController] Problem starting service jboss:service=Naming
java.rmi.server.ExportException: Port already in use: 1098; nested exception is:
java.net.BindException: Address already in use: JVM_Bind
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310)
at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218)

也不知道是哪个程序占用了这个端口。可以通过修改jboss的配置文件，让jboss使用另外一个端口，来修正这个问题。方法如下：

1，打开jboss的jboos-service.xml文件，在我机上位于D:\prog\jboss-4.2.2.GA\server\default\conf 目录。

2，搜索1098，找到 <attribute name=”RmiPort”>1098</attribute>，修改这个端口号为一个一般不会被用到的端口号，比如12345。

再重启jboss应该就OK了。