Middleware as Underwear: 
Toward a More Mature Approach to 
Compositional Software Development

Toward Maturity and Propriety

We think not. Indeed, we take the position that middleware should appropriately be considered the underwear of compositional software development. As such, propriety dictates that it should not be the center of attention. More specifically, we believe that middleware resembles underwear in that:

• Excessive fascination with it suggests immaturity. To date, there seems to have been an obsession with middleware and its properties. We believe that this emphasis has been misplaced, and had inevitably led many who are interested in compositional software to lose sight of the other points listed below.
• In general, it should be kept hidden from public view. Not even seams should be apparent. Unfortunately, contemporary middleware is often embarrassingly visible to software users and it is far from seamless from the perspectives both of users and of software developers.
• It should never dictate, limit or prevent changes in what is publicly visible. In compositional software terms, middleware should not determine, nor be mistaken for, architecture. Rather, architecture should be determined at the level of applications and expressed in applications-level terms.
• No one style can be expected to meet all needs. Just as football uniforms and tuxedos are best worn with different styles of underwear, different software applications have different middleware needs. Attempting to provide a single, all-purpose solution is certain to lead to chafing or lack of necessary support. Moreover, as applications and their salient properties (i.e., their ilities) evolve, it should be relatively easy, and yet invisible, to make appropriate changes in middleware. Presently, an application's choice of middleware is all to often, as noted in the workshop description, a pervasive and irrevocable commitment.
• In most circumstances, it should be as simple as possible. In particular, while system-wide properties will necessarily impose demands upon middleware, we do not believe that mechanisms for providing such properties are appropriately provided by middleware.
• It must be reliable. Failures can have embarrassing, and often painful, consequences.

Toward a Mature Attitude on Middleware

• Formal foundations: A deeper understanding, preferably based on suitable formalization, will be crucial to allowing multiple, minimal, flexible, reliable and easily interchangeable middleware approaches. We have, for example, begun to develop a formal foundation for establishing type compatibility between software components written in different languages [BRW97]. Similar foundations are needed for other facets of software composition addressed by middleware. The recent FSE/ESEC workshop on Foundations for Component-Based Software was an encouraging indication that this direction is being pursued.
• Zero language/model growth: The standard computing community approach to any problem has always been to invent yet another language. More recently, this approach has evolved to inventing yet another (object-oriented) type model. Although we ourselves have been guilty of contributing to type-model bloat in past work on interoperability [WWRT91], we are now dedicated to crafting middleware solutions that utilize only the (already plentiful, entirely adequate and widely used) models found in existing programming languages [KRW97]. This approach, as exemplified by our PolySPIN interoperability technology [KW96], not only inhibits population explosion but facilitates both seamlessness and incorporation of legacy components in compositional software systems.
• Component-based middleware: The middleware industry seems to be falling prey to the very kind of monolithic-systems mentality that compositional software is intended to overcome. We believe that middleware should be based on architectures that support plugable replacement of components. To that end, for example, our PolySPINner interoperability toolset [BKW96] can generate middleware that utilizes any of several inter-language communication mechanisms. Similarly, our JSpin persistent Java system [KMRW96,RTW97] was implemented by plugging a standard Java compiler (which we had modified in user-invisible ways) to either of two distinct persistent storage systems.

Acknowledgments

References

[BRW97] Barrett, D.J., Ridgway, J.V.E. and Wileden, J.C., Assuring Type Safety in Polylingual Software Systems, September 1997, 10 pp. (submitted).

[KMRW96] Kaplan, A., Myrestrand, G.A., Ridgway, J.V.E. and Wileden, J.C., Our SPIN on Persistent Java: The JavaSPIN Approach, Proceedings First International Workshop on Persistence and Java, September 1996, 11 pp. URL: http://www.sunlabs.com/research/forest/UK.Ac.Gla.Dcs.PJW1.pj1.html

[KRW97] Kaplan, A. Ridgway, J.V.E. and Wileden, J.C., Why IDLs Are Not Ideal, November 1997, 8 pp. (submitted).

[KW96] Kaplan, A. and Wileden, J.C., Toward Painless Polylingual Persistence, Proceedings Seventh International Workshop on Persistent Object Systems, May 1996, pp. 11--22.

[RTW97] Ridgway, J.V.E., Thrall, C. and Wileden, J.C., Toward Assessing Approaches to Persistence for Java, Proceedings Second International Workshop on Persistence and Java, August 1997, 21 pp. (to appear). URL: http://www.sunlabs.com/research/forest/COM.Sun.Labs.Forest.PJava.PJW2.pjw2.html

[WWRT91] Wileden, J.C., Wolf, A.L., Rosenblatt, W.R. and Tarr, P.L., Specification Level Interoperability, Communications of the ACM, 34:5, May 1991, pp. 72--87. --tr7ifeQepk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --tr7ifeQepk--