 |
Claims  |
|
|
We claim:
1. A method for sending an object oriented programming language based
message having dynamic binding from a first object in a first process to a
second object in a second process, said method comprising the steps of:
transmitting, using a first processing means, said object oriented
programming language based message to a first proxy in said first process;
using said first proxy and said first processing means, encoding said
object oriented programming language based message into an operating
system based message at run time;
transmitting said operating system based message to said second process in
said second processing means at run time;
decoding, using a second process, said operating system based message into
a language based message;
transmitting, using said second processing means, said object oriented
programming language based message to said second object in said second
process;
executing said object oriented programming language based message by said
second object in said second process.
2. The method of claim 1 further including the steps of:
said second object in said second process and generating an object oriented
programming language based result;
encoding, using said second processing means, said object oriented
programming language based result into an operating system based result at
run time;
transmitting, using said second processing means, said operating system
based result to said first process at run time;
decoding said operating system based result into an object oriented
programming language based result at run time, using said first processing
means;
transmitting, using said first processing means, said object oriented
programming language based result to said first object.
3. The method of claim 1 wherein said object oriented programming language
based message comprises a method and an argument.
4. The method of claim 1 wherein said second object executes said method on
said argument when executing said message.
5. The method of claim 1 wherein the step of executing said object oriented
programming language based message further includes the steps of:
said second object determining, using said second processing means, whether
additional information is needed to execute said object oriented
programming language based message;
said second object generating, using said second processing means, an
object oriented programming language based query if it is determined that
additional information is needed;
encoding, using said second processing means, said object oriented
programming language based query into an operating system based query at
run time if it is determined that additional information is needed;
transmitting said operating system based query to said first process at run
time, using said second processing means if it is determined that
additional information is needed;
decoding, using said first processing means, said operating system based
query into an object oriented programming language based query at run time
if it is determined that additional information is needed;
transmitting, using said first processing means, said object oriented
programming language based query to said first object if it is determined
that additional information is needed.
6. The method of claim 5 further including the steps of:
said first object generating, using said first processing means, an object
oriented programming language based reply to said object oriented
programming language based query;
encoding said object oriented programming language based reply into an
operating system based reply at run time, using said first processing
means;
transmitting, using said first processing means, said operating system
based reply to said second process at run time;
decoding, using said second processing means, said operating system based
reply into an object oriented programming language based reply at run
time;
transmitting, using said second processing means, said object oriented
programming language based reply to said second object.
7. The method of claim 6 wherein said first processing means and said
second processing means are the same processing means.
8. The method of claim 1 wherein said object oriented programming language
based message comprises an objective C message.
9. The method of claim 1 wherein said operating system based message
comprises a Mach message.
10. The method of claim 1 wherein said first proxy represents said second
object.
11. A method for sending an object oriented programming language based
message having dynamic binding from a first object in a first process to a
second object in a second process, said method comprising the steps of:
transmitting, using a first processing means, said object oriented
programming language based message to a first proxy in said first process;
using said first proxy and said first processing means, encoding said
object oriented programming language based message into an operating
system based message at run time;
transmitting, using said first processing means, said operating system
based message to said second process at run time;
decoding, using said second processing means, said operating system based
message into an object oriented programming language based message at run
time;
transmitting, using said second processing means, said object oriented
programming language based message to said second object;
said second object generating an object oriented programming language based
query, using said second processing means;
creating, using said second processing means, a second proxy in said second
process;
transmitting, using said second processing means, said object oriented
programming language based query to said second proxy;
using said second proxy and said second processing means, encoding said
object oriented programming language based query into an operating system
based query at run time;
transmitting, using said second processing means, said operating system
based query to said first process at run time;
decoding, using said first processing means, said operating system based
query into an object oriented programming language based query at run
time;
transmitting, using said first processing means, said object oriented
programming language based query to said first object;
said first object generating an object oriented programming language based
reply, using said first processing means;
encoding, using said first processing means, said object oriented
programming language based reply into an operating system based reply at
run time;
transmitting, using said first processing means, said operating system
based reply to said second process at run time;
decoding, using a second processing means, said operating system based
reply into an object oriented programming language based reply at run
time;
transmitting, using said second processing means, said object oriented
programming language based reply, using said second processing means, and
generating an object oriented programming language based result;
encoding, using said second processing means, said object oriented
programming language based result into an operating system based result at
run time;
transmitting, using said second processing means, said operating system
based result to said first process at run time;
decoding, using said first processing means, said operating system based
result into an object oriented programming language based result;
transmitting, using said first processing means, said object oriented
programming language based result to said first object.
12. The method of claim 11 wherein said object oriented programming
language based message comprises a method and an argument.
13. The method of claim 12 wherein said second object executes said method
on said argument when executing said message.
14. The method of claim 11 wherein said first process and said second
process are located on first and second computers respectively.
15. The method of claim 11 wherein said object oriented programming
language based message comprises an objective C message.
16. The method of claim 11 wherein said operating system based message
comprises a Mach message.
17. The method of claim 11 wherein said first proxy represents said second
object.
18. The method of claim 11 wherein said second proxy represents said first
object.
19. A method for sending, in a C environment with minimal run time support,
an object oriented programming language based message having dynamic
binding from a first object in a first process to a second object in a
second process, said method comprising the steps of:
transmitting, using a first processing means implementing said C
environment, said object oriented programming language based message to a
first proxy in said first process;
using said first proxy and said first processing means, encoding said
object oriented programming language based message into an operating
system based message at run time;
transmitting said operating system based message to said second process at
run time;
decoding, using a second processing means implementing said C environment,
said operating system based message into a language based message;
transmitting, using said second processing means, said object oriented
programming language based message to said second object.
20. The method of claim 19 further including the steps of:
said second object executing said object oriented programming language
based message, using said second processing means, and generating an
object oriented programming language based result;
encoding, using said second processing means, said object oriented
programming language based result into an operating system based result at
run time;
transmitting, using said second processing means, said operating system
based result to said first process at run time;
decoding said operating system based result into an object oriented
programming language based result at run time, using said first processing
means;
transmitting, using said first processing means, said object oriented
programming language based result to said first object.
21. The method of claim 20 wherein the step of executing said object
oriented programming language based message further includes the steps of:
said second object determining, using said second processing means, whether
additional information is needed to execute said object oriented
programming language based message;
said second object generating, using said second processing means, an
object oriented programming language based query if it is determined that
additional information is needed;
encoding, using said second processing means, said object oriented
programming language based query into an operating system based query at
run time if it is determined that additional information is needed;
transmitting said operating system based query to said first process at run
time, using said second processing means if it is determined that
additional information is needed;
decoding, using said first processing means, said operating system based
query into an object oriented programming language based query at run time
if it is determined that additional information is needed;
transmitting, using said first processing means, said object oriented
programming language based query to said first object if it is determined
that additional information is needed.
22. The method of claim 21 further including the steps of:
said first object generating, using said first processing means, an object
oriented programming language based reply to said object oriented
programming language based query;
encoding said object oriented programming language based reply into an
operating system based reply at run time, using said first processing
means;
transmitting, using said first processing means, said operating system
based reply to said second process at run time;
decoding, using said second processing means, said operating system based
reply into an object oriented programming language based reply at run
time;
transmitting, using said processing means, said object oriented programming
language based reply to said second object.
23. The method of claim 21 wherein said operating system based message
comprises a Mach message.
24. The method of claim 21 wherein said first processing means and said
second processing means are the same processing means. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
FIELD OF THE INVENTION
This invention relates to the field of object-oriented programming and
distributed computing.
BACKGROUND ART
Object-oriented programming is a method of creating computer programs by
combining certain fundamental building blocks, and creating relationships
among and between the building blocks. The building blocks object-oriented
programming systems are called "objects." An object is a programming unit
that groups together a data structure (instance variables) and the
operations (methods) that can use or affect that data. Thus, an object
consists of data and one or more operations or procedures that can be
performed on that data. The joining of data and operations into a unitary
building block is "encapsulation." In object-oriented programming,
operations that can be performed on the data are referred to as "methods."
An object can be instructed to perform one of its methods when it receives
a "message." A message is a command or instruction to the object to
execute a certain method. It consists of a method selection (name) and
arguments that are sent to an object. A message tells the receiving object
what to do.
One advantage of object-oriented programming is the way in which methods
are invoked. When a message is sent to an object, it is not necessary for
the message to instruct the object how to perform a certain method. It is
only necessary to request that the object execute the method. This greatly
simplifies program development.
Object-oriented programming languages are generally based on one of two
schemes for representing general concepts and sharing knowledge. One
scheme is known as the "class" scheme. The other scheme is known as the
"prototype" scheme. Both the set-based and prototype-based object-oriented
programming schemes are generally described in Lieberman, "Using
Prototypical Objects to Implement Shared Behavior in Object-Oriented
Systems," OOPSLA 86 Proceedings, September 1986, pp. 214-223.
Class Scheme
An object that describes behavior is called a "class." Objects that acquire
a behavior and that have states are called "instances." Thus, in the
objective C language, which is the computer language in which the
preferred embodiment of the present invention is implemented, a class is a
particular type of object. In objective C, any object that is not a class
object is said to be an instance of its class. The classes form a
"hierarchy." Each subclass in the hierarchy may add to or modify the
behavior of the object in question and may also add additional states.
Inheritance is a fundamental property of the class scheme and allows
objects to acquire behavior from other objects.
The inheritance hierarchy is the hierarchy of classes defined by the
arrangement of superclasses and subclasses. Except for the root classes,
every class has a superclass, and any class may have an unlimited number
of subclasses. Each class inherits from those classes above it in the
hierarchy. Thus, a superclass has the ability to pass its characteristics
(methods and instance variables) onto its subclasses.
FIG. 1 is a block diagram that illustrates inheritance. Class 1 (generally
indicated by block 101) defines a class of objects that have three methods
in common, namely, A, B and C. An object belonging to a class is referred
to as an "instance" of that class. An example of an instance of class 1 is
block 102. An instance such as instance 102 contains all the methods of
its parent class. Block 102 contains methods A, B and C.
As discussed, each class may also have subclasses, which also share all the
methods of the class. Subclass 1.1 (indicated by block 103) inherits
methods A, B and C and defines an additional method, E. Each subclass can
have its own instances, such as, for example, instance 104. Each instance
of a subclass includes all the methods of the subclass. For example,
instance 104 includes methods A, B, C and E of subclass 1.1.
Not all object oriented programming languages permit new methods to be
added per instance. For, example, in Objective C, an instance can not have
methods that are not contained in its parent class.
A disadvantage of an inheritance-based, object-oriented programming
language is object size. Because each subclass must, by definition,
include all methods of its parent class and super classes, instances are
larger at the bottom of the inheritance hierarchy.
Object-oriented programming languages that utilize the
class/instance/inheritance structure described above implement a
set-theoretic approach to sharing knowledge. This approach is used in
object-oriented programming languages, such as Simula, SmallTalk, Flavors
and Loops.
Prototype Scheme
The prototype scheme is an alternate approach to sharing knowledge in an
object-oriented system. In prototype scheme systems that use the
individual instances, rather than a class, ("prototypes") are created
first, instead of a class. The prototypes are then generalized by defining
aspects of their concepts that are permitted to vary. The mechanism for
implementing this process is known as "delegation." Examples of prototype
languages include the actor language and lisp-based object-oriented
systems, such as director, t, and orbit.
Delegation removes the distinction between classes and instances. To create
another object that shares knowledge with a prototype, an "extension"
object is created that has a list containing its prototypes that may be
shared with other objects and containing personal behavior limited to the
object itself. When an extension object receives a message, it attempts to
respond to the message using the behavior stored in its personal aspect.
If the object's personal characteristics are not suitable to answer the
message, the object forwards the message on to other prototypes to see if
one can respond to the message. This method of forwarding is called
"delegating the message."
An example of delegation is illustrated in FIG. 2. Object A provides a
message 201 to object B. The message includes a method and arguments to
the method. Object B does not have the method required by the message.
Therefore, object B cannot respond to the message. Instead, object B sends
the method and message to its delegate. The delegate of object B is object
C. Object C has the method requested in the message. The method can then
be executed and a response provided to object A.
Distributed Programming
A disadvantage of current object-oriented programming systems is that all
objects are required to exist in a single program or process. This
prohibits utilizing an object-oriented programming system when writing
distributed applications. In addition, these prior art limitations prevent
the creation of applications that are distributed physically over networks
of machines.
The difficulty of creating distributed object-oriented programs is
illustrated in FIGS. 8A and 8B. In FIG. 8A, all objects are resident in
the same program, namely program LOCAL 801. A sender object 802 sends a
message 804 to a receiver 803. The message may include a method and an
argument. The receiver 803 executes the method of the message 804 and
returns a result 805. The result 805 is provided back to the sender 802.
In the example of FIG. 8A, the object-oriented program resides entirely on
one side of a boundary 806.
FIG. 8B illustrates a prior art object-oriented programming system
attempting to communicate across a boundary between processes. A local
process 801 includes a sender object 802 that generates a message 804
destined for receiver object 808. However, object 808 is on the opposite
side of boundary 806. That is a separate process identified as REMOTE 807.
An object, such as receiver 808 which resides in a different process than
a sender object, is known a "remote object." The language and run time
support of the local process 801 does not provide a mechanism to send a
message 804 directly to the remote object 808. At the transition point 809
of boundary 806, the message is stopped.
One prior art approach for writing distributed applications consists of
explicitly defining the boundaries between different programs by
specifying protocols, generating client/server stubs, and communicating
between processes or programs by using function calls that automatically
transport arguments and return values between the client layer and the
server layer. At such boundaries, the object-oriented developer can no
longer treat items as objects as soon as the boundary of the process is
crossed. This defeats the purpose and advantage of using object-oriented
programming in the first place.
Another prior art method for providing distributed object oriented
programming is described in "Design of a Distributed Object Manager for
the SmallTalk-80System," D. Decouchant, OOPSLA 86 Proceedings, September,
1986, pp. 444-452. The Decouchant reference describes the design of a
distributed object manager that allows several SmallTalk-80 systems to
share objects over a local area network. When a local object desires to
communicate with a remote object, the local object communicates with a
"proxy" that locally represents the remote object. A proxy is part of the
private data of the object manager. The proxy has two fields that describe
a remote object, namely, the resident site of the remote object and a
virtual pointer to the object in the resident site. If the referenced
object migrates, the contents of the referencing object are not modified.
The proxy is updated accordingly by the object manager. In this
implementation, a proxy is functionally equivalent to a Unix link, except
that a proxy is not visible to the programmer. It is a private data
structure which is handled by the object manager like other Small-Talk
objects.
In the Decouchant reference, three processes cooperate to perform the
object manager functions. These are the network manager, the main memory
manager and the secondary manager. SmallTalk interpreter processes which
access the objects to perform SmallTalk actions may also be present on the
site. The network manager is the master process of a SmallTalk site. It
ensures consistency of the shared objects with the other network sites and
controls the local processes. The main memory manager is in charge of the
object management in main memory. It resolves object faults by allocating
free space for the missing object and sending an object load request to
the secondary storage manager. The secondary memory manager takes care of
the object management in secondary storage. This storage is represented by
two files, one of which contains the SmallTalk object table and the other
one contains the object space.
Another prior art method to provide distributed object-oriented programming
is described in "The Design and Implementation of Distributed SmallTalk,"
John K. Bennett, OOPSLA, Oct. 4-8, 1987, pp. 318-330. SmallTalk itself is
a language environment that provides a single user with access to a single
object address space. Only rudimentary support exists within SmallTalk for
cooperation among users, and no support exists within SmallTalk for object
sharing between users or between different machines or between processes
on the same or different machines. The Bennett references describes
"distributed SmallTalk" (DS) as a method of providing improved
communication and interaction among geographically remote SmallTalk users,
direct access to remote objects, the ability to construct distributed
applications in a SmallTalk environment, and a degree of object sharing
among users.
The system described in the Bennett reference does not allow remote
classes. Instead, the system requires that classes and instances be
co-resident on all processes and machines. This impacts object mobility
adversely. Instances can only move to hosts with compatible classes and
insuring class compatibility is difficult. In addition, the system of
Bennett does not operate in an object-oriented programming system that
utilizes class inheritance and reactiveness. (Reactiveness describes the
ability of a system to present objects for inspection or modification).
The system of Bennett uses ProxyObjects and a RemoteObjectTable to
implement distributed message passing. A ProxyObject represents a remote
object to all objects in a local address space. There is one ProxyObject
per host per remote object referenced by that host. ProxyObjects cause a
remote object's message interface to appear to local objects as if the
remote object were locally resident. ProxyObjects redefine the
doesNotUnderstand: message of object. This is the primary message defined
for ProxyObjects. In other words, messages sent to ProxyObjects are
intended to fail. The system responds to this failure by sending the
message doesNotUnderstand: to the receiver with the message that was not
understood as an argument. The ProxyObject's response to the
doesNotUnderstand: message is to forward the original message to the
RemoteObjectTable on the appropriate machine or process. The location of
the remote object is part of the internal state of the ProxyObject.
The RemoteObjectTable is responsible for receiving and replying to messages
forwarded by ProxyObjects. There is one RemoteObjectTable per host. It is
the sole instance of class RemoteObjectTable. The RemoteObjectTable can be
thought of as a set of extensions to the object tables (if present) of all
remote machines. The RemoteObjectTable keeps track of all local objects
that are remotely referenced. When the RemoteObjectTable receives a
message from some ProxyObject, it schedules a process that will contain
the execution context of the actual message receiver by sending the
message perform to the receiver with the forwarded selector and arguments
(if any) as arguments to the perform message. The value returned by the
perform message is returned to the remote sender in a reply message
constructed by the RemoteObjectTable.
Before an object can be sent between processes, the classes must be checked
for compatibility. The three cases to consider are:
1. The required class is already present and is compatible;
2. The required class is present, but it is determined to be incompatible;
and
3. The required class is not present.
In case 1, the system proceeds normally. In the second case, the attempted
move fails and the user is notified of the error. In case 3, the user is
asked whether the desired object's class should be moved. If the response
is affirmative, the object's super class is checked for compatibility.
This procedure continues up the class hierarchy until class object is
reached. However, class object may not be moved.
Another method for providing distributed object-oriented programming is
described in "Transparent Forwarding: First Steps" Paul L. McCullough,
OOPSLA 1987 Proceedings, Oct. 4-8, 1987, pp. 331-341. As in the Bennett
system, the McCullough system utilizes ProxyObjects and the
doesNotUnderstand: message for identifying and transmitting messages. In
the McCullough system, the implementation of doesNotUnderstand: creates an
ethernet packet containing the original message and forwards it to the
machine containing the remote object. The proxy contains information in
its instance variables about where the remote object resides.
FIG. 6 illustrates an overview of the operation of the McCullough system. A
message 601 destined for a remote object is provided to a ProxyObject 602.
The ProxyObject instance forms a representation of the message, including
both the selector and the arguments, suitable for transmission to a remote
machine. This message 603 is forwarded across the process boundary 606 to
a remote object 604. The remote object 604 receives the representation of
the message, extracts the message selector and arguments and executes the
message send as though it originated on the same machine as the remote
object. This result object 605 is transmitted across the process boundary
606 to the ProxyObject 602. The ProxyObject 602 uses the return
representation to reconstruct the result object and returns it to the
sender of the original message 601.
The McCullough system implements four possible message parameter passing
schemes, namely, pass by value, pass by reference, pass by proxy and pass
by migration. In pass by value, a representation of the object is shipped
to the remote machine, which in turn reconstructs the object. Pass by
reference cannot be used in a SmallTalk environment because the compiler
prevents assignment to formal parameter variables. In pass by proxy, a
proxy for the object and any messages which are sent to the proxy are
automatically forwarded to the remote object. In pass by migration, we
move an object from one machine to another, leaving a proxy object in its
prior home.
A centralized control scheme, referred to as PolicyMaker, is used to
deliver messages to remote objects. Individual proxies need not record the
current network location of a shared object, that is the responsibility of
the PolicyMaker. PolicyMaker responsibilities include the decision of
whether to pass objects by value, proxy or by migration, and whether to
forward a message to a remote object or whether to migrate the object to
the local machine for execution. In addition, PolicyMaker keeps track of
open connections between machines. For each connection to a remote
machine, the PolicyMaker creates an instance of class TransporterRoom. The
TransporterRoom takes care of communications protocols between machines,
as well as the linearization of messages and objects.
FIG. 7 illustrates the flow control of sending a message from a machine to
a remote object using the scheme of the McCullough system. A message 701,
destined for a remote object, is provided to a ProxyObject 702. The sender
of the message 701 believes it is sending to a local object, but in
reality it is sending to a remote object. The ProxyObject 702 sends a
message 703 to the local PolicyMaker 704. The PolicyMaker 704 determines
whether the arguments of the message should be sent by copying or by proxy
to the remote object. The PolicyMaker establishes a connection to the
remote machine via transporter room 706. The PolicyMaker 704 provides the
message 705 to the TransporterRoom 706. The TransporterRoom 706 linearizes
and transmits the message as message 707 to the remote machine across
process boundary 708.
The TransporterRoom 709 of the remote machine receives the message 707. The
TransporterRoom 709 sends the reconstructed message 710 to the remote
object 711. The remote object 711 returns a message 714 to the
TransporterRoom 709. The PolicyMaker 712 considers the resulting object
and determines whether to return it by value or by proxy and communicates
to the TransporterRoom 709 on path 713. The TransporterRoom 709 sends the
message 707 to the TransporterRoom 706 across process boundary 708. The
TransporterRoom 706 reconstructs the result object and provides it as
message 715 to proxy object 702, which can then return it to the sending
context.
The use of migration limits the performance and ease of use of these prior
art schemes. Migration of objects from their home process adds to the
complexity of the system. Another disadvantage of these prior art schemes
is that each process and thread must be forked to anticipate each expected
iteration. There is no provision for dynamic recursive communication
between processes. In addition, these prior art schemes rely on a pure,
large object oriented language/environment, such as SmallTalk. This
requires substantial run time support to implement communication between
processes. In addition, the prior art schemes do not implement suitable
object collection methods.
SUMMARY OF THE INVENTION
The present invention permits the distribution of objects and sending of
messages between objects that are located in different processes.
Initially, a "proxy" object is created in the same process as a sender
object. This proxy acts as a local receiver for all objects in the local
program. When the proxy receives a message, the message is encoded and
transmitted between programs as a stream of bytes. In the remote process,
the message is decoded and executed as if the sender was remote. The
result follows the same path, encoded, transmitted, and then decoded back
in the local process. The result is then provided to the sending object.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram illustrating the concept of inheritance in
object-oriented programming.
FIG. 2 is a block diagram illustrating delegation in object-oriented
programming.
FIGS. 3A-3C illustrate the distributed processing object oriented
programming system of the present invention.
FIG. 4 is a block diagram illustrating a general purpose computer system
for implementing the present invention.
FIG. 5 is a flow diagram of the forwarding method of the present invention.
FIG. 6 is a block diagram illustrating the prior art distributed processing
object-oriented programming system.
FIG. 7 is a block diagram illustrating another prior art distributed
processing object-oriented programming system.
FIGS. 8A and 8B illustrate non-distributed programming systems.
DETAILED DESCRIPTION OF THE INVENTION
A method and apparatus for distributed execution of methods is described.
In the following description, numerous specific details, such as
object-oriented programming language, operating system, etc., are set
forth in detail in order to provide a more thorough understanding of the
present invention. It will be apparent, however, to one skilled in the
art, that the present invention may be practiced without these specific
details. In other instances, well known features have not been described
in detail so as not to obscure the present invention.
The present invention may be implemented on any conventional or general
purpose computer system. An example of one embodiment of a computer system
for implementing this invention is illustrated in FIG. 4. A keyboard 410
and mouse 411 are coupled to a bi-directional system 419. The keyboard and
mouse are for introducing user input to the computer system and
communicating that user input to CPU 413. The computer system of FIG. 4
also includes a video memory 414, main memory 415 and mass storage 412,
all coupled to bi-directional system bus 419 along with keyboard 410,
mouse 411 and CPU 413. The mass storage 412 may include both fixed and
removable media, such as magnetic, optical or magnetic optical storage
systems or any other available mass storage technology. The mass storage
may be shared on a network, or it may be dedicated mass storage. Bus 419
may contain, for example, 32 address lines for addressing video memory 414
or main memory 415. The system bus 419 also includes, for example, a
32-bit data bus for transferring data between and among the components,
such as CPU 413, main memory 415, video memory 414 and mass storage 412.
Alternatively, multiplex data/address lines may be used instead of
separate data and address lines.
In the preferred embodiment of this invention, the CPU 413 is a 32-bit
microprocessor manufactured by Motorola, such as the 68030 or 68040.
However, any other suitable microprocessor or microcomputer may be
utilized. The Motorola microprocessor and its instruction set, bus
structure and control lines are described in MC68030 User's Manual, and
MC68040 User's Manual, published by Motorola Inc. of Phoenix, Ariz.
Main memory 415 is comprised of dynamic random access memory (DRAM) and in
the preferred embodiment of this invention, comprises 8 megabytes of
memory. More or less memory may be used without departing from the scope
of this invention. Video memory 414 is a dual-ported video random access
memory, and this invention consists, for example, of 256 kbytes of memory.
However, more or less video memory may be provided as well.
One port of the video memory 414 is coupled to video multiplexer and
shifter 416, which in turn is coupled to video amplifier 417. The video
amplifier 417 is used to drive the cathode ray tube (CRT) raster monitor
418. Video multiplexing shifter circuitry 416 and video amplifier 417 are
well known in the art and may be implemented by any suitable means. This
circuitry converts pixel data stored in video memory 414 to a raster
signal suitable for use by monitor 418. Monitor 418 is a type of monitor
suitable for displaying graphic images, and in the preferred embodiment of
this invention, has a resolution of approximately 1020.times.832. Other
resolution monitors may be utilized in this invention.
The computer system described above is for purposes of example only. The
present invention may be implemented in any type of computer system or
programming or processing environment.
The preferred embodiment of the present invention implements an
object-oriented programming system using objective C language. Objective C
is an extension to ANSI C that supports the definition of classes of
objects and provides syntactic and run-time support for sending messages
to objects. This language model is partially derived from SmallTalk and
has been described in "Object-Oriented Programming; An Evolutionary
Approach," Brad J. Cox, Addison-Wesley 1986 and in "SmallTalk-80: The
Language and its Implementation," Adele Goldberg, Dave Robson,
Addison-Wesley 1983.
One feature of objective C is "dynamic binding" of messages to the actual
methods to be invoked, depending on the class of the receiver. A
programmer writing code in objective C can create code that sends a
message "doSomething" to an object. The actual method corresponding to the
class of the target object does not need to be determined until the
message must be sent. This allows objects of any classes that implementing
the doSomething method to be substituted for the target object at run time
without having to modify the part of the program that sends the message.
Also, in objective C, programs have run time access to method
"signatures," that encode a method's argument and return types for each
class. The method signature provides a way for two programs to agree on
the format of messages. Moreover, there is a way to extract arguments from
the stack using the signature.
In its preferred embodiment, the present invention is implemented in a
computer system using an object-oriented operating system. One such
object-oriented operating system is known as the "Mach" operating system
and is implemented on computers manufactured by NeXT, Inc., the Assignee
of the present invention.
The Mach operating system is an object-oriented operating system that
supports distributed programming. It is a multi-tasking operating system
kernel, allowing multiple, independent "tasks," which provide the basic
environment of a program in the form of a demand-paged virtual "address
space" and one or more "threads" of execution. Mach supports
message-passing within and between tasks. This support is distinct from
objective C messaging described earlier.
Fundamental to Mach's ability to deliver messages between different
programs is an abstraction called a "port." A Mach port is a buffered
communication channel over which messages are sent. This channel, which is
maintained by the operating system, may be local, may span two tasks on
the same machine, or may span tasks on different machines. The physical
location of the receiving end of a port has no effect on the sender, which
always sees a local reference to the port.
The messages sent on a port are buffered, that is, a sender writes messages
to a port with a "send" primitive, and a receiver accepts messages with a
"receive" primitive. The messages themselves may be of any size, and
consist of a header followed by zero or more data objects. For efficiency,
large array arguments are passed out-of-line with copy-on-write semantics.
Of particular interest is the ability to pass Mach ports themselves as
data objects in a message. By this means, one task may pass a port to
another, with the kernel maintaining address translation along the way.
This allows tasks to learn about the existence of new external objects, or
make new "acquaintances," by receiving their ports in a message. Thus,
ports may also be viewed as a reference for an object that is independent
of any particular space, and may be freely passed between programs.
For a task to communicate with a "receiver" object in another address
space, it must first establish a connection with that program, and then
create a local "proxy" for the object. When a message is sent to this
proxy, the elements of the objective C message are encoded into a Mach
message, which is then forwarded through a Mach port to the other program.
On the receiving side, the message is received, decoded, and then
forwarded it to the target objective C object. The return value of the
objective C method is then encoded and sent back to the originator, where
it is decoded and returned as the value. Each part of this model is now
described.
In order to communicate with an object in a different program or process,
that program or process must be known. The present invention uses Mach
ports to represent "domains" of objects, and a token to identify objects
within that domain. This two-part address is easily communicated, since
the port maintains its identity as it moves between domains. In Mach,
acquiring ports is synonymous with acquiring privileges to communicate.
The present invention requires that the local domain has send rights to a
port that the remote domain has receive rights to, and also that the
remote domain has send rights to a port that the local domain has receive
rights to, before any communication can take place. Thus, mutual consent
is required to communicate.
In addition to learning of each other's ports, each domain must also
provide the other with the token corresponding to its "first proxy." A
first proxy is required to bootstrap the communication. There must be at
least one known object in a remote domain before a message can be sent to
it. Because a connection allows messages in either direction and initiated
by either party, each side of a connection must have a first proxy. This
first proxy may be | | |
