CMS Watch Liferay Feed

JSR 286: The last portlet standard?

info@jboye.dk(Janus Boye) — Tue, 24 Jun 2008 10:46:00 -0400

The final release of the updated portlet specification, JSR 286, which came out earlier this month, marked the end of a long process for the important (Java) portal standard.

As a follow-up to the widely-adopted JSR 168, this portlet specification 2.0 moves to make portals more like integrated apps and less like collections of disconnected windows. Specifically it adds support for events, public render parameters, resource serving, and a portlet filter.

Some vendors like eXo, IBM, JBoss and Liferay have already been supporting earlier iterations of the standard and two years ago, I commented that most commercial portal vendors are behind this new portlet standard. While this is still the case, many significant changes have happened in the marketplace since the initial draft of JSR 286 in August 2006.

Jason E. Shao from the CampusEAI Consortium asks in a blog whether the next generation portlet specification really matters and over at the TheServerSide.COM you can find a healthy discussion on the final spec release.

Standards generally go missing in this marketplace, but judging from the very limited attention this new version of the portlet spec has received, it makes me wonder whether the marketplace has already left the need for it in the dust. As a buyer the new industry standard might seem the preferred option over the many proprietary implementations that build on the shortcomings of JSR 168, but make sure to study the emerging implementations of the new standard carefully to avoid an early mover disadvantage.

Sun Portal Server rides into the sunset in favor of Liferay

info@jboye.dk(Janus Boye) — Sun, 25 May 2008 04:52:00 -0400

In a bold move Sun used the JavaOne conference earlier this month to announce that it will begin to work closely together with Liferay on next-generation web technologies.

It took me a couple of weeks to digest the news and distill what the press release did not spell out. Really what will happen is that Sun will take a snapshot of the Liferay Portal code and use this to create a Sun-branded portal with added functionality. An initial version is expected in late 2008 or early 2009.

This is pretty big news because Sun already has a portal offering, which now will go away. The current release of Sun Portal is 7.2 and customers should not expect a Sun Portal Server 8. Sun says it will provide some level of migration tool for existing Sun Portal customers with the initial release and more will come down the road (e.g., by a 1.1 or 1.2 release).

For Liferay this is clearly a great commitment to their open source platform, which has risen in popularity in recent years. Those presently considering Sun Portal should already today take a closer look at Liferay, to avoid future migration costs. As readers of the Enterprise Portals Report know, the two products overlap substantially and share many similar strengths and weaknesses. Liferay Portal recently released version 5 and promises version 5.1 in late June, with several improvements to enterprise features, e.g. workflow and global distribution of portlets. I would certainly expect an even stronger enterprise focus in the Liferay Portal roadmap after the Sun announcement.

While the announcement may not impact Oracle in any way, it is interesting to note that while Sun effectively is taking their product out of the market Oracle still maintains its position with 4 enterprise portals.

Maria, why is your portal so mean to me?

tbyrne@cmswatch.com(Tony Byrne) — Fri, 9 May 2008 08:46:00 -0400

A CMS Watch customer implementing Liferay Portal sent me this screenshot below. On the whole, the implementation is going well enough, but the abrupt tone of some of the error messages is turning off early community testers.

Of course, cryptic and even rude error messages are famously the bane of many software applications, and at least the Liferay messages include the magic word "please" after telling you that you screwed up. Thing is, when the software in question serves developers, the vendor gets a lot of direct blowback, but when the software serves business users, there is typically an intermediary at the customer who suffers first.

For example, behind every portal project lies the portal project manager. Let's say her name is Maria. Maria may be leading a Liferay (or IBM, or Oracle, or Jetspeed or whatever) implementation, but end users don't know and probably don't care which tool is getting deployed. To them, it's Maria's portal. And they will ask, "Maria, why is your portal so mean to me?"

