Jeffrey Eric Altman
Department of Computer Science
University at Stony Brook
July 24, 1992
Computers are used to collect and manipulate raw data and turn it into information. Traditionally this has meant starting a program and using it to manipulate a variety of data files. This model of application development and program use has shaped the way software is distributed and how information is exchanged.
The last few years have seen a tremendous increase in the use of object oriented technologies. Object oriented programming has changed the way software is programmed. As opposed to thinking of programs as procedural sequences of actions, programs are now viewed as a series of objects which communicate both with themselves and the user. Object orientation has also significantly altered the user interfaces of modern operating systems.
GUIs such as Microsoft Windows allow the user to perform their jobs by manipulating a combination of program and data objects. However, the rules for manipulating programs and those for manipulating data files are distinct. Data objects can be dragged and dropped, or linked, or embedded but these have no meaning for a program object. The program object contains all of the functionality and none of the data, while the data object contains all of the data but none of the functionality. It is only the combination of a program object with a data object that allows work to be accomplished. This model of software development in which the user is aware of the distinction between programs and data shall be referred to as the <application-data file> model.
There are a number of drawbacks inherent in this model:
1. Data created by a user on one system may not be useful when transported to another system.
2. Computer software can only be extended by changing the original source code or using a proprietary add-in interface.
3. In GUIs, many users become confused because of the different properties program objects and data objects possess.
4. Licensing of software is hard to monitor and enforce both for software publishers and consumers.
These drawbacks have inadvertently caused both software publishers and users harm. Computers are used to create information. Most information is useless unless it is shared with others. However, most information is stored in proprietary data files which can only be used if the original application is available. This need to share information with others or manipulate one's data in more than one location has resulted in wide spread illegal software reproduction, a reduced amount of information sharing, and the loss of large amounts of time and energy.
The inability of software to be easily extended or modified results in fewer third party innovations and longer time periods between software updates.
The differences in the properties of the program objects/files and data object/files cause novice users to become frustrated and turned off by computers. This results in a slower acceptance of computers in the home and therefore reduced market size.
Software licensing is almost unenforceable. The restrictive licensing agreements used by most software vendors do not meet the needs of the user base. Current licensing causes individual users such as those with a home computer to pay more for computer software which they use less than large companies which use it more. Individuals therefore make illegal copies of software for use at home because they either need to bring home work from the office or can not justify the cost of the word processor after spending the money for the hardware to run it on. A typical student who buys a machine for writing reports spends $1500 on a computer and printer and then another $500 or more on software to write reports and generate some graphics. This is a large amount of money for ten reports a year.
One begins to think "there must be a better way." There is. In object oriented programming languages an object is described as a structure containing both data (state) and methods (functionality.) In this model, the <object> model, the object's data and functionality are treated as one. Wherever the object data exists, so does the functionality belonging to the object. The goal of this paper is to demonstrate how the <object> model could be used as a general model for application development.
Real world objects have several properties which need to be incorporated into any computer object model.
1. Each object is physically unique.
2. It is possible to alter the state of an object.
3. Each class of object has a set of well defined properties. (States it can exist in and things that can be done with it.)
4. Objects can be combined to form more complex objects.
5. Objects can be acted upon in groups.
6. Objects can be duplicated.
7. Objects maintain their functionality as they are moved from one place to another.
Computer objects must have the same properties.
The <application-data file> model which is currently used fulfills all of the necessary properties except for the seventh. With the <application-data file> model it is necessary that all users of the data file have access to the application which created it. If the application is not owned or is not available due to lack of available network licenses, the data file is useless.
By applying the <object> model used in OOP to application development we can satisfy all of the necessary conditions. In this model, an object is defined in the system as both data and functionality such that the object is useful wherever it may be. The user manipulates objects instead of programs and data files. The benefits of the <object> model are as follows:
1. Free exchange of software objects among users using a common operating system regardless of hardware architecture.
2. Reusability and extendibility of software objects.
3. Conceptual elegance.
4. A powerful alternative software licensing mechanism.
"Free exchange of software objects" refers to the ability to transport an object from one computer to another and have it be usable without additional requirements.
"Reusability and extendibility" refers to the ability to derive new types of objects (classes) from existing object classes without the need to recompile.
"Conceptual elegance" refers to the consistency with which the <object> model allows programmers and users alike to conceive of computerized tools with which they work.
Objects are distinct entities and as such can be licensed individually. This allows pricing to be set based upon the quantity of use and removes the headaches associated with monitoring and enforcing current license agreements.
These capabilities are only partially available (if at all) in currently available or planned operating systems such as UNIX, OS/2, Microsoft NT, or Taligent Pink.
The <object> model is the application of OOP techniques to the next higher level, the user level. In addition to the use of standard OOP concepts in the design of the individual programs, these same concepts are applied to the user level. The user becomes unaware of files. Instead the user only sees a consistent set of objects. There is no distinction between program objects and data objects. All objects contain both data and functionality. The objects may be manipulated with the standard mechanisms provided by the operating system's user interface.
Objects are individually licensed. The operating system provides the necessary mechanisms to enforce the licensing of object classes. Three types of creation rights exist: unlimited, licensed unlimited, and licensed. The unlimited creation right allows anyone with the object to create any number of copies. The licensed unlimited creation right allows an unlimited number of copies to be made on the originally installed machine but no copies made be made on other machines. The licensed creation right provides for a specific number of objects which may be created.
New objects are created by a request to the operating system. Copying an object is the creation of a new object with the exact same state as the first but with a different name. A request to create a new object from a class with no available licenses will fail.
Objects may be transferred from system to system either via networks or removable media. The receiving system does not have to possess the same architecture as long as it is using the same operating system. Object classes are automatically installed on the receiving system during an object transfer. The transfer of an object results in the transfer of that object's license, if any, to the receiving machine.
Objects may be recycled. An object which is no longer needed may be destroyed. This results in an increase of the available license count for that class by one.
Resources such as fonts and bitmaps are special classes of objects.
Objects classes are derived from parent classes. The inherited functionality is linked at run time. All objects with a public interface may be inherited from.
Note: The <Object> model could be implemented on top of an existing operating system (OS/2 2.0, Windows NT, UNIX, etc.) as part of the user shell. However, this implementation would present large holes in the licensing system as the user would still have file system level access. However, this approach would provide a means for testing the concepts and provide compatibility with the <application-data file> model.
The <object> model is based upon a hierarchy of standard base classes. These base classes contain all of the functionality necessary to interact with the operating system and the user. The base classes contain all of the windowing mechanisms, message queues, license management, etc.
Each object class is implemented as a Dynamically Linked Library (DLL). The DLL provides all of the new methods for the class as well as mandatory constructor, destructor, messaging, and process management methods. The use of DLLs allows for the sharing of code between processes and run-time linking (inheritance and overloading) necessary in an object oriented environment.
Object classes (DLLs) are distributed using a semi-compiled version of the code. The machine dependent version is not created until the object class is installed. At installation, the compilation of the code is completed. This allows the same program code to be distributed to multiple computer architectures without a degradation in performance. When objects are transferred from one computer system to another, it is the semi-compiled version of the class methods which are packaged with the object data.
All <object> classes are registered with the operating system. The operating system provides an API for the purpose of registering and de registering object classes. The registration process is necessary so that the operating system knows which DLLs contain the class methods. During the registration process several class properties specified by the programmer are provided to the operating system: persistence, scope, and creation rights.
Persistence: <objects> may be persistent or temporary. A persistent object's state is maintained between sessions (turning off and on the machine.) Temporary objects lose their state at shutdown.
Scope: <objects> may be public or private. Public objects are available to the entire system. They may be created as independent objects, or may be inserted into other objects. Only public objects may be created upon a request from the user. Private objects are limited in scope. They may only be created upon the request of another object. In all other ways public and private objects are identical.
Creation rights: The operating system provides support for three types of object creation privileges: unlimited, unlimited licensed, and licensed. Object classes with unlimited creation rights have no limit on the number of objects of that type which can be created both on the local system or any other system to which one of the objects has been transported.
Object classes with unlimited licensed rights have no limits on the number of objects which may be created on the originally installed system. However, when the object class is transported to a new system the creation right is changed to licensed. This allows the use of the object on the new system but prevents the creation of additional objects of that type. (The primary use of this option is for resources such as fonts and logos.)
Object classes with licensed creation rights are limited in the number of objects of that type which may be created. The number of objects which may be created is determined by the unused license count for that object class. License counts may either be maintained on the local machine or via a network license server. License counts may be reused after an object is destroyed.
Each copy of the operating system is assigned a unique ID number which determined by the boot device. This could be the MAC address on a network or the serial number of the hard disk.
When a "public" object arrives at a new system, the operating system creates a new entry in its class table containing the locations of the DLLs, and the class properties. If the object is licensed, the new entry contains an "unused license count" equal to zero. Therefore, no additional objects of this type can be created.
In order for the user to create additional objects of this type, the user must:
call the company to purchase additional object licenses, or
provide the operating system with the network address of an object license server, or
recycle a existing object.
The operating system provides a mechanism for validating object license numbers. This mechanism will require four parameters:
the object class ID (only known to the software developer),
the operating system ID number,
the object license, and
the date the object license was issued.
where:
<object license> = f( license count, class ID, OpSys ID, date ).
The combination of these parameters will result in a specific number of additional object licenses. Invalid combinations will result in zero additional licenses. License numbers may not be reused as they are recorded by the operating system.
A user needs an unused license whenever s/he either creates a new object or copies an existing one. Objects may be recycled. If the user has an object they no longer need they destroy it. This results in an increase in the unused license count for that object's template.
When objects are transported from one system to another there needs to be a mechanism for transferring the class methods in addition to the data. There are two different methods used depending on the media.
When using removable media such as diskettes or tapes, the object's data as well as all necessary distribution code is copied. This allows the object to be used on a machine which does not already contain that object. A short cut mechanism may be used when the user knows the object has already been registered. In that case, the distribution code would not be copied. However, this would limit the usability of the object significantly.
When using a network, the object may be included as part of a mail message. This would require the transfer of all distribution code. Or the object could be transferred using the Object Transfer Protocol (OTP) which provides for negotiated transfer between two system of object data and functionality. Using the OTP only the minimum code necessary is actually transferred.
The <object> model is a solution for some of corporate computing's biggest problems. Since objects are transportable and fully functional there is less of a need to force the use of one application as the corporate wide solution for a given task. The use of many different brands or even versions of spreadsheets in a large organization has always caused problems due to the lack of good data exchange.
The other major problem facing networked companies is how to determine how many licenses of a given application are necessary. This is going to become an even larger problem with the rapid spread of multitasking systems. Multitasking systems enable the user to work comfortably by learning many different programs running simultaneously on the desktop. This causes problems for companies because these running programs require valid licenses even if they have been idle for days. The <object> model alleviates this problem as the only time that licensing is an issue is at the time of object creation. Therefore, the users are always able to gain access to their data regardless of the number of concurrent users.
The adoption of the <object> model will necessitate a major change in software distribution methods. Using the <application-data file> model, software is distributed in one of three forms: freeware, shareware, and commercial. With freeware and shareware, the author expects the software to be widely distributed by copying the program from one machine to another. However, commercial software is not allowed to be distributed in that manner because it would violate the user's license.
It would appear that commercial software publishers would balk at using the <object> model in which the full functionality of an object is maintained on all systems it is transported to since that means that their program goes whether the data goes. Doesn't this make software piracy the law of the land?
The answer to that question is 'No'. Lets examine the most common forms of software piracy.
1. Buying one license and installing it on all machines in the office.
2. Buying one license and installing it on a network server.
3. Installing a program owned by the office at home.
4. Sharing with friends.
For the first two cases, the primary reason software is pirated is budgetary constraints. The department manager cannot justify purchasing a license for every machine when s/he really needs additional machines, doesn't want to fire an employee, etc.
In the third and fourth cases, the piracy occurs because the individual can not justify the cost of the software when compared to the amount of potential use or in addition to the cost of the computer hardware. ("What do you mean I just spent $1500 for a computer and it can't do anything!")
The solution to these causes of software piracy is not to license the software but instead license what the software produces, objects.
With the use of the <object> model software may now be sold based upon its amount of use and not upon a flat rate. This has benefits for both the publisher and the user.
For the small household user, it means lower prices. The household user on average uses software less frequently than business users. However, they have to pay the same or higher prices. Instead of buying a word processor to write twenty or thirty documents in a year for school at a cost of $500, the student might now pay $2 a document for a total cost of $60.
For large organizations, selling by the object means paying only for what is actually used and reductions in the frustration of monitoring site licenses and illegal software use.
For publishers, object sales provides new methods of software distribution and marketing. Printed manuals can now be distributed separately from the software. The software can be distributed via On-line Information Services, Bulletin Boards, and via computer networks. There is no need to create special limited use or demo versions, nor to offer money back guarantees. Software publishers can easily distribute trial copies by shipping single objects to the potential customer.
The <object> model one significant drawback. The goal of the model is to increase the ease of using and distribution computer generating information. It does this by transferring the functional code along with the data whenever an object is moved from one system to another. Given the trend in today's applications, it is possible that transporting a two page document object might result in the transfer of ten or fifteen megabytes.
The assumption made is that this is a limitation of today's hardware and not of the model. Recent advances in networking technologies and in removable media storage capabilities are sure to reduce the impact of transferring these quantities of raw data.
Most of the techniques needed to implement the <Object> model already exist in today's advanced operating systems. IBM's System Object Model as implemented in the Work Place Shell of OS/2 2.0 provides the necessary functionality to implement a programming language independent model for object based development with run time inheritance. SOM has been given to Taligent for inclusion in Pink. However, the implementation of SOM still assumes the <application-data file> model due to its lack of object based licensing mechanisms, architecture independence, and object transfer mechanisms.
The Open Software Foundation has been working on a system independent distribution format. This format would allow software publishers to sell shrink wrapped software which could then be installed on any hardware which runs OSF/1.
Microsoft is working on a project called Cairo which is supposed to add an Object layer on top of there Windows NT operating system. It is unclear what functionality will be included in Cairo. However, it does appear unlikely that the <object> model is part of that project.
The following is a brief list of the areas of development which need to be researched to implement this model:
1. Development of licensing mechanisms.
2. Development of two stage compilation methods to provide for architecture independent distribution.
3. Development of Object Transfer Protocols.
The <object> model should be seriously considered as the future model of software development.