Portals and Web Applications

There are many tools for building web applications and portals, so it is useful try to classify these a bit. The field also suffers from overlapping terminology ("framework" providing the worst example) and overlapping functionality. I'll take an informal stab at trying to organize these things.

Programming Tools and Languages: this is the simplest group (hopefully) to define. PHP, PERL/CGI, Java Server Pages and Servlets are all examples. One could argue that JSP is more of a development framework (below), but these aren't sharp definitions. I'll err on the side of usage--most people don't write JSP using beautiful MVC architected code.

Goodies and Widgets: these are useful little or medium-sized extensions that can be easily plugged into several different development environments. PEAR/PHP and Java Tag Libraries seem to be best examples on the server side. Various JavaScript libraries (such as YUI) are good examples of client-side applications. These can be embedded into several different toolkits and frameworks. These are distinct from development framework modules (i.e. Ruby on Rails modules) since they are meant to work with both Programming Tools (above) and more specific, derived Development Frameworks (below). Thus one can put useful tags into JSP as well as JSF.

Development Frameworks: Frameworks are typically one level of abstraction above the common programming language tools. Java is full of these: Struts, JSF, Velocity, etc. Ruby on Rails is another famous example. DWR, Google Web Toolkit, and other tools also fall in here. ASP.NET and various compatible, open source implementations like Mono go here.

Frameworks typically encode a development methodology (MVC) and provide an extensibility framework so that all developers create code more or less in the same way. Frameworks thus allow you to develop reusable and useful little modules that can be shared with other developers using the same framework.

A framework can be used to build standalone applications, but it can also be used to develop a rich, self contained component that can be deployed into a container. In contrast, a container (after installation) comes up immediately with useful tools such as login modules, layout managers, and some user tools (say, a calendar or a blog authoring tool). In this example, one may use JSF (a framework) to build a web calendar or a web email application, but one would also typically want to embed these into a more comprehensive container (a portlet container in the Java world).

Application Containers: Joomla (php), Zope (python), Mambo, and Drupal (php) are examples. Java JSR 168 containers and various similar efforts also fit here: GridSphere, LifeRay, uPortal, Jetspeed2, etc. Sakai is another example--it supports the Java standard but also has its own component model. Interestingly, the non-Java containers mentioned above all began life as content management systems.

Arguably only Java's portlet standard really takes the container philosophy completely seriously. Joomla et al, really don't care about portability of codes across container vendors, although they do obviously care about shareable community developed modules. All Java portlet container providers (except Pluto, the reference implementation) don't just give you a container for managing your own portal components--they also give you lots of built in functionality and other goodies (calendars, chat tools, document managers, etc). LifeRay and Sakai are good examples of this.

Related Things: Web-based containers for content and document management, blogging, wikis, and learning management are related closely to portals. There are many different content management systems. Learning management varies from Moodle to Blackboard. Blogging is often provided as an online service (such as Google's Blogspot), but you can also install and run your own blogging service. WordPress is a prominent example of blogging software. Many frameworks (such as Drupal) come with blogging modules. Wikis are similar to content management and document management systems. The best known wikis (MediaWiki and Twiki) are standalone tools, but many containers come with Wiki modules (Sakai for example).

Services for Portals: One of the dangers of portal tools at any level is that they can become monolithic. The danger here is that you will be stuck with inflexible technology and can't respond to changing requirements. The current Enterprise vs. Web 2.0 conflict provides a compelling example. Many famous Web 2.0 sites (flickr, youtube, etc) are Web Services as much as they are Web sites, so modern portals must be able to easily integrate (rather than compete) with these large third party services.

External services: there is a great temptation of course to bundle everything into a particular portal for simplicity of installation and maintenance. However, this is not a good plan in the long term since you will (for example) tie your managed content to a particular tool rather than a portable standard.

When choosing a framework or container, a good starting point in the evaluation process is to see if it supports clients to the following standard services.

• Authentication and Authorization: these are often tied to LDAP, CAS, or (in the Grid world) MyProxy. Shibboleth is an authorization mechanism. The basic idea is that the portal needs to go to an external database to get the login information. This DB is independent of the portal and may have other clients.
  
• RSS/Atom feeds are particularly important in Web 2.0 applications, since most of them publish syndication in some form or another. Many containers provide RSS readers. This is any easy way to incorporate external content (say, YouTube videos) into a portal.This is particularly important topic in modern education portals, as for example one may embed publication feeds from Connotea and CiteULike, slides from SlideShare or ImageLooop, SciVee or YouTube for scientific visualizations and online lectures, etc. As can be seen from the previous list, there are dedicated, high quality online services for many education and science portal content that can be incorporated into a portal pretty generically as RSS/Atom. It is a bad idea to reinvent this stuff or tie it too closely to your portal framework.
  

We may also turn this problem upside down: if you run a resource management portal,
you must be able to export that portal's content to other user interfaces such as iGoogle
and NetVibes that users are more likely to use every day.

• Calendars: Collaborative calendars are obviously best extracted from portals since there are so many calendar clients. This is also an example of a reversible service: you typically want to synch your online calendar with your local PC or mobile device. A relevant standard is iCal.
• WebDAV servers for content management. WebDAV is an extension of HTTP and is supported by many Web servers (with the right module, of course).
• Grid and workflow services for running scientific applications and accessing data.
  
• Digital libraries: access to Fedora, etc. Don't reinvent this or jackbooted librarians will be goose stepping into your cubicle.
  

It is of course inadequate to simply support such services through clients, as the implementation must be useful and enjoyable. On the downside, however, it is also hard to know when one has crossed the line that separates a rich, useful client from a full fledged internal service that can't be easily extracted from the framework. I certainly can think of several examples that I've written.

Social Networking: the other challenge facing education portals is how much to integrate with social networking sites such as FaceBook or LinkedIn.