What Hasn't Changed and What Has

Liferay DXP 7.0 is a new major version of the Liferay platform and as such it includes 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.0.

What has not changed? Even though there are many improvements in Liferay DXP 7.0, there are also many great familiar aspects from previous versions that have been preserved. Here are some of the most relevant ones:

1. 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, facilitating replacing it with a different presentation, if desired.

2. Support remains for previously supported standards such as Portlets (JSR-168, JSR-286), CMIS, WebDAV, LDAP, JCP (JSR-170), etc.

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

4. Liferay Developer Studio is still the preferred tool to develop for Liferay, even though you are still free to use tools that best fit your needs.

5. Service Builder and other developer tools and libraries continue to work as they have in 6.2.

6. Traditional plugins for portlets and hooks still work (once they’re adapted to Liferay DXP 7.0’s API) through a compatibility layer.

7. The Plugins SDK can also still be used and transition to the new Liferay Workspace, if desired, is easy.

Here are some key changes of interest to existing Liferay developers:

1. 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.0, 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.

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

3. Core Public APIs are provided through portal-kernel (previously known as portal-service); all other public APIs are provided by their own modules.

4. You can reuse modules and libraries, and manage the dependencies among them.

5. Registration of classes implementing extension points is now simpler and more consistent; it’s based on the standard @Component annotation instead of declarations in portal.properties or 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.

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

7. Complete integration of Liferay specific tools (such as Service Builder) within Maven and Gradle. Additionally we’ve adopted some new tools such as Bnd.

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.

Tiered Architecture

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.

Figure 1: Liferay Portal 6's architecture, shown in this figure, is still generally valid in Liferay DXP 7.0.

The most significant change (and improvement) over this architecture is that the portal is no longer a single large Java EE Web Application. Liferay 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).

Modular Architecture

The figure below represents Liferay DXP 7.0’s architecture from a structural perspective.

Figure 2: Liferay DXP 7.0 is composed of the Liferay Core, independent application modules, and App Suites, each with their own set of application and framework modules.

Liferay Core

As its name implies, it’s Liferay DXP 7.0’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.

Foundation

The Foundation suite sits on top of the core, providing administrative interfaces and familiar development building blocks. It includes modules for user and role administration, LDAP integration, authentication, licensing, upgrades, clustering, DAO, and front-end mainstays for themes, CSS, taglibs, and JavaScript. The Foundation suite’s modules depend on Liferay Core, as do all the App Suites and non-core modules.

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.

Liferay Collaboration

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.

Independent Apps

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 DXP 7.0 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 DXP 7.0 too. Liferay DXP’s 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 7.0 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 directories 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 DXP 7.0 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 DXP 7.0.

Next, you’ll explore how these new concepts and the new modular architecture benefit you as a developer.