Here are some of the interesting 2008 predictions I have come across
A few days back I noted how Apache Shindig is disconnected from the Apache Portals project. Janus Boyce of CMSWatch has opined that this is exactly how Apache functions - innovative but disconnected.
Recently I came across the Apache Ivy project which seems to reinforce this sentiment. Apache Ivy is a dependency management framework tightly integrated with Apache Ant, the build tool. And if you use Ant + Ivy you get most of the stuff that can be done by Apache Maven, the software project management tool.
While the Ivy project developers make a fair argument, it is true that there is a whole lot of redundancy across Apache projects that needs to be fixed lest it leads to confusion and fragmented developer communities.
This post is a part of the Portlet 2.0 (JSR 286) Tutorial series
Introduction to Web Portals
A Web portal is a website that acts as a single point of access for a wide variety of information. Think of a site like Yahoo.On Yahoo, you can check news, shop, read your emails, chat, play games etc. You also have access to a wide varietyof other content and services provided by Yahoo. Yahoo is a good example of a Web portal.
Web portals need not always be accessible to everyone. They can exist within the confines of an organization, accessible to only people who are a part of the organization like employees, contractors, partners, suppliers etc. These portals are called Intranet Portals.Portals like Yahoo, that are open to all, are called Internet Portals.
Web Portal software
While it is possible to build a web portal like any other website using technologies like Servlet/JSP, ASP, PHP etc, today there exists a wide range of software that help build a web portal pretty quickly. For instance, If you are a .Net developer you could consider using the Microsoft Office Sharepoint Server
The advantage of using portal server software is that the software would already have most of the common portal functionality in place. All portal software will offer some means of managing your users (user management), login/logout (authentication), skins/themes (customization), creating multiple user profiles (personalization), search etc. Most portal software will offer significant out-of-the-box functionality like RSS feedreaders and email/calendar applications. Thus portal software, in general, will reduce the amount of code that you need to write to have a portal up and running. It reduces your design/code/test/debug cycles and also makes your portal easier to maintain/upgrade.
The disadvantage of using portal server software is that sometimes it might not be as flexible as you want it to be. All portals offer only a certain degree of customization. If you require something beyond that, you might be better off writing your own solution. Most portals are bulky, loaded with features and functionality. If you are looking for something that's simple, the size and complexity of the portal might come as a pain.
Java Portlets
While all portal software offer many useful out-of-the-box functionality, sometimes it is necessary to write your own custom code and "plug it" into the portal. Java portals allow you to do do this by writing a standardized plugin component called a Portlet. The Java Portlet , defined by the JSR 286, allows you to write your own code and put it into any compliant portal server. Just like you can write a servlet and deploy it to any web server/servlet container , you can write a portlet and deploy it to any portal server/portlet container.
There are a wide array of vendors that support the Portlet spec. IBM, BEA, Sun, Jboss, Liferay, Apache, Exo are a few examples.
In this ongoing series of blog entries I intend to provide a comprehensive guide to creating web portals using the Java Portlet technology. This tutorial assumes prior knowledge of Java Servlets and Java Server Pages (JSP).
Posts in this series
Been trying to update myself with whatever’s been happening in the security space. There are two new specifications in the realm of authentication and access control that seem to have potential to create a huge impact : OpenID and OAuth. Unlike other efforts in this space, like say the Liberty Alliance these specifications are (thankfully !) simpler and seem much more practical to use and implement.
OpenID
The vision of OpenID is to create a single unique identifier for a user, across the Web. This ID is in the form of a URI, any URI as long as the user has control over it. There are a bunch of OpenID providers (in OpenID parlance, an OP ) like http://www.myopenid.com. Sign up with them and you get your own OpenID URI. If you already own a registered domain name, then you can use the same as your OpenID. All you need is a simple setup to delegate your calls to an OpenID server. Finally, if you are really paranoid, you have the option to run your own OpenID server too.
Sites that accept OpenIDs are called Relying Parties or RP. When you use your OpenID URL in an RP, you get redirected to your OpenID Provider, you authenticate and get redirected back to the RP. The OpenID protocol ensures that the RP knows if you have successfully authenticated or not.
The industry response to OpenID has been lukewarm. All AOL users now have an OpenID. Many prominent sites have started supporting OpenID in some form or the other. You can find a list of supported sites at http://openiddirectory.com/
OAuth
OAuth is defined as a “an open protocol to allow secure API authentication in a simple and standard method”. Don’t be tempted to think that OAuth implies “open authentication”. It doesn’t. It is closer to “open authorization”. Let’s say you are registering as a delegate on a conference website. With OAuth it is possible for the conference website to automatically add the event to your google calendar or yahoo calendar with your consent (assuming google and yahoo support OAuth). How does it work ? Well, once you decide to let the conference website add an event to your google calendar, you get redirected to google. On google , you explicitly authorize the conference website to modify your calendar. After this authorization, the conference website will have permission to modify your calendar data.
Most portals already offer APIs to achieve this functionality, albeit in a proprietary form. Google’s AuthSub and Yahoo’s BBAuth are good examples. OAuth represents a standardization of this functionality.
Complimentary or Competing?
In theory, OpenID and OAuth are complimentary. OpenID helps determine who you are (“authentication”) and OAuth defines how you give access to protected data (“authorization”). A site that supports OAuth could also support OpenID for authentication.
However, my view is a little different. Given that the current trend amongst the internet giants (Google, Yahoo and MSN) is to : (a) increase their user base (b) make more people use their services, OpenID might not excite them. It works against (a). Even AOL, which has 63 million OpenIDs does so by being an OP. They are still not a relying party (RP). It will be interesting to see how they support it. Will you be allowed access AOL services with any OpenID ? Will you be asked to fill a whole bunch of profile info after login?
OAuth on the other hand ought to please these companies. They can keep their entire use base and data to themselves and yet allow third parties to integrate into their services. The more the number of external websites that integrate with them, the more their services will be used (Almost all popular websites today release a "developer” API for the same reason).
OAuth, in a way, makes the case for OpenID weaker. If OAuth was not around, it would have been tempting to use OpenID in order to expose one’s services to a larger audience. With OAuth, that argument no longer holds true.
Hence in my opinion, 2008 will see a rise of OAuth support while OpenID adoption might not be phenomenal.
Apache Shindig is an open source OpenSocial container. It is possible that Shindig ends up being the reference implementation for OpenSocial.
This does not seem to be related to the other Apache Portals projects at all, which is quite surprising.
Been playing around with the OpenSocial APIs. While the promise of OpenSocial is impressive, the current release is premature and buggy. If you are a developer planning to get your hands dirty, I would recommend that you give it a little more time.
If you are a portal vendor, this is a space you need to watch out. I'd expect most portal servers to support the OpenSocial APIs at some point.
Check out this interesting article on TechCrunch : The New Portals: It’s the Bread, Not the Peanut Butter
I think the author makes a very valid point.
Check it out:
http://www.findmyghar.com
I have used the YUI Grids CSS to create a 100% fluid layout. YUI Menu has been used for the top navigation bar.
I am not a front-end engineer. When I designed findmyghar.com I spent a lot of time getting the UI right. What looked beautiful on one browser was horrible on another. And the same user interface looked totally different in different display resolutions. Eventually, I had to rewrite the entire User Interface (yes, I write HTML manually :-) so that it worked properly on the most popular browsers and display settings.
Ever since, I have been hunting to find a better solution to the user interface problem - cause I never thought that writing HTML was such a pain. And that's how I discovered the Yahoo UI Library (YUI) project. I was, and still am, a little surprised because I didn't really think Yahoo cared much for the developer/hacker crowd. I thought they were just busy making money :-) Apparently, I was mistaken. Or perhaps things have changed. Whatever it might be, looks like they have a pretty good developer strategy now.
The first question I had in mind when I checked out YUI was: "Can it work with Google Maps ?" After mucking around a little bit, I have figured out that it is possible. Couldn't find too many examples, so I am posting a simple one here.
You can download the attached simple.html (I have zipped it up). All you need to do is to replace [YOUR GOOGLE KEY] with your Google key and host the page. You will actually see something like this:
The code is self explanatory. You define a div called "map". You then create a Google map in the div:
map = new GMap2(document.getElementById("map"));
You also create a Yahoo context menu on the same div:
oMenu = new YAHOO.widget.ContextMenu("basicmenu", { trigger: "map" });
Now, right-clicking on the google map will invoke the Yahoo context menu widget. And every menu item has javascript that invokes the map.
There you go. Have fun !
Recently I put up a small Web 2.0 site which can be used for sharing real
estate information in the city of Bangalore. It uses Google Maps (duh!) and a
a few other open source libraries.
You can check it out here : www.findmyghar.com.
Ghar means "home" in most Indian languages :-)
Just noticed that the early draft version 2 of JSR 286 (Portlet 2.0) was open to comments last week : Portlet 2.0 ED2
Looks like this is finally getting somewhere :-)
I just noticed that eXo has announced the first portlet 2.0 container implementation. Great move on the part of eXo to get there first.
Kudos to them for that !
However, I am pretty disappointed with the quality of this release because I am yet to figure out how to get it running. After starting tomcat, all I see is a page which asks me to select some of the listed portlets. The listing however is empty (Windows XP, jdk 1.5, IE7/FF2, if it matters).
As for documents, they don't seem to exist :-)
Here's a quick question : which one of these environments makes you more productive ?
In my opinion, web portals in their current form might not be around for long. They would be replaced by what I would like to call "desktop portals" or "widget portals". Here is why :
I am pleasantly surprised. Ever since I closed down my work blog : The Portal Zone, I have had a lot of friends, coworkers and blog readers urging me to continue blogging on the same subject.
Some mentioned that they found my notes on JSR 286 a good learning resource. Some were more interested in the occasional commentary and linking. These are some of the reasons I am starting this blog – the new and improved Portal Zone :-).
However, the primary reason I am starting this blog is because I find blogging to be a great learning experience. They say the best way to learn something better is to teach it to someone else. I have found the same holds true for blogging. When you blog about your opinion, your understanding of a technical concept or your ideas, you are expressing yourself to the whole world. Anyone who has a counter argument, a different way of looking at the same thing is free to leave a comment- question your understanding, and sometimes set you thinking in a totally different direction. Therein, in my opinion, lies the real value to blogging.
That said, I do hope that at least a few developers do benefit from this blog.
Welcome to The Portal Zone !!
This work is licensed under a
Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.
Subscribe in a reader
