Wednesday, March 7th, 2007

Ajax Portlets: JSR-168 portlets, SOA, and more

Category: Portal, Screencast, TIBCO

TIBCO GI recently had a webinar on Ajax portlets where they discuss various topics revolving around portals, SOA, and Ajax. The content was recorded and is now available for your perusal.

Ajax RIA + Portal + SOA = Success for H&R Block

H&R Block Sr. Systems Architect, Dan Cahoon, shares how H&R Block delivered SOA-connected Ajax portlets to its more than 12,000 branch offices to deliver composite workspaces streamlining the staffing operations for the nation’s largest seasonal employer. Dan shares his learning from the project and discusses the successful pattern they are reusing to get more solutions to market quickly.

How to Deploy Ajax Portlets to JSR-168 and Other Portlet Containers

Howard Weingram, Sr. Architect for TIBCO PortalBuilder, shows you how to deploy rich Ajax portlets to JSR-168 and other types of portlet containers and more…

The Role of the Proxy in Creating Ajax Mashups within Portals

The role of a proxy in accessing data across hosts and domains.

An Ajax “PageBus” for Client-Side Pub/Sub in Ajax & Portlets

How to architect for modular applications that publish and subscribe to events and message using an Ajax PageBus architecture.

Posted by Dion Almaer at 5:29 am

3.9 rating from 39 votes


Comments feed TrackBack URI

I know at least IT Mill is developing portlet features into IT Mill Toolkit. In this approach each portlet is a simple Java application (Ajax or plain HTML) and programmed in Java language only.

Comment by Sami — March 7, 2007

portals are a waste of time. 5x the complexity for modest customizability gains.

Comment by joe — March 7, 2007

I agree with Joe, here. Unfortunately, many corporate and governmental orgs have bought (for instance) IBM WebSphere Portal Server, which is just screaming for separation of concerns (as in my four rules; [Shameless plug :) ])

Comment by Peter Svensson — March 7, 2007

The ugliest so-called portal of them all is of course Microsoft Sharepoint. Unfortunate for all of those who have to use it but worse for those who have to develop with it. I take JSR168 any day.

Comment by Kevin Hoang Le — March 10, 2007

JSR-168 portlets are really an obsolete and unnecessary technology these days — something that’s only pushed by the big-vendor/consultant miltary industrial complex.

If you’ve got money and time to burn, then JSR168 is perfect for you.

Our organization wasted a huge amount of time and money going down the JSR168 route — pushed on us by consultants, and embraced by one PHB (pointy-haired boss).

The amount of unneccesary, artificial complexity was amazing. And the complexity just snowballed as we found that the portal code infrastructure just got in the way of developers and designers, and we had to craft workarounds for some really simple problems.

We finally abandoned the project, but not after an immense waste of time and money. A simple, lightweight non-enterprise Java solution would have brought us to market in less than half the time, and with a lot more flexibility.

Meanwhile competitors did many times better than that, using ultra-lightweight LAMP-based platforms to deliver offerings much more quickly, with richer functionality — and that were way more polished.

Actually, it was the extremely bad experience with this portal project that finally pushed me to try Ruby on Rails. In that sense, maybe JSR168 was the best thing that ever happened to me. I was able to implement a version of the app in less than a month. And I was able to have fun doing it too.

So thank you JSR168, for finally making it clear to me just how stupid and wasteful enterprisey technologies are. It’s been a career and life-changing experence for the better.

Comment by Anthony — March 10, 2007

Don’t mix all in one: JSR-168, portal and enterprisey technologies. I agree about JSR-168, it’s out of date now and introduce complexity without reason (well, there are some reason behind the scene). Anyway portal technology is different. I am in portal/portlet development about 6 years for now and guess … we never used JSR-168. Portal engine is very complex framework that suppose to solve very complex problems, don’t even try to implement something like this by your team. So Portal is good solution for complex enterprise geterogenous environment. But using JSR-168 over there MAY be waste of time (say, in 95% projects).

Comment by Dmitry — May 14, 2007

Leave a comment

You must be logged in to post a comment.