Wednesday, September 08, 2010

Liferay 6: notes about the West Coast Simposium

According to the business presentation more than 10,000 customers are looking for a change as their current portals are in end of feature life (EFL). Liferay is then promising to cover that gap. How? Let's review what I heard today.

It was a pleasure meeting the liferay team and knowing their plans. I started sympathizing with them when I first heard the story: They went to the Madrid Liferay Symposium dressed a la "Silicon Valley", well you know blue jeans and that cool stuff. A big surprise when in the auditorium from junior to executives everybody was wearing a suit and a tie. Well, we will do better next time and here they are in Garden Grove, CA and they come wearing ties just to find people wearing Silicon Valley clothes.

The point is though that Liferay support all of us, those that wear a tie and those who don't and we will see more on this broad support below.

The new Liferay 6 comes with Workflow support, JSR 286, extended permission aware modularity, user ranking based on better rules (social ranking), a complete IDE solution based on Eclipse (Liferay Developer Studio)

Nate Cavanaugh, the leader of AlloyUI (based on YUI) presented an introduction to YQL, showing how all apis are hosted in Yahoo and there is minimum that gets locally downloaded. That has made a difference in terms of performance (check this to see why even cache will not be there to help if you load all javascripts in your site header). Thanks Nate for your explanations! The on-demand use of different javascript inclusions just by the time you really need them and the combination of them to minimize the amount of open sockets are a plus that YUI natively offers out of the box. The YUI documentation is great and so is the Liferay (Alloy UI). As Nate stated the Alloy UI tag libs are created from javadocs. See for example "aui:column" and "aui:script" tags. The examples I saw were not invasive so any HTML attribute from original HTML tag can be overridden. This is very important to keep sites with semantic markup. JQuery has been dropped and that is official now. YUI migration was really easy according to Nate.

Chris Stavros from Level Studios talked about the needed collaboration between front end and back end guys. The message has been taken by Liferay as you will read below. He talked about exposing services (for example User, Role) then accessing them (Utility Services) and finally aggregating them (Using Portal and Template capabilities). He showed an intensive use of Velocity templates in his showcase: Minimum code on the backend needed and a lot of front end development otherwise. I mentioned to him the BHUB idea instead of an extra service layer which he agreed to be a better approach. We talked about how JSR-286 is still not applied to most of the current portlets but rather stick to the JSR-168 specification. The Search Portlet is an example of it. I asked the about JSR286, servlets and service builders opinion just to find out we are on the same page. He concluded pointing to monsterenergy.com as a sample implementation of a complete change of the Liferay UI in fact that is full Flash!

Richard Sezov spoke about ServiceBuilder. How the idea of defining entities in just one file (service.xml) sounds perfect. He showed how to put your portlet in the control panel. He presented MVCPortlet which supports JSR-286. The most important feature of this as I have said before is the possibility of reusing same Controller to serve different content (see serveResource() method) He showed how AlloyUI tag libraries allow to reuse validations from the front end. He showed how to use for example the SearchContainer tag to render a table with the consistent Liferay look and feel. Talked about permissions: Resources are declared to be integrated with the permission system. He is finalizing the "Liferay in Action" book, the officially recommended developers guide. ....

Ali Loghmani from CIGNEX Technologies spoke about integrating Liferay in SaaS environments. "Liferay is SaaS ready" he stated. Liferay caching mechanisms integrating with Terracotta and ehCache are important features to consider that leads Ali to choose Liferay as the View side (rendering engine) for his distributed projects. He stated that most of the operations in websites are read operations, this is arguable valid in all projects but certainly a situation for many of those I have faced. Liferay as just the Front End layer: He presented a case study using REST APIs. This is actually in Sync with my postings about BHUB architecture. A second show case showed the use of ESB (providing security, cache, transaction, transformation services) to integrate legacy SOAP APIs. I asked the question and he has successfully used Mule for his ESB implementations.

Greg Amerson (who was member of MyEclipse project) presented the Liferay IDE (Liferay Developer Studio). Liferay IDE 6 will come with support for JIRA for example. There are plans for Workflow visual editors in the near future. He showed layout and theme development from the eclipse IDE. Same for Service Builder including the new possibility to expose web services from plugins. Some features like Code Snippets view, Liferay Tags Search and wizard Layouts from Eclipse UI are of a real interest to those "traditional developers" (Keep on reading to find out what Brian Chiang thinks about types of developers out there) in constant search of IDE capabilities. The old days of table generation for layout in Liferay are gone. Default layout were generated using <div> and not tables like in the past. He showed how to import and convert plugins. He explained the current support for deployment and responding my question he said he has plans to support external running servers (my preferred method as it respect the separation of concerns. Bottom line an embedded server slows down the IDE - unnecessarily). His recommendation in the meanwhile is to check out Eclipse (RSE) to use external automatic deployment of things like JSPs. Now "Report Bugs" is integrated in the GUI and Greg will get the bug reports directly, I guess in JIRA.

