Liferay DXP Interview: How Developers Can Use the New Platform

In this interview, Veriday COO, Chris Lamoureux, sits down with Delivery Lead, Sam Hyland, to discuss Liferay DXP compared to previous Liferay platforms, and how it affects developers working with the platform. This is Part 2 of our ongoing series of interviews about Liferay DXP. For an overview of the new platform, check out Part 1 of the series.
_________________________________________________________________

Chris Lamoureux: How are you doing this morning, Sam?

Sam Hyland: Good, good! How are you, Chris?

Chris: Very good, very good. We’re here to talk about Liferay DXP, which has been on the  marketplace for about half a year now. At Veriday, we have been using it since it rolled out and more and more you have been out working with clients who are thinking about upgrading to DXP.  Who are thinking about how to actually develop on it. What are your first thoughts on the DXP platform?

Sam: Well, first I think the platform has certainly evolved. Liferay is referring to DXP as an “experience platform”. The experience for users (the front end and the interface) is certainly a lot more advanced than it was in Liferay 6.2. It’s bringing it into the modern era. A lot of the other changes are in the back-end, in the development frameworks available, which is what we’re here to talk about today.

The big, big change in the back-end is the move to  very modular development. So, you’re building small components that are discreet, easy to manage and upgrade. I’m hearing a lot of excitement about the modulation of DXP. Even though the previous portal architecture supported somewhat of a modular approach (you could deploy portlets individually) there were some challenges with that approach.

A lot of clients had developed large applications, with a lot of different portlets in them, to work through that. In the end, a single change involved re-deploying their entire application. It involved doing a full regression test against that application because they didn’t have the confidence that their change was isolated. That it would only affect one part of the application. This made the cost of a change quite high. Clients are excited about the new OSGI modular approach because it allows them to separate components while still allowing for all the flexibility needed for communication between the components. Deploying components with that modular framework means that developers can ensure their changes are isolated, enabling more rapid change.

Chris: Very interesting. Historically, Liferay was always thought of as the lightweight portal, does this imply that Liferay is getting even lighter relative to competitors in the marketplace?

Sam: In some ways it does, because each of these modules can be turned on and off individually. This means you can deploy your individual modules but you can also look to the Liferay components. If there are certain modules there that you don’t need, you can turn them off and disable features that aren’t relevant to you.

Chris: So I’ve heard a lot about OSGI, and I’m trying to get my head around it. Tell us a little bit about what the change to OSGI is all about. What’s the impact to the developers using the Liferay platform?

Sam: OSGI itself isn’t anything new. It’s been around for many years now. If your application developers or Java application developers use Eclipse, or any products built on top of Eclipse, they will have seen OSGI before.

Eclipse uses OSGI behind the scenes. It’s a proven platform that’s been around for a long time and it’s a specification that, at it’s simplest, is a Java jar. If you’re familiar with Java development you’re familiar with the concept of a jar, which people traditionally use for libraries. If you deploy a library, that’s a jar. It gets out there and it makes certain classes available. OSGI now adds some extra information to the manifest file inside the jar that declares capabilities this jar has to make available. So you deploy a jar to the OSGI container, the manifest file exposes certain requirements and capabilities, which are then available to other OSGIs that are there.

So, for example if you deploy an OSGI jar with your user service, for looking up users. It might say, “I have this capability that I know about all the users on the Liferay platform”. Then your application with the OSGI module says, “I need to know about the users.I have this requirement. I require this capability”. The OSGI container takes care of wiring everything together, looking up all the references and pulls everything together. It says “Liferay, you have this user service, you can provide this capability. Application, you need this capability, we are going to connect the two of you together.”

In some ways, it’s not that different from the EJBs. It’s the same sort of idea. It’s just a newer take on it that is working very well. It has been used by Eclipse for ages. Liferay is using their new foundation and it’s being adopted by other vendors throughout the marketplace.

Chris: So Liferay is keeping pace in that area?  

Sam: Oh Definitely!

Chris: What are the other areas of Liferay DXP, from an application development standpoint, that you would mention specifically to an existing developer thinking about how to do something differently in DXP?

Sam: So the first thing I’ll point out is that if you’re used to building and deploying portlets, you’ll still be doing that in Liferay DXP. There is actually a compatibility layer that allows you to continue to build and deploy portlets the old way if you have an existing portlet that would better suit your needs.

If you’re looking at this OSGI stuff and think “this modular deployment, this lifecycle works for me and our development team, we want to build portlets using OSGI” you can do that as well. The biggest difference that developers will notice when building portlets in OSGI is that you no longer define the portlets inside .xml files.

Traditionally, when you build a portlet there would be a series of .xml files with most of the configuration in them. There would be a “porlet.xml” which would have things like your portlet name in it. If you were using portlet communication you would have some of the settings for that. There would also be a “Liferay-portlet.xml” that would define any additional capabilities for your portlet. When you’re building an OSGI, all of those are using Java annotations. So, you’d create your portlet class, put an @ at the top of your class and you would put all your properties at the front.

