Liferay Architecture

Enterprise Architecture

• Service Oriented Architecture (SOA) - Liferay uses SOA design principles throughout and provides the tools and framework to extend SOA to other enterprise applications.

• The ServiceMix enterprise service bus (ESB) is a central connection manager that allows applications and services to be added quickly to an enterprise’s infrastructure. When an application needs to be replaced, it can be easily disconnected from the bus at a single point. Other open source ESBs such as Mule can also be plugged in.
• Support for Web Services makes it easy for different applications in your enterprise to communicate with each other. Java, .NET, and proprietary applications can work together easily because Web Services use XML standards.
• Support for REST-style JSON Web Services for lightweight, maintainable code and to support AJAX-based user interfaces.

• Security – Liferay uses industry standard, government-grade encryption technologies including advanced algorithms such as DES, MD5 and RSA. Liferay was benchmarked as among the most secure portal platforms using LogicLibrary's Logiscan suite.

• Single Sign On – Liferay offers customizable single sign-on with Yale CAS, JAAS, LDAP, Netegrity, Microsoft Exchange, and more. Yale CAS integration is offered out of the box.

• Multi-Tier, Limitless Clustering – Cluster Liferay Portal Enterprise at any combination of multiple tiers – presentation, service, business logic, and database – to meet your specific load requirements, one processor at a time. Liferay has also been deployed to Amazon EC2 which uses virtualization and cloud computing technologies to scale dynamically to geographically specific areas of demand.

• High Availability – Maintain zero down time for business critical applications with Hardware/Software Load Balancing, HTTP Failover, Session Replication, and Distributed Cache (using Lightweight Multicast Protocol).

• Page Caching – Increase web performance with full-page caching for static content.

• Dynamic Virtual Hosting – Granting individual community members their own page with a user-defined friendly URL.

Portal API
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.
Liferay also holds a seat on the JSR-286 committee with plans to fully move  to this standard with version 5.0.

Struts & Tiles
All HTTP and WAP requests go through MainServlet which extends the basic Struts ActionServlet. MainServlet processes all requests and ensures that each request is routed to the proper PortletAction. Refer to Struts for a better understanding of how the portal's web framework functions.

Layout information for the portal is managed with customizable templates. Refer to articles about Tiles to get a better understanding of how Tiles works as a layout manager.

EJB Spring 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.

com.liferay.portlet.bookmarks.service.persistence.BookmarksEntryHBM
com.liferay.portlet.bookmarks.service.persistence.BookmarksFolderHBM

Persistence 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.BookmarksEntryPersistence
com.liferay.portlet.bookmarks.service.persistence.BookmarksFolderPersistence

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.

com.liferay.portlet.bookmarks.service.persistence.BookmarksEntryUtil
com.liferay.portlet.bookmarks.service.persistence.BookmarksFolderUtil

Pooling classes are also created to minimize object creation. Behavior can be modified in portal.properties.

com.liferay.portlet.bookmarks.service.persistence.BookmarksEntryPool
com.liferay.portlet.bookmarks.service.persistence.BookmarksFolderPool

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.

com.liferay.portlet.bookmarks.service.impl.BookmarksEntryServiceImpl
com.liferay.portlet.bookmarks.service.impl.BookmarksFolderServiceImpl

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.

com.liferay.portlet.bookmarks.service.http.BookmarksEntryServiceHttp
com.liferay.portlet.bookmarks.service.http.BookmarksFolderServiceHttp

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.

com.liferay.portlet.bookmarks.service.http.BookmarksEntryServiceSoap
com.liferay.portlet.bookmarks.service.http.BookmarksFolderServiceSoap

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.

com.liferay.portlet.bookmarks.service.impl.BookmarksEntryLocalServiceImpl
com.liferay.portlet.bookmarks.service.impl.BookmarksFolderLocalServiceImpl

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 & 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.

Source from : http://portal.nctu.edu.tw:8080/web/guest/community/architecture/soap_rmi_tunneling