Category: Portal

Thoughts on portal solutions.

JBoss Portal and Alfresco

I recently delved into JBoss Portal to put together a demo for a client. I started with JBoss Portal 2.2.1 without Alfresco just to get my feet wet. I was a bit underwhelmed. The documentation was spotty, which I expected. The admin UI was clunky at best and wholely non-functional in some instances (here’s a tip: stick to the XML descriptors and avoid the UI for now).

The bigger problem for my immediate need was that the out-of-the-box CMSPortlet instance couldn’t be easily customized through either XML or the admin interface to show anything but the default content stored in the embedded jackrabbit (JCR/JSR-170) repository. The problem was that the URL was configured as an initialization parameter instead of a portlet preference. To fix that I snagged the updated CMSPortlet from the 2.4.0 Alpha release and deployed it to my 2.2.1 instance which worked great.

My next source of frustration was the JBoss-Alfresco bundle. I didn’t know exactly what was going to be included in the bundled instance of JBoss Portal and Alfresco–in hindsight my expectations were set too high. What I was hoping for was that Alfresco would be configured as the replacement JCR repository for JBoss Portal and that there would be a set of useful portlets that exposed the Alfresco repository to portal users. At a bare minimum I would have expected an Alfresco search portlet and a trimmed down “spaces” portlet.

Instead, what’s included is a single “Alfresco Client” portlet that essentially wraps the entire Alfresco UI in a single portlet. The embedded jackrabbit repository still exists and can be used with the CMSPortlet, but Alfresco isn’t configured out-of-the-box to be used as the content repository for JBoss portal.

These annoyances can obviously be addressed with code. And because JBoss and Alfresco leverage open standards, that code will be easier to write and maintain. I was just hoping that the bundle would have been more tightly integrated. (In the immediate-term I was hoping for a more powerful demo with less sweat equity).

As a side note it makes me wonder: Does Alfresco already have these portlets (and other similar types of value-added code) in-house but not easily accessible (or accessible at all) by the community or do they not exist?

This really illustrates the need for services firms to help clients take open source components the “last mile” by adding glue-code, implementing useful add-ons (portlets, integrations, etc.), and beefing up documentation, all of which could and should be injected back into the community in some form or fashion.

Red Hat acquires jBoss

Red Hat has signed a deal to acquire jBoss.

How will this affect the world of ECM? jBoss has portal and workflow offerings. Although I’ve never seen it in real life, and I’m unsure of its origins, Red Hat does have a portal solution. I have no basis for this opinion but I’d wager that the jBoss portal is more complete than Red Hat’s.

Red Hat tried their hand at content management. Their offering was based on the now-defunct ArsDigita Community System (ACS). If Red Hat wants in to the ECM game they’d have a decent start with jBoss’ portal and workflow. All they’d need is a repository. How ’bout Alfresco?

Documentum Web Publisher Portlet Builder

EMC Documentum announced today the release of their new product, Web Publisher Portlet Builder. The goal of the product is to allow non-technical users to define and deploy new portlets to a portal by filling out forms in a wizard-style interface.

In the product announcement, EMC called portal “the new web master bottleneck”. I think this can certainly be true. When a company makes an investment in web content management, the management of the content itself is streamlined, obviously, but when that content is being served up through the portal, you end up with a new layer of process, administration, and management inefficiencies.

For example, suppose we have a portal in which each portlet is serving up a specific static URL. A press release portlet might contain a list of press releases, and the list of press releases would change over time, but that portlet would always contain press releases. The WCM system makes sure that non-technical owners of press releases can contribute the content, route it for approval, transform it into the desired formats, etc. But what if the portlet needs to start serving up press releases from a company subsidiary or maybe an entirely new type of content altogether? Often, the portal administrators have to be involved at that point.

As another example, suppose an entirely new portlet is being added. In some implementations, adding a new portlet can require a fairly involved build process. The portlet might be built in a development environment, get migrated to the test environment, and then finally rolled out to production as part of a scheduled maintenance release. This process certainly results in a quality end-product, but is not very responsive to change.

Because portlet configuration is usually XML-based, it lends itself to a more automated, forms-based approach, like the product Documentum has announced. In fact, I know of others who have done this on their own using home-grown approaches or by leveraging XML-based templating engines built-in to their web content management system.

I haven’t played with Documentum’s new offering yet so I cannot say how robust it is. I do wish it supported more than just BEA WebLogic Portal. I imagine they’ll offer more support for other vendors (probably IBM WebSphere Portal and Oracle) over time.

The bigger issue is that portal vendors need to do more to beef up and simplify portlet deployment. And content management vendors need to do more to allow their repository to be integrated with the portal more seamlessly so that dynamic content can be delivered to the portal without requiring costly integration, duplication of back-end stores, or performance hits.

Alfresco, Plone make EContent 100

EContent Magazine has posted the EContent 100, an annual list of “…companies that matter most in the digital content industry”.

Notable newcomers include open source ECM and Portal platforms Alfresco and Plone. Wiki software provider, SocialText, returns for a second year.

EMC Software (Documentum), a long-time EContent 100 stalwart, having appeared every year since 2001, did not make the 2005 list, but Autonomy, now with a three-peat, did.

“Our goal was to be sure that those who make the list again and again don’t do so out of habit or mindshare, but rather because they continue to innovate and deliver products and services that further the evolution of digital content,” said Michelle Manafy, Editor of EContent magazine.

Stop by at KMWorld

I’ll be at the KMWorld & Intranets conference this week in San Jose. I’m speaking on Thursday on the Southwest Airlines Intranet migration to an Enterprise Portal (Session D302, 11:30 a.m. – 12:15 p.m.).

My colleague, Patrick Dawson, will be speaking on Wednesday. His talk is on making usability a priority in document management applications (Session E201, 10:30 a.m. – 11:15 a.m.).

Drop by and say hello if you are in the neighborhood.

FatWire still around

Die hard for FatWire Spark. After FatWire acquired the Content Server product line from divine in 2003, most commentators expected the original FatWire “Spark” product to fade away. Although sold almost exclusively in the USA and not easily upgradable to the more robust Content Server package, FatWire has kept Spark alive and today announced that Sun Microsystems will offer an unlimited – use license free to Sun Portal Server customers. This is an interesting move for two vendors struggling to find their niche. FatWire may see Spark as a lead generator, but some Sun licensees might come to find Spark limiting — although, to be fair, other portal vendors’ CMS tools are similarly light. Other customers might be frustrated that Sun, and not FatWire, will handle product support. Internationally, the FatWire sales force could be left in an awkward position, with Sun giving away Spark for free while the FatWire reps try to push the more complicated (and expensive) Content Server product. By Janus Boye. [CMS Watch Trends and Features]