Middleware’s role, today and tomorrow Dejan Milojicic Hewlett Packard Laboratories 1501 Page Mill Rd. Palo Alto, CA 94304 dejan@hpl.hp.com 70 IEEE Concurrency Mary Kirtland Who is using middleware? I think eventually everybody is going to use middleware. The people I talk to are primar- ily Web application developers and LOB [line of business] application developers, ranging from tens of clients to 10,000s of clients. Some of the higher-end customers or people doing automation, process control—that sort of thing—have rolled their own middleware, because they couldn’t buy something that met their needs at the time they were making design decisions. But that means they have to main- tain the custom solution, which might not make good business sense in the long run. So they’re looking at using a third-party product, getting out of the middleware business themselves. So, you can’t earn money on middleware; you need it, but that’s not where you get money. I think for application developers that’s true—most busi- nesses are not in the business of developing software for soft- ware’s sake. They’re in some other business and they have to get the software written to support the business. And for that, the less extraneous stuff they have to write themselves and sup- port themselves, the better. Another thing about middleware is that it’s rare to find peo- ple, at least that I talk to, who have in-depth knowledge of all the different technologies used in a distributed application. They want to use them, but they don’t necessarily want to— or should need to—completely understand the theory or how to write the middleware themselves. How can we make middleware more accessible to users? T his second installment of “Trend Wars” is dedicated to middleware. Middleware represents a programming infrastructure positioned typically be- tween the operating system (or bare hardware in certain cases) and the user applications. It serves as a framework for building (typically distributed) applica- tions. Examples of middleware frame- works include OSF DCE, Microsoft DCOM, Java RMI, and OMG CORBA. Middleware frameworks provide com- mon services, such as network commu- nication primitives (RPC and distributed objects, for example), naming and locat- ing services, and security support. Middleware is meant to abstract away the underlying environment from applications and present a homoge- neous interface to application pro- grammers and users. There are various levels for achieving homogeneity. OMG CORBA supports heteroge- neous environments—both hardware and software—with the middleware level itself offering homogeneity. Be- cause Microsoft’s DCOM approach is based on the Intel architecture and the MS Windows operating system, it is designed around a homogeneous hard- ware and operating system base. Sun designed its middleware solution on top of a programming language envi- ronment (Java), using it as a single homogeneous base. Each approach has its advantages and challenges. The controversy around these dif- ferent approaches makes this topic an excellent choice for our department. In an attempt to predict the outcome of today’s “middleware trend wars,” we have invited five distinguished researchers and developers. Mary Kirtland is a program manager with the COM+ team at Microsoft. Doug Lea is a professor at New York State University at Oswego. Joe Sventek is a lab director at HP Labs, who has been involved with middleware develop- ment for over 20 years. As Chief Tech- nical Officer and cofounder of Iona Technologies, Annrai O’Toole has been pivotal in development of Iona’s ORB. Ann Wollrath is a senior staff engineer with Sun Microsystems and the principal architect of the Java Remote Method Invocation (RMI) system and one of the original archi- tects of the Jini technology. We asked each interviewee a com- mon set of questions that tries to unveil the middleware trends in the institutions that make middleware’s today and future. The questions are listed in the box on the facing page. —Dejan Milojicic Trend Wars