Those exploring the OpenPortal community will be interested in reading this articulation (by Simon Phipps, Sun's chief open-source officer) of the diverse perspectives that must be grasped in order to understand the dynamics that drive open source --

The Meanings and Motivations of Open-Source Communities

If you want to build a rich user interface web application that requires several state changes, spans multiple business processes and requires complex data handling at the back-end and still want to give the users a really rich and consistent experience (no refreshes!), then do have a look at Flex as I believe that it is definitely a good choice.

Refer Sandeep's blog to get a fair idea regarding flex and it's advantages. After that if you are ready to try your hands on it, have a look at my blog where I have explained this with an example.

Often people ask me what I do for a living. The work of the user experience person includes a wide range of activities including (but not limited to) -

   - gathering requirements from users
   - developing user scenarios  
   - creating storyboards that illustrate how the product will be used in different scenarios  
   - designing the detailed UI flow and the screens   
   - conducting user tests
Read more in my blog entry Purple People Eater.

Rajesh has an interesting observation on using Google commands to discover some external/internet-facing deployments of Sun Java System Portal Server. So essentially a peek at the power and simplicity of Google search, as well as some insight into the adoption of Sun's Portal in a particular category (i.e. external-facing), if you will.

Basically, you can type -- inurl:"/portal/dt" -- in the Google search text box to get a sub-set [1] of the external/internet-facing [2] Sun Portal deployments on the web. The results show diversity of deployments; traction in the commercial/enterprise, government, education, etc spaces..

[1] sub-set since this may only capture the deployments that have not modified the default, out-of-the-box URL ("/portal/dt"), as well as largely picking non-localized deployments (Sun Portal is localized in many languages), etc. Also, the search results presumably reflect the extent of what Google picks up at any given moment. Other caveats may apply.

[2] internet-facing since obviously the search results do not capture intranet URLs; a large proportion of deployments are inside company firewalls (e.g. B2E, etc).

OK, so this did the rounds on the blogosphere many months back and The Portal Post missed out on the fun (er, pun).

So let's spin it, shall we. Here we go --

Ah, so, not so much when you compare it for example to Jonathan's near $ 1M valuation.. but a modest start.. And thanks to your readership (and authorship, for those taking the time to write on this space) we hope the stock continues to climb... :-)

Note: if you wish to dig deep on how this is calculated, read basis/assumptions/limitations from the source (e.g. this is based on Technorati sources).

Sun is a great place to work for telecommuters. Of Sun's 35,000 employees, 13,000 are part of the iWork program. So being a telecommuter at Sun does not make you feel isolated from the rest of the group.

But I always find Dilbert's take on telecommuting very funny. Here's a compilation of Dilbert's telecommuting related cartoons. Enjoy!

P.S. Note to my manager: The time it took me to write this blog counted as work. ;) 

This cartoon from gapingvoid.com says it all :-) 

And now back to regularly scheduled programming..

    The OpenPortal build has started to consume the OpenPortal Portlet Container binaries on the fly :) This just goes to show how modular the Portlet Container itself is, and how easy it is to consume it. Moreover, it provides for innovation to happen in pieces. So contributors to the Portlet Container can continue to contribute knowing that it is not going to be just part of a server side component, but it will be part of an enterprise level Portal implementation.

The Ivy dependency management tool is being used to manage the dependency on the Portlet Container. This is part of the OpenPortal component based architecture, and is thus providing fruitful results. For instance, if a developer just wants to check out the portlets to test for compliance or to just get a feel of how it might look and work, the OpenPortal Portlet Container, which provides the runtime environment for Portlets, can be downloaded and used easily. The same can then be deployed on the enterprise class OpenPortal knowing that it will work fine, since the OpenPortal is just bundling the same Portlet Container that you tested on. Similarly other components will be consumed on the fly thus providing the level of flexibility yearned by everyone in the open community.

So, if you are still on the fence about the OpenPortal community, just be careful, for the fence is becoming thinner and there is a good chance that you will be forced to jump over it to our side very soon :)

Sang Shin, from JavaPassion.com, and also a Sun technology evangelist has released a brilliant new tutorial on Building Portlets with Ajax behavior. This tutorial comes with a hands-on lab and covers everything from installing the right plugins in your Netbeans IDE to deploying your portlets in the OpenPortal Portlet Container. A couple of portlets he uses in the lab are from the OpenPortal Portlet Repository.

