Liferay 门户通过扩展 struts 的基本类 ActionServlet
生成自己的 MainServlet
类，而所有的
HTTP 或 WAP 请求都要提交给这个类来处理，以保证能传递给合适的 PortletAction
来处理。
Liferay 不再依赖于 EJB，它完全可以单独装配到一个 servlet 容器（如：Tomcat,JBoss
等）中。而所有的业务逻辑都通过 Spring 管理的 POJO 来实现。这样的实现利益于 Spring
的 AOP 各 IOC 特性。
但在 POJO 的实现方法上 Liferay 的两个版本有所不同，企业版（enterprise）中通过 EJB
从 而 为 大 站 点 提 供 了 高 扩 展 性 各 良 好 的 事 务 支 持 能 力 （ 如 集 群 ） ， 而 专 业 版
（professiona）直接通过轻量级的接口完成。
所有的业务数据都通过 Hibernate 来实现并通过 POJO 来调用。Liferay 曾经使用 CMP 技
术.来实现持久层，但后来因速度及灵活性等原因改用 Hibernate。在数据库方面，Liferay
也完全兼容大多数主流类型 DB。
Liferay 使用 JAAS 来完成用户认证安全管理，好处是当一个用户登录后，它的安全属性可
以在 Servlet 和 EJB 层中沿用，真正作到系统级的 SSO。具体讲，远程 EJB 可以沿用安全
检查及权限属性，本地的 EJB 是为其它 EJB 提供业务逻辑服务的，不能被远程调用所以也
不必做此类检查；安全原则也派生到 POJO 实现中，而这此实现其实是远程 EJB 的基础类。
企业版式使用 EJB，所以系统分别可以在 WEB 服务器、EJB 服务器、数据库服务器三层
中实现集群。当然在 n 层的系统中，集群也保持优势，而且在每一层都并不强迫使用集群，
这些都为大企业应用提供了极好的弹性选择权。
系统中的 EJB、HBM、以及模式 Model 者是 ant 执行 build-ejb 任务时，通过读取目录/
portal-ejb 下的 ejb.xml 文件，然后自动生成的。每个有持久层对象的门户单元（ portlet）
都有自己的 ejb.xml 文件（可以在/portal-ejb 下搜索得到清单）。当需要生成持久层的类时，
就把文件复制到/portal-ejb 下，这生成工具是建立在 XDoclet 之上的。
也生成了专门的协助类（Helper classes），可以用来调用持久层方法。默认时，协助类
调用 Hibernate 的方法来对数据库进行更新操作，但是也可以改写 portal.properties
中的配
置，使用自己专用的类来完成，但这种类要求要继承默认的持久层类。换言之，用户完全
可以定制自己的持久层数据，可以是一个正统的数据库，或者是 LDAP 服务器，其它什么
的。
为了减少对象生成的成本，引入了对象池，可以通过修改 portal.properties
文件来控制池
的基本动作。
评论2