Middleware, at its most basic form, is the stuff that lets System A talk to System B.
For example, if you are a staff member at Case and you decide to take some classes, so you are now a student and a staff, a new account doesn't get generated for you. Middleware reconciles the fact that you are the same person, just coming from two different systems (or more). This processing is easier said than done, and you would be *shocked* to learn that most colleges end up generating its users different accounts each time a person appears in a different system: Registrar, Human Resources, Alumni Database, etc. We don't do that here. We try to handle all of those systems appropriately. Additionally, we handle several other schools/organizations (with more coming everyday).
So, what you end up really looking at:
Boiling it down, Middleware is not about developing/deploying/supporting applications; rather, it is about designing and creating general frameworks that other applications plug into and use. Things like Directory Servers, Active Directory, Oracle Internet Directory, Kerberos, Meta-Directories, etc.; these are components of Middleware. Authentication (which is "prove to me who you authentically are") is part of Middleware. Authorization (which is different than authentication) is part of Middleware. Public Key Infrastructure is part of Middleware. Federated Identity and Identity Management are part of Middleware. There's a lot of fun stuff in Middleware, and it makes it interesting to work on. The harder the problem; the more interesting it is.
"So, you work in Middleware; and Middleware does all of this stuff... so, why do you work on the Blog@Case system?
Well, we Middlewarers tend to dabble in a lot of stuff. We take care of the email system and the calendaring system and the spam control and the email anti-virus stuff and the new mailing list manager (and, the old MLM, for that matter) and we run a web server that hosts some CGIs and some other virtual hosts and some of us do some hostmaster stuff and IP address database stuff and some of us (I believe) even help with some of the PPP stuff and cable stuff. (That is all in addition to the regular "Middleware" stuff I described before.)
And, yes, we are but four.
And, yes, we do develop and run the Blog@Case system. And, there's a tiny little story with that. I'll share it with you because, if you have already read this far, you probably aren't turning back now.
Back in November of 2003, I wrote a proposal stating that Case should offer a blogging service. I was already an avid blogger, and I could tell that a blogging service could be very impactful in a University setting. And, I had all of these grand visions for what a University blogging system could do. Visions of sugar plums were dancing in my head. But, the proposal ended up not stirring up anybody's attention. It probably got placed in a desk drawer somewhere and forgotten.
"Alas," I thought to myself, "if only engineers ruled the world."
Fast forward to the Democratic National Convention of 2004, where they had setup a special area for bloggers to cover the convention. And CNN and MSNBC we giving bloggers press coverage and "bloggers this" and "bloggers that" and "blogblogblogblog." Shortly, thereafter, someone stopped by my desk and said, "we should really offer a blogging system at Case."
So, since I had written the proposal a year ago, it fell into my lap. So, I whipped it out (in record time, too). And, here it is.
So, that's the "Everything You Wanted to Know About Middleware But Were too Afraid to Ask" post and the Blog@Case story. Now, I have to write my real "About Jeremy Smith" page.