Raymond Auge clarified some workflow doubts I had. I will need to come back with questions for Mike Hon on this regard. Basically the workflow engine is proprietary (Named Kaleo). The reasons for that decision are the current complexity of JBPM and Intalio which even though are supported as plugins would make the integration a real challenge as external systems will need to be configured and supported (not real embedded paths for those monsters). Still I want to understand why going with proprietary and not reusing simpler engines like Drools or why not SCXML. On a side note I asked Raymond about the decision on using a proprietary scripting language and more than that favoring it over velocity for email templating. He was clear that he will consider supporting Velocity for email templates for up coming releases.


Brian chiang spoke about development strategies: Customizations and New developments. He went through the six types of plugins on the customization side. Even extension environment is now a plugin. Hooks are lighter and have runtime support however they are limited still in comparison with the extension environment. He put as an example http://www.sesamestreet.org/ (Sesame street website). He mentioned really quick web plugins and the best practices using the liferay-plugin tag. He jumped into New development and then he went ahead classifying developers as: Traditional developers(they love compilers and things like JSF, they like IDEs), content developers (ui developer who loves to do things directly in the browser), script developers (lightweight developers, those that like interpreted languages). He said version 6.1 will make some features available for the latest. In fact he showed a Controller built in pure JSP which I am very interested on seeing in action. Let us put it this way, this allows for real rapid development even though of course if you are one of the first two type of developers you will probably do not like. A sandbox sample was presented where he just created a directory and after naming it as a theme Liferay automatically generated there a theme project and made it available directly from the server URL. He wants to do the same for portlet development and basically this demonstrates the commitment Liferay team has for agile approaches but at the same time the respect for those that prefer to work in different ways, The statement is clear Liferay wants to atract all kind of developers and not just java developers. He zipped a PHP file and dropped it in liferay and the same can be done with ruby so PHP and Ruby will be pretty soon available to fast coding on the front end side. I have to admit it the JSP Controller was something cool I have thought about many times before. Simpler is better and Java developers do already know JSP. Listen careful I am still advocating for the support of the MVC pattern but giving the possibility for fast changes without recompiling. I asked the question about JPA and the response was it is almost there, however Liferay team will continue supporting both JPA and hibernate XML files. I guess something like the Petclicnic spring example where you can chose from different persistent mechanisms is what Liferay team has in mind. I asked in terms of Maven and I was pointed to Thiago post (http://www.liferay.com/web/thiago.moreira/blog/-/blogs/liferay-s-artifact-are-now-mavenized) He has done the job on mavenizing Liferay and this is simple great news. I started that effort myself with some portions of the Portal but now no effort is needed on this regard. Still the Liferay team is comitted to support both Maven and Ant. Once again giving space for different tastes.

James Min gave a presentation on High Availability, how to handle concurrent users and reduce the single point of failure. Too much to cover in so little time: Search Index (lucene), database, repositories (jackrabit),
mod-jk, mod-proxy, ehcache or tomcat tcpcluster, f5 hardware for load balancer, oracle RAC or MySQL cluster for DB redundancy, ehcache, lucene in combination with SOLR or clusterlink for centralization
jcrhook in portal properties abd DB to use a centralized place for documents. Better a SAN. He stressed on the need for a concrete test case to test clustering is working with cache replication before you actually assume your cluster is properly functioning. He spoke about performance tunning (portal properties, JVM params). Here are the three components he says are needed: repeatable test script, load test client (jmeter for example), java profiler. At least to cover the use case of concurrent users login at 9 am in the morning is a must have he said. Keep on recording the results (starting at a baseline without let us say any changes to default configuration) he advises and then after each change keep on recording to show later the statistics. Use a Java profiler to identify bottlenecks and keep on improving. He recommended the use of tools like visual vm, jmx console, jconsole. He explained the importance of tweaking the jvm garbage collector and java heap. I have been there before and it makes absolutely sense to me all his words. For Liferay he recommends to maintain minimum and maximum heap memory with equal values. He went on through app server config, monitoring threads in development boxes, look at memory, cpu, blocked threads. An important question from the auditorium was about using or not session replication. I have talked about this before, if not a need do not use it! He answered there is overhead for session replication so it should be decided in a per project basis. I asked the question about the need of Cache replication and the response for that is of course a big YES as Liferay uses Hibernate caching and so all servers in the cluster must be updated when a change is done in any of them.

1 comment:

Reformer said...

Gr8 article!!!

Followers