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.
This work is licensed under a
Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.
Subscribe in a reader
