Hot or Not: - Widgets in the Java portlet world


News: Hot or Not: - Widgets in the Java portlet world

  1. As a portlet fan at my company, I was wondering how the current widget hype affects the portlet market. As widgets, in my view, have the same principles as portlets we have been creating for years, I don't really saw why widgets became such a hyped thing in the blogosphere and beyond. Even Wordpress in which I wrote this has drag & drop widgets! Most of all, widgets (or gadgets as Google calls them) can be easily installed by anyone; they are simple pieces of Javascript. You can install them on a drag & drop portal page, like you see here:This way you can rapidly build one or more pages showing you, in one simple view, all information you need: news, blog entries, new videos, new games, your top 10 new mails and so forth. You no longer have to check all the sites or download some clunky RSS reader. Most these platforms allow you to put such a widget on your homepage by using a copy-paste of javascript directly in your HTML source. Theoretically you can build a page with a lot of functionality in a very short time. When playing around with this, you immediately see that these components are all trivial functionalities. Importing some content, very simple interaction and show some pictures. But that is exactly the idea: using some very simple-to-install software to add a part of a (much) bigger functionality. For instance, a company can run a customer relationship management (CRM) system and expose the most active clients for you in a widget on your Google homepage. Java portlets are in this same markets: exposing partial functionalities of bigger (bank-end) systems, like CRM systems, HRM systems and so on. So why didn't portlets get "bigger?" They have much less market potential than widgets have, as most portlets are deployed and created in enterprise environments. However, if widgets are so interesting, then one would expect portlets to have more potential than they currently are showing. The scope of portlets is one of the main problems: portlets are usually enterprise; widgets are, mostly, completely not enterprise. Another problem is: there are many platforms to easily create and expose widgets as ASP services, while these are not there for portlets. Portlets remain in the realms of the enterprise dominated by BEA, IBM, Oracle and recently SAP and Redhat (JBoss). And, as a simple search will show; there are simply not many portlets readily available (commercial or non-commercial), while widgets there are thousands and thousands. [Editor's note: right on. Portlet repositories .. yeeick. We need portlet developers to start applying podiatric extremities to rear-ward facing surfaces of humans and writing down nomenclatures.] However, the Java portlet market is heating up and changing because of widgets. Companies are getting more interested in delivering the widget promise companies by packaging, one way or the other, portlets as widgets and widgets in portlets. Companies are also learning from widget and web 2.0 hype to create tools which are much more user-friendly and more interesting for less enterprise-savvy developers. One of the enterprise companies moving into this space is Kapowtech which has been creating tools to build portlets on different platforms for a long time already. With their new platform OpenKapow they try to capture the mash-up and widget hype with the exact tools they sell to build portlets. The bigger boys also feel the heat. Take, for instance, BEA systems, a big portlet compatible tool and platform developer is building and selling tools already for this heated market of mash-ups, widgets and (enterprise) portlets. Widgets have a lot of promise I think, but not in their current form. You really want security and authentication looked after by a solid enterprise platform, as most companies run their in-house systems completely seperated from the evil internet. Portlets have a much better security status while widgets don't have any at all apparently. A company trying to addressing this problem and, in the process, meshes the platform is small enterprise software developer who did not only create a flurry of commercial portlets, but also built a drag & drop site manager like the above mentioned widget homepages and a portlet to select and use widgets, picked from thousands available on Pageflakes, Google, Netvibes and others, in a portal. How do you think the Java portlet and widget market will integrate further? Interesting links:

    Threaded Messages (8)

  2. Widgets are the new Portlets...[ Go to top ]

    I have often believed that Portlets have been a good answer to deliver web applications in. In the past though, the promise that the portlet spec was going to deliver was not met. Portlets let us down. The functionality was rudimentary, and additionally to that, complex to develop on. Functionality was simple, because you could do only simple things with them. If you wanted to do something more interesting, you needed to max the portlet, or worse, go to the actual Application that the portlet is delivering. To add to this limitation, one of the most needed features of portlets, inter-portlet communication was not part of the spec, so every vendor had their own implementation to handle this. It was difficult to build on because, as a developer, you needed to get your servlet container or app server started, then you had to get your portlet container started. This took a lot of time. In recent time, this has been improved with ligthtweight containers, but in my opinion, too little, too late. Whereas Widgets never promised a lot. They were always this piece of screen real estate that would do something very simple (hence why they were called widgets), but as time went on, they over delivered and became quite useful (Note that I didn't say 'very useful', because I am not one of these people that believes widgets are going to bring us world peace - but they do have their place in the world). Widgets became sophisticated enough to allow a user to put together a meaningful page of content, very simply and with simple tools. That is why I look with interest to see what is coming out of companies such as portaneo and kapow tech. I think that there is an answer in simplifying the portlet expectation, and looking for an enterprise answer in widgets. I still haven't seen anything that does this well, but as soon as I do, I think that will be the new UI platform to be delivering Web Applications on.
  3. On the portlet spec ...[ Go to top ]

    I have often believed that Portlets have been a good answer to deliver web applications in. In the past though, the promise that the portlet spec was going to deliver was not met.
    I'm a member of the EG of the portlet spec - so let me answer this comment from the spec's perspective. You're right that the API is a great let down for "developing" portlet applicatios. I can't agree more. However, as far as I see it, the role of the API is now to act as a conduit between web frameworks and portals. It is not really designed for writing web apps from ground up - although it is possible to do so. Instead, it is meant for taking web apps written using other frameworks (Spring MVC, JSF etc), and "portletize" those at run time via some kind of a bridge runtime. If you look at the latest draft of JSR286, a number of features try to address use cases for building such bridges.
  4. Re: On the portlet spec ...[ Go to top ]

    Problem is with inter-portlet communication. We have no possibility to integrate portlets from different vendors. We need some standard definition for inputs and outputs for every portlet (event format). Than we need wiring component where we should transform output formats from one portlet to input format of another one. This is very important. To have independent portlets which shouldn't communicate make no sense.
  5. Portlets - bleeding edge...[ Go to top ]

    The upcoming JSR286 is trying to solve the inter-portlet communication issues (and some others as well...) But if found it hard in the past to build portlets in JSF and use AJAX and some component frameworks! Last week the AJAX4JSF and Richfaces components were changed to work in the portlet context ( - but there are still some ui-component-frameworks that just do not work :( I'm just thinking about the "right" granularity of slicing portlets - even in one app. Does this approach make sense? Is there any framework for controlling the flow behaviour of more than one portlet? Is there any Framework that builds ontop of the JSR286 for inter-portlet communication?
  6. Re: Portlets - bleeding edge...[ Go to top ]

    BEA portal for example have interportlet communication framework. You can make for example Struts portlet and "call" individual actions from outside. However BEA is missing wiring component. Events are working but wiring integration component is missing. We developed our own but it will be much better to have it in standard directly.
  7. WebSphere Portal has powerful interportlet communications since 2003. You can exchange message with POJO as payload or you can leverage Click2Action/Wiring for decoupling sender and receiver. We build very complex apps with these capabilities but can run only on IBM platform. We hope that with new JSR286 we'll be able to develop portable portlet-based solutions.
  8. Here is an example for a preliminary implementation of WSRP 2.0. This demo ( shows how to build a JSF app, consume portlets in it, and wire JSF components with portlets by passing parameters and performing partial page refresh.
  9. Re: On the portlet spec ...[ Go to top ]

    I agree with Subbu, if you look at the Portlet specification, it's rather low level for developping applications, still it is possible of course. People today use web frameworks and those web frameworks should integrate either with the Servlet specification or the Portlet specification natively.