Matthew Grove <m.grove@rdg.ac.uk>Portal Developers Workshop, February 2008

Portal integration and code reuse in portlets.

Outline

• This talk describes our experiences with two approaches to integrating web applications.

1. Skinning (themes).

2. Embedding inside portals.

• The message is: we don’t want re-write or fork code and you don’t have to.

• The VRE II VERA project is used as an example throughout the talk.

What do we mean by integration?• There are a huge number of well maintained web

applications which have had a lot of time and money invested in them.

• You probably already use some of these applications (including portal containers) in your projects.

• By integration we mean assembling a system from several existing web applications and making the whole system look / behave the same from a users perspective.

• We don't want to re-write everything or fork established projects if possible. If we fork things, who is going to maintain them? Do we have the money to maintain them?

Two approaches to integration

• If you want to use a portal container you could integrate the portal into your existing system (make a skin for the portal).

• You could embed an existing application inside a portal without re-writing the application (using bridges and scrapers).

• In the VERA project we have tried both skinning a portal to integrate it with an existing system and embedding web applications inside a portal.

Web application skinning

• VERA has a web presence which is also the platform for our research environment.

• We used off the shelf web applications to provide the wiki and the blog.

• We had to skin the wiki and the blog to provide a consistent user experience (integration).

• The skins consisted of CSS and a bit of JavaScript. Not a lot needed writing from scratch because we already had CSS and JavaScript from the web site design itself.

The VERA website

Skinning pros

• Can be almost trivial to do if you have strong CSS-fu.

• No forking code - we can use mainstream packages supported and maintained by our Linux distribution's package management system, so security updates are essentially automatic for us and we don't have to maintain any code.

• This approach is language agnostic, web applications could be written in Java, PHP, Python etc.

Skinning cons

• No single-sign on built in. However, we have added this before in other projects like the acet.rdg.ac.uk site, where we made all of the web applications single sign-on.

• It relies on the web applications you choose supporting skinning.

Skinning a portal container

• Remember you will be skinning a portal container not a portlet.

• This can be just like skinning a web application like Wordpress or Drupal.

• We did this for Gridsphere 3 (GS).

Skinned Gridsphere

GS skinning experiences

• GS does support themes (skins).• GS lets you include JavaScript for a portlet but not for the

whole portal (this makes our little up arrow at the top of the web site break). We fixed this by hacking the GS code (forced to break our own rule - we don't want to fork the code!).

• JavaScript is going to be more common with Web 2.0, supporting only CSS is not sufficient for skins any more.

• We couldn't make some page elements do what we wanted because of the structure of the XHTML but we got the rest of the page looking identical to the rest of the VERA site.

• Changing the URL for the container broke everything for GS; we have heard that this is fixed now. We could have got round this by using something like Apache rewrite. The URL is another aspect of providing a consistent user experience.

Skinning summary

• If you have existing applications or want to use some complex web applications that are maintained by the community, maybe you should look at skinning for your integration.

• What it boils down to is how much effort is required to port everything to a portlet compared to writing some skins.

• We could adapt the authentication system we used with the acet.rdg.ac.uk site to provide single sign-on to integrate web apps outside of portals.

Embedding apps inside portals

• This is almost the opposite approach; the web application goes inside a portlet.

• The tricky bit is how to get a web application to look like a normal portlet to the user without rewriting the whole thing!

• There are existing tools such as the Portlet Bridge (now un-maintained) which let you embed some web applications inside portlets by using web scraping techniques.

When web scraping fails...

• VERA is committed to getting an application called the IADB inside a standards compliant container.

• The IADB is 15 thousand lines of PHP and JavaScript, we are not going to re-write it.

• We have worked with the web scraping tools during VRE I, and we know that the existing web scraping tools can't cope with a site like the IADB. Mainly because of the nested iframes and complex JavaScript that the IADB uses.

• In this kind of scenario other people have tried using iframes but you can end up with an application which does not integrate well into the portal from a users perspective. The main issue is the lack of single sign-on (you log into the portal then have to log into the embedded application again).

Vanilla IADB

Single sign-on for embedded apps • The elegant part of our solution is to use the client

(web browser) to link the authentication information between the portal and the embedded application being consumed.

• We wrote a portlet called the Recycle Bridge which sets a cookie containing the username of the user logged into the portal.

Recycle Bridge cont.

• The Recycle Bridge uses an iframe to display the embedded application inside the portal.

• You have to write an authentication plugin or patch for the application that is embedded to use the cookie (and suppress the applications log in screen).

• From the users perspective the application looks like part of the portal.

• There are settings for the Recycle Bridge to alter the appearance of the iframe to try and make the integration seamless from the users perspective.

Wordpress in the Recycle Bridge

Security for the cookie

• Essentially the web application needs to have a way to trust the cookie contains authentic user information.

• The Recycle Bridge shares a secret security token (salt) with any web application you want to embed. When you set things up you must provide a unique salt in the configuration files.

• The Recycle Bridge includes an MD5 hash with the cookie based on the salt and username to provide a way for the authentication plugin to check that the cookie has not been tampered with.

Writing the authentication plugins• This plugin approach is language agnostic -

we can support any language that can read a cookie.

• We have split the process into two steps:– We have a generic library which provides

the functions to read the cookie and check it is valid.

– You will need a plugin or patch for the specific application you want to embed.

Plugins cont.

• We have written the authentication library for PHP.

• And plugins for:– MediaWiki (runs Wikipedia).– Wordpress which is a very popular

blogging app.– We also wrote a patch for IADB, we have

check in access to the IADB source repo.

We want your code!

• We want more plugins and libraries.

• The Recycle Bridge SVN repo is set up to make it very easy for us to accept code from you.

• Even if you write a plugin for some obscure application, if you split the cookie functions out into a separate file (library) you will be helping anyone who wants to embed an application written in that language.

• We are happy to help you write your plugin, especially if it uses a language we don't yet have the library for.

We want your portals!

• The Recycle Bridge is a JSR-168 portlet.

• As we all know, unfortunately portal containers do not have standard XML files for portlet deployment.

• We want help testing Recycle Bridge in your container, we don't have the manpower to install and test every container.

• If you tweak anything to get the Recycle Bridge to work in a portal, we want your changes!

Summary

• We have tried two ways of using portals to re-reuse existing web applications.

• In the first we treat the portal like just another web application and integrate it into our website along side other complicated web applications using CSS and JavaScript skins.

• The second approach uses the Recycle Bridge to embed existing web applications into a portal.

Future work

• We hope the Recycle Bridge will be useful for other people who are heavily invested in applications they don't want to / can't afford to re-write as portlets or who want to use web applications which are maintained by the community (like MediaWiki).

• We would like your help writing adding support for more applications to the Recycle Bridge.

Links

• http://vera.rdg.ac.uk/software/ - Recycle Bridge homepage (with code).

• http://acet.rdg.ac.uk/~mjeg/blog.php - Blog aggregating all of my research activities.

• http://www.portletbridge.org/ - Portlet Bridge (best of the web scrapers).