This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: An Object-based Systems Architecture
Feed Title: Richard Demers Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml
Feed Description: Richard Demers on Smalltalk
I've been discussing some ideas about subsystems, and have repeatedly called for a marriage of the object-oriented Smalltalk programming language and the object-based architecture of the OS/400 operating system. Hamish Harvey asked for more information on OS/400, but I couldn't find anything useful in all material about System/38, AS/400, OS/400, iSeries at ibm.com. I hope no one objects to my repeating the following that I wrote on comp.lang.smalltalk (with some minor corrections). The original topic was the use of "capabilities" for system security.
Capability based security systems go back to the late 60's or early 70's. I am not fully aware of the history of this idea, but I believe one of the earliest implementations was a Plessy system out of England. The most notable (and successful) implementation is that of the IBM System/38 (later renamed the AS/400, and now iSeries), which was developed in the late 70's. In the late 1970's I had the privilege of designing the part of the S/38's operating system related to message and exception handling, so I became very familiar with its architecture.
Few people outside of IBM's Rochester development lab. are aware that the AS/400 is a marvelous bit of advanced technology -
still (IMHO) many years in advance of anything else on the market. For some reason I have never understood, IBM has consistently failed to adequately promote this technology - kind of a "best kept family secret." The AS/400's users have certainly reaped its benefits, but this isn't the place for me to sing its praises.
Instead, I'll summarize the AS/400's capability-based security
features (to the best of my memory - it has been more than ten years since I last looked at this!). First, the AS/400 is an object-based system in which encapsulated objects reside in a single-level, uniformly addressable, 64-bit virtual address space. This virtual memory system eliminates all distinctions between main memory and disk memory, dynamically loading and storing pages of objects as needed, taking advantage of the locality-of-reference characteristics of programs and data.
AS/400's high-level virtual machine implements a fixed repertoire of object types at two levels, Program Objects for the number, string, etc. types manipulated by programming languages and by the system's embedded database, and System Objects that contain program objects. Examples of System Objects are Data Spaces, Indexes, Queues, Files, Directories, User Profiles, Executable Programs, Processes, and a variety of process work spaces. Each System Object is a separate 32-bit virtual address space in which program objects are mapped in various ways.
There is one, and only one, way for an executable program to
address a program object in a System Object, and that is by means of a type of program object called a System Pointer - a "capability" by another name. Each System Pointer is 16 bytes long, the first 64 bits contains a virtual address, and the last 64 bits contains
authorization information. A key concept to remember is that System Pointers are inviolable; they can only be created by the Virtual Machine, and there is no way for an executing program to change them. In fact, they are protected in real memory by extra "tag bits" that can only be set by the VM.
In operation, a program asks a Directory object to resolve a name into a System Pointer. The Directory object looks up the name and asks a User Profile object for the access rights of the requesting user for that object. It then creates and returns an appropriate System Pointer. (Actually, there's more to it than this, but I don't remember all of the details.) The program can then request any of the encapsulated operations permitted by that type of object that are allowed by the System Pointer. The Virtual Machine looks at the access information in the System Pointer to determine if it is allowed to perform a requested operation for that user.
Actually, there is a second kind of System Pointer, called a Space Pointer, that loosens things up a bit so that executable programs can easily work with program objects within a System Object. Space Pointers give programs the ability to freely address the contents of a System Object, to do all of the data manipulation things programs normally do. However, the Virtual Machine creates Space Pointers for only certain types of System Objects that are designed for this level of flexibility. One such type is the Space Object, which is just an empty address space. A program can map a Space Object however it wants. For example, it could be managed as a garbage-collected heap. The Virtual Machine provides instructions for manipulating Space Pointer addresses, but it never allows the creation of an address that "leaks" outside of the
designated System Object.
There is MUCH MORE to this beautiful systems architecture than I can describe here, but I do want to point out how fantastic it would be to marry it with Smalltalk. Some of Smalltalk's key ideas (class objects, inheritance, dynamic message binding and polymorphism) were not publicly available at the time the System/38 was designed in the late 70's. There were many discussions among the architecture staff about finding a way to bring some of the system's object-based facilities into the programming languages the S/38 planned to support (RPG and COBOL, initially, but many other languages, today), but there were schedules to meet and the target market for the S/38 had no such requirements.
When I first learned Smalltalk (in about 1983), I knew I'd seen the
promised land, but I was not able to sell it to the "powers that be" at IBM Rochester. Later, a version of VisualAge Smalltalk was implemented on the AS/400, but it was a straightforward implementation that did not take advantage of the AS/400's unique architecture (and it was never really marketed).
I am still hopeful that it might someday be possible to incorporate AS/400 architectural ideas into an "enhanced Smalltalk."
Previous Topic
