Transcript slides - grove.me.uk

Portal integration and code
reuse in portlets.
Matthew Grove <[email protected]>
Portal Developers Workshop, February 2008
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 CSSfu.
• 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 signon 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).