Evolution of the Campus “Middleware” Computing Environment

A modern university is asked to maintain an increasingly complex computing environment, “seamlessly integrating” the computers, users, and systems that are now linked through a common network. Vendors run expensive advertising campaigns showing how wonderful integrated environments can be, but never showing what it actually takes to achieve integration. When the computing reality includes new and old systems from a variety of vendors it is a major to get systems to work together at all, much less be “seamlessly integrated”.

The technical key to integration lies in what are called middleware systems, with somewhat obscure names such as DNS, DHCP, LDAP, and Active Directory. The name middleware comes from the favored approach to linking two application systems, say A and B. Rather than modifying A to match B or vice versa, system M designed to work with both A and B is placed in the middle. If standards are adopted defining how middleware systems work, they can be used to integrate a large set of components and in a manner that is relatively immune to changes in individual components. That is, A can change to A’ without any impact on B, as long as A and A’ both interact with M according to standard. Standardized middleware components are the key to integration. Unfortunately, because this is still an emerging technology there are obstacles to be overcome and contention as to exactly how middleware can and should be used.

The reality on the UM Missoula campus and broader collection of four UM is the need to support and integrate a highly diverse collection of components. These include multiple operating systems (OpenVMS, Unix, MacOS, and Windows NT, 2000, and 2003), as well applications such as Banner, the on-line library system, email, and others. The relative immature of middleware standards, conflicts between different versions of the standards, and need to support “legacy” applications that pre-date the standards provide major challenges. There is likely no one design that can support everyone’s ideal integration goals, so some compromise is inevitable. We also know from the start that resource conflicts are likely, because new resources are likely to be needed and resources are scarce. Though there are real technical issues involved here, equally important is the social challenge of approaching middleware design in a manner that produces acceptable compromise rather than just contention.

The purpose of this memo is to announce the formation of a Middleware Task Force chartered to look at campus-wide middleware needs and produce a report identifying requirements, alternatives, constraints, and resource implications. The report will be widely circulated to guarantee campus-wide review. The Task Force will identify viable alternatives and resource implications – it will not unilaterally define the middleware design for the campus. I’ve asked Profs. Joel Henry from Computer Science and Shawn Clouse from Business to lead the Task Force. They will be joined by four to six other technical staff to be selected from units across campus, giving the Task Force a wide range of expertise. This group is not asked to know or decide what is best, but rather to work with other local and national experts to find out what is needed and what is possible. I hope that all who are involved with designing and supporting computing facilities in units across campus will assist the Task Force in this effort.