REST向左，SEAM向右

这两年REST(Representational State Transfer)随着ajax, web2.0, ROR逐渐火了，起来。不得不承认REST确实是一种在互联网环境下非常好的架构风格。REST中一个非常重要的约束，就是服务端无状态，将大部分的状态管理向客户端转移。而SEAM正好朝向REST的反面走去，而且是走得很彻底。SEAM是完全的服务器端有状态，所有的状态都在服务器端来管理。所以seam的文档里都会自称自己是一个stateful的框架。要说服务器端有状态，其实JEE的标准的web container基本上都是以服务器端有状态的方式来运行的, servlet的 session scope, application scope就是这个服务器端状态的容器。SEAM为了更好的进行服务端的状态的管理，还添加了另外几个scope： 会话 Conversation scope : 跨越多个页面，但是比session要短 page scope : 在同一个页面内同一个棵JSF组件树上保存状态，不同于jsp的 page scope business scope : 跨越多个session的业务流上下文 有了session, 服务器能记住每一次的客户端的请求是由谁发送来的；有了conversation, seam更有能力知道用户正在处理哪几个页面，做哪个用例；而 business scope 更是让seam有能力记住用户的操作是在哪个业务流程里的。这种想要让服务器记住一切与客户端交互上下文，维持交互状态的设计，让SEAM变成一个彻底的REST风格的对立者。 在SEAM里面集成了RichFaces等ajax框架，但是java script在seam和 REST的眼中，地位完全不一样。在REST里，java script被用作是客户的VM语言，肩负着在客户端维护状态，展现资源的重任，而在SEAM里，ajax只不过是一锦上添花的小玩具而已。因为即使你用ajax方式来发一个请求，服务端还是要走一个非常复杂的流程（各种状态的恢复和维护），这种ajax并不会带来多少的性能上的提升。 REST风格是针对于互联网来说有，互联网网存在着高延迟和高并发的特性，数据的传输需要花费很多的时间，对一台服务器的访问量可能由于一则花边新闻而骤然升高，在这种情况下，服务端和客户的缓存显得尤为重要。客户端缓存可以减少不必要的请求，服务端的缓存可以减少对相同资源的处理时间。为了能让缓存尽量的发挥它的作用，所以很强调服务端无状态的特性。而每一次请求都要包含状态数据的SEAM应用在应对高延迟和高并发时，显然没有REST风格有优势。不过，从目前的情况来看，SEAM也就是把自己定位成企业应用的WEB框架，而企业网络，和因特网相比则没有那么高的延迟和并发了。 这样看来，如果是做互联网应用，REST风格的架构要比SEAM这种架构要好；而如果是做企业应用，SEAM还是个不错的选择的。