Maria will of course try to make the error messages friendlier and more meaningful. But her developers explain that this part of the portal remains undocumented, and the messages appear to be system generated. That's not a good answer, because even though the codebase is open source, Maria has been around the block enough to know that sending her developers off on a wild goose chase to track down, modify, and recompile some part of the platform is asking for trouble later. So, Maria appeals to the original portal developers and the broader community, but doesn't get a satisfactory reply. Fixing error messages joins the to-do list for Maria's Portal, version two.

Of course, the very same set of events could have transpired if Maria's firm had gone with a commercial portal product, but somehow I think that certain open source projects are particularly vulnerable here -- especially those where contributors get their props and cred for the features they develop, rather than the usability they engender.

As Enteprise Portals Report readers know, Liferay the company (center of Liferay the open source project) pretty much falls into that category. Liferay is a somewhat distractable and hyperkinetic firm that seems rather more interested in putting out cool modules than debugging them. Again: I know many commercial vendors with the same profile. As always, test first, and ye shall find...

JBoss Portal gets a bit more decoupled (soon)

info@jboye.dk(Janus Boye) — Fri, 21 Mar 2008 13:54:00 -0400

In news from last month's JBoss World conference, JBoss Portal will as of Version 2.7, due out in Q3 2008, use a new portlet container that supports the Portlet 2.0 specification (JSR 286). Also the portal platform no longer requires JBoss Application Server (AS).

Support for more application platforms is particularly significant as this enables customers to leverage their existing platform investments, rather than forcing them to also adopt the JBoss AS. Support for more application servers has been on the roadmap for JBoss Portal since January 2007, when BEA WebLogic Server was mentioned and expected due out in Q3 2007. Note, however, that with this news, still only Tomcat will be supported as an alternative to JBoss AS.

Other open source enterprise portals, e.g. Liferay, already support 14 different application platforms, including BEA, IBM, and Oracle. On the commercial side, interestingly most major portal vendors only support their very own platform, e.g., IBM, Microsoft, Oracle, and SAP.

When a portal software supplier only supports its own application server platform, it certainly seems to contradict the idea of loosely coupled software. As a buyer you need to understand that in 2008, selecting an enterprise portal platform might lock you into a specific application server.

Enterprise Portal Marketplace: 2008 Vendor Risk Profile

jb@boyeit.dk(Janus Boye) — Thu, 17 Jan 2008 00:01:00 -0500

It is all too easy to identify vendors for your shortlist based on their supposed "leadership" status in the market. But CMS Watch contributing analyst Janus Boye argues that CIOs, procurement officers, and other technology leaders considering investments in enterprise portals should carefully examine the risk profile of prospective vendors to help identify the right "fit" for their needs.

Scalability the Terracotta Way

kthomas@cmswatch.com(Kas Thomas) — Tue, 14 Aug 2007 06:23:00 -0400

One of the theoretical advantages of Java-based Portals and Content Management applications is the ability to cluster servers for better performance. But the reality is that clustering is a black art that few vendors and implementation teams really ever seem to master adequately. So it comes as a (welcome) surprise to learn of an open-source technology that delivers many (if not most) of the things customers want here, but in surprisingly quick, painless fashion, at low cost, with no need to recompile code or stay up nights learning about disturbing-sounding concepts like "STONITH" (shoot the other node in the head).

The technology in question is called Terracotta, and it works by clustering the Java Virtual Machine in such a way that even a participating JVM itself doesn't know that it has been enlisted in a coordinated effort of any kind. Through a clever bit of boot-time dependency injection, Terracotta patches a handful of core JVM memory-management bytecode instructions, achieving transparent virtualization across any number of enlisted VMs, under the control of a Terracotta server that lives in "aspect space." The Java memory model is not altered. Application code does not have to handle locks any differently or follow any special APIs, or even know that it's been clustered. Have I lost you here? Think of it this way: Instead of implementing special cluster services at the application level using product-specific APIs, Terracotta clusters the Java heap itself, underneath your applications.

It all sounds like science fiction until you try the tutorials, read the white papers and technical literature, and examine the long list of integration efforts (listed on the Terracotta website) involving other Java-based modules like Apache Lucene.

