This page needs updating. Please add relevant information from Liferay 5 and forward. See Wiki - Need Updating for more information.
This page contains information on Liferay's portal architecture.
Liferay Portal 6 #
This section needs information.
Liferay Portal 5 #
This section needs information.
Liferay Portal 4 #
Users can access the portal from traditional and wireless devices. Developers can access the portal from the exposed APIs via SOAP, RMI, and our custom tunneling classes.
Portlet API (JSR-168)#
Liferay is designed to deploy portlets that adhere to the Portlet API (JSR-168). Many useful portlets are bundled with the portal (Mail, Document Library, Calendar, Message Boards, to name a few) and can be used as examples for adding your own custom portlets.
Session EJBs, Spring, and Hibernate#
Liferay is no longer dependent on EJBs and can be deployed on a standalone servlet container. All business logic is concentrated inside POJO implementations that are looked up and instantiated by Spring. These implementations can be modified or enhanced via Spring's AOP and IOC capabilities.
The enterprise release of the portal wraps the POJO implementations with Session EJBs to provide heavy scaling and transaction support required by large sites. The professional release of the portal calls the POJO implementations directly to provide a light weight facade.
All data is persisted using Hibernate and is called through the POJO implementations. Liferay used to rely on CMP technology to achieve persistence, but switched over to Hibernate because of its raw speed and flexibility. Liferay is database agnostic and can run on a variety of popular databases.
Liferay uses JAAS Web security so that when a user logs in, their principal is propogated to the Servlet and EJB tiers. Remote Session EJBs can take advantage of this by checking security and permissions at the EJB level so it does not have be duplicated else where. Local Session EJBs exposes business logic to other Session EJBs and does not specifically check for security since they cannot be called remotely. Principals are also propagated to POJO implementations that are the base classes for Remote Session EJBs.
The enterprise release uses Session EJBs which allows the deployer to separate the Web server, EJB server, and database server to achieve clustering at three levels. This is true n-tier deploying because no one is forced to cluster at any single layer and allows the most flexibility for large companies.
Most of our EJBs, HBMs, and Models are generated through the ant task build-service which reads the file service.xml in /portal-ejb. Each portlet that persist data has its own service.xml (do a search in /portal-ejb and you will get a list back). We copy this file to /portal-ejb when we want to generate the persistence classes for that portlet. This is an internal tool that is built on top of the XDoclet engine.
For example, upon reading service.xml found in the Bookmarks portlet, the following model classes are generated. Each model class reflects a table in the database. Never edit BookmarksEntryModel. Do edit BookmarksEntry to add hand massaged code. BookmarksEntry is generated once and extends BookmarksEntryModel. This allows us the ease of generated code and flexibility of hand massaged code.
com.liferay.portlet.bookmarks.model.BookmarksEntry com.liferay.portlet.bookmarks.model.BookmarksEntryModel com.liferay.portlet.bookmarks.model.BookmarksFolder com.liferay.portlet.bookmarks.model.BookmarksFolderModel
Hibernate classes are generated that map to the model classes. This allows for an n-tier architecture for cases where your model classes are marshalled across the wire and your Hibernate classes are not.
Persistence methods to add, update, delete, find, remove, and count the Hibernate entries are generated as the default persistence mechaninsm.
Helper classes are generated that call the persistence methods. By default, the helper classes call the Hibernate persistence methods to update the database. You can override this in portal.properties and set your own persistence class as long as it extends the default persistence class. This means you can customize where you store your data. It can be a traditional database, a LDAP server, or even something else.
Pooling classes are also created to minimize object creation. Behavior can be modified in portal.properties.
POJO implementations that extend PrincipalBean are generated to hold business logic that check the caller principal and can be called remotely. Calling getUserId() returns the user id of the current user. Calling getUser() returns the User model that represents the current user. The Session EJB that extends the POJO implementation implements PrincipalSessionBean.
For example, these classes allow you to delete a bookmark entry or folder if and only if you are the creator of that entry or folder.
These classes are only generated once if they do not already exist.
Helper classes are generated based on the POJO implementations. They help save developer time and prevent polluted code. Instead of writing many lines of code just to look up the appropriate Session EJB wrapper or POJO implementation, you simply call BookmarksEntryServiceUtil.addEntry to call the equivalent method in BookmarksEntryServiceImpl.addEntry.
BookmarksEntryServiceUtil calls BookmarksFolderServiceFactory to look up the class that implements BookmarksEntryService. BookmarksFolderServiceFactory defers to Spring and settings in portal.properties on whether to load the Session EJB wrapper or the plain POJO implementation. The Session EJB extends the POJO implementation.
com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryServiceEJB com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryServiceEJBImpl com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryServiceHome com.liferay.portlet.bookmarks.service.spring.BookmarksEntryService com.liferay.portlet.bookmarks.service.spring.BookmarksEntryServiceFactory com.liferay.portlet.bookmarks.service.spring.BookmarksEntryServiceUtil com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderServiceEJB com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderServiceEJBImpl com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderServiceHome com.liferay.portlet.bookmarks.service.spring.BookmarksFolderService com.liferay.portlet.bookmarks.service.spring.BookmarksFolderServiceFactory com.liferay.portlet.bookmarks.service.spring.BookmarksFolderServiceUtil
Tunneling classes are generated so that developers can call the POJO implementations over port 80. An example of this given in the section V of this document.
Soap classes are generated so that developers can call the POJO implementations over port 80. Soap is slower than tunneling because tunneling streams requests in binary format. Soap is more flexible than tunneling because the client classes are not limited to Java.
POJO implementations classes that do not extend PrincipalBean are generated to hold business logic that do not check the caller principal and can be called locally. These classes exist so that business logic can be easily integrated with other projects.
These classes are only generated once if they do not already exist.
Helper classes are also generated.
com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryLocalServiceEJB com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryLocalServiceEJBImpl com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryLocalServiceHome com.liferay.portlet.bookmarks.service.spring.BookmarksEntryLocalService com.liferay.portlet.bookmarks.service.spring.BookmarksEntryLocalServiceFactory com.liferay.portlet.bookmarks.service.spring.BookmarksEntryLocalServiceUtil com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderLocalServiceEJB com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderLocalServiceEJBImpl com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderLocalServiceHome com.liferay.portlet.bookmarks.service.spring.BookmarksFolderLocalService com.liferay.portlet.bookmarks.service.spring.BookmarksFolderLocalServiceFactory com.liferay.portlet.bookmarks.service.spring.BookmarksFolderLocalServiceUtil
Some of our users needed to call the Local Service classes remotely, so Remote Service classes that parallel their Local counterparts are also generated.
com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryRemoteServiceEJB com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryRemoteServiceEJBImpl com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryRemoteServiceHome com.liferay.portlet.bookmarks.service.spring.BookmarksEntryRemoteService com.liferay.portlet.bookmarks.service.spring.BookmarksEntryRemoteServiceFactory com.liferay.portlet.bookmarks.service.spring.BookmarksEntryRemoteServiceUtil com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderRemoteServiceEJB com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderRemoteServiceEJBImpl com.liferay.portlet.bookmarks.service.ejb.BookmarksFolderRemoteServiceHome com.liferay.portlet.bookmarks.service.spring.BookmarksFolderRemoteService com.liferay.portlet.bookmarks.service.spring.BookmarksFolderRemoteServiceFactory com.liferay.portlet.bookmarks.service.spring.BookmarksFolderRemoteServiceUtil
A lot of people stay away from Session EJBs because they are heavy and require a lot of coding. Our build scripts show that you can leverage the advantages of Session EJBs while minimizing repetitive labor so that you can strike a good balance between effort and results.
Spring gives Liferay additional flexibility. Developers can test their POJO implementations with Liferay Portal Professional in a servlet container and deploy to production with Liferay Portal Enterprise in an application server.
SOAP, RMI, and Tunneling#
All of our remote POJO implementations are exposed to the external world via SOAP, RMI, and our custom tunneling classes.
We do not do this simply because Web services is a buzz word, but because we find it extremely useful for integration. The following is an example of a company that leverages these resources.
3sixteen is a t-shirt company that needed to get up and running fast. In the fashion industry that relies on cutting-edge appearance and presentation, 3sixteen needed to keep its Flash MX front-end "brochure" website that would not be used to sell clothing but to offer an experience through the music, graphics, and articles. Due to the static nature of Flash, the brochure site was not an e-commerce solution because products would need to be added, removed, and updated on a constant basis. To solve this problem, they decided to separate their web presence into two sites: a brochure site and shopping site.
www.3sixteen.com became the graphic oriented site built in Flash and my.3sixteen.com became the shopping site using the vanilla Liferay distribution. These two sites are hosted on two different Linux machines, and for all intents and purposes could have resided on different continents.
They also needed to build a mailing list to collect email addresses for all their interested customers. To accomplish this, they added a JSP pop up box on their Flash site that would tell the portal server to add the email address to a contact in the Address Book portlet.
The following is a JSP snippet that shows how the guys at 3sixteen leveraged ABContactServiceHttp to add a contact.
String URL = "http://my.3sixteen.com"; HttpPrincipal httpPrincipal = new HttpPrincipal(URL, "joe_bloggs", "password"); ABContactServiceHttp.addContact(httpPrincipal, firstName, lastName, emailAddress);
ABContactServiceHttp invoked addContact in ABContactServiceUtil. The invocation was sent over port 80 and received by http://my.3sixteen.com/tunnel/servlet/AuthTunnelServlet. The application server made sure the authentication matched and then processed ABContactServiceUtil as if the user with the id joe_bloggs was calling addContact. ABContactServiceUtil then called ABContactServiceImpl to do the actual work. You can trace the logic of this by viewing the source included in the generated JavaDocs.
Now Joe Bloggs can log into the portal and look in his Address Book portlet to see that he has a new contact. All of the included portlets have this capability because these helper classses are generated. This means you can write applets or any other Java application to access the Session EJBs that contain your business logic. This can be a security hazard if someone had your password, so you can configure to limit the Tunnel Servlet to only listen on certain ports by editing portal.properties.
You can also access the Session EJBs over SOAP and RMI.