Q. Should You Use a Portal Server? A. No.
Allow me to elaborate: I can’t think of a reason I would suggest to any of our clients to use a portal server. In my personal experience, portal servers, especially commercial ones, are just gigantic bags of more or less related, often quite useless functionality that create far more problems than they solve. One could say that Portals are the ESBs of front-end technology (and many of the arguments for and against them apply).
My suggestion for any company looking at a portal server would be to instead a) hire a good Web designer to create some nice reusable CSS files and example HTML layouts and put them somewhere developers can include them from b) establish single sign-on functionality by means of a shared service, ideally supporting something like OpenID and OAuth and c) offer a few URIs where people can pull useful HTML and/or JS fragments from to include in their Web apps. If needed, I’d make sure I get bonus points in the bullshit marketing category by labeling this a “pragmatic open portal strategy”.
What do you think?
ESB/EAI and portals are great technos for system integrators. What is the use case (really useful for business end user) for a portlet? A simple widget to read with a link to the source application to edit will do most of the time.
While I agree your sentiments (most portals are awful) the rather dull reality is that they are often just thin smokey veneers over other vendor functionality; most commonly a document/content management system.
Exhibit A: Sharepoint is ‘as beautiful as an airport’ but it is tolerated initially because of it’s ‘office files on the Lan’ capabilities that are good enough (oh, and it starts free in that ‘playground dealer’ kind of way).
Put another way, it is rarer to buy/select a pure portal solution when mainly they are used as packaging framework apps for all the other offerings a vendor has - and that’s hard to untwine.
YES! I hate trying to mash a portal solution into a business need just because some high-up heard the word “portal” and decided they needed one.
And on a side note, I’m becoming increasingly convinced that “enterprise solutions” is code for expensive configuration efforts. I’d much rather just write an app that would actually fit the business need and make sure that it scales. If your IT department can’t build/maintain that, you probably shouldn’t be attempting anything that has the word enterprise in it.
Obviously portals are not the right solution for every problem. However you will end up building or evolving into something similar to a portal framework if you attempt to roll your solution. There are some good reasons functional / non functional requirements for portals. I agree that many times the rationale for portals is pretty silly.
I strongly disagree. Why would I? What features do you think I’d replicate?
+1 Portals are the ultimate pigs of software products. One question I’d have is whether something like netvibes, iGoogle or the like would come under this definition of “portal”. They are certainly a standardised approach but much more aligned to the CSS/HTMLer type model that you talk about than the traditional portals, they are also certainly some form of portal.
One piece on the CSS/HTML late aggregation portal that can cause an issue is cross site scripting exploits where people aggregate in external elements which end up causing massive problems. The more rigid JSR 168 portal approach might be a pig but it does at least prevent these forms of exploits.
Steve
What do I think? I think you should trademark “pragmatic open portal strategy” immediately.
Seriously though, didn’t the idea of Mashups supersede Portals some time ago?
I strongly disagree. Why would I? What features do you think I’d replicate?
The core feature of portals - that is allowing the user to assemble disconnected units of information onto a single page. It’s not often that you need it, and most of the time it never gets used. But when you *really* need it, portals are nice.
Having said that, I agree with you - as a UI technology, I think portals are a massive failure both at the Intranet and Internet scenarios. Sure there’re tons of portals created and deployed, but how many of them use the portal’s core feature?
I’m one of those unfortunate developers stuck on a Websphere Portal server project. I seriously look forward to the day when management finally listens to us developers and abandons the portal server for the kind of projects we are doing. These projects are regular web applications with a minimal potential for reuse of fragments in a page.
Yes portals can be useful for some things. But it is seriously a big mistake if management thinks that a portal is the solution for every web project. I have never before (and hopefully never again) felt more constrained in my development efforts than on the portal.
I honestly believe that our team could develop exactly the same functionality on Tomcat or even IBM Websphere Application Server as a regular web app in about half the time of what we use on the portal server. Management have time and time again been given this information, but for some reason listens more to what the IBM salesperson says.
If the reason for using a portal is to just aggregate fragments of xhtml, then I would suggest you to take a look at Apache Wicket instead.
I have no intention of writing “experience with Websphere Portal server” on my resume even though I have been developing on it full time for about a year now - I really don’t want to be hired for another portal project any time soon.
It depends on what you think a portal is.
We’ve based our product on a portal server (Liferay) - we didn’t really know what kind of UI was needed so we wanted to be extremely flexible. It was clear that lots of different user groups would be going to use it (intranet app). A portal server seemed like a good idea to us.
Would I do that again?
I’m unsure. My main concern with the portal specification and its implementations they don’t care about the GUI. In the end we had to develop our own Ajaxy Javascript framework to have portlets interact with each other seamlessly. Now it works like a charm. But most of the time we’ve developed not on top of Liferay but more less a few miles off of it. So in the end portals are too enterprisey (with all negative connotations) - they are clumsy and unsexy. I still like the idea - not the specification.
I would love to agree, and for the most part a portal is a big front-end waiting to fail. It doesn’t solve most of the underlying problems, (ie the single sign-on) and without proper user evaluation and IA implementation it just makes a bunch of separate systems into an unrecognisable mess. But don’t blame the technology, for that it’s mostly in the implementation where it fails, and for us (me in our group) within a University we are bound by a variety of off-the-shelf, alternate vendor, cutting edge (chuckle), alternate applications that don’t flex well when you try to make them read a base css. A portal can be a way of integrating these things but it bears it’s own set of challenges and overhead in administration and usability.
It depends on what you want to do. Many companies have had large-scale successful websites built on portals. A portal in my experience is some combination of:
I’ve worked with BEA’s WebLogic & AquaLogic (Plumtree) portals, I’ve helped sell, install, and build projects on them. Some projects were complete disasters, and some were big successes. OTOH, I think they’ve become more passe’ these days, because many portals they take a langauge-centric / library-centric means of integrating information instead of just spidering & crawling web resources…. but frankly I’m not sure “roll your own” is suitable everywhere.
As for your recommendations, I think you make it look a bit too easy to “roll your own”…. one “easy to recommend, hard to implement” thing is SSO. If you really need rich RBAC, and you’re an enterprise, buy + integrate, don’t build. Delegated administration and fine-grained RBAC is very hard to do correctly. Even if you pick up something like OpenSSO (which only recently got an RBAC entitlements engine!)
Similarly for search & CMS, I’m sure Nutch+Lucene would be fine, but…. an integrated product might be easier to get up and running.
I guess it’s a preference, as to whether you’re OK with huge products or like to cobble together smaller ones.
As always it depends on which choice adds the least friction.
It all about working out how these things interact to produce an optimal path.
Now of course often the best path ends up being what you suggest.
But definitely not all the time, and maybe not even most of the time.
Alex
Well, I agree with Fabian who wrote “I still like the idea [portal] - not the specification”.
Every often, unfortunately, portals look like comunism: the idea is good, but the implementation sucks.
One should calculate the portal ROI: portals may have been interesting, but don’t forget: they are about integration (for example, every often, portal security is based on top of an external security product) ! and while existing building blocks grow, the integration layer is finer and finer. So, the portal ROI is decreasing very fast over time.
IMHO, portals are like REST: it’s an architecture idea, and while it has been standardized at the API level (see JSR), it has not a bright future.
Well, first, portals in short/medium-term will have to fight GWT, because it will more and more easier to build a portal using GWT, read: Portlet life looks like EJB, but future sounds like GWT or The portlet/GWT comparison is in favor of GWT
And in the medium/long-term, they will have to fight anoter competitor, that is, OSGi, read: Portlets in the light of OSGi and other technologies
So, I don’t want to work personally on any portal project, and I think too portals will loose more and more interest due to growing competitors and/or building blocks.