Liferay 7.0 was a new major version of the Liferay platform and as such it included many improvements over previous versions. Having said that, most of the characteristics from Liferay Portal 6 that you have learned to love are preserved, having been changed only slightly or not at all. Any experienced Liferay developer will be able to reuse most of his/her existing knowledge to developing for Liferay DXP 7.1.
What has not changed? Even though there are many improvements in Liferay 7, there are also many great familiar aspects from previous versions that have been preserved. Here are some of the most relevant ones:
The Portal Core and each Liferay app continue to use the three layer architecture: presentation, services, and persistence. The presentation layer is now always provided as an independent module, making it easier to replace with a different presentation, if desired.
Support remains for previously supported standards such as Portlets (JSR-168, JSR-286), CMIS, WebDAV, LDAP, JCP (JSR-170), etc.
Most Liferay APIs have remained functionally similar to those of 6.2, even if many of their classes have moved to new packages, as part of the modularization effort.
Liferay Dev Studio DXP is still the preferred tool to develop for Liferay, even though you are still free to use tools that best fit your needs.
Service Builder and other developer tools and libraries continue to work as they have in 6.2.
Traditional plugins for portlets and hooks still work (once they’re adapted to Liferay DXP 7.1’s API) through a compatibility layer.
Here are some key changes of interest to existing Liferay developers:
Extraction of many features as modules: So far you have been used to working with Liferay as a large web application, of which all of it had to be deployed or none of it. In Liferay DXP 7.1, many out of the box portlets, features, and associated APIs have been extracted as OSGi modules. You can choose which ones to deploy and use.
Adoption of modern OSGi standards: OSGi is a set of standards for building modular systems. It’s very powerful. Although it was previously difficult to learn and use, its modernized standards, such as Declarative Services, have made learning and using it much easier.
Core Public APIs are provided through portal-kernel (previously known as portal-service); all other public APIs are provided by their own modules.
You can reuse modules and libraries, and manage the dependencies among them.
Registration of classes implementing extension points is now simpler and more consistent; it’s based on the standard
@Componentannotation instead of declarations in
portlet.xml. Note, previous registration mechanisms have been preserved where possible. See the Breaking Changes article to examine where extensions and configurations that have not kept backwards compatibility.
Third party extensions and applications are now first-class citizens. Traditional plugins had some limitations that developments done in the core (or done as Ext Plugins) did not have. Modules don’t have these limitations and are much more powerful than plugins ever were.
Complete integration of Liferay specific tools (such as Service Builder) within Maven and Gradle. Additionally we’ve adopted some new tools such as bnd.
The Plugins SDK is no longer available. Visit the Deprecated Apps in 7.1: What To Do article for more information on the Plugins SDK removal. Liferay Workspace, is now Liferay’s opinionated development environment.
Since the modularization of the Liferay web application is the change most relevant to you as a developer, let’s dig deeper into that change and how it affects Liferay’s architecture.
Embracing a Modular Architecture
The largest improvement in Liferay’s architecture is the adoption of a modular development paradigm. Within each Liferay module (or group of modules that form an app), as well as within what remains as Liferay’s core, the existing great characteristics of previous versions of Liferay prevail.
Liferay Portal 6’s architecture diagrams often focused on the tiers for the frontend, services layer (for the business logic), and persistence layer (mostly auto-generated by Service Builder). These layers still exist and have been embraced throughout the modularization effort.
The most significant change (and improvement) over this architecture is that the portal is no longer a single large Java EE Web Application. Liferay Portal has been broken down into many modules to benefit from the Modular Development Paradigm. Those benefits are described in the next section. The modules are often grouped into apps (such as Wiki or Message Boards) and the main apps are grouped into suites (such as Web Experience, Collaboration, and Forms & Workflow).
The figure below represents Liferay DXP 7.1’s architecture from a structural perspective.
As its name implies, it’s Liferay DXP 7.1’s central and most important part. The Liferay Core is a Java EE application in charge of bootstrapping the system and receiving and delegating all requests. It also contains Liferay’s OSGi Engine on top of which all applications run.
Most of the apps, frameworks, and APIs you’ve come to know and love have been aggregated in App Suites. The suites are available in Liferay bundles and are also available on the Marketplace. Here are the different App Suites:
Liferay Web Experience
Contains apps such as Web Content and Site management, Web Content Display, Asset Publisher, and Breadcrumbs and features and frameworks such as Application Display Templates, Tags, and Recycle Bin.
Comprises Liferay’s social apps and collaboration apps, such as Message Boards, Wiki, and Blogs. It also contains Liferay’s Documents & Media Library.
Liferay Forms and Workflow
Provides apps such as Forms (New!), Dynamic Data Lists, Kaleo Workflow, and Calendar. It also contains the Dynamic Data Mapping framework used by Web Content and Documents & Media to provide custom form and templating capabilities.
Last but not least, Liferay’s independent apps and modules also play a part. They provide unique functionality and stand on their own; it would be unnatural to add any one of them to a particular suite. Apps such as Liferay Sync, the Marketplace Client, Knowledge Base, and many more apps available on the Marketplace are independent Liferay apps.
The beauty of the Liferay ecosystem is that it is made up of simple easy-to-use modules that depend on and communicate with each other. And you as a third-party developer can create and deploy your own modules into the mix.
You can continue developing traditional WAR-style apps for Liferay too. The Portlet Compatibility Layer converts each plugin WAR to a Web Application Bundle (WAB), which is a module.
Let’s consider the structure of a Liferay DXP modular app.
The Structure of a Modular App
As mentioned, each app can be formed by one or more modules. This section explains the most common way to structure an app.
The best practice for structuring an app is in several modules. In particular the following modules are the often the best way of structuring an app:
Service: Contains the service (business logic) and persistence implementations.
API: Contains the public API of the application. By being separate from the service, it’s simpler and faster to deploy new versions of the implementation without affecting any module using the API. It also allows changing the versioning of the implementation independent from the versioning of the API.
Web: Contains the presentation tier, very often the portlets provided by this app.
Test: Contains the tests. These are not included in the app for production.
Specific purpose modules: Other modules are also often created for specific purposes or to provide alternative implementations of some of the app’s features. For example the Wiki app has one module for each of the supported Wiki Engines.
All the modules in an app usually sit in folders next to each other in the source to facilitate referencing them.
For deployment to production Liferay provides the LPKG packaging format that allows bundling a set of modules into a single file and add additional metadata about it. This format can also be used to upload apps to Liferay’s Marketplace.
Now you have a basic understanding of the architectural changes introduced in Liferay 7 and have become acquainted with the new structure used in Liferay’s apps. You have learned some key concepts that are new for Liferay Portal 6 developers and have been assured about developer features you’ve used in previous Liferay releases that have been carried into Liferay 7.
Next, you’ll explore how these new concepts and the new modular architecture benefit you as a developer.