Is There a Future For the Portal? Perficient's Michael Porter Thinks So...


News: Is There a Future For the Portal? Perficient's Michael Porter Thinks So...

  1. Portal servers have always been over-hyped by the sales teams, and when it comes to feature implementation, development teams have never been able to cash those checks that the vendors have been so anxious to write. To make things worse, the big vendors were never able to make the portal all of those things it was supposed to be, that is: friendly, easy to use, personalized and fun, never really came to fruition. The promise was always a 'Facebook-like', fun to use experience. Instead, all we ever seemed to get were static pages that simply maintained a common, corporate, mundane look and feel. 

    So, what's the future of the portal? Take a look at Mike's column on the topic and find out.

  2. True. I have worked on Portal application and the Java's Portal API was unnecessary complex. Just the reason that it did not use Servlet API kills it.
    I think just by using "jsp:inlcude"'s is all we need to create Portal like apps.
  3. JSR286, the new Portal API (why couldn't they have numbered it 268, since the old JSR was 168), is much more in line with the Servlet and JSP API, with the requisite listeners and PortletFilters. But JSR286 support has only happened within the last year or so, so they do seem to be coming a little late to the ball.

    And yes, mashups and tiles and layout frameworks like that are really making people wonder about the value of portal server technology. I'm working on an article about how Facebook killed the portal, or at least, destroyed the entire believe on how portals needed to be done. Still, there are alot of big players invested in it, so I'd say the future is yet to be written. 
  4. I question the value of a portal server in a world with decent component frameworks like JSF, Wicket and .NET, at least on the server side.

    I think folks just work at too low of a level (buttons and fields), but really there's no reason you can't write sophisticated portlets using component technologies today. Why not have a Forum component, Chat component, RSS Feed component.

    Now, all of the corporate uses of portal tech I have seen have forgone the "lets move all this stuff around" ala yahoo etc. But even that technology is a pretty thin layer on top of the existing component frameworks.
  5. Open Social?[ Go to top ]

    Haven't Portals been out flanked by Open Social and Gadgets?
  6. WebSphere Portal 7.[ Go to top ]

    Tell that to the people who are about to release WebSphere Portal 7.

    Many large corporations have adopted the portal, including the Government of Ontario. The aggregation and centralization abilities are strong. I'm not sure if anyone in the Government of Ontario regrets the decision.
  7. Web 2.0 and Flex[ Go to top ]


    Portals(both JSR) in my experience are not very efficient and too complex for development teams. It had never been successful amidst all hard work by the JSR teams. However the recent developments on the Flex side looks promising like AMF/Web services support, cairngorm, blazeds/spring etc and easier for java folks. This will certainly fulfill the rich internet experience using the Java platform

  8. The question if and how to use a Portal Environment is just a question about what you want to integrate and who will use the Portal/Applications. The point that Portal is more complex than other frameworks or technologies is just a point of view. You are targeting a completely different solution when you integrate Business applications in an Enterprise than developing a customer website with a few applications.
    A Portal server is no perfect solution for all situations, but I dont think it is going to be useless.

    If you want to have Portal Solution with a bunch of applications that have a cool UI and a lot of Web 2.0 features than just integrate Google Web Toolkit (GWT) with the Portlets. So we did in the last nearly two years and our customers were surprised how fast the development cycle and how many UI features we could use with it.

    See a few demos of what I'm talking here (german)
    or at Google Apps Marketplace (german)

  9. Unless an enterprise has invested a lot of time and effort on Portlets, this technology is irrelevant. It is overly complex for any large enterprise developments. Web 2.0 and distributed architecture put together do a much better job, much cheaper.
  10. Well, I have published myself different posts about portlets:

    Portlets in the light of OSGi and other technologies

    The term "portal" is, at least, rather confusing!

    Portlet life looks like EJB, but future sounds like GWT

    The portlet/GWT comparison is in favor of GWT

    My conclusion is that :
    (1) portlets are very over-hyped and expensive to deal with
    (2) portlets are a standardization of the portal concept at the wrong level.
    Well, portal is a architecture concept, just like REST. Portlets are a standardization of this concept into the API level, and introducing too much contraints.
    IMHO, portal concept should have been better defined, just like REST, at the architecture level.
    (3) GWT, for example, enables to define faster better portals than portlet technology.

  11. jAPS2.0 project[ Go to top ]

    Hi Manickadas,

    I totaly agree with you. I found out  jAPS project ( which is a new kind of lightweight and flexible platform.

    jAPS Team doesn't use portlet standards because they introduce many constraints and high costs in a project. 

    Take a lokk at this jAPS Team article "What we think about Portlets Standards"



  12. I completely agree with all of you! From a programmer point of view things are even worse. I have discovered that portlets are only a nice concept since they are _not_ portable! The classic "hallo word" portlet can be freely imported everywhere but a complex portlet, for what I have seen, always invokes core elements of the underlying framework that makes it not portable, at least in the implementation  I've seen to date.

    Just my two cents!

  13. Aukcell is a seasoned and recognized expert in all aspects of Liferay deployment ,which is based in China.It has successfully implemented sound Liferay portal custom solutions, including the solutions of e- Learning ,video portal ,education portal, government portal ,multi-systems integrate into Liferay, facebook and myspace integrate into Liferay portal and so many more.

    At Aukcell you’ll find one-stop solutions for all your Liferay projects: From support, consulting and training we offer services to help you implement and develop Liferay based solutions.

    Aukcell has great trainings that will teach you hands on to use Liferay the way it was intended,the onsite and online 5-day Liferay Portal Training which covers both portal administration and development as well as the custom online training package at a very cost effective price,the training language will be in English and Japanese.

    If you are looking for the right-partner and cost effective solutions for Liferay Training ,Liferay consulting ,custom solutions and more ,then you have got the right place at the right time.


    General: support at aukcell dot com
    Business: cherry at aukcell dot com
    Skype : aukcell
    AIM: eonpeter

    Tel: +86-411- 84898263
    Fax: +86-411- 84898263