If you have been waiting for some good information to get your hands dirty with Ajax and Portlets, then it won't get any better than this. And if you happen to build any exciting portlets, be sure to contribute them to the OpenPortal Portlet Repository for others to use!
 

When bringing an application into a portal, when is a Web service better than an old-school portlet? That's not a rhetorical question  - what do you think?

 The answer will probably vary, based on the type of application you want to expose. My work has been primarily with commercial ISV's (Citrix, Elluminate, Documentum, etc.), maintaining our Core Portal Ecosystem. Originally, every portlet project was 100% custom. Most ISV's had decent API's, but it was still a lot of manual work (not to mention constant business negotiations, measurement, etc.). The rapid adoption of the Java Portlet Specification (JSR 168) standard helped (by providing a container, consistent authentication mechanisms, etc.), as did WSRP's enabling of Web service consumption. Better still, many ISV's began publishing and supporting portlet sets of their own, taking over about 80% of the portlet development work.  However, even with these advances, code to support portal-specific features (e.g. single sign on and, in our portal's case, Secure Remote Access) was still done largely by hand.

This Google spellcheck portlet started with a Web Service. To learn how to build this yourself, visit the tutorial. 

Clearly, Web services are the future for commercial ISV portlets. Some are already phasing out portlets in favor of publishing Web services (Interwoven and Business Objects come to mind). SIDE NOTE: I've been advocating the creation of a core series of reusable infrastructure services (e.g. a single sign-on service, a secure remote access service) to glom* together with the ISV services as our model for supporting commercial portlets going forward. Some of our gifted engineers are validating the concept as we  speak. What's your take? 

Also, almost half of the proposed features in the upcoming Portlet Specification 2.0 address WSRP alignment. So where does that leave the portlet as we once knew it? Is it strictly to be used for obscure, one-off tasks or ...?

Which method do you prefer in which circumstances? Please share your ideas and experiences.

Thanks-
Kim Buck

PS - If you're interested in portals, you're probably interested in SOA. For a glimpse into Sun's SOA ISV community, feel free to visit my SOA Solar System blog. Most of the content is business oriented vs. technical, but it's a good place to learn about  how SOA vendors - from established platform players to innovative startups - are shaking up that space.

*glom - to mash, to moosh, to adjoin with reckless abandon (trademark pending) ; )

David suggests that portals evolved from a web directory (Yahoo) to search (Google) and have now morphed into a mechanism to share information (Facebook, MySpace). According to him, portals of tomorrow will provide a 'social graph' - a network of relationships that will push information to you. So it's no longer the portal administrator or content editors who will decide what you see on your portal. Heck, it's not even you who'll decide what you see on your portal; it'll be your social graph! (Of course, you'll still have control over whom you want to hear from.)

The important point David makes here is that aggregation is no longer the only core function of a portal. The new portals are all about sharing. It's about using your social graph to learn and to share more efficiently. David emphasizes that the social graph will not replace search, but augment it with new capabilities. So he warns us to not look at sharing as the peanut butter, but look at it as the bread itself. In other words, the social graph shouldn't be considered as just another feature, but as a core function of the portal itself.

We, in the Sun Portal Server team, could not agree more with David. And to prove it we've been working over the past two years on making our portal completely "share"-ready. The Sun Portal Server 7.x has community features baked right into the bread (see this demo) so that you don't have to worry about finding ways to make your users talk to each other. It allows users to create Wiki-based communities that can be used by community members to share information. Access to these communities can be open or restricted. The communities can host portlets that will allow users to share documents or discuss on topics using a forum.

However the sharing features that we focussed on thus far were mostly from enterprise users' point of view. I believe enterprise portals should look for inspiration even outside the enterprise landscape. There are number of features that are implemented by the current crop of web 2.0 websites that'll be very useful inside an enterprise. For example, the social news ranking feature implemented by Digg can be used by enterprises to foster bottom-up innovation. The portal will be then transformed into an idea marketplace where feedback for new ideas can be sought from a large community instead of a handful of people. Similarly tagging and social bookmarking can further improve the social graph of an enterprise.

The ideas are out there, and with OpenPortal there is a robust open source portal platform out there as well. Now all we need to do is to go convert these ideas into code. Wanna sign up?