Web Proxies for Fun and for Profit

I submit that one of the most powerful and valuable, yet most under-appreciated, features of uPortal is the CWebProxy channel.

Somewhere, somehow, at your institution, you are managing some HTML. Maybe it's handcrafted HTML lovingly maintained via Vi, or maybe it's in a rich content management system, and probably you have both and everything in between. You can manage HTML fragments suitable as channel content however you manage other HTML content at your institution and so long as it produces a content fragment that uses portal-appropriate styling, you can use the CWebProxy channel built into the uPortal framework to present that content. Advanced usages of this API even include some neat tricks around tagging links to determine whether they will open their content into that same channel box or whether the link takes the user out of the portal and of course you can do the target=_blank trick to pop new windows on click leaving the portal session available in the existing browser window.

Another common approach is to invent an XML language for your content (links? A tree menu? Something else?) and then use the CGenericXSLT channel to transform that XML via XSLT to present it in the portal. Then you can manage the semantic content of the channel in the XML doc and the styling of the channel in the XSLT.

There are JSR-168 versions of these channels, with an enhanced or at least different mix of features. At present in uPortal you can buy some standards adherence and cross-portal possibilities by adopting these portlets, at the cost of accepting some additional complexity. One neat consequence of adopting a web proxy architecture is your choice of within-portal binding becomes only loosely coupled with the backing content, such that if you build CWebProxy-fronted content and applications today, you have a clear and incremental upgrade path to instead front those resources with a JSR-168 portlets when that move makes sense for you.

Using web proxy technology also helps to address increasing desires for robustness in the portal as universities use portals for more and more critical services. Producing content and doing interesting business logic elsewhere than in the portal JVM and proxying or transforming the output of that through the portal isolates those applications outside the portal JVM. They may fail, but if they do, their failure is limited to breaking an individual channel in the portal and is isolated from affecting the rest of the channels and portal systems. Web proxy technology applies not just to simple static content and links you can use the CWebProxy channel or the UW Web Proxy JSR-168 portlet to proxy entire applications written to produce portal-appropriate markup, with those applications then free to be hosted elsewhere and implemented using whatever technologies you are comfortable with .NET, ASP, JSP, SpringWebMVC, PHP, Ruby, at that point the world is your oyster. Those proxied applications then have their own maintenance windows and outages independent of the portal. Adoption of a single sign on framework including proxied credentials technology -- CAS foremost among these, but there are others -- along with pervasive SSL secures the pipeline between proxied applications and the portal.

Yale University and Rutgers University uPortal instances demonstrate some applications of this loose coupling approach, and Susan Bramhall (of Yale) in particular took the time and care to present on this topic.