 |
Claims  |
|
|
What is claimed is:
1. In an object oriented system wherein there exists client applications,
objects, object type definitions, object implementations and servers, an
object invocation and communications system comprising:
a local node;
a first spring object located on said local node for executing a call from
an application procedure to a first object, said first object being an
object implementation of said first spring object, without said
application knowing a location of said first object or a location of said
first object's implementation and without said application knowing details
of how arguments must be marshaled for calling said first object, and said
first object comprising a data structure;
a stub located on said local node which assists in executing calls on said
first object by marshalling arguments for said first object into a
communications buffer;
a plurality of client-side subcontract mechanisms said subcontract
mechanisms being distinct from object managers, which can perform remote
invocation of operation calls in different ways, wherein different spring
objects within a single application can be associated with a different one
of said plurality of client-side subcontract mechanisms; and wherein a
client-side portion of one of said plurality of client-side subcontract
mechanisms is coupled to a.sub.-- spring object, said client-side portion
of a subcontract mechanism not being required to have knowledge of types
of said arguments being sent to said first object and said client-side
portion of a subcontract mechanism configured to receive from said stub a
method identifier and a pointer to a communications buffer which contains
arguments to be sent in a call to said first object, wherein said
client-side portion of a subcontract mechanism has an option to add
additional data to said communications buffer to provide additional
information to said first object, and can transmit selectively one of a
parameter representing a pointer to said communications buffer and said
communications buffer's contents to said first object and wherein the
client-side portion of said one of said plurality of subcontract
mechanisms can execute operation calls to generate a new object which is
related to an existing object;
a server node; and
a plurality of server-side subcontract mechanisms each of which is
associated with a corresponding one of said plurality of client-side
subcontract mechanisms, wherein a server-side portion of said.sub.--
plurality of server-side subcontract mechanisms located on said server
node and associated with said client-side portion of said subcontract
mechanism for exchanging messages with and for processing operation calls
initiated by, said client-side portion of said subcontract mechanism, said
server-side portion of said subcontract mechanism configured to unmarshal
said arguments in said communications buffer, deliver said arguments to a
called object, receive results from said called object, marshall said
results into a results buffer, and communicate selectively one of a
parameter representing a pointer to said results buffer and said results
buffer's contents to said client-side portion of said subcontract.
2. The object invocation and communications system of claim 1 wherein the
client-side portion of said one of said plurality of subcontract
mechanisms can marshal information about its associated object into said
communications buffer.
3. The object invocation and communications system of claim 1 wherein
selectively communicating one of said parameter representing a pointer to
said communications buffer and said communications buffer's contents by
said client-side portion of said one of said plurality of subcontract
mechanisms allows said client-side portion of said subcontract mechanism
to:
transmit a copy of an object from one location to another; and
transmit an object from one location to another.
4. The object invocation and communications system of claim 1 wherein the
server-side portion of said one of said plurality of subcontract
mechanisms can execute operation calls to create an object, and to revoke
an object.
5. In an object oriented system wherein there exists client applications,
objects, stubs, object implementations and servers, a computer implemented
method for communicating messages between a client application and a
server, wherein the messages include arguments, at least one element of
which includes an object, said method comprising the following steps:
under computer control generating an operation invocation on a local object
by a client application, said object comprising a data structure;
receiving said operation invocation by a client-side stub of said object;
marshaling arguments associated with said operation invocation into a
communications buffer, said marshalling operation comprising the steps of:
determining whether any of the arguments to be marshaled is an object;
for each object which is an argument to be marshaled, identifying one of a
plurality of subcontracts which is associated with said object to be
marshaled;
using said identified subcontract which is associated with said object to
be marshaled, marshal said object which is being used as an argument to be
marshaled into a communications buffer; and
returning a completion signal to said client-side stub;
transforming said operation invocation into an operation call on a
client-side subcontract by said client-side stub, said client-side
subcontract being one of a plurality of subcontracts;
using said client-side subcontract to transmit said operation invocation
and associated communications buffer from said client application to said
object's implementation;
using said client-side subcontract to receive a reply from said object's
implementation, and to deliver a return communications buffer to said
client-side stub;
unmarshalling said results and returned communications buffer by said
client-side stub; and
making said results available to said client application.
6. The system of claim 5 wherein said client applications and object
implementations may reside on different computers in said distributed
computer system.
7. In an object oriented distributed system comprising a variety of
different kinds of objects, and a set of subcontract identifiers, where
each subcontract mechanism is identified by a subcontract identifier, a
computer implemented method for unmarshalling an object from a
communications buffer comprising the steps of:
under computer control unmarshalling a subcontract identifier from said
communications buffer by a first subcontract mechanism, said first
subcontract mechanism being one of a number of different subcontract
mechanisms for communicating with remote objects, where each different
subcontract mechanism comprises a set of procedures for performing at
least object marshaling, object unmarshalling and object invocation;
using a subcontract registry to locate a set of procedures that implements
a second subcontract mechanism which is identified by said subcontract
identifier by performing the additional steps of:
checking said registry to determine if a subcontract mechanism associated
with said subcontract identifier is contained in said registry;
constructing a shared library filename based upon said subcontract
identifier; and
calling a dynamic linker program mechanism to link a program code mechanism
to said registry, said program code mechanism being identified by said
shared library filename based upon said subcontract identifier, said
program code mechanism identified by said shared library filename based
upon said subcontract identifier being said subcontract mechanism
associated with said subcontract identifier;
selecting an unmarshal procedure from said set of procedures that
implements said second subcontract mechanism;
performing a local procedure call to said unmarshal procedure to perform
unmarshalling of said object; and
unmarshalling said object by unmarshalling data and communications
information that is appropriate to said second subcontract mechanism.
8. In an object oriented system wherein there exists client applications,
objects, object type definitions, object implementations and servers, an
object invocation and communications system comprising:
a local node;
a first spring object located on said local node for executing a call from
an application procedure to a first object, said first object being an
object implementation of said first spring object, without said
application knowing a location of said first object or a location of said
first object's implementation and without said application knowing details
of how arguments must be marshaled for calling said first object, and said
first object comprising a data structure;
a stub located on said local node which assists in executing calls on said
first object by marshalling arguments for said first object into a
communications buffer;
a plurality of client-side subcontract mechanisms said subcontract
mechanisms being distinct from object managers, which can perform remote
invocation of operation calls in different ways, wherein different spring
objects within a single application can be associated with a different one
of said plurality of client-side subcontract mechanisms; and wherein a
client-side portion of one of said plurality of client-side subcontract
mechanisms is coupled to a.sub.-- spring object, said client-side portion
of a subcontract mechanism not being required to have knowledge of types
of said arguments being sent to said first object and said client-side
portion of a subcontract mechanism configured to receive from said stub a
method identifier and a pointer to a communications buffer which contains
arguments to be sent in a call to said first object, wherein said
client-side portion of a subcontract mechanism has an option to add
additional data to said communications buffer to provide additional
information to said first object, and can transmit selectively one of a
parameter representing a pointer to said communications buffer and said
communications buffer's contents to said first object, and wherein the
client-side portion of said one of said plurality of subcontract
mechanisms can marshall and unmarshal an argument to a call wherein said
argument is itself an object;
a server node; and
a plurality of server-side subcontract mechanisms each of which is
associated with a corresponding one of said plurality of client-side
subcontract mechanisms, wherein a server-side portion of said.sub.--
plurality of server-side subcontract mechanisms located on said server
node and associated with said client-side portion of said subcontract
mechanism for exchanging messages with and for processing operation calls
initiated by, said client-side portion of said subcontract mechanism, said
server-side portion of said subcontract mechanism configured to unmarshal
said arguments in said communications buffer, deliver said arguments to a
called object, receive results from said called object, marshall said
results into a results buffer, and communicate selectively one of a
parameter representing a pointer to said results buffer and said results
buffer's contents to said client-side portion of said subcontract.
9. In an object oriented system wherein there exists client applications,
objects, object type definitions, object implementations and servers, an
object invocation and communications system comprising:
a local node;
a first spring object located on said local node for executing a call from
an application procedure to a first object, said first object being an
object implementation of said first spring object, without said
application knowing a location of said first object or a location of said
first object's implementation and without said application knowing details
of how arguments must be marshaled for calling said first object, and said
first object comprising a data structure;
a stub located on said local node which assists in executing calls on said
first object by marshalling arguments for said first object into a
communications buffer;
a plurality of client-side subcontract mechanisms said subcontract
mechanisms being distinct from object managers, which can perform remote
invocation of operation calls in different ways, wherein different spring
objects within a single application can be associated with a different one
of said plurality of client-side subcontract mechanisms; and wherein a
client-side portion of one of said plurality of client-side subcontract
mechanisms is coupled to a.sub.-- spring object, said client-side portion
of a subcontract mechanism not being required to have knowledge of types
of said arguments being sent to said first object and said client-side
portion of a subcontract mechanism configured to receive from said stub a
method identifier and a pointer to a communications buffer which contains
arguments to be sent in a call to said first object, wherein said
client-side portion of a subcontract mechanism has an option to add
additional data to said communications buffer to provide additional
information to said first object, and can transmit selectively one of a
parameter representing a pointer to said communications buffer and said
communications buffer's contents to said first object, and wherein the
client-side portion of said one of said plurality of subcontract
mechanisms can marshal a copy of its associated object into said
communications buffer;
a server node; and
a plurality of server-side subcontract mechanisms each of which is
associated with a corresponding one of said plurality of client-side
subcontract mechanisms, wherein a server-side portion of said.sub.--
plurality of server-side subcontract mechanisms located on said server
node and associated with said client-side portion of said subcontract
mechanism for exchanging messages with and for processing operation calls
initiated by, said client-side portion of said subcontract mechanism, said
server-side portion of said subcontract mechanism configured to unmarshal
said arguments in said communications buffer, deliver said arguments to a
called object, receive results from said called object, marshall said
results into a results buffer, and communicate selectively one of a
parameter representing a pointer to said results buffer and said results
buffer's contents to said client-side portion of said subcontract. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the fields of distributed computing
systems, client-server computing and object oriented programming.
Specifically, the present invention is a method and apparatus for
providing program mechanisms which are independent of the operating system
kernel, to handle inter-client communications involving objects.
2. Background
A key problem in Operating Systems development and maintenance is
permitting the introduction of new interfaces and implementation
techniques in a way which allows clients and programmers maximum
flexibility without loading the operating system down with implementation
details. Moreover, this problem becomes more intense when developing
object oriented operating systems which have micro-kernel architectures.
Micro-kernels typically permit clients to implement complex sub-systems at
the client level, such as file systems, for example. Nevertheless, basic
system processes such as interclient or intercomputer communications are
so complex that clients and object implementors should not be concerned
with these processes. That is, these inherently "system" type processes
are more efficiently done by standard modules, but should be handled in a
way which does not require that the base operating system is constrained
by these processes.
This disclosure describes a solution to this basic problem for systems
which use the object metaphor to define the interfaces between different
components of a system. An elegant solution is described which allows
standard modules to handle communications of object calls between remote
computers which may be sending other objects as parameters of the calls.
In an object oriented system, an object is a component comprising data and
operations which can be invoked to manipulate the data. The operations are
invoked on the object by sending calls to the object. Each object has an
object type. The object type defines the operations that can be performed
on objects of that type. The object operations are implemented independent
of the objects themselves. Additionally, one object type may inherit the
object operations defined and implemented for other object types. For
further description of object oriented design and programming techniques
see "Object-oriented Software Construction" by Bertrand Meyer,
Prentice-Hall 1988.
In client-server computing, typically there is a set of computers that can
communicate with one another through a network connecting the computers.
Some of these computers act as providers of services or functionality to
other computers. The providers of such service or functionality are known
as "servers", and the consumers of such service or functionality are
called "clients". The client-server model also generalizes to the case
where distinct programs running on the same computer are communicating
with one another through some protected mechanism and are acting as
providers and consumers of functionality.
In object oriented distributed systems based upon the client-server model,
there exist servers that provide object oriented interfaces to their
clients. These servers support objects consisting of data and the
associated software. Clients may obtain access to these objects and may
execute calls on them. These calls are transmitted to the server from the
client. At the server these calls are executed via the software associated
with the object. The results of these calls are then transmitted back to
the client.
The object metaphor is a useful technique because it provides a separation
between an object's interface and its implementation and because it
permits multiple implementations of a single interface, which in a
distributed system may reside on different machines. However, in existing
object oriented systems the base system defines fundamental object
properties such as what object "invocation" means, what it means to "pass
an object as an argument", etc.
Unfortunately, by letting the base system define what the fundamental
properties are, the base system is required to support all those
fundamental properties that we wish objects to have. For example, assume
that we wish to support object replication so as to increase reliability.
It is not desirable for client application code to do extra work in order
to talk to replicated objects. Therefore it would be preferable to support
replication by the system. But there are lots of ways of implementing
replication. The question is does one build some of these ways into the
base system and reject the others? If an application developer discovers a
more efficient way of managing replicated objects within his application
then it would be desirable for him to be able to use his new mechanism
without having to change the base mechanism. Moreover, while the base
system could be used to support some standard base mechanisms for
particular properties such as replication, persistence, crash recovery,
and caching, this seems to pose two dangers. First, it may make simple
object invocation expensive, even for those objects that do not desire the
expensive properties. Secondly, it makes it difficult for third parties to
add new properties that are peculiar to their particular needs.
Accordingly, what is needed is a method to provide control of the basic
mechanisms of object invocation and argument passing that are most
important in distributed systems, wherein the method is implemented by
some scheme which is separated from object interfaces and object
implementations.
Techniques for providing a language-level veneer for remote operations (for
example, "Remote Procedure Calls") have been in use for many years.
Typically these take the form that a remote interface is defined in some
language. Then a pair of stubs are generated from this interface. The
client stub runs in one machine and presents a language level interface
that is derived from the remote interface. The server stub runs in some
other machine and invokes a language-level interface that is derived from
the remote interface. Referring now to FIG. 1, to perform a remote
operation, a client application 12 on one machine 10, invokes the client
stub 14, which marshals the arguments associated with the invocation into
network buffer(s) and transmits them to the server stub 22 on the remote
machine 18, which unmarshals the arguments from the network buffer(s)and
calls the server application 24. Similarly, when the server application 24
returns a response, the results are marshaled up by the server stub 22 and
returned to the client stub 14, which unmarshals the results and returns
them to the client application 12. The entire mechanics of argument and
result transmission, and of remote object invocation, are performed in the
stubs. Both the client application and the server application merely deal
in terms of conventional language-level interfaces.
When the arguments or results are simple values such as integers or
strings, the business of marshaling and unmarshaling is reasonably
straightforward. The stubs will normally simply put the literal value of
the argument into the network buffer. However, in languages that support
either abstract data types or objects, marshalling becomes significantly
more complex. One solution is for stubs to marshall the internal data
structures of the object and then to unmarshal this data back into a new
object. This has several serious deficiencies. First, it is a violation of
the "abstraction" principle of object-oriented programming, since stubs
have no business knowing about the internals of objects. Second, it
requires that the server and the client implementations of the object use
the same internal layout for their data structures. Third, it may involve
marshalling large amounts of unnecessary data since not all of the
internal state of the object may really need to be transmitted to the
other machine. An alternative solution is that when an object is
marshalled, none of its internal state is transmitted. Instead an
identifying token is generated for the object and this token is
transmitted. For example in the Eden system, objects are assigned names
and when an object is marshalled then its name rather than its actual
representation is marshalled. Subsequently when remote machines wish to
operate on this object, they must use the name to locate the original site
of the object and transmit their invocations to that site. This mechanism
is appropriate for heavyweight objects, such as files or databases, but it
is often inappropriate for lightweight abstractions, such as an object
representing a cartesian coordinate pair, where it would have been better
to marshal the real state of the object. Finally, some object-oriented
programming systems provide the means for an object implementation to
control how its arguments are marshalled and unmarshalled. For example, in
the Argus system object implementors can provide functions to map between
their internal representation and a specific, concrete, external
representation. The Argus stubs will invoke the appropriate mapping
functions when marshalling and unmarshaling objects so that it is the
external representation rather than any particular internal representation
that is transmitted. These different solutions all either impose a single
standard marshalling policy for all objects, or require that individual
object implementors take responsibility for the details of marshalling.
Within object-oriented languages, the technique of reflection permits
object implementors to gain control of some of the fundamental object
mechanisms. [See "Reflective Facilities in Smalltalk-80," by Brian Foote &
Ralph E. Johnson 1989, OOPSLA '89 Proceedings, pages 327-335]. Very
simply, a reflective system is one which incorporates structures
representing aspects of itself, and reflective computation is a system's
computations about itself.
For example in the 3-KRS language, objects can have meta-objects associated
with them. A meta-object provides methods specifying how an object
inherits information, how an object is printed, how objects are created,
how message passing (that is, object invocation) is implemented, etc.
3-KRS does not however provide any control over argument passing.
By providing reflective object invocation in Smalltalk-80 it was possible
to implement objects which are automatically locked during invocation and
objects which only compute a value when they are first read.
However while reflection has been used within a single address space, there
has been no attempt to apply it specifically to the problems of
distributed computing.
Accordingly, the present invention provides an apparatus and a method
comprising a logic module, called a sub-contract, that has been designed
to provide control of the basic mechanisms of object invocation and
argument passing that are most important in distributed systems, in a way
which makes it easy for object implementors to select and use an existing
sub-contract, and which permits the application programmers to be unaware
of the specific sub-contracts that are being used for particular objects.
SUMMARY OF THE INVENTION
The present invention provides an elegant and simple way to provide
mechanisms for invocation of objects by client applications and for
argument passing between client applications and object implementations,
without the client application or the operating system knowing the details
of how these mechanisms work. Moreover, these mechanisms functions in a
distributed computer environment with similar ease and efficiency, where
client applications may be on one computer node and object implementations
on another.
The invention includes a new type of object, termed a "spring object,"
which includes a method table, a subcontract mechanism and a data
structure which represents the subcontract's local private state.
The subcontract mechanism is the heart of the present invention, and each
subcontract contains a client-side portion and a related server-side
portion. Each object type has an associated subcontract. The client-side
portion of a subcontract has the ability to generate a new spring object,
to delete a spring object, to marshal information about its associated
object into a communications buffer, to unmarshal data in a communications
buffer which represents its associated object, to transmit a
communications buffer to its associated server-side subcontract, which
includes either transmitting an object from one location to another or
transmitting a copy of an object from one location to another. The
server-side portion of the subcontract mechanism includes the ability to
create a spring object, to provide support for processing incoming calls
and related communications buffers and to provide support for revoking an
object.
The invention includes methods for using subcontracts to process object
invocations, including the passing of arguments, which arguments may
themselves be objects, in a distributed computing system, wherein the
client applications may be on different computers from the object
implementations.
DESCRIPTION OF THE DRAWINGS
The objects, features and advantages of the system of the present invention
will be apparent from the following description in which:
FIG. 1 illustrates the prior art relationship of client and server
applications to stubs and network software.
FIG. 2 illustrates the major system components of the SPRING operating
system.
FIG. 3 illustrates the relationship between stub objects, subcontract
objects and server application objects.
FIG. 4 illustrates remote object invocation using subcontract.
FIG. 5 illustrates object invocation on a single machine using subcontract.
FIGS. 6-9 illustrate a flow chart of an exemplary use of the inventive
method of subcontract.
FIGS. 10a & 10b illustrate the SPRING view of objects versus the prior art
view of objects.
NOTATIONS AND NOMENCLATURE
The detailed descriptions which follow may be presented in terms of program
procedures executed on a computer or network of computers. These
procedural descriptions and representations are the means used by those
skilled in the art to most effectively convey the substance of their work
to others skilled in the art.
A procedure is here, and generally, conceived to be a self-consistent
sequence of steps leading to a desired result. These steps are those
requiring physical manipulations of physical quantities. Usually, though
not necessarily, these quantities take the form of electrical or magnetic
signals capable of being stored, transferred, combined, compared, and
otherwise manipulated. It proves convenient at times, principally for
reasons of common usage, to refer to these signals as bits, values,
elements, symbols, characters, terms, numbers, or the like. It should be
noted, however, that all of these and similar terms are to be associated
with the appropriate physical quantities and are merely convenient labels
applied to these quantities.
Further, the manipulations performed are often referred to in terms, such
as adding or comparing, which are commonly associated with mental
operations performed by a human operator. No such capability of a human
operator is necessary, or desirable in most cases, in any of the
operations described herein which form part of the present invention; the
operations are machine operations. Useful machines for performing the
operations of the present invention include general purpose digital
computers or similar devices.
The present invention also relates to apparatus for performing these
operations. This apparatus may be specially constructed for the required
purposes or it may comprise a general purpose computer as selectively
activated or reconfigured by a computer program stored in the computer.
The procedures presented herein are not inherently related to a particular
computer or other apparatus. Various general purpose machines may be used
with programs written in accordance with the teachings herein, or it may
prove more convenient to construct more specialized apparatus to perform
the required method steps. The required structure for a variety of these
machines will appear from the description given.
DESCRIPTION OF THE PREFERRED EMBODIMENT
The following disclosure describes solutions to the problems which are
encountered by object oriented systems designers when attempting to
implement schemes for object invocation and for argument passing in
distributed systems wherein the arguments may be objects, in ways which do
not lock the object oriented base system into methods which may be
difficult to change at a later time. The invention includes a new type of
object, termed a "spring object," which includes a method table, a
subcontract mechanism and a data structure which represents the
subcontract's local private state. A method and an apparatus are disclosed
for a subcontract mechanism which is associated with each object. Each
subcontract contains a client-side portion and a related server-side
portion. Each object type has an associated subcontract. The client-side
portion of a subcontract has the ability to generate a new spring object,
to delete a spring object, to marshal information about its associated
object into a communications buffer, to unmarshal data in a communications
buffer which represents its associated object, to transmit a
communications buffer to its associated server-side subcontract, which
includes either transmitting an object from one location to another or
transmitting a copy of an object from one location to another. The
server-side portion of the subcontract mechanism includes the ability to
create a spring object, to provide support for processing incoming calls
and related communications buffers and to provide support for revoking an
object.
In the following description, for purposes of explanation, specific data
and configurations are set forth in order to provide a thorough
understanding of the present invention. The preferred embodiment described
herein is implemented as a portion of the SPRING Object-Oriented Operating
System created by Sun Microsystems.RTM., Inc. (Sun Microsystems is a
registered trademark of Sun Microsystems, Inc.) However, it will be
apparent to one skilled in the art that the present invention may be
practiced without the specific details and may be implemented in various
computer systems and in various configurations, or makes or models of
tightly-coupled processors or in various configurations of loosely-coupled
multiprocessor systems.
A SPRING object is an abstraction that contains state and provides a set of
methods to manipulate that state. The description of the object and its
methods is an interface that is specified in the interface definition
language. The interface is a strongly-typed contract between the
implementor (server) and the client of the object.
A SPRING domain is an address space with a collection of threads. A given
domain may act as the server of some objects and the clients of other
objects. The implementor and the client can be in the same domain or in a
different domain.
Since SPRING is object-oriented it supports the notion of interface
inheritance. Spring supports both notions of single and multiple interface
inheritance. An interface that accepts an object of type "foo" will also
accept an instance of a subclass of "foo". For example, the address.sub.--
space object has a method that takes a memory.sub.-- object and maps it in
the address space. The same method will also accept file and frame.sub.--
buffer objects as long as they inherit from the memory.sub.-- objec | | |
