Name: (Dr.) Karen R. Sollins Title: Research Scientist Affiliation: MIT Laboratory for Computer Science Postal Address: 545 Technology Sq. Cambridge, MA 02139 Email Address: sollins@lcs.mit.edu Phone: (617)253-6006 Fax: (617)253-2673 The Need for Middleware Supporting Longevity in the Next Generation Internet Karen R. Sollins MIT Laboratory for Computer Science March 27, 1997 The occasion of building a new large scale internetwork provides us with an opportunity to address problems that have arisen through lack of understanding in previous efforts, in other words to learn from those experiences. Based on our experiences with the popularity of the World Wide Web, we now understand, in a way that perhaps only a small number of midddleware architects did previously, the extremely broad utility of a general purpose middleware architecture. With hindsight we also have learned a number of lessons about that experience that would lead to a revised approach, given the opportunity. Before we address the problems of an information infrastructure, it is important to understand the value of a middleware abstraction as a model of the network. Applications and applications builders function in a world inhabited by databases, voice and video, advertisements, bank accounts, etc. The network as realized by the TCP/IP protocols provides a collection of streams of bits. If we are lucky, it provides files or email messages as containers for arbitrary sets of bits that something else besides the file transfer or email applications might interpret as databases, voice, video, advertisements, bank accounts, etc. The Web goes the next step. It allows an application to consider the network to be a collection of linked resources, pages, images, etc. Thus, to the extent that pages and images are the commodities with which browsers operate, this is a much more appropriate model. Now, consider the investment in that resource base. Even now, still in the early stages of the enterprise, the investment is huge and growing exponentially, doubling every nine months. One has to ask with that much investment and that clear a need and desire for a better network based middleware infrastructure how we will move into the future. Are we prepared for the long-term investment? How will we survive and evolve into the future? The Next Generation Internet provides us with an opportunity to architect for longevity in a middleware layer, providing a network abstraction that will support the needs of applications and protect the applications from evolution, revolution, and inappropriate abstractions from the lower layers of the network. Two issues of particular concern when architecting for longevity are mobility and evolvability. What are the issues involved when information moves? How can we support information resources taking on new functionality over time? We propose an object-based architecture with naming and typing as the key features. Each object has at least one long- lived, globally unique identifier (independent of location) and supports at least one _role_, our kind of type. It is called a role, because as with people who play different roles, an object can also play more than one role, and the set of roles it can play may change with time. Evolvability is especially important with respect to roles. First, because an object can play new roles and stop playing older roles, it can evolve. Second, because role definitions are proscribing an abstraction, both a functional abstraction and a structural abstraction, we can separate the implementation and representation from the abstraction. For example, a book may be defined to have the abstract parts of title, author, table of contents, chapters, and pages. At one point the table of contents may be represented by an array and another time by a linked list. No one other than the implementor should know or need to know. Third, and perhaps most importantly, all roles support introspection. The root role, called the _object_ role, of the singly rooted multiple hierarchy supports an abstract function that knows which roles the object supports, and all other roles inherit this eithe directly or indirectly. Thus, as an object evolves, potential customers do not need to keep track because they can always ask about the roles the object plays. In discovering and communicating with a new object, the customer or adaptable application simply can ask it what roles it supports. This discovery, along with the other components of the architecture make for a very simple, yet powerful base. It is important to recognize that this model blurs the distinction between active and passive objects. Any application or user of the object can simply identify parts of an object or request functions of the object. Whether the object executes them or something executes on its behalf is unknown and immaterial to the "client". Furthermore, whether the object has a set of actions of its own or is handled by some manager again is immaterial. The second core aspect of the architecture is naming. Traditionally names have provided three functions, identification, access, and semantics or mnemonics. We propose (and have been part of the URN/URL/URC effort in the IETF) to separate these functions in order to better support longevity and in particular mobility. We expect that within their lifetimes many objects will move a number of times: their parent organizations may merge, split or dissolve; their homes sites may become obsolete; new improved schemes for handling them may be built, etc. Being able to embed a long- lived identifier without location or other semantic information into a link or other object implies that the meaning and use of the identifier need not change over the potentially long lifetime of the object. Then we need separately to engineer a resolution mechanism to discover the location of the object when needed. This is being done both in our research group and cooperatively within the IETF in the URN working group. The identifiers are called Uniform Resource Names or URNs and the locators Uniform Resource Locators or URLs. A critically important feature of the Web is the ability to create links or relationships between objects. We extend the idea in several directions. First, if links are first class objects, they can link to each other. Second, they can also have more than two end-points, viewed as critically important to allow for richer relationships. Third, by linking into the exposed abstract structure of their endpoints links are no longer dependent on a particular representation of their endpoints. Finally, by using URNs as the identifiers of the endpoints, links can have a useful lifetime as long as any other objects. Providing for long-lived links will be critically important. The work reported here is being done mostly as a research project, The Information Mesh, at MIT, but addresses problems which we have an opportunity to address more effectively in the Next Generation Internet to provide a long-lived global information model of the network in support of applications.