I personally am a big fan of annotations. It’s easier to look at. You’re looking at your portlet class; all your properties are there in one place. Everything is ready for you to go.

Chris: So, if you’re a new developer and you’re not experienced with Liferay 6.2, what are you thinking about as you start to use DXP?

Sam: As you get in and start using Liferay DXP, like everything else, there’s going to be a learning curve. You’re going to start small and look at, “how are we going to build our applications on Liferay?”. If you have built web applications before, you’ve probably used an MVC framework, and so the model, the view, the controller. Liferay supports that approach.

You’re going to build your view as a portlet. You’ll have to do a little bit of reading on what the portlet specification is and what a Java portlet is. It’s going to take you an hour or so and you’re going to have a “hello world” portlet up and running that’s going to spit out a view for you.

Then you’re going to say, “well we can display some information. We can have a simple form. We’re interacting with that form.” You’re probably using a JSP (if you’re a Java developer you’re probably used to JSPs) for your view. Then you’ll want to interact with a service.  Now you have to interact with something.

This is where you’re really going to start building multiple OSGI modules. You’ll have one OSGI module that’s your view, then you can start building your service. The first thing you’re going to do when building a service is define an API for it. Your API itself is another module. It’s going to be one Java class, It’s going to be the interface into your service. You’re going to deploy that as a module and make it available to your view.

Then you’ll have to write the implementation for that service (another OSGI module). That’s going to start talking to your database. It’s going to start storing and retrieving data and making it available to you.

As you go deeper into Liferay, you may find that you’re using it for integration. It’s an excellent platform for integration. You might be calling out to third party services. You may also want to store your data within Liferay.

After you reach that level of expertise you might look at some of the tooling available in Liferay. It has a service builder, essentially a code generation tool. You would define your model. You would define all the data fields needed. You would define any descriptions or associations within an .xml file. Liferay has a code generation tool, so you would run a command and it would generate all the classes for your service using all the OSGI modules needed for your database.

Chris: So, Liferay has a “sweet spot” within the marketplace. Historically, they’ve had nice growth but with DXP where is that “sweet spot”? Is it the same as what it was in 6.2? For you, as an application developer, in what situations would you use this is a product to solve client problems?

Sam: I think it continues to solve all the problems it solved in Liferay 6.2. It works as an integration platform on the front end. It can serve as your system of engagement (system of record). I think in DXP it does a better job of that because of some of the front-end pieces, which we won’t discuss in detail today. It has a much richer interface. It’s more modern. It has all the Ajax pieces to wire everything together. It’s a single page application. So, instead of refreshing the entire page every time you click, it only refreshes the data that’s changing, making it a lot faster and smoother for your end user.

Liferay DXP also has some very strong mobile libraries and toolkits available, allowing you to turn the web application you built out into a mobile application. Everything in Liferay is responsive, condensing down nicely on your phone. Liferay has a “Liferay Screens” feature that turns your application into a mobile application. It makes spruces available on mobile, it has a mobile SDK. You can use that or you can use some of the Liferay built-in pieces to build a kiosk application. Maybe you’re in retail and you’ve got kiosks available for your customers to interact with. So, now you’re not just engaging on the web, you’re engaging on phones, kiosks, etc.

Chris: Which is where the marketplace is going… going, gone.  

Sam: Exactly!

Chris: So, Sam it sounds to me like Liferay has continued to raise the bar when it comes to its ability to increase YOUR productivity as an application development at a material level, which is ultimately what customers want. They want to get better, faster, cheaper. Give us your observations so far on your usage of DXP and your productivity?

Sam: I would say it has gone a long way in improving productivity. Liferay before – the preferred way to develop on it was using Liferay’s SDK. So, you had to learn their toolkit if you wanted to work with Liferay. You could stray beyond Liferay’s libraries but there was always a gentle nudge saying “this is the Liferay way to do it. Let’s do it the Liferay way”.

What DXP has done is become more platform agnostic. So, if you like using Grails for your build, that’s well supported. If you like using Maven or Ant, you can do that as well. You’re no longer pushed towards using Liferay’s toolkit. The same thing goes for the front-end and the middle tier. As you’re building out your application, if you have a Javascript framework that you love, it can be used with Liferay with a lot less of the conflicts that you would have seen historically working with Liferay. A lot of the challenges that were there in Liferay 6.2, when working with, and bringing in new toolkits, have been removed thanks to the added modularity in DXP.

Chris: So, it sounds like Liferay has come out with a great product!

Sam: I would fully agree!

Chris: Well, thank you very much for your time, Sam.

Sam: Thank you, Chris!

___________________________________________________________________________________________________________

That ends our interview with Sam Hyland, Service Delivery Lead at Veriday. We touched on many points related to the new Liferay DXP. We discussed OSGI technologies, the modularity of the new Liferay platform, various features of the new platform from a back-end perspective and how Liferay will affect developers working on the platform.

Stay tuned for more interviews about Liferay DXP, the new digital experience platform brought to you by Liferay.

If you have any questions or comments about this discussion, please let us know on twitter @VeridayHQ or #LiferayDXP