Tip:
Highlight text to annotate it
X
Okay, I guess we'll just start with a brief background and history here at Hopkins with
uPortal. It started as a pilot project back in summer of 2005. At the time Hopkins IT
was working closely with the library, specifically with Elliot Metsger who helped launch the
initial portal in February of 2006 to a pilot audience.
I began working for Hopkins in April 2006 as tech lead of the portal.
June 2006 was our first launch to an official audience. We herded all of our incoming freshmen
in through the portal to provision their email accounts and their JHED accounts. JHED is
their directory account here at the University that gives them access to all the resources
at Hopkins.
So we had about 2,000 users at that time come in and we've grown to about 80,000 registered
users. We get about 2 million page views per month now with about 15 to 20 thousand unique
users per day.
We've put a lot of highly visable highly used applications like search, the Web-based SSL
VPN software is offered through the portal, there are a number of resources, for JHU staff
their timesheets are filled out through the portal.
All provisioning of the incoming freshman class to JHU is still done through the portal
so we've got another round coming up in June about to start their provisioning.
So obviously our user base has grown tremendously. That's happened over time as we've introduced
new services and centralized services into the portal.
We should talk about sign on.
At Johns Hopkins we use a product called Netegrity Site Minder for single sign-on and we have
about 300 applications currently protected with Site Minder authentication not all of
which are available through the portal but quite a few of which are available right through
the portal.
With all that said I'll jump into the demo. We're not only offering a portal to the university
constituents, we're also supporting a portal for the Hopkins medicine organization, also
the hopsital.
So we've got a lot of clinical apps we're starting to look at integrating into the portal
as well as the university community's.
We actually have right now four public-facing entry points into the portal. We've implemented
custom URL based personalization. If you go to my.jhu.edu you'll see the portal that you
see right now on the screen.
If you go to my.jhmi.edu that redirects you to get a different skin. The content looks
the same there but it's actually housed in a separate area in our content management
system.
We also have the School of Advanced International Studies. They're out of Washington DC but
they're also offices in China and Bologna. They maintain all their own content as well.
That's another public entry point. So if you go to insider.sais-jhu.edu that's another
public entry point and they manage all their own content as well.
We also have worked with the Engineering for Professionals which is a part of Johns Hopkins
University. They have their own skin and their own public entry point which is myep.jhu.edu.
We're also working with the Carey Business School. They're working on their own skin
and their own public entry point as well.
This is all being served from the same portal instance. To give you an idea of what our
setup looks like:
We have six physical machines that are serving our portal that are fronted by two switches.
They're actually spread across two data centers, so our load is distributed across two data
centers, across six app servers. We have two virtual machines on standby that we can just
throw into the mix at any time.
We're using Tomcat 5.5. We're actually running on Win they're not Linux boxes and we're fronting
it with IIS. We have a number of custom Cold Fusion applications that we proxy into our
portal that are running on these same 6 portal boxes.
We're looking in the next year to go completely virtual and not have any physical machines.
We also have a development environment and a staging environment. We convert one of our
prod boxes into a pre-prod environment when we're preparing releases.
We release probably on a monthly basis, sometimes more, sometimes less depending on what we're
putting out.
We try to stick to a monthly release schedule and we try to pumpt things through the development
staging to prod as much as we can.
So I've got to show you the authenticated view. There's not much useful content to individual
users per se in the public entry points. Except for SAIS, they've done a really nice job at
posting latest news and events and things like that.
But the authenticated view looks something like this. And this is just my experience,
just to give you an idea. We have close to 30 individual DLM fragments defined for the
various constituencies within both the university and the hospital so we have a large number
of interested communities in publishing content out to those individuals who want to receive
it.
We heavily use PAGS [Person Attribute Group Store] and we also use the Smart LDAP Group
Store for Active Directory integration. We consume close to I want to say about 50 Active
Directory groups right into the portal to use for authorization for resources within
the portal channels, DLM fragments, things like that.
We're making JDBC calls to get person attributes. We actually have some custom person directory
plugins that make web service calls. We have web service calls going out to WebCT to get
their IMS id as a person attribute so we can use that to assign permissions.
We
really were excited about the Quick Links that came along with uPortal 3.
Just to note, we were one of the early adopters of uPortal 3 back in the summer of '08 I believe.
I guess we launched in the August-September timeframe.
We've been on uPortal 3 since then and made a number of incremental updates to the codebase.
Tried to patch our code base with security patches and things of that nature.
Have been looking at a jump to 3.1. We're still evaluating what we're going to upgrade
to.
We were really excited when we first jumped onto 3.0 about the Quick Links. Instead of
relying on the portal framework to provide that functionality, we broke that funtionality
out of the portal and wrote our own app so we could proxy that content in. You know,
let the portal do what it does best and we kinda just enhanced the quick links so we
can group links. So we have multiple mail systems here at Hopkins. As you can see I
have four different quick link icons that break out into a horizontal.
One thing that one of the developers here did is give us a quick email preview, it makes
a Web Service call out to Outlook and just displays a real quick link and actually when
you click one of these emails it will just take you out to a separate browser session
through Outlook Web online.
These quick links are configurable. We have a configure quick links that breaks out here.
I don't necessarily want to see all the quick links that are available so this gives the
end user the capability to control their quick links. We really like the idea of being able
to control pushing out required links to people but we wanted to give the end user the control
to do that.
From an administrative standpoint you can lock down the quick links to be readonly so
they have to get it. So everybody has to get the first quick link here which is the "my
profile" which gives them access to their directory information and their visibility
attributes and things of that nature.
So that was one peiece of functionality where we kind of deviated from the core uPortal
codebase and rolled our own quick links based on the concept by uPortal.
We're actually using Quick Links information that's in the uPortal tables itself but the
application itself is just standalone.