One of the more intriguing integration efforts thus far has been Geert Bevin's recent quest to achieve heretofore unknown levels of scalability and performance with the open-source Web CMS package, Drupal. Drupal is actually written in PHP, but in this case runs on Caucho's Quercus (a Java implementation of PHP), leveraging Terracotta in the cache layer. As Web CMS Report readers know, Drupal is a collaboration-intensive CMS solution of the "let's cache everything in the database" variety -- with difficult scalability problems to match. Bevin's system is highly experimental at this point, but it hints at what people might be able to accomplish with the technology.

In the meantime, other content technologies that take advantage of well-known Java subsystems like Hibernate, Tomcat, Resin, EHCache, Quartz, and so on have the most to gain by exploring Terracotta as a fast path to scalability. Individual subsystems can be tested against Terracotta separately, to find sweet spots.

It will be interesting to see how long it takes mainline ECM and Portal players (particularly those that rely heavily on Java-based infrastructure components) to include Terracotta in their "supported product configurations." I would expect the Alfrescos and Liferays of the world to stay out in front of the situation. Purveyors of complex proprietary solutions might miss the boat.

Scalability always has been (and probably always will be) the Achilles' heel of all the technologies we cover. I'll be watching to see how other communities adapt Terracotta-like notions to other well-known virtual machines (e.g., .NET). Anyone at www.mono-project.com listening?

Introducing portals to content managers

tbyrne@cmswatch.com(Tony Byrne) — Wed, 18 Apr 2007 23:00:00 -0400

Although the hype around enterprise portals seems to have subsided, I believe genuine interest remains high. Yesterday at the annual AIIM Expo, we held an "Enterprise Portal Smackdown," where a packed room of document and records managers keenly watched 7-minute demos presented by different consultancies (Ironworks, Molecular, and Liferay) demonstrating, respectively: BEA WebLogic, IBM WebSphere, and Liferay Portal. Here's a very brief summary of the demos:

Liferay: "We're cool"
Molecular/IBM: "Beware...portals are complicated"
IronWorks/BEA: "E-business dashboards rock"

More enterprises are recognizing use-cases for accessing content repositories and services from other applications. Obviously, portal platforms represent one option here, although panelists discussing "convergence" the day before seemed a bit more sanguine about enterprise search in this regard. On the whole, I think web and enterprise content management specialists underestimate both the power and perils of enterprise portal software.

Portal Kudos and Shortcomings -- Summer, 2006

jb@boyeit.dk(Janus Boye) — Thu, 27 Jul 2006 15:24:00 -0400

Segmenting the portal software marketplace by putting products into boxes on charts is a popular exercise among pundits. But CMS Watch contributing analyst Janus Boye argues that for buyers, a meaningful vendor breakdown must describe how well the various offerings fit actual requirements across specific business scenarios. See how Janus compares the major portal products in the marketplace today...

Liferay launches v4 with new features, but same weaknesses

info@jboye.dk(Janus Boye) — Wed, 19 Apr 2006 16:19:00 -0400

Last week saw the release of version 4 of the open source Liferay portal. This major new release introduces improved security, enterprise taxonomy, velocity template support, JSR-170 compliance, theme (a.k.a. skin) enhancements, and more documentation. As Enterprise Portal Report readers know, Liferay is comparatively weaker in clustering, personalization, and WebDAV support. Unfortunately these areas were not addressed by the new release.

Liferay Portal skins contest

info@jboye.dk(Janus Boye) — Thu, 19 Jan 2006 09:23:00 -0500

The company behind the Liferay open source portal recently concluded a "portal themes contest." A "theme" -- often called a "skin" in other systems -- allows designers and developers to modify the look and feel of the portal without modifying the underlying portal code. Themes are contained in
componentized .war files and usually developed for specific customer projects. The winning themes can now be downloaded from the Liferay site. Prizes in the competition included donations to the winners' favorite charities. Compared to other open source portal projects (e.g., JBoss, Plone), Liferay also offers a very large collection of freely available portlets. Liferay boasts a growing and active community, but as a technology it remains quite weak in key areas, such as clustering, personalization, and WebDAV support.