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.BookmarksEntrycom.liferay.portlet.bookmarks.model.BookmarksEntryModelcom.liferay.portlet.bookmarks.model.BookmarksFoldercom.liferay.portlet.bookmarks.model.BookmarksFolderModelHibernate 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.
com.liferay.portlet.bookmarks.service.persistence.BookmarksEntryHBMcom.liferay.portlet.bookmarks.service.persistence.BookmarksFolderHBMPersistence methods to add, update, delete, find, remove, and count the Hibernate entries are generated as the default persistence mechaninsm.
com.liferay.portlet.bookmarks.service.persistence.BookmarksEntryPersistencecom.liferay.portlet.bookmarks.service.persistence.BookmarksFolderPersistenceHelper 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.
com.liferay.portlet.bookmarks.service.persistence.BookmarksEntryUtilcom.liferay.portlet.bookmarks.service.persistence.BookmarksFolderUtilPooling classes are also created to minimize object creation. Behavior can be modified in
portal.properties.
com.liferay.portlet.bookmarks.service.persistence.BookmarksEntryPoolcom.liferay.portlet.bookmarks.service.persistence.BookmarksFolderPoolPOJO 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.
com.liferay.portlet.bookmarks.service.impl.BookmarksEntryServiceImplcom.liferay.portlet.bookmarks.service.impl.BookmarksFolderServiceImplHelper 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.BookmarksEntryServiceEJBcom.liferay.portlet.bookmarks.service.ejb.BookmarksEntryServiceEJBImplcom.liferay.portlet.bookmarks.service.ejb.BookmarksEntryServiceHomecom.liferay.portlet.bookmarks.service.spring.BookmarksEntryServicecom.liferay.portlet.bookmarks.service.spring.BookmarksEntryServiceFactorycom.liferay.portlet.bookmarks.service.spring.BookmarksEntryServiceUtilcom.liferay.portlet.bookmarks.service.ejb.BookmarksFolderServiceEJBcom.liferay.portlet.bookmarks.service.ejb.BookmarksFolderServiceEJBImplcom.liferay.portlet.bookmarks.service.ejb.BookmarksFolderServiceHomecom.liferay.portlet.bookmarks.service.spring.BookmarksFolderServicecom.liferay.portlet.bookmarks.service.spring.BookmarksFolderServiceFactorycom.liferay.portlet.bookmarks.service.spring.BookmarksFolderServiceUtilTunneling 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.
com.liferay.portlet.bookmarks.service.http.BookmarksEntryServiceHttpcom.liferay.portlet.bookmarks.service.http.BookmarksFolderServiceHttpSoap 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.
com.liferay.portlet.bookmarks.service.http.BookmarksEntryServiceSoapcom.liferay.portlet.bookmarks.service.http.BookmarksFolderServiceSoapPOJO 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.
com.liferay.portlet.bookmarks.service.impl.BookmarksEntryLocalServiceImplcom.liferay.portlet.bookmarks.service.impl.BookmarksFolderLocalServiceImplHelper classes are also generated.
com.liferay.portlet.bookmarks.service.ejb.BookmarksEntryLocalServiceEJBcom.liferay.portlet.bookmarks.service.ejb.BookmarksEntryLocalServiceEJBImplcom.liferay.portlet.bookmarks.service.ejb.BookmarksEntryLocalServiceHomecom.liferay.portlet.bookmarks.service.spring.BookmarksEntryLocalServicecom.liferay.portlet.bookmarks.service.spring.BookmarksEntryLocalServiceFactorycom.liferay.portlet.bookmarks.service.spring.BookmarksEntryLocalServiceUtilcom.liferay.portlet.bookmarks.service.ejb.BookmarksFolderLocalServiceEJBcom.liferay.portlet.bookmarks.service.ejb.BookmarksFolderLocalServiceEJBImplcom.liferay.portlet.bookmarks.service.ejb.BookmarksFolderLocalServiceHomecom.liferay.portlet.bookmarks.service.spring.BookmarksFolderLocalServicecom.liferay.portlet.bookmarks.service.spring.BookmarksFolderLocalServiceFactorycom.liferay.portlet.bookmarks.service.spring.BookmarksFolderLocalServiceUtilSome 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.BookmarksEntryRemoteServiceEJBcom.liferay.portlet.bookmarks.service.ejb.BookmarksEntryRemoteServiceEJBImplcom.liferay.portlet.bookmarks.service.ejb.BookmarksEntryRemoteServiceHomecom.liferay.portlet.bookmarks.service.spring.BookmarksEntryRemoteServicecom.liferay.portlet.bookmarks.service.spring.BookmarksEntryRemoteServiceFactorycom.liferay.portlet.bookmarks.service.spring.BookmarksEntryRemoteServiceUtilcom.liferay.portlet.bookmarks.service.ejb.BookmarksFolderRemoteServiceEJBcom.liferay.portlet.bookmarks.service.ejb.BookmarksFolderRemoteServiceEJBImplcom.liferay.portlet.bookmarks.service.ejb.BookmarksFolderRemoteServiceHomecom.liferay.portlet.bookmarks.service.spring.BookmarksFolderRemoteServicecom.liferay.portlet.bookmarks.service.spring.BookmarksFolderRemoteServiceFactorycom.liferay.portlet.bookmarks.service.spring.BookmarksFolderRemoteServiceUtilA 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. We will post more examples of that shortly.
Application Service Provider
Liferay was built from the ground up to be used by application service providers. The following is a sample list of portals running off of one portal instance hitting one database and shows the capabilities of Liferay.
http://demo.liferay.nethttp://my.ccuc.nethttp://www.gatewayfriends.orghttp://www.hope-harvest.orgUsers in each of these portals have no information about the other portals. They are separated by domain and each portal exists in its own space based on the company's id.
See
Multiple Portals for detailed informaton on how to set up multiple instances of Liferay on one machine.
